Claude Code 團隊如何進行程式碼審查

我們之前已說過，Claude 會撰寫約 90% 的 Claude Code 自己程式碼。那麼我們如何在產量如此龐大的情況下進行程式碼審查？還有人閱讀程式碼嗎？若程式碼出錯，誰會發現？

本文說明 Claude Code 團隊的程式碼審查流程以及其演變。從六月到九月，合併到 Claude Code 程式碼庫的 pull request 數量翻倍以上，而需要回滾的比例下降了 40% 以上。

我們並未取消審查。但我們已將大部分閱讀工作交給機器，並最佳化以節省人力與注意力，同時投入大量資源使流程快速且易於撤銷錯誤。

重新思考程式碼審查的目的

當代理程式撰寫程式碼時，變更數量會迅速增加。在 Anthropic 的 monorepo 中，每日落地的變更量從五月的 2,500 次增至九月的 30,000 以上，今年已大幅提升。

Claude Code 以獨立的倉庫運作，與 monorepo 分離，但同樣面臨巨大壓力。當交付速度如此之快時，手動逐行審查程式碼幾乎不可能完成。

程式碼審查有兩個工作：

在程式碼發布前發現並修復問題
在團隊中建立共同的上下文與程式碼庫理解

本文主要聚焦於發現並修復問題，但我們將在結尾回顧第二項工作。

我們認為「有人閱讀了程式碼嗎？」是一個不精確的代理，用來衡量「這次變更可能出現什麼問題，以及自動化檢查或人工檢查哪一個最適合捕捉它？」

提出這個問題也改變了何時進行審查。以前，審查是道路盡頭的門檻：編寫程式碼、開啟 PR，等待同事。

現在，審查持續進行，類似於寫作時的拼字檢查。大部分變更至少被 Claude 在人類審查前審查並修正一次。這能捕捉大多數日常錯誤，並將團隊注意力留給更高層次的問題與審查。

稀缺資源：人力與注意力

我們希望將人力與注意力保留給只有人類能解決的問題，同時確保自動化檢查捕捉其餘問題。以目前的變更速度，人類仍有大量工作要做，我們的團隊幾乎每天都面臨新的挑戰。

人力時間涵蓋審查成本的兩個面向：人員花在審查上的時間，以及修復程式碼錯誤所花的時間。若只削減第一項，若第二項仍然存在，則無法節省人力。

因此，我們的目標是讓 Claude Code 倉庫（CLI、桌面與網頁應用程式，以及行動應用程式）的 pull request 大多數在最多一個人參與的情況下合併，該人可為作者，且不會增加回滾或事故率。為衡量人力，我們追蹤每個 PR 的人類批准（中位數與 95 分位數）、人類評論，以及 PR 等待人員的時間。回滾與事故率是安全閥：若其上升，我們並未節省人力，僅是移動了人力。

變更的生命週期

典型的變更，從工程師的筆記型電腦（或 Slack 中的 Claude 會話）開始，會經過多層程式碼審查。

變更的生命週期

典型的 Claude Code 變更，從作者機器到使用者

圖 A大部分流程為自動化；人員的注意力聚焦於風險所在

層層檢查

多層檢查，而非單一門檻

六層檢查，並配備回滾機制

圖 B每一層都能捕捉部分問題，但仍有遺漏。很少能通過所有層，回滾機制處理其餘問題。

1. 工作在任何人檢視之前已被驗證

大部分審查現在在 PR 存在之前完成。我們給 Claude 可以執行的東西——例如測試、建置或截圖以對照設計——並請它顯示輸出，而不是說已完成。接著子代理會在新的背景下審查差異。這兩個習慣來自我們的最佳實踐指南。

在開啟 PR 之前，我們許多人還會執行幾個內部技能：一個尋找錯誤，一個簡化差異，還有一個端對端檢查行為。UI 變更也會根據我們的設計指南進行檢查。

建立 Claude Code 的 Boris Cherny 認為，讓 Claude 能夠驗證其工作是最重要的事，以取得良好成果。他估計這會使最終結果提升兩到三倍，並寫道：「驗證在每個領域看起來都不同。它可能僅是執行一個 bash 指令、執行測試套件，或在瀏覽器或手機模擬器中測試應用程式。」

當自動審查者持續標記同一專案時，我們在源頭修正： 在技能中、透過 lint 規則，或更新說明檔案，例如：

