Claude Code 團隊如何進行程式碼審查：七個步驟，不設熔斷機制

2026 年 10 月 15 日，Claude Code 團隊發表了一篇自家如何審查程式碼的說明，那是一篇閱讀時間十四分鐘的工程文章，署名者為 Addy Osmani、Morgan Westlee Lunt 和 Qing Wang。解釋為什麼會有人搜尋這件事的那句話很早就出現了：Claude 撰寫了 Claude Code 自身約 90% 的程式碼。這篇文章並不是在為那個數字辯護，而是在描述：在這樣的比例還能撐得住之前，底下必須先存在的機制；而值得細讀的部分，正是那些仍然缺失的環節。

大多數摘要都停在兩個頭條數字上：2026 年 6 月到 9 月間，合併到 Claude Code 程式碼庫的 pull request 增加了一倍以上，而必須回退的比例則下降了超過 40%。這兩者都來自團隊本身，且都可能由幾種不同的安排產生，包括人們所假設的那一種，也就是審查被悄悄移除。文章說並非如此。他們把大部分的閱讀工作交給機器，針對人類的時間與注意力進行最佳化，並投入資源讓錯誤能快速且容易地復原。其餘的一切則是怎麼做到的細節。

為什麼覆核一開始會成為瓶頸

這股壓力並非來自某項政策決定，而是來自數量。文章指出，在 Anthropic 的 monorepo 中，每天落地的變更從 2026 年 5 月約 2,500 筆，增加到 2026 年 9 月的超過 30,000 筆。Claude Code 位於自己獨立的儲存庫，與該 monorepo 分開，但它也承受著規模較小的相同壓力。

照這樣看，貼文承認，逐行人工審查極其困難，甚至不可能。文中沒有人主張人工閱讀每個 diff 是不必要的。他們主張的是，閱讀每個 diff 已無法規模化，而且「是否有人類讀過這段程式碼」一直以來都是個不精確的代理指標，無法真正回答關鍵問題：這項變更可能出什麼問題，而哪一種檢查——自動化或人工——才是捕捉該問題的正確方式。

一旦這樣表述，把關的位置就變了。審查不再是道路盡頭的一道門，而是變成持續進行的事，更接近你寫作時的拼字檢查。大多數變更在任何人查看之前，就已經由 Claude 讀過並修正。

他們為了什麼而優化，以及什麼算作失敗

所宣稱的目標是：Claude Code 各儲存庫（文章中描述為 CLI、桌面與網頁應用程式以及行動應用程式）中的大多數 pull request，在流程中最多只有一個人參與的情況下就能合併，而這個人可以是作者本人，且回退或事故不會增加。第三項條件正是讓它成為真正的目標、而非削減成本手段的關鍵所在。

他們從帳本的兩端衡量人力時間：人們花在審查上的時間，以及花在修復不良程式碼所造成的破壞上的時間。若成本在後者重現，削減前者也無濟於事，而團隊也直言這一點。因此，追蹤的數字是每個拉取請求的人工核准數（以中位數與第 95 百分位數回報）、人工評論，以及拉取請求等待人員處理的時間。回退率與事故率則作為護欄，位居這一切之下：若這些比率上升，人力時間就沒有被節省，只是被轉移了。

單獨來看，審查成本指標很容易被操弄；一個什麼都放行的審查者，能畫出漂亮的核准時間圖表。真正能防止圖表說謊的，是護欄機制。

七個步驟，而非一道關卡

這篇文章將典型變更的流程拆解為七個編號步驟。每一層都會攔下一些問題、漏掉另一些，而較便宜的檢查會先於較昂貴的檢查執行。

• 在 Pull Request 出現之前的驗證。Claude 會執行測試、建置與 linter，並由第二個代理程式在全新的脈絡中審查 diff。許多工程師也會執行內部技能：一個專門獵捕 bug、一個簡化 diff、一個端到端檢查行為。創造 Claude Code 的 Boris Cherny 曾說，讓 Claude 有辦法驗證自己的工作，大概是獲得好結果最重要的一件事，並估計這能讓最終成果好上兩到三倍。

