轉念學 – 敏捷三叔公的學習之旅

Claude Code 團隊怎麼審查 AI 寫的程式碼

敏捷三叔公

九成的 code 是 AI 寫的，審查怎麼跟得上？

Anthropic 說，Claude Code 這個產品自己的程式碼，約 90% 是 Claude 寫的。2026 年 10 月，Claude Code 團隊的 Addy Osmani、Morgan Westlee Lunt 和 Qing Wang 發表了一篇文章，說明他們怎麼在這種產量下做 code review。

先講結果：6 月到 9 月之間，合併進 Claude Code 的 PR 數量翻了一倍以上，需要 revert（撤回）的 PR 比例卻下降超過 40%。

一句話結論：他們沒有取消 code review，而是把「讀程式碼」這件事大部分交給機器，把人的時間留給機器做不來的判斷，並且花很大力氣讓「出錯後快速撤回」變得又快又容易。

這篇文章把原文整理成中文，盡量用白話說明。

第一步：換一個問題問

壓力有多大？Anthropic 整個 monorepo 每天落地的變更，從 5 月的約 2,500 個，暴增到 9 月的超過 30,000 個。在這種速度下，逐行人工審查已經不可能。

團隊認為 code review 其實在做兩件事：

  1. 在上線前找到並修掉問題
  2. 讓團隊成員共同理解這份程式碼

關鍵的轉念是：「有沒有人讀過這段 code？」是個不準確的指標。真正該問的是：「這個變更可能出什麼錯？哪一種檢查（自動的或人工的）最適合抓到它？」

這也改變了 review 發生的時間點。以前 review 是終點的閘門：寫完、開 PR、等同事來看。現在 review 是持續進行的，更像你打字時一直在跑的拼字檢查。大多數變更在人看到之前，已經被 Claude 審過並修過至少一輪。

他們量測的方式也很務實。目標是：大部分 PR 在「最多一個人參與」（可以是作者本人）的情況下就能合併，而且 revert 和事故的比例不能上升。追蹤的是每個 PR 需要幾個人核准、留了幾則人工評論、PR 等人等了多久。revert 與事故率是護欄：一旦上升，就代表沒有省下人力，只是把時間從「審查」挪到了「救火」。

一個變更的旅程：六層關卡，底下還有安全網

一個變更從工程師的電腦（或 Slack 裡的 Claude session）出發，到真正交到使用者手上，會經過下面這些關卡。

白框是自動進行的步驟，強調框是人做決定的地方，淺色底是出事後的安全網。每一層都會抓到一些問題、漏掉另一些；很少有問題能一路穿過所有層，剩下的靠快速回滾處理。

幾個步驟值得多說一點：

第 1 步：先驗證，再給人看。 他們給 Claude 可以執行的東西（測試、build、或拿來比對設計稿的截圖），要求它拿出執行結果，而不是口頭說「做完了」。接著由另一個 subagent 用全新的 context 審一次 diff。開 PR 前，很多人還會跑幾個內部 skill：一個找 bug、一個簡化 diff、一個做端對端檢查。

這一步靠兩個檔案給 Claude 脈絡：

  • CLAUDE.md：告訴 Claude 這個專案是什麼，用什麼技術、有哪些慣例、目標與非目標。每次 review 都會載入，所以要短，細節放到其他文件去。
  • REVIEW.md：由 code owner 寫，告訴審查器「在我負責的這塊 code 裡，什麼才重要」。好的 REVIEW.md 很短：說明這個 repo 裡「失敗長什麼樣」（文件的失敗是「它說謊」，設定檔的失敗是「它導錯路」）、限制挑毛病的數量、列出要跳過的路徑，並要求給出檔案與行號當證據。

當自動審查器一直標出同一種問題，他們不是每次手動回應，而是從源頭修：改 skill、加 lint 規則，或更新上面這些檔案。

第 3 步：AI review 怎麼運作。 每個 PR 在人看之前，先由 Claude 把 diff 放在整個 repo 和 PR 的意圖下讀一遍，問三個問題：有沒有解決問題？合不合這個系統？會不會弄壞別的地方？研究預覽推出後，內部 PR 收到實質 review 評論的比例從 16% 升到 54%。每個發現都必須被回應：要嘛修掉，要嘛附理由關閉。常常是 agent 在夜裡接手修復，作者早上回來時 PR 已經又過了一輪。

第 5 步：風險分級。 文件修正和自動更新器的變更，風險天差地遠，所以審查強度也不同：