CLAUDE.md 告訴 Claude 這個專案是什麼：技術棧、慣例、目標與非目標。每一次審查都會載入它，因此在大型程式碼庫中我們保持簡短，並從中指向其他檔案。審查者也會標記違反其中慣例的程式碼，以及使其內部某行過時的變更。
REVIEW.md（由程式碼擁有者撰寫）告訴審查者在其程式碼區塊中重要的事項。我們會單獨檢查審查者是否真的遵循它。好的檔案簡短明確。它說明在該倉庫中失敗的樣貌（對檔案而言是「它說謊」；對設定而言是「它路由錯誤」），限制 nit，列出要跳過的路徑，並要求提供檔案與行號作為證據，而非僅憑名稱猜測。它們還會要求一個以數量開頭、明確說明無需修正的摘要。

2. 每一次拉取請求都進行 AI 審查

每一次拉取請求在有人檢視前都會接受 Claude 審查。它會將差異與整個倉庫及 PR 的目標對照，並詢問：此變更是否解決其問題、是否符合系統，或是否破壞其他功能？

在修復錯誤時，它會尋找根本原因。公開版本，Code Review for Claude Code，現在在 Team 與 Enterprise 計畫中普遍可用，且 /code-review 在本機執行較輕量的版本。

當我們啟動研究預覽時，內部 PR 獲得實質審查評論的比例從 16% 提升至 54%。大多數超過 1,000 行的 PR 會得到發現，而大部分小型 PR 則保持乾淨。管理員為每個倉庫設定 Quick、Standard 或 Deep。當漏掉一個錯誤的成本高於額外審查時間時，Deep 是值得的。

在人工審查前，發現會先由其他代理進行驗證。幾個代理同時尋找錯誤。接著另一組會對每項發現投票，只有足夠人同意其真實性時才會發布。僅關於風格、診斷或清理的發現會被丟棄。我們在自己的 PR 上對這些過濾器進行 A/B 測試後才保留。剩下的以內聯評論形式顯示，按嚴重程度排序。每條評論都標記為 Important、Nit 或 Pre-existing，讓 PR 未引入的錯誤不會被誤認為作者的過錯。

每項發現必須得到回覆。 你要麼修正它，要麼用理由結束討論。通常代理會在夜裡修復，作者回來時，PR 已經經過另一輪。

3. 可阻擋的安全審查

安全也會有自己的自動審查。只要 bug 審查或安全審查中仍有發現，PR 就無法合併。你要麼修正它，要麼以簡短理由結束討論，這樣就能清除偽陽性。

如果後續提交修正了問題，發現會自動消失。你可以使用開源安全審查 GitHub Action 或 /security-review 指令來設定同樣的功能。設定說明請參閱 Claude Code 中的自動安全審查。

4. 可阻擋的自動檢查

通常包括：lint、型別檢查、跨平臺測試以及建置。(我們已在此處撰寫關於擴充 CI 的文章。) 一個典型的 CLI 拉取請求在任何人檢視前可能會執行數十項檢查。PR 範本會詢問變更如何測試以及如何還原。Claude 可以填寫，但提出變更的人必須簽署確認。

5. 依風險分級的人員審批

檔案修正與自動更新程式變更風險不同，因此會接受不同的審查。

風險	範例	人員審批
低	檔案、複製、僅內部使用的功能、隱藏旗標後的增量變更	一旦自動審查與安全檢查綠燈，即不需要人員審批
中	普通產品變更，以及對敏感區域（如快取、自動更新程式或系統提示）的變更	一人
高	最高風險程式碼，以及始終需要兩人審批的少量路徑	兩人

變更決定風險等級，而非作者。 分類器會閱讀變更並挑選其風險等級。第二個分類器則會詢問，即使等級表示不需要，該變更是否仍需另一人審批。某些路徑永遠需要人員審批，任何被所有者列為敏感的專案以及任何 CI 工作流程檔案。

只有受信任的作者才可使用較輕的審批路徑。 只有倉儲受信任列表中的作者（主要是負責團隊）才可使用輕量化路徑，其他人都需要第二位人員審批。代理的審批也不算作人員審批。自動審查可清除低風險變更，但無法取代需要人類審批的空位。

促發變更的人負責此變更。 在代理撰寫的 PR 中，指揮代理的人算作所需審核者之一，與其親自編寫程式碼相同。

審批僅適用於特定提交。 若有新的提交系統無法驗證，例如代理推送或手動合併，審批必須重新給予。

6. 合併佇列、旗標與漸進式發布

合併佇列會在主分支上重新執行所有檢查，並套用變更，因此兩個分別通過的 PR 不能合併成破壞主分支。新功能通常先在旗標後提供給 Anthropic 員工，且我們大量使用往往在使用者之前就暴露回歸。公開發布首先送至 latest 頻道，stable 頻道則跟進。