• 每次提取請求都會進行 AI 審查。Claude 審查會對照整個儲存庫以及提取請求所聲明的意圖來閱讀差異。多個代理會平行尋找錯誤，接著由另一個群組對每項發現進行投票，只有在足夠多的人同意它是真實問題時才會發布。關於風格、診斷或清理的發現會被捨棄。存留下來的會以內嵌註解呈現，並標記為「重要」、「小問題」或「既有問題」。研究預覽推出時，內部提取請求獲得實質審查意見的比例從 16% 上升到 54%。管理員可將每個儲存庫設定為「快速」、「標準」或「深入」。

• 安全性審查。 一項獨立的自動化檢查。只要任一項審查有未解決的發現，拉取請求就無法合併；你要修正它，或以簡短理由關閉該討論串。同一項檢查已公開為開源的安全性審查 GitHub Action，或 /security-review 指令。

• 會阻擋的自動化檢查。 在每個平台上進行 Lint、型別檢查、測試，以及建置。

• 人工核准，依風險分級。 分類器會讀取變更並設定層級，而不是由作者自行設定。這個步驟會在下方有專屬章節，因為大部分有趣的設計都在這裡。

• 合併佇列、功能旗標與漸進式發布。 佇列會在套用變更後，針對 main 重新執行每項檢查，因此兩個各自通過的 pull request 不會合併成損壞的 main。新行為會先透過旗標向 Anthropic 員工發布，再發布到 latest 頻道，stable 則隨後跟進。

• 快速偵測與回滾。功能旗標無需部署即可關閉，每週有值班輪替，事故檢討會追問哪一層本應攔下問題。有些錯誤仍會漏過，因此最後一層的重點在於盡快察覺，而非事先防止。

這項變更設定的是層級，而不是作者。

文件修正與自動更新程式變更的風險並不相同，因此不會接受相同的審查。該文章的表格分為三個層級，每個層級都只回答一個問題：這項變更合併前，需要多少人（如果有的話）核准。

低風險涵蓋文件、文案、僅供內部使用的功能，以及藏在旗標後的新增變更；一旦自動審查與安全性檢查通過，就不需要任何人介入。中風險涵蓋一般產品變更，以及快取、自動更新程式與系統提示等敏感領域，需要一個人。高風險涵蓋最高風險的程式碼，以及一小組始終需要兩個人參與的路徑。

分類器只是整體設計的一半。第二個分類器會判斷：即使層級顯示不需要，這項特定變更是否仍需要另一個人。有些路徑無論層級為何一律需要真人：擁有者列為敏感的任何內容，以及任何 CI 工作流程檔案。只有位於儲存庫信任清單上的作者（大多是擁有團隊）才能走較寬鬆的路徑；其他所有人都需要第二個人。代理人的核准絕不算作真人的核准，因此自動審查可以放行低風險變更，但不能填補需要真人的名額。無論是誰發起這項變更，都要對它負責。而且一項核准只涵蓋某個特定提交，因此新的提交（包括代理人的推送或手動解決的合併）需要重新取得核准。

有兩個細節值得借用，即使你從來不建立分類器。等級取決於變更本身，而非作者；而信任則是疊加於其上、獨立且更窄的一道關卡。此外，核准是綁定到某個 commit，而不是綁定到一個 pull request，這堵住了審查系統中最常見的漏洞：在分支初期掙得的綠勾，被花在沒有人看過的程式碼上。

審核人員是針對其自身的事件接受訓練的。

這正是大多數報導會略過的部分，而它說明了為什麼這套安排能持續運作，而不是逐漸偏離。

團隊蒐集了過去引發事故的拉取請求，以及它們的修復前推與還原，並讓熟悉那段程式碼的工程師確認每個錯誤及其所在位置。這份蒐集現在成了一套評測。審查器每天都會對它執行。當它的提示、工具或模型變更時，該變更必須通過整組評測：分數上升就保留，否則就捨棄。這些失敗案例成了本該捕捉它們失敗之工具的測試套件。

這與調校 linter 是截然不同的姿態；後者是依據固定規則集來評判的。這個審查器則是依據此程式碼庫已經具體出過故障的方式來評判，因此每當有地方出錯，評估就會擴充。在我們讀過的 Anthropic 已發布內容中，沒有出現它的分數；而且文章也沒有聲稱這個審查器已經完成。

尚未建置的圖層

這正是讓這篇文章可信的坦白。上述內容描述的系統會捕捉並逆轉錯誤，而不是能察覺自身錯誤率正在變化的系統。該團隊目前還沒有能在回退或事故數量變動時自動收緊審批的斷路器，而當地工程師希望在更多程式碼轉向零人工合併之前先擁有這些機制。

