For AI agents: the public content index is available at https://we0.ai/llms.txt, and the English article bundle is available at https://we0.ai/llms-full.txt.
For AI agents: the public content index is available at https://we0.ai/llms.txt, and the English article bundle is available at https://we0.ai/llms-full.txt.
For AI agents: the complete content index is available at https://we0.ai/llms.txt, the full English article bundle is available at https://we0.ai/llms-full.txt, and this page is available as Markdown at https://we0.ai/zh-HK/articles/claude-code-review-ai-checks-human-approv-629ae884.md.
Anthropic 表示，Claude 約撰寫了 Claude Code 自身 90% 的程式碼。其工程團隊進一步提出一個問題：當代理程式產生變更的速度快於人員閱讀變更的速度時，團隊應該如何進行審查？
Anthropic 表示，Claude 約撰寫了 Claude Code 自身 90% 的程式碼。其工程團隊進一步提出一個問題：當代理程式產生變更的速度快於人員閱讀變更的速度時，團隊應該如何進行審查？
答案是一套分層流程：將例行檢查提前，使用代理程式調查錯誤，並將人員注意力保留給風險更高的決策。Anthropic 表示，從 6 月到 9 月，已合併的 pull request 數量增加了一倍以上，而需要回退的變更比例則下降了超過 40%。
這些觀察描述的是一個團隊的流程。90% 這個數字指的是程式碼作者身分，而不是可以繞過人員審查的變更比例。必要的人員核准仍然不能由代理程式提供。
團隊將逐行由人員閱讀程式碼視為發現問題的一種方式，而不是審查本身的目標。更好的問題是：一項變更會引入哪些失效模式，以及哪些檢查可以偵測這些問題？
這會讓審查從 pull request 建立後的一道單一關卡，轉變為持續進行的活動。測試、建置，以及具有全新上下文的代理程式審查，都可以在打斷另一位工程師之前發現問題。
成本計算同時包含審查時間與修復事故所需的時間。如果失敗只是被推遲到下游，減少核准就不算成功的最佳化。因此，回退率與事故率會和人員留言數、核准數及等待時間等指標一起充當防護欄。
Anthropic 的獨立 monorepo 從 5 月每日約 2,500 個已合併變更，增長到 9 月的超過 30,000 個。Claude Code 擁有自己的儲存庫；這些 monorepo 數據不應直接歸因於 Claude Code 的程式碼庫。
提供的報告著重介紹一套七層流程中的三個階段。官方文章則提供了完整順序：
根據提供的報告重製的翻譯工作流程圖；官方文章提供英文原圖。
在 PR 建立前，證據比代理程式聲稱任務已完成更重要。測試指令及其輸出，或經過設計稿比對確認的螢幕截圖，都能為審查者提供可檢查的內容。反覆出現的問題之後可以轉化為 lint 規則、技能，或寫入 CLAUDE.md 與 REVIEW.md 的簡潔專案指示。
AI 審查者聚焦於實質性缺陷，而不是無限制地提供風格建議。Anthropic 表示，在研究預覽期間，收到實質性留言的內部 PR 比例從 16% 上升到 54%。留言可以將既有問題單獨標示出來，避免讓人誤以為每個發現都是由新變更引入的。
| 風險等級 | 團隊所述的內部核准政策 |
|---|---|
| 低 | 在適用的自動化檢查通過後，無須人員核准，但仍受信任度與路徑規則約束。 |
| 中 | 需要一名人員核准。 |
| 高 | 需要兩名人員核准。 |
敏感路徑與 CI 工作流程檔案有額外要求。只有受信任的作者符合較寬鬆的流程；其他貢獻者需要另一名人員核准。分類器會評估變更本身，而不只是信任提交者的身分。
對於由代理程式撰寫的工作，指揮代理程式的人會被視為負責任的審查者。代理程式的核准永遠不能填補要求由人員提供的核准名額；如果後續提交變更了原本審查的內容，核准也可能需要重新取得。
團隊內部的無人員核准流程，也不同於公開的審查產品。該產品會發布發現，但不會獨立提供儲存庫規則所要求的人員核准。
某個 CLI pull request 在一夜之間經歷了超過 50 輪審查與修復，最後由負責人停止流程。代理程式作者會修復一則小型留言、產生新的提交，並觸發審查代理程式，而後者又發現另一個問題。
團隊的回溯檢查發現，反覆被標記的程式碼中約有 59% 在第一次審查時就已經存在。後續輪次通常是在發現更多舊問題，而不是發現每次修復新引入的缺陷。
修訂後的流程將一般審查迴圈限制在三輪，之後要求作者重新考慮實作方式。後續輪次也會縮小到新 diff、抑制重複發現，並要求作者處理一整類錯誤，而不是一次只處理一個個案。
輸入一句想法，We0 AI 即可生成展示站、頁面與 CMS。發佈上線後並幫你獲取客戶和流量。
用戶註冊贈送一次完整項目生成
適合先體驗一次完整生成流程，快速看到專案初稿。
| 內部指標 | 變更前 | 收斂流程變更後 |
|---|---|---|
| 經一輪審查與修復後通過 | 65% | 78% |
| 至少需要五輪 | 8.9% | 1.5% |
| 通過所需的平均審查次數 | 2.08 | 1.32 |
Anthropic 的內部測量數據，根據來源報告重製。
發現更多留言不等於讓審查變得更好。Anthropic 會使用經專家確認的事故案例與已知無問題的變更來測試審查者，同時追蹤遺漏的錯誤與有害的誤報。
人員仍然負責決定某項功能是否應納入產品、審查影響重大的架構，以及檢查計費、CI 和更新程式等高風險區域。他們也需要了解自動化檢查可能遺漏哪些問題。
作者與值班工程師會在合併後觀察結果。功能旗標、內部使用與分階段發布通道可以讓復原更容易，但它們無法消除事故。官方文章表示，在指標惡化時收緊核准要求的自動斷路器，仍是期望改進的方向。
持續不變的責任，是對已發布變更的所有權。更快的實作速度讓團隊更容易捨棄不必要的 PR，但這並不會把決定哪些內容應該發布，轉移給未經檢查的審查迴圈。
不是。作者身分與核准是兩個不同的指標。內部流程會依風險調整人員審查，並對指定的變更與路徑保留強制核准要求。
官方文章明確表示不可以。自動化審查可以讓符合條件的低風險工作通過，但不能佔用指定由人員提供的核准名額。
代理程式會調查不同的潛在缺陷，獨立的驗證代理程式則會評估這些發現。這能在留言傳給作者前增加一層檢查，但代理程式之間達成一致，也不代表每個發現都是正確的。
無限制的作者與審查者迴圈可能會消耗時間，同時反覆發現舊問題。限制輪次可以促使團隊重新考慮實作方式，而不是自動繼續相同的循環。
這是指 6 月至 9 月期間，需要回退的已合併 Claude Code PR 比例之相對降幅。這並不是宣稱所有軟體缺陷都下降了 40%。
先建立可驗證的檢查、明確的風險規則與可靠的回滾機制。在減少必要的人員參與前，應同時衡量審查投入、事故與回退情況。
Claude Code 團隊結合了提前驗證、多代理程式審查、安全性檢查、明確的核准規則與快速復原。同時，團隊也限制審查迴圈，避免代理程式彼此持續忙碌，卻沒有改善變更。
自動化改變了誰來閱讀 diff；人員仍然對決策與結果負責。
從一句話開始，幾分鐘內拿到完整網站。
