前言：「所以到底 Code Review 該由誰做？」

這是第三部的最後一篇，也是這系列問到現在最直接的一個問題：如果程式碼是 AI 產生的、規則是架構測試在驗證的、複雜度預算是 CI 在檢查的，那人在這整個流程裡還剩下什麼工作？是不是人已經被排除在 Review 這件事之外了？

答案是否定的，但角色確實變了。今天要把第三部這幾天講過的東西——Outside-In TDD、GOOS 的核心洞察、架構測試、複雜度預算、CLAUDE.md／Skill——收斂成一個具體的分工框架：人定規則，工具驗證，AI 產生。

今日目標

• 理解這三個角色（人、工具、AI）各自該負責什麼，不該負責什麼
• 看懂這個分工模型跟第一部講過的「Review 舊模型追不上」之間的因果關係
• 把第三部前六天的內容,對應進這個框架裡的具體位置
• 認識這個框架裡最容易被誤解、誤用的地方
• 建立一個可以立刻檢視自己團隊現狀的自我評估角度

三個角色，三種不同的工作

人定規則：人的判斷力最稀缺、也最不該浪費在逐行讀程式碼上，該花在決定「什麼樣的規則,能反映這個系統真正在乎的品質」——例如「新增欄位的合理改動範圍是 3-5 個檔案」這種數字該怎麼訂、「哪些 pattern 是我們團隊判定為過度設計高風險、要明確禁止」，這些判斷需要對系統的業務脈絡、團隊能力、維護成本有整體理解，AI 跟工具都做不到。

工具驗證：架構測試、複雜度預算檢查、CI pipeline，負責把人定出來的規則,轉譯成每一次產出都會被自動檢查的動作。它們的價值在於「不會累、不會漏、不會因為趕時間就睜一隻眼閉一隻眼」——這正是 Day 19 講過的，把「感覺有點多層」這種模糊印象，變成一條會自動擋下的具體檢查。

AI 產生：AI 負責的是「在人定的規則跟工具驗證的邊界內」把程式碼寫出來——如果邊界劃得清楚（Day 21 講過的先跑 Outside-In 流程），AI 在這個角色裡其實可以做得很好，因為它被限定在「回應具體的驗收測試」這件事上,而不是漫無邊際地自由發揮。

為什麼這個分工能解決第一部提出的問題

第一部反覆講的問題是：人的閱讀速度固定，AI 的產出速度指數成長，靠「人眼逐行審查程式碼」這個舊模型,結構性地追不上。這個新分工模型解決問題的方式,不是讓人讀得更快，而是把人的工作,從「跟上 AI 的產出速度」換成「跟上規則的變化速度」——規則的變化速度遠遠慢於程式碼的產出速度，一條複雜度預算、一條架構測試規則,定好之後可能幾個月都不需要調整，但 AI 每一次對話都可能產出幾百行新程式碼。人不需要再跟時間賽跑,去讀完每一行 AI 寫出來的東西，只需要在規則的層次上保持判斷力。

這正是這個系列從 Day 1 就要走到的結論：AI 沒有發明過度設計，它只是讓過度設計的速度追上了你按下 Enter 的速度；Review 要跟得上，審的就不能再是程式碼本身，而是產生程式碼的規則。 人定規則、工具驗證、AI 產生，就是把這句話拆成三個角色各自的具體職責。

常見誤區：把這個分工誤解成「人不用看程式碼了」

這個框架最容易被誤解的地方,是有人會覺得「既然有工具驗證、AI 產生，那人就完全不用看程式碼了」。這是錯的。人仍然需要偶爾深入讀程式碼——尤其是像 Day 15、16 講過的「架構測試抓不到、需要語意判斷」的問題（例如一個 SqliteUnitOfWork 名字承諾了交易保護,實際上是 no-op），這類問題仍然只有人讀懂實作內容才抓得出來。分工模型改變的是人該花多少比例的時間,在「逐行審查每一份 AI 產出」跟「訂規則、抽查關鍵風險點」之間，不是完全取消其中一種工作。

❌ 誤解：分工模型 = 人完全退出 code review

「反正架構測試會擋、複雜度預算會抓，
  PR 我看過測試有過就直接合併了」

✅ 正確理解：人把有限的審查時間,集中在工具驗證不到的語意風險上

架構測試/複雜度預算先做第一輪過濾，
人專注抽查：
- 名字承諾的行為，實作有沒有真的做到（交易保護、重試邏輯）
- 同一條業務規則有沒有在多處重複、未來會不會改一漏二
- 這個規則本身（複雜度預算的數字、架構測試的邊界）是否還合理

把第三部收在一起看

第三部這幾天的內容,其實就是在填滿這個框架的三個角落：Outside-In TDD／ATDD（Day 17）跟 GOOS 的核心洞察（Day 18）,講的是「AI 產生」這一格該怎麼被限制在正確的因果順序裡；架構測試（Day 19）跟複雜度預算（Day 20），是「工具驗證」這一格具體長什麼樣；讓 AI 自己先跑 Outside-In 流程（Day 21）跟寫進 CLAUDE.md／Skill（Day 22），是把前面幾格串起來,變成一套會被持續執行、不用每次重講的整體流程。人定規則,是這整套流程裡唯一沒辦法被自動化取代的部分，也是這系列接下來要繼續往下探討的——這套方法論的邊界在哪裡、什麼時候人的判斷力仍然不可或缺，會是第四部的主題。

今日思考題

把你自己團隊現在的 Review 流程,套進「人定規則、工具驗證、AI 產生」這三格裡，哪一格目前是空的？如果只能先補一格，你會先補哪一個？

今日重點回顧

• 人定規則：決定什麼樣的規則能反映系統真正在乎的品質,這件事沒辦法被工具或 AI 取代
• 工具驗證：把人定的規則轉譯成每次產出都會自動檢查的動作，不會累、不會漏
• AI 產生：在人定規則跟工具驗證劃出的邊界內把程式碼寫出來，邊界清楚時可以做得很好
• 這個分工把人的工作從「跟上 AI 產出速度」換成「跟上規則變化速度」，才是真正解決第一部提出的落差問題
• 分工模型不等於人完全不用看程式碼，語意層次的風險（名不符實的實作）仍然需要人親自判斷

明日預告

第四部要把這套框架拿去更複雜的場景測試——Day 24 會用推演的方式，在兩個版本上各自疊加一個新需求，看這套規則在更複雜的情境下是否還站得住腳。

老派工程師的心得

寫到這裡，回頭看第三部這七天,我發現自己其實是在重新回答一個十幾年前就該想清楚的問題：Code Review 的本質從來不是「有沒有人看過這段程式碼」，而是「這段程式碼有沒有被某種可靠的機制檢驗過」。以前那個機制主要靠人眼、靠經驗、靠資深工程師的直覺，這件事在程式碼產出速度可控的年代還撐得住。現在 AI 把產出速度拉到人類閱讀能力遠遠追不上的程度，這個機制本身不換掉不行——但換掉的不是「Review 該不該做」，而是「Review 該由誰、在哪個層次上做」。這大概是我這幾天寫下來,對自己最誠實的一個結論。