前言：「多找幾個人 review 不就好了？」

這是很多團隊面對「AI 產出太快、review 跟不上」這個問題時的第一個直覺解法：加派人手、要求更仔細的 review、拉長 review 的時間。這個解法背後有一個沒有明講的假設——只要人夠認真、時間夠多，人眼逐行看程式碼這件事本身沒有問題,問題只是資源不夠。

今天要把第一部（Day 1-7）收尾，講清楚為什麼這個假設本身就站不住腳：這不是資源問題，是舊模型的結構性問題。

今日目標

• 總結前六天累積的觀察，理解「人眼逐行看程式碼」這個 review 模型的結構性限制
• 分清楚「review 不夠仔細」跟「review 模型本身追不上速度落差」是兩個不同層次的問題
• 理解為什麼「加派人手」只能緩解、不能解決這個落差
• 用本系列前六天的具體數字，把「追不上」這件事講成可以量化的落差,而不是模糊的抱怨
• 為系列第二部（案例本體）跟第三部（解法）鋪路,說明接下來要往哪個方向走

舊模型的假設：人眼審查速度跟得上程式碼產出速度

傳統 code review 的模型，建立在一個過去大致成立的假設上：一個工程師寫程式碼的速度,跟另一個工程師讀程式碼、理解程式碼、判斷程式碼好壞的速度,量級是相近的。這個假設成立的時候，「多花點時間仔細看」是一個合理的解法——反正寫的人跟看的人速度差不多,看的人只要願意花時間,終究追得上。

AI coding agent 打破的正是這個假設的前提。寫的人的速度,不再受限於打字速度、思考速度，變成受限於算力；看的人的速度，還是原本那個人類閱讀理解的速度，完全沒有變。 Day 1 就講過這個結構性落差，這裡再用本系列累積的具體數字重新確認一次。

用前六天的數字，把「追不上」講成可以量化的落差

• Day 2：同一句模糊需求，AI 自由發揮出的過度設計版本，檔案數是遵循 TDD 紀律版本的 248 倍，行數是 87 倍——這個量級的產出，不是靠「多花點時間看」就能追上的。
• Day 3：兩個版本都通過同一組驗收測試，光看 CI 綠燈完全看不出差異——這代表傳統「測試過了就可以合併」的把關方式，在這個落差面前直接失效。
• Day 5：92% 的程式碼是從未被任何測試呼叫過的死碼，這種規模的「假設性功能」要靠人眼逐一確認「這段東西到底有沒有被用到」，本身就是一件耗時的工作,而且耗時程度會隨著程式碼量線性（甚至更快）增加。
• Day 6：改一個欄位，過度設計版本要動 10-11 個檔案，是乾淨版本的 3-4 倍——這代表就算通過了第一次 review，往後每一次維護的 review 成本,也會持續被這個放大過的改動範圍拖累。

把這幾個數字放在一起看，結論很清楚：「人眼逐行看」這件事的處理速度是線性的、有上限的；AI 的產出速度是指數放大的。用一個有上限的東西去追一個指數放大的東西，差距只會越拉越大，不會因為更認真而縮小。

常見誤區：以為問題出在「人不夠認真」

❌ 把落差歸因於執行力問題：

「上次那個過度設計的 PR 會合併進去，
是因為 reviewer 太累了沒仔細看。」

這句話聽起来合理，但它暗示了「只要 reviewer 更認真，這種事就不會發生」——這個推論在小規模的落差下也許成立，但面對 87 倍、248 倍這種量級的落差，就算 reviewer 用兩倍的時間仔細看，也追不上 AI 用十分之一時間生出十倍程式碼的速度。問題不是認真程度，是這個賽局的規則本身不對稱。

✅ 把問題定位在模型本身：

「這種規模的產出，靠人眼逐行看本來就追不上，
我們需要的不是更認真的 reviewer,
是能自動驗證『改動範圍有沒有超出需求範圍』
這類規則的機制。」

為什麼這件事重要：這決定了解法要往哪裡找

如果把問題定位成「人不夠認真」，解法會停留在「多找人、拉長時間、寫更詳細的 checklist 要求人手動檢查」——這些解法本質上都還是在跟一個指數成長的東西比賽線性速度，注定越來越吃力。

如果把問題定位成「舊模型結構性追不上」，解法方向就會完全不同：與其讓人眼去追蹤程式碼本身的每一個細節，不如把「什麼樣的程式碼算合格」這件事,寫成可以被工具或流程自動驗證的規則——例如 Day 6 講的改動範圍指標、Day 5 講的複雜度跟業務規則的比例、以及本系列第三部要展開的「複雜度預算」「架構測試」這些做法。這正是本系列的主題句：AI 沒有發明過度設計，它只是讓過度設計的速度追上了你按下 Enter 的速度；Review 要跟得上，審的就不能再是程式碼本身，而是產生程式碼的規則。

第一部小結，銜接第二部

前七天講的都還是「問題陳述」的層次——用 ai-news-test 這個示範案例的具體數字,說明測試通過不等於設計沒問題、過度設計不是新病、複雜度該怎麼分辨、改動範圍可以怎麼量化、以及舊的 review 模型為什麼結構性追不上。從明天開始（第二部，Day 8-16），要正式進入案例本體,具體拆解這個新聞發佈系統的兩個版本是怎麼從同一組驗收測試,長成天差地遠的兩種樣子。

今日思考題

如果你的團隊現在遇到「AI 產出的 PR 太多、review 來不及」的狀況,目前的解法是「加派人手／拉長時間」，還是「調整 review 要驗證的東西」？如果是前者，這個解法能撐多久？

今日重點回顧

• 傳統 code review 模型假設「寫的速度」跟「看的速度」量級相近，這個假設被 AI 打破了
• 本系列前六天的具體數字（248 倍檔案數、87 倍行數、92% 死碼、3-4 倍改動範圍）疊加起來，證明這不是「不夠認真」能解決的落差
• 把問題歸因於「人不夠認真」，只會導向治標不治本的解法（加派人手）
• 正確的方向是把「什麼樣的程式碼算合格」寫成可以自動驗證的規則，而不是繼續依賴人眼逐行判斷
• 第一部到此收尾，第二部開始要具體拆解案例本體

明日預告

Day 8 正式進入第二部：具體介紹 ai-news-test 這個示範專案的設計方式——同一組驗收測試，怎麼分別長成一個乾淨版本跟一個過度設計版本，為接下來幾天逐一拆解兩個版本鋪路。

老派工程師的心得

寫到這裡，我自己重新確認了一件事：這些年我對「review 沒做好」這件事的自責，很多時候方向是錯的。以前覺得是自己不夠仔細、經驗不夠老到，才會漏看一些設計上的問題；現在回頭看，很多時候不是我不夠仔細，是這個賽局從一開始規則就不對稱——一個人要用固定的閱讀速度,去追一個指數成長的產出速度，追不上不代表能力不夠，是規則本身該換了。這個體會，某種程度上也是我開始認真整理這個系列的原因。