🎯 什麼情境該想到我
當 agent 讓變更量暴增，「每個 PR 都由一個人逐行讀過」已經做不到，你在想「那審查要改成什麼樣子才不會出事」的時候。
⚙️ 怎麼用（步驟 / 公式）
1. 先換掉問題
「有沒有人讀過這段 code？」是個不精確的代理指標。真正要問的是：這個變更可能出什麼錯？哪一道檢查（自動或人工）最適合抓到它？
- 審查原本有兩個工作：① 上線前找出並修掉問題；② 讓團隊共享對程式碼的理解。這張卡處理 ①，② 見下方注意。
- 審查從「最後一道閘門」變成「像拼字檢查一樣持續進行」：多數變更在請人看之前，已經被 Claude 審過、修過至少一次。
2. 目標與護欄要一起定
- 目標：多數 PR 合併時最多只有一個人參與，而且這個人可以是作者本人。
- 量測人的時間：每個 PR 的人工核准數（中位數與 p95）、人工留言數、PR 等人的時間。
- 護欄：回滾率與事故率。這兩個數字上升，代表人的時間沒有省下來，只是從「審查」搬到了「修東西」。
3. 疊多層，每層只負責抓一部分
| 層 | 做什麼 | 擋不擋合併 |
|---|---|---|
| ① 開 PR 前先驗證 | 給 agent 能實際執行的檢查（測試、build、對照設計稿的截圖），要它貼出輸出，不能只說「做完了」；再讓一個新 context 的 subagent 審 diff | — |
| ② AI 審查 | 每個 PR 都跑，對照整個 repo 與 PR 宣稱的意圖；修 bug 時要找根因 | 未處理的發現會擋 |
| ③ 資安審查 | 獨立一輪 | 未處理的發現會擋 |
| ④ 必過的 CI | lint、型別、跨平台測試、build、打包 | 紅燈就擋 |
| ⑤ 依風險決定要幾個人核准 | 見 工具-依風險分級的審查核准 | 依層級 |
| ⑥ merge queue | 套上這個變更後，在最新 main 上整套重跑，避免兩個各自通過的 PR 合起來把 main 弄壞 | 擋 |
| ⑦ 上線後 | 功能開關、先給內部用、分階段發布；壞了就關開關或回滾 | — |
- 每個審查發現都要回應：修掉，或寫一句理由關掉。關掉就是處理誤報的方式。
- PR 範本要問「怎麼測的」「怎麼回滾」。Claude 可以幫忙填，但提出需求的那個人要簽名負責。
- 事故檢討要問「哪一層本來該抓到」，把修法放回那一層（CLAUDE.md、skill、lint 規則或新檢查）。同一類發現反覆出現時，也是在源頭修，見 工具-把agent犯的錯變成環境改善。
4. 人留下來做機器做不了的事
- 決定要不要做：方向、品味、範圍。宣稱審查瓶頸已經解決的團隊，對外部團隊送來的變更仍保留人工審查，好讓有人問「這個真的該做嗎？」
- 審高風險的程式碼：計費、自動更新、CI workflow。
- 審會被別人照抄的架構。
- 讀證據：測試輸出、跑了什麼指令、回了什麼、截圖、審查發現。說不出這些檢查會漏掉什麼，就要求真正的審查，不要快速核准。
- 為結果負責：每個上線的變更都有一個人負責，不管是誰打的字。
🧪 我實際套用的紀錄
- 2026-10-31：（待填）
⚠️ 注意 / 什麼時候不適用
- 前提是「容易復原」：變更小、有功能開關、能一步回滾、遙測與內部使用能讓回歸很快冒出來。缺了這些，就不該把人工審查拿掉。原文團隊自己也說，「事故數字變動時自動收緊核准」的熔斷機制還沒有，工程師希望先有它，再讓更多變更走零人工合併。
- 審查的第二個工作（共享理解）不會自己發生。原文團隊沒有正式流程，改成「想懂哪一塊就叫 Claude 針對那一塊寫說明，甚至做成互動小工具」，加上預設在公開頻道工作。他們的看法是：一行文案修改讀了也學不到什麼，針對你要改的模組寫一份說明能學到更多。
- 改方向要早講：agent 讓開工很便宜，有些工作本來就不該合併。不同意見要在討論串裡早點提，不要等 PR 做完才給一個擋合併的留言。
- 原文是 Claude Code 團隊自己的數據與作法（2026-10-15），規模與工具鏈和一般團隊不同。照搬前先確認自己有沒有上述的復原能力。
🔗 相關工具
- 工具-依風險分級的審查核准 —— 第 ⑤ 層的細節
- 工具-調校AI程式碼審查器 —— 第 ② 層怎麼越做越準
- 同儕審查取代變更審批 —— DevOps 版的同一個方向：讓離變更最近的人與自動檢查把關，不靠遠端簽核
- 功能開關、金絲雀發布 —— 第 ⑦ 層的兩塊積木
- 工具-把命令變成可驗證的目標 —— 第 ① 層「給 agent 能執行的檢查」