風險例子需要幾個人核准
低文件、文案、僅限內部的功能、flag 後面的新增功能0 人（自動審查與安全檢查都綠燈即可）
中一般產品變更，以及快取、自動更新器、system prompt 等敏感區域1 人
高最高風險的 code，加上一小組永遠需要兩人的路徑2 人

第 6、7、8 步：讓錯誤便宜。 Merge queue 會把變更套到最新的 main 上重跑所有檢查，所以兩個各自通過的 PR 不會合起來弄壞 main。新功能通常先放在 flag 後面給 Anthropic 員工用，高強度的內部使用常常在外部使用者之前就發現問題。Flag 關掉不需要重新部署。團隊每週輪 on-call，事故檢討時會問：「哪一層應該要抓到這個？」

三個值得學起來的設計

1. 風險層級由「變更」決定，不由「作者」決定

一個分類器會讀變更內容，判定它的風險層級。第二個分類器再問一次：即使層級說不用，這個特定變更是否仍然需要再多一個人？有些路徑永遠需要人：owner 列為敏感的任何東西，以及任何 CI workflow 檔案。

幾條配套規則很關鍵：

  • 只有 repo 信任名單上的作者（主要是擁有該 repo 的團隊）才能走較輕的路徑，其他人都需要第二個人核准。
  • agent 的核准永遠不算人的核准。自動審查可以放行低風險變更，但不能填補一個「需要人」的位子。
  • 誰下的 prompt 誰負責。在 agent 寫的 PR 上，指揮 agent 的人算作必要審查者之一，就跟親手打 code 一樣。
  • 一次核准只涵蓋一個特定 commit。之後若有系統無法擔保的新 commit（例如 agent 的 push，或有人手動解衝突），核准必須重新給。

2. 用多個 agent 互相投票，把噪音濾掉

抓更多 bug 很容易，只要不介意標出一堆非 bug。所以他們需要制衡。做法是：幾個 agent 同時找 bug，然後另一組 agent 對每個發現投票，只有足夠多的 agent 認定為真才會貼出來。純風格、診斷、清理類的發現會被丟掉（這些過濾器先在他們自己的 PR 上做過 A/B 測試）。剩下的以 inline comment 依嚴重度排序，標記為 Important、Nit 或 Pre-existing，這樣不是這個 PR 引入的 bug，就不會看起來像作者的錯。

他們量測噪音的方法也很聰明：把審查器留下的每則評論，依 PR 上的人怎麼回應來分類。修了？說它錯了？說這是刻意的？還是認為不重要？另外也會在已知乾淨的 PR 上跑審查器，數它多常回報會害人做出有害變更的東西。

噪音在作者是 agent 時成本更高。人可以幾秒內揮掉一個挑毛病的評論，但 agent 會去修，也就是又一個 commit、又一輪 review。

3. Review 必須收斂：50 輪的教訓

這是文章裡最精彩的故事。agent 作者和 agent 審查器可以讓彼此無限忙下去。有一個 CLI PR 在一夜之間經歷了五十多輪 review 與修復，直到作者把它停掉。

他們對審查器反覆標出的內容跑 git blame，發現約 59% 是從審查器第一輪時就存在的 code。也就是說，審查器很少在找新 bug，而是每一輪多找到幾個舊 bug。

他們也坦承是自己把事情弄糟的：習慣了預設跑好幾輪，因為每一輪都會抓到新東西。這在高風險變更上值得，但不是每個 PR 都該如此。

對策有四個：

  1. 輪數上限：三輪後，審查器會請作者退一步重新考慮做法。
  2. 前幾輪之後只審新的 diff。
  3. 標記 bug 的「類別」，讓作者一次修掉所有實例，而不是一行一行修。
  4. 不重複貼出已經貼過的發現。

效果很明顯：

指標改善前改善後
一輪 review 加修復就通過的 PR 比例65%78%
需要五輪以上的 PR 比例8.9%1.5%
平均通過所需輪數2.081.32

另一個持續改善的機制是「事故就是 eval」：團隊收集過去造成事故的 PR、連同修復與 revert，請熟悉那段 code 的工程師確認每個 bug 在哪裡。審查器每天跑這個集合；每次改 prompt、工具或模型，都要在這個集合上重新評分，分數有升才保留。

那人還做什麼？

把資深工程師從深度工作中拉出來抓一個例行錯誤，成本遠高於一次自動審查。所以人的時間要花在機器做不來的事上：

  • 決定要不要做。 方向、品味、範圍。有一個團隊宣稱已經解決了 review 瓶頸，卻仍然保留對「團隊外來的變更」的人工審查，為的是有人問一句「我們到底該不該做這個？」
  • 審查高風險的 code。 像計費、自動更新器、CI workflow。
  • 審查會被別人仿效的架構。 一旦定了模式，後面的人會照抄。
  • 讀證據。 測試輸出、跑了什麼命令、回傳什麼、截圖、審查器的發現。如果你說不出「這些檢查會漏掉什麼」，就該要求一次真正的 review，而不是隨手按核准。
  • 為結果負責。 每個出貨的變更都有一個人要負責，不管是誰打的字。

