從「人盯 diff」到「七層自動化 + 風險分層」
Anthropic 在十月十六日發布的官方長文中，第一次完整揭露 Claude Code 團隊如何審查「Claude 自己寫」的程式碼。團隊直接點出核心數字：Claude 寫出 Claude Code 約 九成 的程式碼；Anthropic 整個 monorepo 的每日合併量從今年五月的約 2,500 件，暴增到九月的 30,000 件以上（12 倍成長），Claude Code 自己的 repo 雖獨立於 monorepo，也承受相同量級的合併壓力。
編按：本文綜合整理自 Anthropic 官方部落格、Hacker News 討論串、InfoQ 報導、The New Stack 報導、Claude Code 官方文件，並加入 Siami 編輯部觀點與分析。
團隊坦言，當合併量暴增到這個量級，逐行人工 review 已不可能，因此他們把 review 從「終點關卡」改為「貫穿開發流程的自動化機制」，只在「人類擅長、機器不擅長」的地方保留人力。
七層審查機制：機器讀、人類決
Anthropic 設計的審查流程是一條「七層流水線」：
- PR 前驗證：Claude 自己跑測試、build、linter；另一個 agent 在全新 context 內 review diff。
- 每次 PR 強制 CI：lint、型別檢查、跨平台測試、build。
- 每次 PR 強制 AI 審查：Claude 讀 diff 對照整個 repo，判斷是否解決問題、是否合身於系統。
- 安全審查獨立、可擋合併：任何安全 finding 未結案，PR 不得合併。
- 風險分層的人類核准：classifier 依變更性質決定低中高風險，只有 trusted 作者的低風險改可一人過關。
- 合併隊列 + 漸進式發布：每個 PR 在 main 上重跑所有檢查；新行為通常先對員工開 flag，穩定後才公開。
- 快速偵測、快速回滾：flag 可不部署直接關閉；每週輪值 on-call，事故檢討必問「哪一層該抓到」。
這套機制讓 Anthropic 公開的關鍵指標大幅改善：
| 指標 | 改善前 | 改善後 |
|---|---|---|
| 平均 review 輪數 | 2.08 | 1.32 |
| 一次過關的 PR 比例 | 65% | 78% |
| 需五輪以上 review 的 PR | 8.9% | 1.5% |
| substantive review comments 比例 | 16% | 54% |
| 每月 revert 次數 | — | 下降 40% |
為什麼這件事重要
這篇文章不是產品發表，而是 Anthropic 第一次把「AI 寫九成程式碼」這件事的營運細節全部攤開。它直接回答了整個業界最焦慮的問題：當 agent 是主要產出者，人類的價值定位在哪裡？
Anthropic 的答案非常具體：
- 人類的工作是「spec 設計師」，不是「code 讀者」。他們把人類從讀 diff 移到設計規格、判斷風險、處理事故。
- 「人讀過了」不是審查的目標，「哪一類問題該由哪一層抓到」才是。
- 人機協作的摩擦本身就是成本：agent 寫錯時人會懶得改，因為「看起來很煩」；自動化層越多、人類需要看 diff 的地方越少，實際上越安全。
- CI 必須為「人不再看」設計：lint、型別、測試、build 全面成為合併閘道，人類只在「機器不擅長」的最後一關才介入。
對企業 IT 而言，這是一份可以直接抄的 SOP 草案：把 review 拆成七層、為每一層定義「該抓什麼」、把分類器與 flag 系統化、為 on-call 留事故回饋環。Anthropic 證明這樣做不會降低品質（revert 下降 40%），反而把合併量提升 12 倍。
數據解讀與質疑
雖然指標亮眼，但讀者應該注意幾個前提：
- 12 倍合併量 ≠ 12 倍產出。Anthropic 自己也承認「revert 下降 40%」是用新流程後的數字對比，並未對照「若不放 review、純靠 agent 自動合併」的基線。多合併不等於多價值。
- 「90% 由 Claude 寫」高度選擇性。Boris Cherny（Claude Code 創始人）公開說他個人一天做 30-40 個 PR，但 TeamBlind 評論也有人質疑這數字過於誇張；Anthropic 並未公開每位工程師的 agent 寫入比例。
- 50 輪 review 死循環真實存在。原文自爆有 CLI PR「一個晚上跑超過 50 輪 review 與修復」才被作者喊停，Anthropic 靠「限制輪數 + daily eval 收斂」才解決。代表 agent + agent 的死循環是真實的工程問題，不是危言聳聽。
- 公開版 Code Review 仍要 $15-25/PR（Claude 官方 X 公告），對 1,000+ 行程式碼有 84% 機率會找出問題，但也有 HN 質疑 認為「Claude 寫的 PR 平均 7.5 個真實 bug」，品質並未因自動化 review 而顯著優於人類。
- Anthropic 已搬離 Git。原文只輕描淡寫帶過，但 Slashdot 與 dev.to 報導 指出 30,000 改/天 已超出 Git 基礎設施極限，這代表支撐 AI 寫程式碼的，是新世代程式碼託管平台，不是 GitHub。
給台灣工程團隊的三個可抄做法
如果你的團隊還沒導入 AI coding agent，這套 SOP 提供三個立即可抄的設計：
- 把 review 拆成「機器抓 bug」與「人類決策」兩段。前段全面自動化，後段只看 classifier 標出來的高風險改，其餘一律放行。
- 為每一層失敗寫「事故回饋環」。Anthropic 已經把每次事故變成 eval case，每天對 reviewer 跑一次評估，score 上升就保留，下降就退回。沒有這個環，AI reviewer 會原地踏步。
- 公開版工具先用起來：
/code-review與/security-review已開源，可在個人 repo 立即測試；Team/Enterprise 用戶則可啟用正式版。
如果你的團隊已經在用 AI coding agent，最值得檢討的是 review 輪數。Anthropic 指出 agent + agent 死循環是真實風險，建議主動設定「超過 N 輪就強制收斂」的流程，而不是放任 agent 跟 reviewer 跑一整晚。
編按：本文綜合整理自 Anthropic 官方部落格「How the Claude Code team does code review」、Hacker News 討論串、The New Stack 報導、InfoQ 報導、Claude Code 官方文件、Codeant.ai 解說，並加入 Siami 編輯部觀點與分析。
網友熱門留言 (5)