Anthropic 的 Claude Code 團隊於二零二六年十月十五日公開其程式碼審查流程。該團隊指出，Claude 撰寫了自身程式碼庫約九成的程式碼，而在六月至九月之間，合併的拉取請求增加逾一倍，需要回退的比例卻下降超過四成。做法並非取消審查，而是把逐行閱讀交給機器，將人工注意力集中在方向、風險與架構等判斷，再用可回退的發布機制承接漏網問題。本文整理其分層架構、風險分級、代理審查的收斂機制與導入步驟，供已大量採用代理寫程式的團隊參考。
Claude Code 團隊為什麼要重新定義程式碼審查？
當代理每日產生數萬個變更，逐行人工審查已不可行。團隊把審查目標從「有沒有人看過」改為「哪一層檢查最適合攔截這個風險」。
審查原本承擔兩項工作，一是上線前找出並修正問題，二是讓團隊共享對程式碼庫的理解。當代理寫程式的速度提升，變更數量隨之急升。該團隊提到，Anthropic 單體倉庫每日落地的變更，由五月的約二千五百個升至九月的三萬個以上，Claude Code 本身雖然位於獨立倉庫，同樣承受大量變更的壓力。在這種節奏下，逐行閱讀幾乎不可能完成。
因此審查的時機也改變了。以往審查是流程末端的關卡，先寫程式、再開拉取請求、然後等待同事回覆。現在審查持續進行，更像書寫時的拼字檢查，大部分變更在交到人手之前，已經被代理審查並修正至少一次。這使得例行錯誤在早期被攔下，團隊的注意力得以留給更高層次的判斷。
審查流程分成哪幾層把關？
流程分為七層：開 PR 前的驗證、必須通過的持續整合、AI 審查、安全審查、按風險分級的人工批准、合併佇列與旗標，以及快速回退。
第一層在拉取請求出現之前就已經運作。代理被要求提供可驗證的輸出，例如測試結果、建置產物或與設計對照的截圖，而非單純回報完成；接著由另一個具備全新上下文的子代理檢視差異。團隊亦使用內部技能，分別負責尋找錯誤、簡化差異，以及端到端檢查行為。
第二層是每次拉取請求都必須通過的持續整合，內容包括靜態檢查、型別檢查、跨平台測試、建置與打包，任何紅燈都會阻止合併。第三層是代理審查，會對照整個倉庫與請求的既定意圖，判斷變更是否解決原本的問題、是否契合系統，或是否破壞其他部分。第四層是獨立的安全審查，只要其中一層仍有未結案的發現，該請求就不能合併。
第五層是按風險分級的人工批准，第六層是合併佇列，會在最新主幹上重新執行全部檢查，避免兩個單獨通過的請求合併後弄壞主幹。新行為通常先以旗標對內部員工開放，之後才進入最新通道，穩定通道再往後跟進。第七層是快速偵測與回退，旗標可以不必部署就關閉，並設有每週的值班輪替與事故檢討。
代理審查如何驗證發現並降低誤報？
多個代理同時找錯，再由另一組代理對每個發現投票，達到共識才張貼；只涉及風格或清理的項目會被丟棄，其餘按嚴重程度排序。
團隊不讓單一代理的判斷直接送交人類。多個代理會同時尋找錯誤，另一個群組則對每個發現投票，只有足夠數量的代理認同才會張貼。純粹關於風格、診斷訊息或清理的項目會被剔除，這些過濾條件經過團隊以自身拉取請求做過 A/B 測試才保留。剩下的發現以行內評論呈現，並按嚴重程度排序，同時標示為重要、細節或既有問題，避免把請求並未引入的錯誤歸咎於作者。
每個發現都必須得到回應，作者可以修正，也可以附上理由結案，這正是清除誤報的方式。若後續提交自行修正了問題，該發現會自動解除。團隊表示，在推出研究預覽時，內部獲得實質審查評論的請求比例，由百分之十六升至百分之五十四；超過一千行的請求大多能取得發現，而多數小型請求則以乾淨狀態回傳。
人類在流程中保留哪些決策？
五類決策留在人手：是否應該做這件事、高風險程式碼、會成為範本的架構、閱讀證據，以及為最終上線結果負責。
把資深工程師從深度工作中拉出來，只為攔下一個例行錯誤，代價遠高於自動審查。該團隊指出，工作重心已由閱讀每份差異，轉向機器不擅長的判斷。第一類是方向、品味與範圍，例如某項功能是否值得動工；曾有團隊在宣告審查瓶頸解除後，仍為外部提交保留人工審查，確保仍有人提出這個問題。
第二類是計費、自動更新器與持續整合工作流程等高風險程式碼，第三類是會成為他人範本的架構決定。第四類是閱讀證據，包括測試輸出、實際執行的指令與回傳結果、截圖與審查發現；若無法說明檢查會漏掉什麼，就應要求實質審查而非快速批准。第五類是承擔結果，任何上線的變更都必須有人負責，不論程式由誰輸入。
風險分級如何決定需要幾位人工批准？
風險等級由變更本身決定，而非作者。低風險在自動檢查通過後免人工批准，中風險需一人，高風險及敏感路徑需兩人。
文件修正與自動更新器變更的風險並不相同，因此批准要求也有差異。低風險涵蓋文件、文案、僅供內部使用的功能，以及以旗標包住的增量變更，只要自動審查與安全檢查皆通過，就不需要人工批准。中風險包括一般產品變更，以及快取、自動更新器或系統提示等敏感區域的調整，需一人批准。高風險則是最關鍵的程式碼，加上一小批永遠需要兩人的路徑。
分級由分類器閱讀變更後決定，而非由作者自行申報；另一個分類器會判斷個別變更是否需要額外的人手。部分路徑永遠需要人工，包括擁有者標示為敏感的檔案與任何持續整合工作流程。只有名列信任名單的作者才能走較輕的路徑，其他人都需要第二人批准，而代理的批准永遠不能取代人類的位置。此外，批准只對應單一提交，若之後有新提交無法被系統背書，就必須重新取得批准。
審查迴圈如何收斂並避免無限回合？
團隊加入回合上限：三輪之後要求作者重新考慮做法；首幾輪之後只審新差異，同一類問題一次講清，並避免重複張貼相同發現。
當作者與審查者都是代理，兩者可能長時間互相消耗。團隊提到，曾有命令列工具的請求在一夜之間經歷超過五十輪審查與修正，最後由作者中止。他們對持續被標示的程式碼執行追溯分析，發現約百分之五十九的內容自審查者第一輪起就已存在，顯示審查者很少找到新錯誤，只是每輪多挖出一些舊問題。團隊亦承認自己養成了預設跑多輪的習慣，而這在風險較高的變更上值得，用在每份請求上則不划算。
因此團隊改寫了重新審查的規則：加入回合上限，三輪之後要求作者退一步重新考慮做法；前幾輪之後只審查新增的差異；針對同一類錯誤提出一次，讓作者修正所有同類個案；並避免重複張貼已提出的發現。審查代理亦會在夜間掃描既有程式碼，設法在舊錯誤於其他地方浮現之前先找出它們。調整之後，內部請求一輪即通過的比例由百分之六十五升至百分之七十八，需要五輪以上的比例由百分之八點九降至百分之一點五，平均通過所需輪數由二點零八降至一點三二。
團隊如何用事故建立評估集並持續改進審查者？
每次事故與回退都整理成專家確認的案例，加入每日重跑的評估集；審查者的提示、工具或模型改動，都要在整份評估集上取得更高分才保留。
審查流程本身也是持續改進的迴圈。團隊把過去導致事故的請求連同其修正與回退一併收集，請熟悉該段程式碼的工程師確認每個錯誤及其位置，形成一份評估集，並讓審查者每日對照執行。任何對審查者提示、工具或模型的改動，都要在整份評估集上取得更高分數才會保留，否則就退回。
誤報的衡量方式，是觀察人們如何回應評論：作者是修正它、指出它判斷錯誤、說明行為屬於刻意設計，還是認為無關緊要。團隊亦會讓審查者在已知乾淨的請求上運行，統計它報告多少次會導致有害改動的建議。書面原則寫得很清楚，優先找到真正的錯誤，其次才是減少審查輪數。團隊也提醒，誤報在作者為代理時成本更高，因為人類可以很快略過一個細節，代理卻會為此再提交一次，引發新一輪審查。
其他團隊要如何導入這套流程？
先在單一倉庫加入 AI 審查與持續整合，寫好專案說明與審查說明，並在 PR 範本補上測試、風險與回退方式，再逐步擴大範圍。
團隊認為，多數環節在現有工具下已經可以落實。在拉取請求之前，應給代理可自行運行的檢查，寫在簡短的專案說明檔內，並以掛鉤執行格式化與靜態檢查，或交由具備全新上下文的子代理審查。同時建立審查說明檔，由程式碼擁有者說明該部分的失敗樣貌，把重複出現的評論移入其中。
在拉取請求階段，應要求持續整合通過，並在範本加入測試方式、風險與回退說明。可以先在一個倉庫加入 AI 審查，花數週調校審查說明後再擴大；同時加入自動安全審查，並要求所有審查討論串在合併前結案。審查力度要與風險相稱，例行變更走快速通道，漏掉錯誤代價高昂之處才用深度模式。批准層面應寫下風險等級，由變更本身決定而非作者，並透過程式碼擁有者設定與分支保護，確保安裝程式、計費與持續整合等工作流程永遠需要真人。合併階段則使用合併佇列、功能旗標與先內部後外部的發布節奏，並明確規定機器人的批准不能取代必要的人工批准。
出處連結有哪些？
本文資訊整理自 Anthropic 於十月十五日發布的工程文章，讀者可經下列連結查閱完整流程、圖表與導入建議。
官方文章：https://claude.dev/blog/solving-code-review-at-anthropic/
總結：這套審查流程適合哪些團隊？
這套做法適合已大量採用代理產生程式碼、且有持續整合與可回退發布機制的團隊；變更量小或缺乏自動化基建的團隊，應先補齊基礎。
這套流程的價值，在於把人力從逐行閱讀重新分配到判斷與問責。對已經大量採用代理寫程式、並具備持續整合、功能旗標與合併佇列的團隊而言，分層審查可以在變更量倍增的同時壓低回退比例，這正是該團隊公布的數據所指向的方向。風險分級與回合上限，則分別回應了批准成本與審查迴圈失控兩個常見痛點。
限制同樣清楚。這套做法高度依賴自動化基建與可快速回退的發布機制，若缺乏這些條件，把閱讀交給機器只會把問題延後。團隊亦坦言尚未具備在回退或事故數字上升時自動收緊批准的斷路器，部分工程師希望在更多程式碼轉向零人工合併之前補上。對正在導入代理工作流程的團隊，先建立可驗證的檢查與可逆的發布，比先追求更高的代理自主度更務實。
