PR 翻倍、退版降四成
Claude Code 團隊在 2026 年 10 月 15 日發表文章，說明他們如何審查程式碼。團隊先前提過，Claude Code 自己約 90% 的程式碼是由 Claude 寫的；程式碼量暴增之後，逐行人工審查幾乎不可能。
文章提到兩組數字：
- Anthropic 的 monorepo 每天合併的變更，從 5 月約 2,500 筆，增加到 9 月超過 30,000 筆。
- 從 6 月到 9 月，Claude Code 程式庫合併的 PR 增加一倍以上，需要退版（revert）的比例卻下降超過 40%。
他們沒有取消審查，而是把大部分「閱讀」交給機器，把人的時間留給只有人能判斷的問題，同時讓出錯後能快速復原。團隊用來衡量成效的是每個 PR 的人工核准數、人工留言數與等待時間；退版率與事故率則是護欄，一旦上升，就代表時間只是被搬到別處。
開 PR 前先讓 AI 自證
現在大部分審查在 PR 出現之前就完成了。團隊會給 Claude 可以執行的東西，例如測試、建置，或與設計稿比對的截圖，並要求它展示輸出，而不是只說「做好了」。接著再由一個上下文全新的 subagent 審查 diff。
Claude Code 的創作者 Boris Cherny 認為，讓 Claude 有辦法驗證自己的成果，可能是取得好結果最重要的一件事，他估計能讓最終成果好上兩到三倍。
當 AI 審查一再指出同一類問題，團隊會從源頭修正：
CLAUDE.md：寫明專案是什麼、技術棧、慣例、目標與非目標。每次審查都會載入，所以要保持簡短，再指向其他文件。REVIEW.md：由 code owner 撰寫，告訴審查者這一區最在意什麼。好的版本很短，會說明這個 repo 的「失敗長什麼樣子」、限制小問題數量、列出可略過的路徑，並要求以檔案與行號作為證據。
七層把關各有分工
文章把一筆變更從工程師電腦到使用者手上的過程拆成多層，每層都會漏掉一些問題，但能全部穿過的很少，最後再由快速回滾收尾。
- 開 PR 前先驗證（見上一段）。
- 每個 PR 都有 AI 審查：對照整個 repo 與 PR 的意圖檢查。推出研究預覽時，內部 PR 收到實質審查意見的比例從 16% 升到 54%。多個 agent 同時找 bug，再由另一組投票，只有夠多 agent 同意的發現才會貼出，純風格類意見會被過濾掉。
- 可以擋下合併的安全審查：任何 bug 或安全發現未處理，PR 就不能合併；要嘛修好，要嘛附理由關閉。
- 自動檢查：lint、型別檢查、各平台測試與建置。
- 依風險決定人工核准數（見下表）。
- merge queue、功能旗標與分階段發布。
- 快速偵測、快速回滾：旗標不用重新部署就能關閉，並有每週輪值。
| 風險 | 例子 | 需要的人工核准 |
|---|---|---|
| 低 | 文件、文案、僅內部功能、放在旗標後的新增功能 | 自動審查與安全檢查通過後即可，不需人工 |
| 中 | 一般產品變更，以及快取、自動更新、系統提示等敏感區域 | 一人 |
| 高 | 風險最高的程式碼，以及固定需要兩人的少數路徑 | 兩人 |
風險等級由變更內容決定，不看作者是誰，由分類器判斷。只有 repo 信任名單上的作者能走較輕的流程，而且 agent 的核准永遠不能取代人。
審查要收斂，三輪封頂
當作者和審查者都是 agent，雙方可能互相忙個沒完。文章提到，有一個 CLI PR 一夜之間跑了超過五十輪審查與修正，直到作者喊停。團隊用 git blame 檢查審查者反覆指出的問題，發現約 59% 是第一輪審查時就已經存在的程式碼。
於是他們調整重新審查的規則：
- 三輪封頂：超過三輪，審查者會請作者退一步，重新思考做法。
- 前幾輪之後，只審新的 diff。
- 指出整類問題，讓作者一次修掉所有同類寫法。
- 已經貼過的發現不重複貼。
另外，團隊把過去造成事故的 PR 整理成評測集，每天讓審查者跑一次；也會依照 PR 作者的回應（修了、說錯了、說是刻意的、說不重要）來衡量雜訊。
人只做五種判斷
把資深工程師從深度工作中拉出來抓一個例行錯誤，成本遠高於一次自動審查。在 Anthropic，人的工作從閱讀每個 diff，轉向機器不擅長的判斷：
- 該不該做：方向、品味與範圍。
- 高風險程式碼：例如計費、自動更新與 CI 工作流程。
- 會被別人照抄的架構。
- 讀證據：測試輸出、執行的指令與結果、截圖、審查發現。如果說不出檢查會漏掉什麼，就該要求正式審查，而不是快速核准。
- 為結果負責：每一筆上線的變更都有一個人負責，不論是誰打的字。
想理解某段程式碼時，團隊會請 Claude 針對那一塊寫一份說明，幾分鐘就完成，而且反映的是當下的程式碼。
小團隊可以照抄的清單
文章最後列出可直接採用的做法，大部分工具現在就有：
- 開 PR 前：在簡短的
CLAUDE.md列出 agent 可以執行的檢查；在本機跑/code-review與/security-review；新增REVIEW.md，把反覆出現的審查意見寫進去。 - 每個 PR：要求 CI，在 PR 範本加上「Testing」「Risk」「How to revert」；先在一個 repo 加上 AI 審查，調整幾週再擴大；要求所有審查討論都處理完才能合併；限制審查輪數。
- 核准：寫下風險等級，從嚴開始，有證據再放寬；用 CODEOWNERS 與分支保護，讓驗證、計費、CI 與發布流程一定要有人看；新 commit 進來就撤銷舊核准。
- 合併之後：使用 merge queue、功能旗標、先內部使用、分階段發布與一鍵回滾；把事故與退版變成評測集。
如果你是一人公司或小團隊，可以先從前兩項開始：把專案慣例寫進 CLAUDE.md，要求 AI 交付時附上測試輸出，再加上一份短短的 REVIEW.md。