7. 快速偵測、快速回滾

仍有部分錯誤會漏過，因此最後一層重點是快速捕捉。旗標可在不部署的情況下關閉。Claude Code 進行每週值班輪替，事故審查會詢問哪一層應該偵測到問題。

發現不良合併仍取決於作者、值班人員以及回退和事故儀錶板。我們尚未擁有在這些數值變動時加緊審批的斷路器；工程師們希望在更多程式碼進入零人審查前就先擁有它們。

同事說放慢速度確實能降低錯誤率，但大多是因為你做得更少。我們寧願更快地發現並修正問題。

我們如何讓審查者更好

我們的程式碼審查流程不斷迴圈改進。

任何事件現在已成為評估專案。 團隊收集過去導致事故的 PR，並附上其修正和回退，讓熟悉該程式碼的工程師確認每個錯誤及其所在位置。審查者每天對這組資料進行檢查。

我們的事故即為評估

由過去事故與回退構建，每日執行

FIG C評估隨每次事件成長，且每一次審查者的變更都會對整體進行評分。

我們透過觀察人員對評論的處理方式來衡量噪音。 如果你不介意標註大量非錯誤，捕捉更多錯誤就更容易，因此我們需要對此進行檢查。我們將審查者留下的每條評論按 PR 負責人回應的方式分類：他是否修正、指出錯誤、說明行為是有意為之，或認為無關緊要。我們也在已知乾淨的 PR 上執行審查者，統計它報告的事項有多少會導致有人做出有害改動。我們的優先順序已寫下：先捕捉真正的錯誤，再減少審查回合。

噪音成本在作者是代理時更高。人類可以在幾秒內忽略一個小瑕疵，而代理則會修正，產生另一個提交和另一輪審查。

審查必須收斂。 代理作者與代理審查者可無限期互相佔用。一個 CLI PR 經過超過五十輪審查和修正，直至作者停止。

我們對審查者持續標記的程式碼執行 git blame，發現約 59% 的程式碼自審查者第一次通過以來就已存在。審查者很少發現新錯誤，而每輪僅多找出少量舊錯誤。

我們自己把情況搞得更糟。由於每輪都能抓到新東西，我們習慣預設跑數輪。這對高風險變更可能有價值，但並非對每個 PR 都適用。團隊現在同時追蹤通過回合數與召回率，並改進重審流程：

回合上限。 連續三輪後，審查者請作者退後一步重新考慮方案。
僅差異重審 在前幾輪之後。
標示錯誤類別， 讓作者一次修正所有例項，而非僅一行。
不重複 已發表的發現。

審查代理也會在夜間對現有程式碼進行掃描，協助我們在錯誤再次出現前先行捕捉。

收斂式審查

內部拉取請求，收斂前後

FIG D收斂改動後每個內部拉取請求的審查回合數減少

人類仍留在迴路中

將資深工程師從深度工作中抽離來捕捉日常錯誤，成本遠高於自動審查。在 Anthropic，我們的工作已從閱讀每個差異轉向機器不擅長的決策：

我們真的要建這個嗎？ Direction, taste and scope. 一個宣稱已解決審查瓶頸的團隊仍保留對外部變更的人為審查，因此有人會問 \"我們真的要做這件事嗎？\"
風險程式碼 如帳單、auto-updater 以及 CI 工作流程。
架構設定一個其他人會複製的模式。
閱讀證據。 測試輸出、執行的指令以及回傳結果、螢幕截圖、審查者的發現。若你無法說明檢查會遺漏什麼，請要求真正的審查，而非快速批准。
負責結果。 任何釋出的變更都由負責人承擔責任，無論是誰輸入。

當人決定時

五項決策仍由人決定；檢查則在其他地方執行

FIG E人們已從閱讀每一個差異轉向機器不擅長的決策

跨團隊共享上下文

程式碼審查的第二個工作一直是傳播程式碼庫的理解。閱讀同事的差異是學習變更內容及其組合方式的方式。如果機器完成大部分閱讀，誰能學到程式碼？

我們沒有正式的流程。團隊中沒有人把 Claude Code 的完整心智模型儲存在腦中，我們也不認為有人需要。當有人想了解程式碼庫的一部分時，他們會請 Claude 為那個切片寫一份說明。這只需幾分鐘，並反映當前的程式碼。

