[AI 分享] Claude Code 如何重新設計程式碼審查

[AI 分享] Claude Code 如何重新設計程式碼審查

摘要 : Anthropic以分層檢查、風險分級與事故回歸測試，應對AI帶來的程式碼產量成長。

內容:

Anthropic 近期的工程部落格提供了三組值得一起看的數字：Claude Code 約有 9% 的程式碼由 Claude 撰寫；今年 6 月到 9 月，Claude Code 倉庫合併的 PR 數量翻了一倍多；同期需要回滾的 PR 佔比卻下降了 40% 以上。

這不代表 AI 寫的程式碼已經不必審查。相反地，團隊投入了更多心思，只是重新設計了審查流程。要注意的是，PR 與回滾數據來自 Claude Code 的獨立倉庫；另一組常被提及的產量數據——Anthropic 主倉庫每日落地變更從 5 月約 2,500 處增至 9 月超過 3 萬處——屬於不同倉庫，不能混為一談。

當 Agent 大幅降低寫程式碼的成本，瓶頸便轉移到驗證。面對每天數萬處變更，人工逐行閱讀 diff 已不切實際。問題不再只是「有沒有人讀過這段程式碼」，而是「這項變更可能出什麼事、哪一道檢查最適合抓住它」。

檢查從建立 PR 之前開始。 工程師交付任務時，不只要求 Claude 完成功能，也提供可執行的驗證方式，例如測試、建置或可比對的截圖，並要求它展示結果，而非口頭宣稱完成。Claude Code 作者 Boris Cherny 認為，讓 Agent 能自行驗證，是改善成果最重要的做法之一；他估計最終結果可因此改善兩到三倍。提交前，團隊還會讓具備全新上下文的 subagent 閱讀 diff，避免寫程式碼時形成的思路替自己的修改辯護。

PR 建立後，AI 審查者會結合整個倉庫檢查：變更是否解決它聲稱的問題、是否符合系統其他部分，以及會不會破壞別處。多個 Agent 並行尋找問題，另一組 Agent 驗證候選發現；純風格意見則會被排除。留下的意見按重要性整理，並區分問題是否早已存在，避免把舊問題算在這次 PR 作者頭上。上線初期，收到實質審查意見的 PR 比例由 16% 升至 54%；這是評論覆蓋率，不能直接當成缺陷檢出率。

審查規則會寫進檔案：一類說明專案的技術棧、約定、目標與邊界；另一類由程式碼負責人描述特定區域「什麼情況算出事」。好的規則應簡短、具體，限制次要意見、列出可跳過的路徑，並要求每項發現附上檔案與行號。把團隊口耳相傳的判斷標準寫下來，AI 審查才能接上既有的工程文化。

AI 審查之外，還有獨立的安全檢查，以及 lint、型別檢查、跨平臺測試與建置等確定性檢查。安全發現若未關閉，PR 不能合併；關閉時也要留下理由。PR 模板則要求回答兩個問題：「這項改動怎麼測？」以及「出了事怎麼撤回？」Claude 可以協助填寫，但確認責任仍在人身上。

人工批准依變更風險分級，而非依作者職位決定。 低風險變更在自動與安全檢查通過後，可不要求額外人工批准；中風險變更需要一人；高風險或涉及敏感路徑的變更需要兩人。能走較寬鬆流程的作者仍須在倉庫可信名單上，Agent 的批准不能充當人工名額；若又有新提交，先前的批准也必須重新取得。

批准後，合併佇列會將變更與最新主幹組合，重跑全部檢查。新功能先放在 feature flag 後供內部使用，公開版本先進入 latest 通道，再進入 stable。若上線後出問題，可以直接關閉 flag；團隊也安排值班輪換。事故覆盤則追問：「這件事原本應該被哪一層抓住？」團隊坦言，目前仍缺少依事故率自動收緊審批條件的熔斷機制。

這套流程也走過彎路。曾有一個 CLI PR，一夜之間經歷 50 多輪 AI 審查與修復，最後由作者手動叫停。團隊用 git blame 回查發現，審查者反覆指出的程式碼約有 59% 在第一輪時就已存在。後續多輪並非持續找到新問題，而是不斷翻出舊問題。

他們於是設下四項限制：審到第三輪仍不收斂，就停止逐項挑錯，要求作者重新考慮方案；後續複審只看新增 diff；同類問題一次修完；已提出的發現不再重複。調整後，一輪通過的 PR 由 65% 升至 78%，需要五輪以上的由 8.9% 降至 1.5%，平均通過輪數由 2.08 降至 1.32。AI 迴圈的終止條件，不能留給 AI 自己決定。

最後，團隊把過去造成事故的 PR、修復與回滾紀錄整理成回歸樣本，由熟悉程式碼的工程師確認問題及位置。審查器每天對樣本執行；提示詞、工具或模型有變動時，也先用這套樣本評估。指標不只看抓到多少 bug，還包括錯誤評論、修復輪數、人工審批時間、回滾與事故。

誤報尤其值得控制：人類作者可以略過一則無用評論，AI 作者卻可能真的照著修改，產生新提交、新一輪審查與額外成本。因此，團隊也追蹤作者收到評論後究竟是修正、指出評論錯誤，還是說明原本就有意如此。

最值得借鑑的，或許不是某一個審查 Agent，而是整套回饋機制：讓每次事故成為往後的測試題，讓檢查有明確分工，也讓人的注意力留給真正需要判斷的變更。