Claude Code 團隊如何做程式碼審查：PR 數翻倍，撤回比例降逾四成
Claude Code 團隊公開內部的程式碼審查流程：把大部分閱讀交給 AI，以七層檢查層層把關，並依風險決定需要幾位人工核准。2026 年 6 月到 9 月，合併的 PR 數增加超過一倍，需要撤回的比例反而下降逾 40%。
Anthropic 於 2026 年 10 月 15 日在 claude.dev 部落格發表〈How the Claude Code team does code review〉，公開 Claude Code 團隊的程式碼審查流程。Claude Code 本身約 90% 的程式碼由 Claude 撰寫，他們的做法不是取消審查，而是把大部分閱讀交給機器、把人的時間留給只有人能做的判斷，並讓錯誤能快速復原。
核心觀念：該問「哪種檢查最適合抓這個問題」
AI 代理讓變更量暴增：Anthropic 主要 monorepo 每天落地的變更，從 2026 年 5 月約 2,500 個增加到 9 月超過 30,000 個，人工逐行審查已不可行。Claude Code 團隊認為，「有沒有人讀過程式碼」只是不精確的替代指標，真正該問的是：這個變更可能出什麼錯？哪一種檢查（自動或人工）最適合抓到它？
| 面向 | 過去 | 現在 |
|---|---|---|
| 審查時機 | 寫完、開 PR、等同事看 | 寫程式的同時持續進行，像拼字檢查 |
| 誰先看 | 同事逐行閱讀 | 多數變更在人看之前，已被 Claude 審查並修正至少一次 |
| 目標 | 有人讀過 | 多數 PR 最多一位人類參與（可以是作者本人），且撤回與事故不增加 |
七層把關：一個變更從筆電到使用者
| 層 | 開發者可以直接用的工具或做法 |
|---|---|
| 1. 先驗證再送審 | 測試、建置、設計截圖比對；要求 Claude 出示輸出，而不是只說「完成了」 |
| 2. AI 程式碼審查 | Code Review for Claude Code、/code-review |
| 3. 資安審查 | /security-review、開源的資安審查 GitHub Action |
| 4. 自動檢查 | CI；PR 範本要求寫明「如何測試」與「如何還原」 |
| 5. 人工核准 | 風險分級、分類器、信任名單（見下文） |
| 6. 合併與發布 | 合併佇列、功能旗標、latest 與 stable 兩個發布頻道 |
| 7. 偵測與回滾 | 每週輪值待命、撤回與事故儀表板 |
PR 之前：用 CLAUDE.md 與 REVIEW.md 從源頭修正
Claude Code 的建立者 Boris Cherny 認為，讓 Claude 有辦法驗證自己的成果，可能是取得好結果最重要的一件事，估計能讓成果好上 2～3 倍。當審查器一再標出同樣的問題，團隊會從源頭修正：改寫 Skill、加 lint 規則，或更新說明檔。
| 檔案 | 撰寫者 | 寫法重點 |
|---|---|---|
CLAUDE.md |
專案團隊 | 說明技術堆疊、慣例、目標與非目標。每次審查都會載入，大型專案要保持精簡，再指向其他文件 |
REVIEW.md |
程式碼擁有者 | 越短越好：定義此處的「失敗」、限制 nit 數量、列出略過的路徑、要求以檔案與行號為證據、摘要以數量開頭 |
以下是依原文要點整理的 REVIEW.md 範例骨架（非官方範本）：
# REVIEW.md
## 這個儲存庫的「失敗」長什麼樣
- 文件：內容與實際行為不符；設定：請求被導向錯誤的目的地
## 審查規則
- 每個發現都附上檔案與行號，不要只憑名稱推測
- Nit（小瑕疵）最多列出 <N> 項
- 略過路徑：<自動產生的檔案、第三方程式碼等>
## 摘要格式
- 第一行先寫發現的數量；沒有問題就直接寫「沒有需要修正的問題」
AI 審查與資安審查
- Code Review for Claude Code 已在 Team 與 Enterprise 方案正式推出，
/code-review可在本機執行較輕量的版本；研究預覽推出時，內部 PR 獲得實質審查意見的比例從 16% 升至 54%。 - 可替每個儲存庫設定 Quick、Standard 或 Deep；漏掉一個 bug 的代價高於多花的審查時間時，就值得用 Deep。
- 只要 bug 審查或資安審查還有未處理的發現，PR 就不能合併：修正它，或附上理由關閉（誤判就這樣排除）。
依風險決定人工核准人數
| 風險 | 例子 | 人工核准 |
|---|---|---|
| 低 | 文件、文案、僅供內部使用的功能、以功能旗標保護的新增型變更 | 自動審查與資安檢查都通過後，不需要 |
| 中 | 一般產品變更，以及快取、自動更新程式、系統提示詞等敏感區域 | 1 人 |
| 高 | 風險最高的程式碼，以及少數一律需要兩人的路徑 | 2 人 |
- 由變更決定等級，不看作者：分類器判定等級，第二個分類器再確認是否仍需要人看；敏感路徑與 CI workflow 檔一律需要人工。
- 輕量路徑只給受信任的作者；代理的核准永遠不能算成人的核准。
- 下指令的人要負責：代理寫的 PR，指揮代理的人就是一位必要審查者。
- 核准只對特定 commit 有效：代理推送或手動解衝突的新 commit，必須重新核准。
讓審查器更準，而且會收斂
雜訊也要量化：團隊依 PR 上的人如何回應（已修正、評論有誤、行為是刻意的、無關緊要）為每則評論分類，書面上的優先順序是先抓到真正的 bug，其次才是減少審查回合。
代理作者與代理審查者可能無止盡地來回：曾有一個 CLI PR 一夜之間跑了超過 50 輪審查與修正。用 git blame 分析審查器反覆標出的內容，約 59% 是第一輪就已存在的程式碼，它只是每輪多找到幾個舊 bug。團隊因此做了以下調整：
| 調整 | 做法 |
|---|---|
| 回合上限 | 三輪之後，審查器請作者退一步，重新考慮做法 |
| 只審新 diff | 前幾輪之後，重新審查只看新增的 diff |
| 標出 bug 類型 | 讓作者一次修掉所有同類寫法，而不是只改一行 |
| 不重複 | 已張貼過的發現不再重複 |
人的注意力該放在哪裡
| 做法 | 說明 |
|---|---|
| 用 AI 說明取代逐行閱讀 | 想理解某段程式碼，就請 Claude 針對那一塊寫說明，幾分鐘就好，而且反映當下的程式碼；逐行讀一行文案修改，幾乎學不到東西 |
| 誰合併，誰負責 | 變更保持小、一切可逆、依影響範圍設門檻；由最有脈絡的人修正，事故檢討針對系統而不是個人 |
| 方向不對，及早說 | 在討論串中早點提出不同方向，而不是等 PR 完成後才留下阻擋合併的評論 |
請 Claude 為模組寫說明的範例提示詞：
我接下來要修改 <模組或功能名稱>。請閱讀相關程式碼，寫一份說明：它負責什麼、主要的執行流程、相關檔案的位置，以及修改時需要注意的地方。
開發者如何導入：四階段清單
- PR 之前：在精簡的
CLAUDE.md列出可執行的檢查，用 hooks 自動跑格式化與 linter；本機執行/code-review、/security-review；新增REVIEW.md，把反覆出現的審查意見寫進去。 - 每個 PR：要求 CI 通過；PR 範本加上「測試方式」「風險」「如何還原」；導入 AI 審查與資安審查，討論串全部解決才能合併；限制審查回合數。
- 核准：寫下風險分級，先嚴後鬆；用 CODEOWNERS 與分支保護，讓身分驗證、計費、CI 與發布流程、安裝程式一律需要人工；有新 commit 時撤銷既有核准。
- 合併與之後：合併佇列、功能旗標、內部先用、分階段發布與一步回滾；把事故與撤回整理成評測集；以撤回率與事故率作為護欄。
延伸閱讀
- claude.devHow the Claude Code team does code reviewclaude.dev 部落格原文
- ClaudeCode Review - Claude Code DocsCode Review for Claude Code 官方文件
- ClaudeBest practices for Claude Code官方最佳實務：驗證與子代理審查
- ClaudeAutomated Security Reviews in Claude Code
/security-review與 GitHub Action 設定說明 - AnthropicRedesigning source control at AnthropicAnthropic monorepo 變更量暴增的背景
- 本站文章Uncle Bob 的 AI 開發法：不看程式碼，但嚴格把關結果
- 本站文章新的軟體開發生命週期：從「語法工匠」到「AI 代理指揮官」