Claude Code 團隊的 code review：人不再讀每一行，但沒有人會放手

90% 的程式碼是 AI 寫的，那誰在把關？

Claude Code 團隊說過，Claude 寫了 Claude Code 大約九成的程式碼。這馬上引出一個尷尬的問題：改動量這麼大，人根本讀不完，那還有人在看程式碼嗎？出事了誰負責？

2026 年 10 月，Claude Code 團隊在部落格公開了他們的做法。先看結果：從 6 月到 9 月，合併進 Claude Code 的 PR 數量翻了一倍以上，但需要被 revert（撤回）的比例反而降了四成以上。

他們沒有取消 code review。他們做的是三件事：把「讀程式碼」這件事大部分交給機器、把人的時間留給機器做不好的判斷、然後花大力氣讓「犯錯之後能快速撤回」變得又快又便宜。

本文把這套做法用最簡單的方式講一遍，也附上他們建議一般團隊可以怎麼起步。

別再問「人讀過了沒」，改問「哪一層該抓到」

傳統 code review 的隱含假設是：只要有人讀過這段程式碼，品質就有保障。Claude Code 團隊覺得這個指標太粗糙。真正該問的是：這個改動可能出什麼錯？哪一種檢查最適合抓到它——自動化的，還是人？

這個問題一換，review 的時間點也跟著變了。以前 review 是終點站的閘門：寫完程式、開 PR、等同事有空來看。現在 review 像打字時的拼字檢查，從頭到尾一直在跑。多數改動在人看之前，已經被 Claude 審過、修過至少一輪，例行的小錯誤早就被清掉，人的注意力可以留給更高層次的問題。

稀缺資源是人的時間

他們把目標講得很清楚：在 Claude Code 的幾個 repo 裡，大部分 PR 最多只需要一個人經手（可以就是作者本人），而且 revert 率和事故率不能上升。

為什麼要加後面那句？因為人的時間有兩種花法：花在審查上，以及花在收拾爛程式碼造成的後果上。如果只是把前者省下來，然後全跑到後者去，那什麼都沒省。所以他們追蹤的指標是：每個 PR 需要幾個人核准、人留了幾條意見、PR 等人等了多久；而 revert 率和事故率是護欄——一旦上升，就表示省下的時間只是被搬到別處。

一個改動的旅程：七層檢查，不是一道閘門

一個改動從工程師的筆電（或 Slack 裡的一個 Claude session）到使用者手上，會經過七層。每一層都會抓到一些問題、漏掉一些問題，但很少有問題能連闖七關；真的闖過去的，靠最後一層快速撤回。

開 PR 之前先自我驗證。 給 Claude 一個它能實際執行的東西——測試、build、或拿截圖跟設計稿比對——要求它拿出執行結果證明做完了，而不是嘴巴說做完了。接著另開一個全新 context 的 subagent 來審 diff。Claude Code 的創造者 Boris Cherny 說，「讓 Claude 有辦法驗證自己的工作」大概是拿到好結果最重要的一件事，他估計能讓成果好兩到三倍。
每個 PR 都先過 AI review。 多個 agent 同時找 bug，然後由另一組 agent 對每個發現投票，夠多 agent 同意是真的才會貼出來；純粹關於風格或清理的發現直接丟掉。留下的依嚴重程度排序，標上 Important、Nit 或 Pre-existing（原本就有的問題，不是這個 PR 弄出來的，不會算在作者頭上）。每一條發現都必須有回應：要嘛修掉，要嘛寫理由關閉。常常是 agent 半夜就把問題修好了，作者早上回來看到的 PR 已經又跑過一輪。
安全審查可以擋 merge。 安全有自己獨立的一道自動審查。只要 bug review 或安全 review 還有任何一條發現沒關閉，PR 就不能合併。
CI 必須全綠。 lint、型別檢查、各平台測試、build 和打包，一個 CLI 的 PR 在人看之前可能已經跑了幾十個檢查。PR 模板會問「怎麼測的」和「怎麼撤回」，Claude 可以代填，但下指令的那個人要簽字負責。
人工核准，依風險分級。 改文件和改自動更新程式的風險天差地遠，自然不該用同一套審法。細節見下一節。
Merge queue、feature flag、漸進發布。 Merge queue 會把改動套在最新的 main 上重跑所有檢查，避免兩個各自都過的 PR 合在一起反而壞掉。新功能通常先藏在 flag 後面，只開給 Anthropic 員工，自家人用得兇，常常在使用者發現前就先踩到回歸。對外先發到 latest 頻道，stable 頻道落後一段距離。
快速偵測、快速撤回。 總會有東西漏過去，所以最後一層的重點是抓得快。flag 可以不重新部署就關掉；每週有 on-call 輪值；事故檢討時會問「這個問題本來應該被哪一層抓到」。

有位同事說得很直白：放慢速度確實會降低錯誤率，但主要是因為你什麼都做得比較少。他們寧願選擇變得更擅長發現和修正問題。

重複被挑的問題，回頭修在源頭

