Anthropic Claude Code Review 在 AI 撰寫 90% 程式碼後取代例行人工閱讀
Anthropic 表示，隨着 Claude 現時撰寫約 90% 的產品程式碼，Claude Code review 已進入陌生領域。由 2026 年 6 月至 9 月，已合併的 pull request 數量增加逾一倍，但據報需要回退的比例下降超過 40%。
這個組合才是故事核心。Anthropic 並沒有因應機器撰寫的程式碼激增，而安排人類檢查更多程式碼行；相反，它把大部分例行閱讀工作交予其他 Claude 代理，並將人類審批保留給風險較高的改動。
這不只是傳統審查的加速版。它改變了審查的定義、執行者，以及問責從何開始。Anthropic 現時把人類注意力視為稀缺資源，應按風險分配，而非投注在每一行程式碼上。
這個做法亦有重要限制。這些亮眼結果來自 Anthropic 自行量度，未有公開原始數據或接受獨立審核。其流程依賴大規模自動化、內部基建、分階段發布，以及對自家模型的異常高程度使用。
最終的競爭並非 Claude 對人類程式員，而是自動化覆蓋與全面人工檢查之爭。Anthropic 正押注，分層檢查、針對性審批及低成本可逆性，比逐行以機器速度閱讀更能控制風險。
Anthropic Claude Code Review 有何改變
Anthropic 將程式碼審查從單一人工關卡，轉變為由自動檢查、代理審查員、針對性審批及快速回退組成的持續系統。
該公司在 10 月 15 日一篇關於 Claude Code review 的工程文章中介紹這套系統。作者 Addy Osmani、Morgan Westlee Lunt 和 Qing Wang 將問題聚焦於產出量：當代理生成改動的速度超越人類閱讀速度，傳統排隊流程便會成為交付瓶頸。
Anthropic 表示，每個 pull request 均會先接受 Claude 審查，才由人員查看。審查員會根據較廣泛的儲存庫內容及 pull request 所述意圖閱讀建議改動。對於修正錯誤的改動，系統會嘗試找出根本原因，而非只檢查可見的修補內容。
多個代理其後會平行搜尋潛在缺陷。另一組代理會就每項發現投票，而系統只會在足夠多審查員同意時才發出問題。Anthropic 表示，它測試了可移除僅關於風格、診斷或可選清理工作的留言篩選器。
餘下的發現會獲標示嚴重程度。開發人員或代理必須修正每項發現，或說明理由後關閉討論串。獨立的自動化安全審查亦可在問題未解決時阻止合併。
這些審查與傳統保障措施並行。Pull request 仍要通過 linting、型別檢查、建置，以及支援平台上的測試。合併佇列會針對目前的 main branch 重新執行檢查，減少各自有效的改動彼此產生不良互動所導致的失敗。
審查在 pull request 出現前已經開始。Claude 會執行測試、建置或視覺檢查，並展示所得證據。擁有全新上下文的子代理其後檢查 diff，從而減低撰寫代理只是重複原有假設的機會。
Anthropic 早前的 編碼實務 建議分隔撰寫與驗證上下文。新工作流程把這項建議轉化為整個團隊的作業系統。
人類審批取決於改動的分類風險。低風險工作可在通過自動化及安全檢查後合併，例如文件、文案修改、內部功能，以及隱藏在功能旗標後的新增內容。
一般產品工作通常需要一人審批。快取、系統提示及更新機制等敏感範疇亦會獲得人類關注。最高風險的改動需要兩人審批，而某些受保護路徑則必定觸發人工審查。
分類器評估的是改動本身，而不是由人還是代理撰寫。若原有分級看來過於寬鬆，第二個分類器仍可要求人類參與。代理的審批永遠不能填補預留給人員的位置。
這個區別很重要。Anthropic 並未消除人類問責，亦沒有宣稱 AI 審查能讓軟件完全沒有錯誤。它把例行缺陷偵測，與涉及架構、產品方向、敏感系統及可接受風險的決策分開處理。
指示 Claude 的人仍須為結果負責。每次審批只適用於特定 commit，因此後續改動可令其失效。在 Anthropic 的模式中，委派會改變誰輸入及閱讀程式碼，但不會改變誰擁有最終結果。
數字令純人工審查難以持續
Anthropic 公布的指標顯示，程式碼產出已超越任何以全面人工閱讀為基礎的審查流程。
該公司表示，Claude Code 儲存庫中已合併的 pull request 數量，在 2026 年 6 月至 9 月期間增加逾一倍。同期，需要回退的比例下降超過 40%。
這些數字反映方向，而非完整表現。Anthropic 未有披露 pull request 的絕對數量、原有回退率、最終回退率或統計變異。相對下降 40% 可以是由高或低的基準開始。
90% 這個數字亦需要謹慎表述。Anthropic 表示，Claude 撰寫約 90% 的 Claude Code 程式碼。這不代表模型獨立選擇產品優先次序、定義每項要求，或承擔部署責任。
工程師仍會指導任務、判斷證據、解決設計取捨，並決定某項工作是否應該存在。機器撰寫衡量的是程式碼生成，而軟件工程遠不止產生程式碼行。
即使有這些限定，Anthropic 仍面對實際的擴展問題。據報其獨立 monorepo 每日合併改動數量，已由 5 月約 2,500 項增至 9 月逾 30,000 項。該公司建立名為 Scion 的內部源碼控制系統來應付這個工作量。
Claude Code 使用獨立儲存庫，因此 30,000 項改動的數字並不直接衡量產品團隊。然而，Anthropic 對其 源碼控制重新設計 的描述，展示了開發基建承受的更廣泛壓力。
Scion 與 Claude Code 的故事都指向同一個瓶頸。一旦編碼代理能持續建立、測試及修訂改動，撰寫程式碼便不再控制吞吐量。審查佇列、建置、權限、整合系統及發布控制，會成為限制因素。
傳統程式碼審查假設由人發出的改動數量可以處理。另一人閱讀每個 diff、要求修訂，並批准最終版本。當產出增長速度快過審查員能力時，這個模式便開始失效。
增加審查員亦不能完全解決不匹配問題。資深工程師稀缺，而持續審查會打斷設計工作、除錯及產品決策。機構即使增加審查人手，仍可能在持續增長的改動流中失去共享注意力。
因此，Anthropic 衡量的不只是產生了多少留言。它追蹤每個 pull request 的人類審批數目、人類留言、等待時間、回退及事故。其既定目標是在不把時間轉移至生產環境復原的前提下，減少人類審查時間。
該公司亦表示，其商業 AI 審查員把獲得實質留言的內部 pull request 比例，由 16% 提升至 54%。據報大部分超過 1,000 行的改動均會出現發現，而大部分較小改動則會得到乾淨結果。
這個結果本身並不能證明準確度。更多留言可能代表更佳偵測、更多雜訊，或兩者兼有。Anthropic 表示，它會透過觀察開發人員是否修正發現、拒絕發現，或指出所報告行為屬有意為之，來評估留言質素。
更大的訊號在於組織層面。Anthropic 不再把人類閱讀每一行改動程式碼視為審查的決定性證明。它衡量的是整個系統是否能發現問題、妥善引導注意力，以及限制生產環境損害。
這個改變對每個部署編碼代理的工程組織均構成壓力。若代理產出增加而審查政策維持不變，佇列便會擴大，預期的生產力收益亦會消失。團隊必須限制生成，或重新設計驗證方式。
自動化覆蓋正挑戰全面人工檢查
核心競爭在於廣泛的機器覆蓋，與每項有意義改動都值得人類直接閱讀的信念之間。
全面人工檢查提供直觀承諾：合資格工程師理解程式碼、看過改動，並在軟件發布前承擔責任。這種做法能傳播知識，同時捕捉自動化測試遺漏的假設。
然而，當審查變得倉促時，這項承諾便會減弱。面對龐大佇列的人可能只會略看而非推理、批准看似熟悉的程式碼，或將注意力放在風格而非行為上。人類簽署並不保證真正理解。
Anthropic 的替代方案採用多個專門層次。一個代理撰寫改動，另一個以全新上下文審查，多個代理尋找錯誤，另有代理評估每項發現。安全審查、持續整合、合併檢查、分階段發布及回退則覆蓋不同失敗模式。
這類似縱深防禦。由於後續層次可捕捉前面層次遺漏的問題，沒有任何單一層次需要做到完美召回。風險分類其後把稀缺的人類判斷力導向潛在影響較大的改動。
這個機制亦讓 Anthropic 獲得更廣泛的審查覆蓋。機器可檢查每個 pull request，毋須等待同事的時間表。它們可檢視儲存庫上下文、套用已記錄的慣例，並在數以千計的改動中重複相同檢查。
儲存在 CLAUDE.md 的指示會描述專案、其慣例及邊界。獨立的 REVIEW.md 會告訴審查員特定儲存庫中的失敗模式。程式碼擁有者可識別敏感路徑，並排除不相關路徑。
當審查員反覆標示同一錯誤時，團隊可將教訓前移。它可以加入 lint 規則、改善指示檔、修改技能，或建立新的自動化檢查。審查回饋於是成為可重用的基建。
過去的失敗會成為評估案例。Anthropic 表示，它收集了與事故、回退及後續修正相關的 pull request。工程師驗證了底層錯誤，而審查員現時每天均會針對這些案例運行。
這與兩人之間會面式審查有明顯差別。系統嘗試把教訓保存在可執行檢查中，而非依賴個人記憶。每次事故都可擴大機構未來的偵測覆蓋範圍。
然而，人類審查仍會處理無法化約為局部正確性的問題。工程師會決定某項功能是否應該存在、某種抽象是否會開創有害先例，以及證據是否足以支持部署。
它們亦會檢視敏感範疇，包括帳單、更新機制、持續整合及發布流程。即使程式碼在本地看似正確，這些改動仍可能帶來廣泛影響。
因此，這個流程並非宣稱機器在每個層面都是更好的審查者。它把機器能夠重複完成的閱讀工作交給機器，同時把涉及目的、架構、不確定性及責任的決策交給人。
這種分工亦改變了工程技能的要求。工程師需要明確說明意圖、識別限制、設計驗證方法、解讀證據，以及察覺代理何時為錯誤目標作出最佳化。閱讀程式碼依然有用，但已不再是理解系統的唯一途徑。
Anthropic 的 Scion 團隊提供了一個相關例子。工程師表示，Claude 有時會採取低效率或過度防禦性的設計，只因這些設計符合局部模式。人員必須否決這些方向，因為他們理解系統層面的取捨。
「human in the loop」一詞可能掩蓋了這個角色。一個只會批准機器輸出的人，保障作用很弱；一個能界定邊界、選擇證據，並知道何時停止自動化的人，才能提供有意義的控制。
對其他機構而言，教訓不是移除審查者，而是區分機械式檢查與判斷。當人員仍保有對高後果決策及不明確證據的權限時，自動化覆蓋才會變得有價值。
Claude Code 審查如何避免無止境的代理迴圈
Anthropic 發現，若審查流程沒有明確設計為收斂，AI 作者與 AI 審查者可以製造無限工作。
更多審查並不必然更好。Anthropic 描述了一個 Claude Code pull request，於一夜之間經歷超過 50 輪審查及修正，最終由作者終止這個迴圈。
審查者並非每一輪都發現新的嚴重缺陷。Anthropic 利用版本記錄檢視重複出現的發現，並發現約 59% 涉及首次審查時已存在的程式碼。
代理持續找出更多舊問題，而非只評估新的修正。每項意見都觸發另一次修正、提交及審查。系統持續運作，卻沒有有效率地走向可接受的最終狀態。
這個失敗說明了 AI 程式碼審查的一項獨特風險。人只需數秒便可略過低價值建議；撰寫程式碼的代理則傾向照做，產生另一個 diff，令審查代理有更多材料可檢查。
Anthropic 因此加入收斂控制。三輪後，審查者會要求作者重新考慮方法。其後的審查會集中於新的 diff，而非反覆搜尋整項改動。
審查者亦會一次過報告整個相關缺陷類別。這讓作者能修正每個實例，而非在連續多輪收到類似意見。先前已提出的發現不應再次出現。
Anthropic 表示，這些改動改善了其內部審查週期。據報，經一輪審查及修正後便通過的 pull request 比例，由 65% 升至 78%。
據報，需要五輪或以上的 pull request 比例則由 8.9% 降至 1.5%。通過前的平均審查次數由 2.08 降至 1.32。這些指標仍屬公司自行報告，但它們回應了許多代理工作流程忽略的營運問題。
收斂很重要，因為自動化勞動並非沒有薪金便等於免費。每增加一輪都會消耗模型容量、延遲改動、產生更多程式碼，並增加後續檢查必須審視的材料。
當審查者對假設性威脅反應過度時，同樣問題也會出現。Anthropic 表示，對抗式審查可能變得短視，鼓勵過多驗證或複雜性。為找出可能失敗而最佳化的系統，可能會產生新的維護成本。
以風險為本的審查深度提供了一種控制方法。Anthropic 已普遍推出的 Code Review service，為常規及關鍵儲存庫支援不同審查級別。該公司表示，現時大多數審查可在六至十分鐘內完成。
不過，更快的審查者不能解決根本的管治問題。團隊仍須決定哪些發現重要、哪些路徑值得更深入檢查，以及可接受多少個週期。
審查指示亦可能成為隱藏的政策層。若 CLAUDE.md、REVIEW.md 或分類提示包含薄弱假設，代理便可能在整個儲存庫一致地套用這些假設。
一致性只有在規則正確時才有幫助。團隊需要為指引審查者的指示建立擁有權、版本控制、評估案例及審查。否則，自動化可在人類察覺前更快地擴大錯誤政策。
這正是共享工程背景變得重要之處。採用代理的機構需要保存架構決策、事故教訓及被否決方案的長久記錄。可搜尋的 engineering knowledge base 有助將這些背景保留至單一審查討論串以外。
Anthropic 的流程之所以有效，是因為它把審查者視為需要量度的系統。它追蹤準確度、雜訊、輪數、事故及開發者回應。安裝一個 AI 審查者而沒有這些回饋迴路，只會複製可見工具，卻錯過其營運模式。
Anthropic 的結果尚未證明甚麼
最有力的說法仍屬自行報告，而 Anthropic 尚未證明其結果可轉移至基礎設施、預算或失敗容忍度不同的團隊。
第一個不確定因素涉及量度。Anthropic 報告稱，合併的 pull request 增加逾一倍，而 revert 比例下降超過 40%。它沒有公開原始數據、絕對比率或事故嚴重程度分布。
revert 比例下降雖然令人鼓舞，卻仍可能掩蓋重要結果。團隊可以向前修正而非 revert、停用 feature flag，或容忍一項從未被冠以該標籤的回歸。revert 有用，但並不完整。
事故率提供另一道防線，但公開文章沒有提供詳細的事故序列。缺乏嚴重程度及曝露數據，外界無法判斷該流程是降低了風險，還是改變了處理失敗的方式。
90% 的作者撰寫比例同樣含糊。它沒有說明量度的是生成行數、獲接納行數、提交，還是另一種單位；亦沒有揭示最終程式碼之前投入了多少人類提示、編輯及迭代。
Anthropic 的環境特別有利於這種方法。該公司控制模型，可為並行審查者投入大量運算資源，並圍繞代理生成的工作負載開發內部基礎設施。
其員工亦會在公開發布前內部試用 Claude Code。新功能可經內部部署、latest channel，然後進入 stable channel。Feature flag 讓團隊無須完整部署便可停用某項行為。
營運醫療、金融、工業或安全關鍵系統的團隊，可能面對不同要求。快速回滾無法撤銷每一種後果。有缺陷的數據遷移、授權變更或外部行動，可能造成不可逆轉的傷害。
Anthropic 承認，不良合併仍須依靠作者、on-call 工程師、遙測及儀表板來偵測。當 revert 或事故上升時，它尚未具備會自動提高批准要求的 circuit breaker。
這個缺口很重要，因為風險分類可能過時。被標記為低風險的改動，可能與隱藏依賴項互動；一連串各自安全的改動，也可能產生危險的組合狀態。
安全性帶來另一項疑慮。Anthropic 使用自動化安全審查，但其自身風險材料說明了為何人類監督仍有必要。其 sabotage assessment 將模型監控描述為持續演變的控制措施，而非完整保證。
社群反應提出了有關成本及理解的更廣泛問題。一些開發者認為，Anthropic 能維持在其他地方未必合乎成本效益的審查模式；另一些人則憂慮，較少人閱讀 diff 會削弱團隊對程式碼庫的集體知識。
Anthropic 公開表示，Claude Code 團隊中沒有人維持對產品的完整心智模型。工程師需要相關子系統的解釋時，會改為要求 Claude 說明。
這種做法可以讓解釋保持最新，但亦造成依賴。若生成的解釋遺漏某項互動，工程師便可能根據不完整的地圖作決策。同一模型系列也可能重複它所審查程式碼中已嵌入的假設。
跨模型審查可帶來更多多樣性，但不會自動提升準確度。不同系統可能共享訓練模式，或因無關原因而失敗。重要的是獨立證據，而不只是不同的模型名稱。
這些問題都不會否定 Anthropic 報告的結果，但限制了這些結果所能證明的內容。該公司展示的是一套具詳細內容、方向性指標令人鼓舞的內部流程，而非人類程式碼審查的通用替代方案。
三個訊號將測試這個模式能否成立
下一項測試是：當零人手合併擴大、審查產品進入其他公司，以及競爭對手採取不同控制措施時，Anthropic 能否保持品質。
第一個訊號是 Anthropic 自身的批准政策。其現行流程容許指定的低風險改動，在自動檢查通過後，無須另一名人類審查者即可合併。
值得留意的是，這條界線會否擴展至更多產品程式碼。若 Anthropic 加入其工程師期望的 circuit breaker，自動升級處理可令更廣泛部署更可信。事故上升或重新採用更嚴格批准，則會削弱這個論點。
第二個訊號是採用自動化審查的外部機構所提供的證據。Anthropic 已為 Team 及 Enterprise 客戶推出 Code Review，讓不熟悉的儲存庫及工程文化接受更廣泛測試。
有用的指標不會是意見數量或已審查 pull request 的數量。團隊應報告獲接納的發現、漏網缺陷、誤報、審查延遲、人手投入及生產事故。
Anthropic 以外可比較的結果，將加強分層 AI 審查能夠擴展的說法。高雜訊、模型使用量不斷增加，或事故率維持不變，將顯示 Anthropic 的成功依賴其內部環境。
第三個訊號是競爭反應。OpenAI、GitHub、Google、Cursor 及其他 coding-agent 供應商，同樣面對生成程式碼與審查者能力之間的失衡。
它們的選擇將揭示以風險為本的審查會否成為共同模式。競爭系統可能傾向跨模型審查、更強沙盒機制、形式化驗證、儲存庫專屬評估，或更持久的人類批准。
開發者不應把這場討論簡化為 AI 能否找出 bug。實際問題是：一套完整的審查系統能否分配注意力、維持問責，並在每一層都漏掉某些問題時安全地復原。
對工程主管而言，當前行動是量度。在改變批准政策前，先建立審查時間、漏網缺陷、誤報、revert 比率及事故嚴重程度的基線。沒有這個基線，更快合併可能看似改善，實際卻只是把成本轉移到其他地方。
團隊亦應將可逆變更與不可逆變更分開處理。文件、標示為調整的介面變更及內部工具，所需的流程不應與身分驗證、帳單、遷移或發布基礎設施相同。
Anthropic Claude Code 的審查方式，為許多團隊不久後將面對的問題提供了一個具體答案。它把審查視為分層控制系統，而非證明有人逐行閱讀過程式碼。
該公司公布的數字令這個答案值得測試，但不應盲目照搬。如果你的 agents 明天令程式碼產出倍增，哪些證據能讓審查人員今天便可安心停止閱讀所有內容？
