Anthropic 針對 Claude Code 採用七層堆疊的程式碼審查系統，顯著提升了程式碼品質與開發效率。本文將其複雜流程簡化，提供小型團隊可快速導入的五個核心層級，透過 GitHub 分支保護、精簡的 REVIEW.md 和 CI 工作流程，實現高效的 AI 輔助程式碼審查。
Anthropic 透過七層堆疊的系統審查 Claude Code 的程式碼，而一個由一到十人組成的小型團隊，本週即可利用 GitHub 分支保護、簡短的 REVIEW.md 檔案和一個 CI 工作流程，複製其中五個層級。根據 Anthropic 於 2026 年 10 月 15 日發布的報告，經過單輪審查與修正後通過的內部 PR 比例從 65% 提升至 78%，需要五輪以上審查的 PR 比例從 8.9% 降至 1.5%，平均通過審查所需的輪次也從 2.08 降至 1.32。
Claude Code 自身約有 90% 的程式碼是由 Claude 編寫，因此這套審查系統對於確保程式碼安全至關重要。
Anthropic 的審查系統中有兩個層級是小型團隊無法複製的，分別是風險分類器和在 Anthropic 規模下使用的分階段發布通道。以下將介紹這七個層級、一個對應表格、一個入門級的 REVIEW.md 範本、風險分級的經驗法則、確切的 GitHub 設定以及相關的權衡考量。
簡而言之，Anthropic 的層級包括：自我驗證、每個 PR 的 AI 審查、阻擋式安全審查、阻擋式檢查、依風險分級的人工審批、合併佇列加上功能旗標與分階段發布，以及快速回溯。
報告的結果為內部數據，且未提供樣本數：單輪通過率從 65% 提升至 78%，五輪以上審查的比例從 8.9% 降至 1.5%。小型團隊可以從分支保護、依路徑和大小劃分的風險層級規則、REVIEW.md 檔案以及回溯開關中獲得大部分價值。託管的程式碼審查產品適用於團隊和企業方案，Anthropic 的文件指出它本身從不批准或阻擋 PR，而是由你的 CI 負責阻擋。
以下標註「Anthropic 報告」的內容均來自他們的文章。標註「我的建議」的內容則是我個人的建議，尚未在 Anthropic 的規模下進行測試。Anthropic 實際報告的內容描述了一個目標和一個防護措施。目標是大多數 PR 在最多一名人工參與的情況下合併，防護措施是回溯和事故的數量不得增加。
Anthropic 報告指出，從六月到九月，合併到 Claude Code 程式碼庫的 PR 數量增加了一倍以上，而必須回溯的 PR 比例下降了 40% 以上。在更廣泛的單一儲存庫中，每日提交的變更從五月的約 2,500 次增加到九月的 30,000 多次。這些是該公司自己的數據。該文章沒有提供樣本數，也沒有 Anthropic 以外的人進行驗證，因此應將其視為一個方向，而非基準。
有用的部分是其結構，它由七個層級組成，每個層級都會捕捉到前一個層級遺漏的問題。以下是 Anthropic 描述的七個層級：
在任何人審查之前進行驗證。Claude 執行測試、建構或螢幕截圖比較，並由一個具有全新上下文的子代理審查差異。
每個 PR 的 AI 審查。多個代理平行搜尋錯誤，驗證者對每個發現進行投票，只有足夠驗證者同意的發現才會被發布，並標記為「重要」、「小問題」或「既有問題」。
可阻擋的安全性審查。當錯誤審查或安全性審查中的任何發現仍未解決時，PR 無法合併。
自動化阻擋檢查。每個平台上的 Lint、型別檢查、測試和建構。一個典型的 CLI PR 可能會執行數十項檢查。
依風險分級的人工審批。更多細節請見下文。
合併佇列、功能旗標和漸進式發布。佇列會針對 main 分支重新執行檢查，新功能會先透過功能旗標發布給員工，公開發布則會先進入最新通道，然後才進入穩定通道。
快速偵測與回溯。功能旗標無需部署即可關閉，並且有每週輪值的待命人員。
人工審批如何分級
一個分類器會讀取變更並選擇風險層級，因此層級取決於變更所觸及的內容，而非由誰編寫。低風險變更（文件、文案、僅限內部功能、透過旗標新增的變更）在自動化審查和安全檢查通過後，無需人工審批。中風險變更（一般產品變更以及快取、自動更新器或系統提示等敏感區域）需要一人審批。高風險變更需要兩人審批。第二個分類器即使在層級不要求的情況下，也可以強制要求人工審批。
文章中有三條規則值得逐字複製其精神：代理的批准永遠不計為人工批准。對於代理編寫的 PR，指導代理的人員計為所需的審查者之一。批准涵蓋一個特定的提交，因此在批准後進行的推送應重置批准狀態。
層級對層級：小型團隊的替代方案
此表格是我的建議。前兩欄是 Anthropic 報告的設計；後三欄則是我認為一到十人團隊可以做到的事情以及何時可以跳過。
| 層級 | Anthropic 版本 | 小型團隊版本 | 工作量 | 何時跳過 |
|---|---|---|---|---|
| 1. 自我驗證 | Claude 執行測試，並由具新上下文的子代理審查差異 | 在 CLAUDE.md 或自訂子代理中寫入「在開啟 PR 前執行測試指令和差異審查子代理」 | 30 分鐘 | 如果你不使用代理來編寫程式碼 |
| 2. 每個 PR 的 AI 審查 | 多代理審查與驗證者投票 | 在 Team 或 Enterprise 方案中，使用託管的程式碼審查。否則，在本地執行 /code-review 或在自己的 CI 中執行 Claude | 1 小時，加上使用成本 | 如果 PR 少於約 20 行，且你逐一閱讀每個 PR |
| 3. 阻擋式安全性審查 | 未解決的發現阻擋合併 | 在 CI 中執行 /security-review 或安全性任務，並將該任務設為必要的狀態檢查 | 1 到 2 小時 | 如果儲存庫中沒有身份驗證、支付、檔案上傳或機密處理 |
| 4. 阻擋式檢查 | 每個 CLI PR 數十項檢查 | Lint、型別檢查、單元測試、建構作為必要的狀態檢查 | 如果缺少，半天 | 永遠不要。這是最便宜的層級 |
| 5. 依風險分級的人工審批 | 分類器選擇 0、1 或 2 個人 | 依路徑和大小規則選擇 0、1 或 2 個人（見下文） | 2 小時 | 如果你是獨立開發者：層級控制你的謹慎程度，而非誰批准 |
| 6. 合併佇列、功能旗標、分階段發布 | 佇列加上員工旗標，然後是最新通道再到穩定通道 | 如果 main 分支經常中斷，則使用合併佇列；針對高風險工作使用一個功能旗標；先部署到預備環境或金絲雀發布 | 1 天 | 如果你很少部署，且能在幾分鐘內重新部署 |
| 7. 偵測與回溯 | 無需部署即可關閉旗標，每週待命 | 錯誤警報、一個你實際執行過的一鍵回溯指令、本週指定的待命人員 | 2 小時 | 永遠不要 |
如果你只能做三件事，請選擇層級 4、5 和 7。必要的檢查、風險規則和經過實踐的回溯機制，比任何 AI 審查者更能防止損害。
小型團隊設定，逐步說明
步驟 1：編寫一個簡短的 REVIEW.md
Anthropic 表示 REVIEW.md 由程式碼擁有者編寫，並告知審查者在程式碼的哪個部分需要注意。該文章建議保持簡短，說明在你的儲存庫中失敗的樣子、限制小問題的數量、列出要跳過的路徑，並要求提供檔案和行號作為證據，而不是從名稱猜測。
根據 Claude Code 文件，託管審查會從基礎或預設分支讀取 REVIEW.md，而不是從 PR 自己的變更中讀取。這很重要：PR 無法重寫其自身的審查者指令。
這是我為一個典型的網路應用程式編寫的入門範本。編輯第一部分以符合你的儲存庫中會出現的問題。
```
```
將其與涵蓋程式碼編寫方式的 CLAUDE.md 搭配使用。我在「CLAUDE.md 規則在生產環境中存活」中涵蓋了在生產環境中存活的內容。REVIEW.md 是審查者的簡報；CLAUDE.md 是作者的簡報。
步驟 2：新增一個你可以計算的風險層級規則
Anthropic 使用分類器。你可以從檔案路徑和差異大小獲得一個不錯的初始版本。這是我的建議，不是 Anthropic 的規則，你應該在一個月的數據後調整這些數字。
| 層級 | 經驗法則 | 批准數 |
|---|---|---|
| 低 | 僅限文件、文案、測試或配置註釋；或非敏感路徑中變更行數少於 30 行；檢查通過 | 0，在檢查通過和 AI 審查乾淨後 |
| 中 | 其他所有情況，最多約 400 行變更 | 1 人 |
| 高 | 涉及身份驗證、支付、遷移、部署工作流程、機密處理，或超過約 400 行 | 2 人，或 1 人加上作者現場走查 |
在一個三人團隊中，「2 人」可能意味著作者是其中之一。如果你遵循 Anthropic 的規則，即指導代理的人員計為所需的審查者，且 AI 永遠不計為人工，這是可以的。如果你不想手動建構層級腳本，WOWHOW AI Code Review Pipeline Kit 包含一個 REVIEW.md 範本、一個路徑和大小風險層級分類器、一個 GitHub Actions 批准閘門和一個發現解析器。本文中的所有內容都可以在沒有它的情況下運作。
步驟 3：設定 GitHub 分支保護使其生效
一個沒有人執行的規則只是一個建議。在 GitHub 的受保護分支設定中，這些選項對應到各個層級：
在合併前要求拉取請求審查，將所需批准數設為你的預設分支上的 1。GitHub 目前的 UI 可能會將此標記為「在合併前要求拉取請求」；我檢查的頁面使用第一種措辭。
在合併前要求狀態檢查通過，勾選「要求狀態檢查通過後才能合併」的核取方塊。按名稱新增 lint、型別、測試、建構和你的安全性任務。
要求分支在合併前保持最新，以便檢查針對當前的 main 分支運行。
當新的提交被推送時，取消過時的拉取請求批准。這個設定讓你實現 Anthropic 的「一個批准涵蓋一個特定的提交」。
如果 main 分支經常中斷到足以證明其合理性，則要求合併佇列。
透過 CODEOWNERS 檔案為你的高風險路徑進行程式碼擁有者審查，這樣這些路徑就需要指定的擁有者。GitHub 將規則集視為與傳統分支保護不同的功能。兩種方式都有效；使用其中一種，而不是兩者都用，以避免規則衝突。
高風險路徑的兩次批准規則並不存在單一核取方塊。分支保護將一個批准計數應用於整個分支。要實現層級，請為敏感路徑使用 CODEOWNERS，或運行一個小型工作流程，該工作流程讀取已更改的檔案，計算層級，並在足夠的批准存在之前使必要的檢查失敗。該工作流程是整個設定中唯一的自訂程式碼。
步驟 4：決定 AI 審查在哪裡運行
你有四個選項，文件並排列出了它們：
託管的程式碼審查，適用於使用 GitHub 儲存庫的 Team 或 Enterprise 方案組織，由擁有者開啟。審查在 Anthropic 基礎設施上運行，並提供快速、標準和深度層級。
在你自己的 Claude Code 會話中執行 /code-review，適用於任何方案。
透過 GitHub Actions 或 GitLab CI/CD，使用 API 金鑰在你自己的 CI 中執行 Claude。
你自己的審查者作為子代理或技能。
有一個細節會讓人困惑。Anthropic 的文章說其內部設定會阻擋合併未解決的發現。公開文件說託管審查從不批准或阻擋 PR，其檢查運行也不會以失敗告終。因此，如果你想要阻擋式發現，你需要自己建構它：在 CI 中運行一個安全性任務，該任務在發現問題時失敗，並將其設為必要的狀態檢查。該文章沒有提供定價，我也不會引用任何定價；在許多儲存庫中開啟它之前，請檢查程式碼審查成本頁面。
步驟 5：讓回溯變得無聊
層級 7 是小型團隊經常跳過，但卻能拯救一個週五夜晚的層級。選擇一個你可以用一個指令執行的回溯，本週在預備環境中執行一次，並寫下本週的待命人員。如果你透過功能旗標發布，請測試關閉它是否確實移除了該行為。將此與模型本身的迴歸檢查搭配使用；WOWHOW 在 20 項任務評估金絲雀中為此建構了一個，並且模型迴歸金絲雀套件中包含了它。
誠實的權衡
AI 審查在調整之前會很嘈雜。Anthropic 的
覺得值得一看？分享給朋友。
以上為 AI 自動翻譯導讀。原文版權歸 DEV Community (Claude Code) 所有， 建議透過「閱讀原文」前往原始網站，以取得最完整資訊並支持原作者。
43 個來源、每 2 小時更新，太多看不完。電子報每週挑最值得看的幾則，附上 Max 的看法。