如果自動 reviewer 一直挑同一類問題，正確的做法不是每次都修，而是把規則寫進源頭：寫進 skill、加一條 lint rule、或更新兩個關鍵檔案：

CLAUDE.md：告訴 Claude 這個專案是什麼——技術棧、慣例、目標和非目標。每次 review 都會載入它，所以在大型 codebase 裡要保持簡短，細節另外連結出去。
REVIEW.md：由 code owner 撰寫，告訴 reviewer 在這塊程式碼裡「什麼才重要」。好的 REVIEW.md 都很短：說清楚這個 repo 裡「壞掉長什麼樣」（文件類是「它說謊」，設定類是「它導錯路」）、限制 nit 的數量、列出要跳過的路徑、要求 reviewer 給出檔案和行號當證據而不是憑名字猜。

要幾個人看，由改動決定，不是由作者決定

風險	例子	需要幾個人核准
低	文件、文案、僅內部使用的功能、藏在 flag 後面的新增功能	不需要，自動 review 和安全檢查綠燈即可
中	一般產品改動，以及快取、自動更新程式、system prompt 等敏感區域	一人
高	風險最高的程式碼，加上一小組永遠需要兩人的路徑	兩人

這套分級有五條規則，每一條都在堵一個漏洞：

風險等級由分類器讀改動內容決定，不是作者自己填。 第二個分類器還會再問一次：就算等級說不用，這個特定改動是否還是該多一個人看？有些路徑永遠需要人：owner 列為敏感的區域，以及所有 CI workflow 檔案。
只有信任名單上的作者才能走輕量路徑。 名單基本上就是擁有那個 repo 的團隊；其他人一律需要第二個人核准。
agent 的核准永遠不算人的核准。 自動 review 可以放行低風險改動，但不能填補任何一個「需要人」的位置。
下指令的人就是負責的人。 agent 寫的 PR，指揮 agent 的那個人算作必要 reviewer 之一，跟自己親手打字沒有兩樣。
核准只對特定 commit 有效。 如果之後又有系統無法擔保的新 commit 進來——例如 agent 推的、或有人手動解衝突合併的——就得重新核准。

AI reviewer 不是裝上去就好，要一直餵它

每一次事故，都變成考題

團隊把過去造成事故或被 revert 的 PR 全部收集起來，連同後續的修正，請熟悉那塊程式碼的工程師確認 bug 確實存在、在哪一行。這組資料就是 reviewer 的考卷，每天跑一次。只要 reviewer 的 prompt、工具或模型有任何變動，就重新考一次：分數上升就留，沒上升就退回。考卷隨每一次事故持續長大。

雜訊也要量，而且 agent 當作者時雜訊更貴

想抓到更多 bug很簡單，只要不在乎誤報就行，所以必須有反向的檢查。他們把 reviewer 留的每一條意見，依照 PR 上的人怎麼處理來分類：修了、說它錯了、說這是故意的、或決定不重要。他們也拿已知乾淨的 PR 去跑 reviewer，數它多常報出一些「照做反而會改壞」的東西。優先順序白紙黑字寫下來：第一是抓真 bug，第二才是減少 review 輪數。

雜訊在作者是 agent 的時候特別貴。人看到一個 nit 可以幾秒內揮手略過；agent 會認真去修，於是多一個 commit、多一輪 review。

Review 必須收斂：五十輪的教訓

一個 agent 作者加一個 agent reviewer，可以互相忙到天荒地老。曾經有一個 CLI 的 PR，一個晚上跑了五十多輪 review 和修正，直到作者早上把它停掉。

他們對 reviewer 反覆挑出來的程式碼跑 git blame，發現約 59% 從第一輪 review 時就已經存在。也就是說，reviewer 不是在找新 bug，而是每一輪多挖出幾個舊的。

團隊承認這是自己造成的：他們習慣預設跑好幾輪，因為每一輪總會多抓到一點東西。這在高風險改動上值得，但不該每個 PR 都這樣。於是他們開始追蹤「幾輪才通過」，並改了重審的規則：

輪數上限： 三輪之後，reviewer 改為請作者退一步重新思考整個作法。
只重審 diff： 前幾輪之後，只看新改的部分。
標示 bug 的類別： 讓作者一次修掉所有同類問題，而不是一行一行修。
不重複： 已經貼過的發現不再貼。

指標	改之前	改之後
一輪 review 加修正就通過	65%	78%
需要五輪以上	8.9%	1.5%
平均通過輪數	2.08	1.32

Review agent 也會每晚掃一遍既有程式碼，趁舊 bug 還沒在別處冒出來之前先抓到。

人留在哪裡：五種機器做不好的決定

把一位資深工程師從深度工作中拉出來抓一個例行錯誤，代價遠高於一次自動 review。所以 Anthropic 工程師的工作已經從「讀每一個 diff」移到以下五種決定：

