Claude 寫了九成程式，誰來審？Claude Code 團隊公開分層審查流程
Claude Code 團隊公布內部 code review 流程，讓測試、AI 審查、安全檢查與人工核准各司其職。九成程式由 AI 撰寫之後，如何保留結果責任、限制反覆互改，並用撤回與事故檢查成效？
AI 寫程式越快，團隊就越容易卡在審查。Claude Code 團隊說，約九成自家程式碼由 Claude 撰寫，人工逐行閱讀已經很難追上變更量。
他們公布的資料顯示，2026 年 6 月到 9 月，合併的程式變更提案增加超過一倍，需要撤回的比例卻下降超過四成。
這是該團隊的內部結果，並非任何公司換上同一套工具都能得到相同比例。更有參考價值的是，他們如何把測試、AI 審查、安全檢查與人類決策分層。
風險低的文件修改，可以和影響付款、更新程式或發布流程的改動，用不同的門檻。但每項上線變更仍由人負責，AI 核准也不能頂替要求中的人工核准。
對已經使用程式代理的團隊，我會先借用這套分工，再用自己的撤回率與事故率檢查成效，逐步調整人工審查的範圍。
Claude Code 團隊為什麼重做 code review？
變更增加後，稀缺的是能辨認風險的人類時間。code review 就是檢查程式修改是否符合目的、會不會造成其他問題，以及團隊是否理解這項變更。
過去常見的做法，是工程師完成修改，送出 PR，再等另一位工程師閱讀。PR 是請求把一組修改合併進正式程式庫的提案，能保留討論與檢查紀錄。
但代理可以同時產生多項修改，所以等待審查會逐漸形成工作積壓。即使每份程式都有人讀過，也不代表每個重要問題都被辨認出來。
官方內部流程長文 把目標放在節省人類時間，同時避免撤回與事故增加。因為審查少花的時間，若只是搬到修復事故，團隊並沒有省下工作。
這也改變了審查的起點。代理應先用能執行的檢查驗證自己的修改，再請其他檢查或人類接手，而非等到所有程式寫完，才第一次尋找問題。
因此，這套流程最值得借用的是檢查順序。把容易提早發現的錯誤先處理，才能讓後面的審查者專注在值得判斷的地方。
一項變更如何走過測試、AI 與安全檢查？
不同檢查負責不同錯誤，前一層通過不代表後面可以省略。以一項網頁修改為例，畫面能開啟、資料處理正確與權限沒有擴大，是不同的驗收問題。
提出合併前，先拿出能執行的證據
官方團隊會讓 Claude 取得測試、建置或可對照設計的畫面，再要求它展示輸出。因為「我已完成」是敘述，執行結果才有辦法讓別人核對。
專案也要把檢查方法寫清楚。短的 CLAUDE.md 說明專案規則，REVIEW.md 則提供程式負責人希望審查者特別留意的內容，避免每輪都重新猜團隊標準。
這些文件的價值在於具體。例如「檢查權限」很寬，若能指出哪種變更會讓資料被錯誤存取，審查者才比較容易對照程式行為。
審程式與查安全，各自保留阻擋能力
內部流程在每份 PR 都安排 AI 審查，也另外做安全審查。AI 看見的問題會再經其他代理確認，讓進入討論的內容盡量有實際證據。
但人仍要回應問題。被指出的項目可以修正，也可以說明為何是誤判。因為不能把討論留在無人處理的狀態，流程才有明確的出口。
自動測試也保留阻擋功能。格式檢查、型別檢查、不同平台測試與建置各有用途，因為它們能反覆執行，適合承擔可以明確判定的部分。
合併前，還要看修改放在一起會不會出事
兩項修改各自通過測試，合在一起仍可能互相影響。合併佇列會把變更放進接近正式主線的狀態再檢查，降低各自正確、組合後失敗的機會。
這也是為什麼「代理已測過」不能直接等同「正式系統已驗收」。測試使用的版本與環境，要能對應到準備合併的內容。
延伸閱讀：AI 程式驗收教學：人工審查、測試與逐步上線，各自能抓到哪些錯誤
什麼情況要零位、一位或兩位人工審查？
內部流程依變更風險與可信作者條件分流，讓不同改動使用不同門檻。這是團隊自己的工程政策，和產品是否會自動替客戶核准 PR，要分開理解。
以下整理官方提到的風險層級。表格中的零位人工，有自動檢查通過及可信作者等條件，不能單獨擷取成所有文件都可無人合併。
| 風險層級 | 官方舉例 | 人工核准安排 |
|---|---|---|
| 低 | 文件、文案、內部功能、功能開關後的新增內容 | 符合條件且檢查通過後，可不要求人工核准 |
| 中 | 一般產品修改，以及快取、更新程式、系統提示等敏感區域 | 一人 |
| 高 | 最高風險程式與指定路徑 | 兩人 |
表格的差異來自改動會造成什麼後果，所以不能只看檔案大小。短短一行若改變認證邏輯，可能比一大段文件更需要人確認。
可信作者也是條件。團隊對名單外的作者要求額外的人類核准，某些敏感路徑也固定需要人，並不是讓代理自行認定熟悉專案就能跳過。
一份核准，只對應當時那個版本
官方也把人工核准綁在具體提交上。提交是版本系統記錄的一次修改，後續若又加進無法被系統確認的內容，就需要重新取得核准。
因為人審的是當時看到的程式，新修改若自動沿用舊核准，責任就會失去對應。這項規則對代理尤其重要，因為它可能在收到留言後很快又推送多個版本。
商用 Code Review 產品仍是提出發現，沒有替代必要人工核准。把內部流程與產品功能分清楚，才能避免在設定工具時期待它自動執行組織政策。
延伸閱讀：Claude Code Review 正式開放：Team、Enterprise 的 Quick、Standard、Deep 怎麼選？
為何審查越多次不一定越安全？
代理反覆互改會消耗時間，也可能每輪才發現少量既有問題。如果不設定完成條件，工程師回來時看到的可能是更多提交，卻沒有更清楚的結論。
官方長文提到，一份 PR 曾在夜間進行超過五十輪審查與修正。後來回看，被持續指出的內容約有 59% 從審查第一輪時就存在，並非每輪新引入的錯誤。
這個案例說明，讓代理一直審到「沒有新意見」，未必是有效的停止條件。因為每輪可以換一個角度找舊問題，整個任務就可能永遠不收斂。
限制輪數，讓下一輪有新的任務
團隊因此加入三輪上限，之後要求作者重新考慮做法。前幾輪過後，複查也改以新差異為主，避免同一份程式每次從頭被重新挑選問題。
對一般團隊而言，可以先把留言分成必須修正、需要人做決定，以及不影響這次任務的建議。這是本文建議的整理方式，目的是讓下一輪知道自己要確認什麼。
若同一類問題出現多次，應回頭處理共同原因。例如命名規則已清楚寫在專案文件裡，就不需要每份 PR 各自重新討論，讓檢查方式更一致即可。
但只看新差異，也需要保留原本的驗收要求。修好一項問題若破壞了另一項行為，相關檢查仍得重跑，不能把停止重複審查誤當成停止驗證。
上線後出錯，如何發現、撤回並改善？
快速撤回和事故評估，補上事前審查抓不到的部分。因為再多檢查也有自己的盲點，團隊需要知道出錯時如何縮小影響。
功能開關可以先停用某個新行為，撤回提交則可以把程式恢復到較早版本。兩者處理的位置不同，應在修改時就確認哪種方式適用。
官方團隊先在內部使用新功能，再逐步對外發布。當變更真正接觸到使用者，作者與輪值人員也會觀察撤回及事故紀錄，找出哪一層原本應該攔住問題。
把事故變成日後會考的題目
若一個錯誤已經造成事故，只補上修正還不夠。團隊會整理相關 PR、修復與撤回，讓熟悉程式的人確認問題，再把它放入評估審查者的案例。
因為審查工具的提示、模型與工具都可能改變，保留案例才能比較新版本是否又漏掉同類錯誤。這比只問審查者「有沒有更聰明」更容易核對。
噪音也要一起觀察。若審查者把正常行為判成錯誤，代理作者可能真的去修，接著又需要一輪審查，時間就花在原本不必做的修改上。
所以評估不能只看找到多少問題，也得看哪些意見被修正、哪些被判定是誤報，以及處理後是否真的避免事故。
一般團隊如何先在一個程式庫試行？
從可執行的測試、短規則檔與可量測的人類等待開始。若連「現在怎麼判斷改好了」都說不清楚，直接減少人工審查只會增加不確定性。
先固定一種工作，再調整門檻
可以先選日常的小型修正，保留原有人工要求，觀察 AI 審查能提前處理多少問題。因為任務類型接近，比較結果才不會一直被不同難度干擾。
每項變更至少說清楚預期行為、驗證方式與撤回方法。審查者因此不用先花時間重建任務背景，也較容易發現修改超出範圍。
試行時，記錄人工等待、核准次數與來回輪數，再對照上線後的問題。若合併較快，卻需要更多人善後，就應收回較寬鬆的路徑。
用等待與問題率檢查是否省到時間
Claude Code 團隊會追蹤每份提案的人類核准數、中位數與較慢那一端的情況，也看人類留言及等待時間。因為平均值可能被大量簡單修改拉低，少數困難工作是否一直卡住，也需要另外觀察。
這些過程指標要與撤回及事故一起看。若人工留言變少，卻讓作者花更多時間修復上線問題，團隊只是把審查工作搬到後面，沒有達到節省人類時間的目標。
一般團隊可以先用原有流程留下基準，再逐項調整。一次更換模型、規則、風險門檻與發布方式，即使成效改變，也很難知道是哪個改動帶來差異。
這是試行時的比較建議，不代表官方已替其他組織驗證一套固定門檻。團隊仍要依實際使用者影響，決定哪些變更可以走較輕的路徑。
讓負責人能解釋檢查的盲點
負責人不一定要逐行背出代理寫的程式，但應能說明這次檢查證明什麼、沒有證明什麼，以及發現異常時怎麼處理。
例如測試能證明指定輸入的行為，卻未必涵蓋正式資料與所有權限情況。知道這個差別，才能決定是否再找領域負責人確認。
官方最佳實務 也強調提供驗證方式。工具能幫忙執行，但驗收目標仍需要來自知道產品為何而做的人。
常見問題 FAQ：Claude Code 團隊流程能直接套用嗎？
九成程式由 AI 撰寫，代表九成人力可以取消嗎？
這個比例描述程式來源，沒有衡量整份工作的工時或人力替代。
目標、架構、風險判斷與結果責任仍包含人類工作。
撤回比例下降四成，是事故少了四成嗎？
官方說的是需要撤回的 PR 比例，和事故數是不同指標。
因此不能把兩者互換，也不能直接推估其他公司的效果。
有 AI 審查後，可以讓機器自行核准所有 PR 嗎？
官方內部流程仍設有必須人工核准的條件。
代理的核准不能取代那些人類席次，組織也要自己制定與執行政策。
把人留在風險決策與結果責任上
這套流程適合已經有測試與版本管理的團隊借用，尤其是 AI 產出開始超過人工逐行審查速度時。先把檢查分層，再決定哪些人工工作可以減少。
若團隊還沒有可靠的撤回與問題追蹤，應先補上這些基礎。因為能快速生成程式，不會自動讓失誤變得容易復原。
下一個可做的動作，是挑一個程式庫，要求每份提案交出測試與撤回證據，觀察一段時間後再調整門檻。歡迎免費訂閱 AI 郵報，持續追蹤程式代理與團隊實作方法。
