.title: 當 AI 寫下九行程式碼：Anthropic 揭露 Claude Code 的自動化程式碼審查制度與其爭議
.slug: anthropic-claude-code-automated-code-review
AI 寫程式的比例一旦超過某個臨界點，最先崩壞的往往不是開發流程，而是「人類如何理解自己系統」這件事本身。Anthropic 近日在官方文章中說明了 Claude Code 團隊如何重整程式碼審查制度，因為在 Claude Code 這套工具的程式碼中，約有九成已經由 Claude 自己撰寫。這篇文章由 Addy Osmani、Morgan Westlee Lunt 和 Qing Wang 共同撰寫，也是先前 Anthropic 揭露以自研系統取代 git 的續篇：他們的 monorepo（單一儲存庫管理整個組織程式碼的做法）合併量從五月的每天約 2,500 筆，暴增到九月的超過 30,000 筆，審查流程正是下一個被這種規模壓垮的環節。
核心內容：審查制度如何重新設計
Anthropic 為這套制度設定的目標很明確：大多數 pull request（PR，合併程式碼變更的請求）「在最多一名人類介入的情況下完成合併，且這個人可以就是作者本人，同時不增加回退或事故」。換句話說，大部分變更的把關工作交給自動化流程，人類只在特定風險等級時出現。
具體機制是透過一個分類器為每次變更指派風險層級，而且團隊強調「層級由變更內容決定，不是由作者決定」。低風險變更涵蓋文件、文案，以及藏在功能旗標（feature flag，一種能隨時開關新功能的控制開關）後的附加式修改，可以直接合併、不需人工核准。中等風險變更，包括快取、自動更新器和系統提示詞等牽涉核心行為的部分，則需要一名人類審查。制度中有兩條底線：AI 代理的核准永遠不算人類核准，而提出變更指示的人會被算進必要審查者之一，避免球員兼裁判。
最引人爭議的一段話，是團隊直接承認：沒有任何人腦中保有 Claude Code 的完整心智模型，而且他們認為也不需要。當有人想理解某段程式碼時，就請 Claude 現場為那個部分撰寫說明，幾分鐘就能完成，而且內容反映的是程式碼當下的狀態。這種「以 AI 即時產生的說明取代人類累積的理解」做法，成為整篇討論的焦點。
技術脈絡解讀：兩種被揭露的失敗模式
這篇文章之所以引起重視，在於它沒有只報喜。第一個失敗模式出現在作者與審查者都是 AI 的場景：人類看到吹毛求疵的小意見可以幾秒鐘略過，但 AI 代理會真的去修，這意味著再一次提交、再一輪審查。團隊記錄到一個 CLI 相關的 PR 在一夜之間經歷了超過五十輪審查與修正，最後是作者自己喊停。提高預設輪數只讓情況更糟，因此他們最終設了上限。Reddit 上的開發者也回報了獨立得出的相同結論：連續兩次修正失敗就停手，因為反覆失敗通常代表 AI 對程式碼的理解有誤，而不是它一直改的那一行有問題。
第二個失敗模式則觸及審查的實質價值。團隊用 git blame（追蹤每行程式碼由誰、何時寫入的工具）回頭分析審查者持續標記的內容，發現約 59% 其實是第一次審查時就存在的舊程式碼。也就是說，審查者很少找到新問題，而是每一輪再多翻出一些舊問題。這對「多審幾輪就更安全」的直覺假設提出了實證質疑。
影響與限制：心智模型之爭與真實的失控案例
「沒有人需要完整心智模型」這個主張在 Hacker News 上引發激烈辯論。反對者指出，這實際上換掉的是整套信任模型：過去系統出現無人能解的嚴重錯誤時，總有人腦中存在因果模型可以依賴、逐步除錯；現在則變成「相信 Claude 永遠對系統有足夠的理解」。不過也有聲音認為，大型組織的龐大遺留系統本來就沒有人能完整掌握，這種做法只是把現狀變得更透明。
而 Anthropic 自己的儲存庫提供了一個耐人尋味的反例。八月間，Claude Code 協作者 Boris Cherny 在回應一個關於 issue 自動關閉的長期抱怨時，貼出了帶有「由 Claude Code 生成」標記的回覆，宣稱 issue 只會在「長時間無活動且缺少重現所需資訊」時關閉，且「不會只靠計數來分類」。但開發者 marcindulak 實際比對發現，儲存庫中的 issue 生命週期設定是十四天後標記為過期、再十四天後關閉，僅豁免獲得十個以上讚的項目，而超過六千個被標記為已附重現步驟的 issue 仍被以「閒置過久」為由關閉。更矛盾的是，回覆中建議的補救方式——留言讓 issue 重新開啟——被「關閉七天後鎖定」的工作流程擋住，連那個討論此問題的 meta issue 也被鎖定。正如評論者所言：造成這個問題、又誤判了儲存庫實際管理方式的答覆，出自一個世界級模型。
制度的邊界也存在未解問題。有 Reddit 用戶追問：低風險層級是否涵蓋以文件形式包裝的 AI 指令變更？這類修改不動應用程式碼，卻能改變 AI 代理的行為，而該篇文章並未回答，也沒有為 CLAUDE.md（AI 審查者每次審查都會載入的說明檔）指派任何風險層級。合規面向同樣未被討論：有開發者回報自家 SOC 2（一種常見的資訊安全稽核標準）稽核員要求每個變更在上線前必須經過第二名人類審查。團隊自己也承認一個缺口：目前還沒有「斷路器」機制，無法在指標異常時自動收緊核准條件，而工程師希望在更多程式碼走向零人類合併之前先補上。
實務意義與現況
並非所有人都認為這套制度冒進。有評論者指出大型組織從來沒有人掌握全貌，這是對現狀的升級；也有人算了一筆帳：每月花幾千美元用 AI 審查，對比人類審查可能吃掉工程師多達三分之一的時間。從成本結構看，這筆交易相當誘人。
部分成果已公開發布。Code Review for Claude Code 已在 Team 與 Enterprise 方案全面提供，安全審查功能則以開源 GitHub Action 形式釋出——但其 README 明言該工具「尚未強化以抵禦提示詞注入攻擊，應僅用於審查受信任的 PR」。這句免責聲明某種程度上總結了整場討論的張力：自動化審查確實能承載巨大規模，但它的信任邊界、合規要求和失效情境，都還在實務社群的壓力測試中逐步被畫出來。本文內容整理自 InfoQ 於 2026 年 10 月 29 日由 Steef-Jan Wiggers 撰寫的報導。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。