該不該做這個東西？ 方向、品味、範圍。有個團隊宣稱 review 瓶頸已經解決，卻仍然保留對「團隊外部送來的改動」的人工審查，就是為了有人問一句「我們真的要做這個嗎？」
高風險程式碼。 計費、自動更新程式、CI workflow。
會被別人模仿的架構。 一旦定下模式，其他人會照抄。
讀證據。 測試輸出、跑了哪個指令、回傳什麼、截圖、reviewer 的發現。他們的判斷標準很簡單：如果你說不出「這些檢查會漏掉什麼」，就該要求一次真正的 review，而不是快速按下核准。
對結果負責。 每一個上線的改動都有一個人負責，不管程式碼是誰打的。

沒人讀 diff 了，團隊怎麼學程式碼？

Code review 一直有第二個功能：傳遞 codebase 的知識。讀同事的 diff，是你知道「什麼變了、各部分怎麼拼在一起」的方式。如果機器做了大部分的閱讀，那人要怎麼學？

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

如果目標是把人的注意力花在刀口上，這比逐行讀瑣碎的 diff 划算多了。一行文案改動教不了你什麼；一篇關於「你正要動的那個模組」的解說，教得了你很多。團隊預設在公開的 Slack 頻道工作也有幫助：你在別人建造的同時就看到他們在建什麼。

「你 land 的，你負責」

如果你合併了一個中小型改動，之後出了問題，團隊的慣例是通常由你來修。這條規則不會變成互相指責，靠的是五個條件：

改動很小，所以容易審、容易除錯、容易撤回。
一切都可逆：flag、revert、分階段發布，幾分鐘內就能撤掉大多數錯誤。
爆炸半徑決定門檻：代價高的程式碼需要更多人、更多檢查。
回歸很快浮現：靠遙測和內部使用。
這不是究責：由你修是因為你最有 context；事故檢討看的是系統，不是人。

責任也是共享的。團隊大多在公開頻道工作，任何人都能看到別人在做什麼、接手一條線、或指派一個 Claude 去補缺口，連不擁有那段程式碼的人也會給回饋。這種開放，是品質能維持、又不必每一行都設閘門的一大原因。

該停的 PR 就要停

Agent 讓「開始做一件事」變得非常便宜，所以有些工作本來就不該合併。通常是頻道裡有人問一句為什麼、指出先前的某個決定、或建議更簡單的路，作者就把 PR 關掉或改方向。

既然程式碼寫得很快，關掉 PR 就不覺得可惜。訣竅在於：要在討論串早期就提出不同方向，而不是等 PR 完成了才留一條 blocking comment。

你的團隊可以怎麼開始

這套做法的零件今天大多都買得到或自己裝得起來。依照改動的旅程，分四段：

開 PR 之前

給 agent 它能自己跑的檢查，寫在一份簡短的 CLAUDE.md 裡，加上會自動跑 formatter 和 linter 的 hooks。
本機先跑 /code-review 和 /security-review，或開一個全新 context 的 subagent 審 diff。
建一份 REVIEW.md，把一再出現的 review 意見搬進去。

每個 PR

CI 必須通過；PR 模板加上「怎麼測」「風險」「怎麼撤回」三欄。
先在一個 repo 裝 AI reviewer（Code Review for Claude Code，或 Claude Code GitHub Action），花幾週調 REVIEW.md，再擴大。
加上自動安全審查，並要求所有 review 討論串都關閉才能合併。
Review 力道對應風險：例行改動快速掃過，漏一個 bug 代價很高的地方才做深度審查。
設 review 輪數上限；前幾輪之後只重審新的 diff。

核准

把風險分級寫下來，由改動決定而不是作者；一開始嚴格，有證據再放寬。
輕量核准路徑只給你信任的作者。
用 CODEOWNERS 和 branch protection 確保 auth、計費、CI 和發布流程、安裝程式永遠需要人。
永遠不讓 bot 的核准取代必要的人工核准；有新 commit 就撤銷舊的核准。

合併與之後

用 merge queue、feature flag、內部先用、分階段發布、一鍵回滾。
把事故和 revert 做成 eval 資料集；reviewer 的 prompt、工具或模型一變就重新評分。
量「人花了多少時間」，以 revert 率和事故率當護欄。

結語：目標從來沒變

Code Review 產品的公開版本仍然把「核准 PR」留給人，它只貼發現，不按核准。Claude Code 自己的 repo 走得更遠：讓 owner 決定哪些低風險改動可以只靠自動檢查合併，而且那條線還在持續往前移。

每當 review 漏掉什麼，他們問的不是「誰沒看到」，而是「模型當時手上少了什麼」，然後把答案寫進 CLAUDE.md、一個 skill、或一條新的檢查。目標從頭到尾只有一個：每個改動花更少的人力時間，而且 revert 不比以前多。

整篇最值得帶走的一句話，大概是那位同事說的：放慢確實會讓錯誤變少，但那是因為你什麼都做得少了。真正的選擇是變得更擅長發現問題、更擅長修正問題。

原文

How the Claude Code team does code review，Addy Osmani、Morgan Westlee Lunt、Qing Wang，claude.dev 部落格，2026 年 10 月 15 日。