團隊有一條規範叫「誰落地，誰負責」：你合併了一個中小型變更後出事，通常就是你來修。這不是究責，而是因為你有最多的 context；事故檢討看的是整個系統哪裡該補強。能這樣運作，靠的是變更夠小、一切可逆（flag、revert、分階段釋出在幾分鐘內就能撤銷）、爆炸半徑大的 code 有更多人把關，以及 regression 透過遙測和內部使用很快浮現。

還有一件事：agent 讓「開始做」變得很便宜，所以有些工作根本不該落地。通常是頻道裡有人問一句為什麼、指向先前的決定、或建議更簡單的路，作者就把 PR 關掉或重做。因為 code 寫得快，關掉 PR 不會覺得是損失。訣竅是早一點在討論串裡提出不同方向，而不是在完成的 PR 上留一則阻擋評論。

沒人讀 diff 了，那大家怎麼學這份 code？

還記得 code review 的第二個工作嗎？讀同事的 diff，一直是你學到「什麼改了、各部分怎麼接起來」的方式。如果機器做了大部分的閱讀，人怎麼學？

他們的答案很誠實：沒有正式流程。團隊裡沒有任何人腦中有完整的 Claude Code 心智模型，他們也不認為需要。當有人想了解某個部分時，就請 Claude 針對那一小片寫一份 explainer。幾分鐘就好，而且反映的是此刻的 code，不是三個月前的文件。有些人更進一步，請 Claude 做一個小工具，用自己喜歡的方式把那段 code 視覺化。

他們的論點是：如果目標是把人的注意力花在刀口上，這比逐行讀瑣碎的 diff 好得多。一行文案變更幾乎教不了你什麼；但針對你即將修改的模組的一份 explainer，能教你很多。

再加上團隊習慣在公開的 Slack 頻道工作，你會邊做自己的事邊看到別人在建什麼，有人會接手別人的線頭，也有人會指一個 Claude 去補缺口。這種開放性是品質能維持、又不必在每一行 code 上設閘門的重要原因。

還沒解決的事，以及你可以怎麼開始

文章對自己的不足講得很坦白。他們目前還沒有「斷路器」：當 revert 或事故數字上升時，自動收緊核准門檻的機制。工程師希望在更多 code 走向零人工合併之前，先把這個做出來。發現壞合併，目前仍然依賴作者、on-call 和 dashboard。知識共享也沒有正式流程。

有一句話值得記下來：一位同事說，放慢速度確實會降低錯誤率，但主要是因為你什麼都做得少了。他們寧可在「發現問題」和「修好問題」上變得更快。

最後他們給了一份起步清單，大多數工具今天就有：

PR 之前

  • 給 agent 可以執行的檢查，列在簡短的 CLAUDE.md 裡，加上會跑 formatter 和 linter 的 hook。
  • 本地跑 /code-review 和 /security-review，或用一個全新 context 的 subagent 做 review。
  • 加一個 REVIEW.md，把反覆出現的 review 評論搬進去。

每個 PR

  • 強制 CI；PR 模板加上「怎麼測的」「風險」「怎麼還原」三欄。
  • 先在一個 repo 加 AI reviewer，調 REVIEW.md 幾週，再擴大到其他 repo。
  • 加自動安全審查；要求所有 review 討論串都解決了才能合併。
  • review 力度對應風險：例行變更快速掃，漏掉 bug 很貴的地方深度審。
  • 限制 review 輪數；前幾輪之後只審新的 diff。

核准

  • 把風險層級寫下來，由變更而非作者決定；從嚴格開始，有證據再放寬。
  • 較輕的核准路徑只給你信任的作者。
  • 用 CODEOWNERS 和 branch protection，讓 auth、計費、CI 與 release workflow、安裝程式永遠需要人。
  • 絕不讓 bot 的核准取代必要的人；有新 commit 就撤銷核准。

合併與之後

  • merge queue、feature flag、內部先用、分階段釋出、一步回滾。
  • 把事故與 revert 變成 eval set；每次改審查器的 prompt、工具或模型，就重新評分。
  • 量測人類時間，用 revert 與事故率當護欄。

整篇文章的目標從頭到尾沒變：每個變更花更少的人類時間，而且 revert 不比以前多。

參考來源

發佈留言