Diagram titled "If machines do most of the reading, how does anyone learn the code?" On the left, a grid stands for the codebase, with a few squares highlighted as managed settings, the part you want to understand; nobody keeps a complete mental model of it in their head. An arrow labeled "Ask Claude about exactly that slice", with the example question "How does Claude Code retrieve managed settings?", leads to two outcomes: Claude writes an explainer, which takes minutes and reflects the code as it is today; and, for some, Claude builds a small artifact that visualizes that part of the code and teaches it the way that person likes to learn. Along the bottom: reading trivial diffs line by line, a one-line copy change teaches you almost nothing; an explainer for the module you are about to change teaches you a lot.

我們中的一些人更進一步，讓 Claude 建立一個小型 artefact，視覺化該部分程式碼並以該人喜歡的方式教授。

如果目標是有效利用人類注意力，這比逐行閱讀瑣碎差異更好。單行複製變更幾乎教不會什麼。即將更改的模組的說明會教你很多。我們習慣預設在開放的 Slack 頻道工作也有幫助，因為你可以在他們建置時看到他們在做什麼。

\"你落地，你負責\"

如果你部署了小型或中型變更，仍有問題發生，通常團隊會自行修復。以下幾點能避免情況惡化：

變更規模小，因此易於審查、除錯與回復。
一切皆可逆。旗標、回滾與分階段發布能在數分鐘內撤銷大部分錯誤。
影響半徑設為門檻。昂貴的程式碼會吸引更多人審查與檢查。
回歸問題會迅速浮現，透過遠端偵測與內部使用。
這不是責備。負責修復即擁有最多背景資訊；事件回顧會聚焦於系統。

所有權亦共享。團隊大部分工作於開放式頻道，任何人都能看到他人正在建置什麼，接手討論，或將 Claude 指向缺口，且回饋來自不負責該程式碼的人。這種開放性是品質保持高且不需在每一行上設門檻的關鍵。

當我們改變方向時

Agents 使啟動工作成本低廉，因此有些工作不應該被合併。通常頻道中的人會詢問原因、指出早先決策，或建議更簡單的路徑，然後作者關閉或重新塑造 PR。

由於程式碼寫得很快，關閉 PR 並不會感覺像失去什麼。關鍵是盡早在討論串中提出不同方向，而不是在完成 PR 後以阻塞評論。

你如何採用此流程

目前大部分實作此流程的要素已經存在。

在拉取請求之前

提供你的代理可以執行的檢查，列在簡短的 CLAUDE.md 中，並加入執行格式化器與靜態分析器的鉤子。
在本機執行 /code-review 和 /security-review，或進行一個全新情境的子代理審查。
新增一個 REVIEW.md，並將重複的審查意見移入其中。

在每一次 Pull Request 上

要求 CI，並在 PR 範本中加入「Testing」、「Risk」以及「How to revert」欄位。
在一個倉庫加入 AI 審查者（Code Review for Claude Code 或 Claude Code GitHub Action），先調整 REVIEW.md 幾週，然後擴大使用範圍。
加入自動化安全審查，並要求每一條審查執行緒在合併前都已解決。
將審查力度對應風險：常規更改快速通過，對於錯過的錯誤成本高昂的情況則進行深入審查（Code Review 的 Quick、Standard 或 Deep）。
限制審查回合；在前幾回之後，只重新審查新的差異。

批准

寫下風險等級，根據變更而非作者設定；起初嚴格，隨著證據累積逐漸放寬。
對你信任的作者保留較輕鬆的批准流程。
使用 CODEOWNERS 與分支保護，確保授權、帳單、CI 與發布流程，以及安裝程式始終需要人工介入。
絕不允許機器人的批准取代必須的人類批准；在新提交時撤銷批准。

合併後

使用合併佇列、功能旗標，先內部使用，再分階段發布，並支援一步回滾。
將事件與回滾納入評估集合，並在其提示、工具或模型變更時重新評分審查者。
以回滾與事件率作為守門檻，衡量人力時間。

此舉的方向

Code Review 的 announcement 說批准 pull request 仍然是人類的決策；產品只發布發現，而非批准。我們自己的倉庫更進一步，讓擁有者決定哪些低風險更改僅靠自動檢查即可合併，這條線持續前進。

當審查漏掉某項時，我們會詢問模型缺少什麼資訊，並將修正納入 CLAUDE.md、一項技能或新的檢查。目標未改變：每次更改的人力時間更少，且回滾次數不再增加。

如果你的團隊允許代理開啟 pull request，我們想聽聽你已自動化的檢查、仍需人工的檢查，以及你認為我們哪裡做錯了。

感謝 Emma Webb、Michael Segner 與 Amie Rotherham 的審查。