取而代之的是人的察覺。功能旗標不需部署就能關閉，每週的待命輪值負責盯著看，而事故檢討會追問：哪一層原本就該攔下這個問題。一位同事說的那句話，對任何打算以類似方式推行的人來說是最受用的一句：放慢速度確實能降低錯誤率，但主要是因為你什麼都做得更少。團隊寧願在察覺與修復問題上變得更快，也不願在製造問題上變得更慢。

帶著這個想法重新讀一遍這七個步驟。其中六個步驟決定一項變更是否繼續推進。第七個步驟則是一套用來在事後察覺問題的習慣。系統並沒有把回饋迴路從結果接回那道關卡，而打造這套系統的人也是這麼說的。

評論的第二項職責，而本文大多略過不提

這篇文章明確指出，程式碼審查有兩項職責：在問題上線前找出並修正它們，以及在團隊中建立共享脈絡。文章聚焦於第一項，之後再回到第二項，並給出一個異常誠實的答案：這件事沒有正式流程，沒有人會在腦中維持 Claude Code 的完整心智模型，而他們也不認為有誰需要這麼做。想理解程式碼庫的某一部分嗎？直接請 Claude 針對那個片段做說明。

有兩個指令檔承載著過去只存在於審查者腦海中的脈絡。CLAUDE.md 告訴 Claude 這個專案是什麼、技術堆疊、慣例、目標與非目標，並刻意保持簡短。REVIEW.md 則由程式碼擁有者撰寫，說明在他們負責的那部分程式碼中，失敗長什麼樣子、哪些路徑該跳過，並要求指出檔案與行號，而不是憑猜測。

問責自成一條：你讓它上線，你就要負責。合併小型或中型變更後出了問題，規範就是由你來修復。這之所以行得通，是因為變更很小，因為功能旗標與回退能在幾分鐘內撤銷大多數錯誤，也因為影響範圍決定了變更需要多少道檢查。這是在核准規則之上疊加的一項規範，而不是取代它。

路由器適用之處，以及不適用之處

上述管線是一連串模型呼叫：一個審查代理對照整個儲存庫來讀取差異、數個並行尋找 bug 的代理、一個群組對每項發現投票、一道安全檢查，以及審查器每天針對不斷擴大的評估集重新執行。這首先是路由問題，其次才是審查問題，因為單一供應商某個下午出狀況，不該讓合併佇列停擺。

OrcaRouter 是一個與 OpenAI 相容的端點，只要一組金鑰就能使用超過 200 個模型，並提供跨供應商的自動容錯移轉與零加價，也就是直接採用供應商的定價。執行這套流程自有版本的團隊，只需處理一個帳務關係，並在審閱者的品質評價改變時，有一個切換模型的地方，而這正是每日評估旨在偵測的情況。

界線很重要。我們託管模型。我們不託管 Claude Code，也不為 Claude Code 執行 Code Review，且無法存取本文所談的管線。Claude Code 的 Code Review 是 Anthropic 的產品，在 Team 與 Enterprise 方案中一般可用，另有較輕量的版本可透過 /code-review 在本機使用。如果你要的是那條管線，它就在那裡；在你團隊自己的版本中，router 是管線基礎架構的決定，而不是審查決定。

規模較小的團隊實際上能複製什麼

把審查規則寫下來，放在審查者讀得到的地方：為專案寫一份簡短的 CLAUDE.md，並為每個領域各寫一份 REVIEW.md，明確指出失敗長什麼樣子，並要求提供檔案與行號，而不是憑猜測。把風險分級寫進文件，讓它成為變更本身的屬性，而不是作者的屬性；一開始從嚴，只有憑證據才放寬。為自動審查可核准的範圍設上限，絕不讓代理的核准等同於人的核准。把核准綁定到 commit。執行合併佇列。把事故與回滾轉化為測試案例，並且每次更動審查器時就重新評分，因為未被量測的審查器，不過是個行銷話術更漂亮的 linter。

那麼，要看的是護欄指標，而不是核准時間。團隊自己的說法，正好為你正在考慮的任何審查流程變革提供了檢驗標準：回滾率和事故率是否維持不變，還是時間只是從審查者轉移到事後收拾善後的人身上？這個問題可以用多數團隊已經擁有的資料來回答，也能區分真正變快的流程，和只在某一季看起來變快的流程。