🎯 什麼情境該想到我
當你已經在用 AI 審查 PR，但遇到兩種狀況：一是不知道它到底準不準、改了 prompt 有沒有變好；二是 agent 寫、agent 審，兩邊來回好幾輪都停不下來。
⚙️ 怎麼用（步驟 / 公式）
1. 用自己的事故當評估集
- 收集過去造成事故的 PR，包含後來的修補與回滾，請熟悉那段程式的工程師確認每個 bug 與它所在的位置。
- 審查器每天對這組案例跑一次。
- 每次改審查器的 prompt、工具或模型，都對全部案例重新評分：分數上升才保留，否則丟掉。
- 每多一次事故，就多一個案例。評估集的通用做法見 工具-AI系統評估；「改動要有對照組」見 工具-AI改動的AB對照評測。
2. 量雜訊：看人怎麼回應留言
只追求抓到更多 bug 很容易，只要不在乎誤報就好，所以一定要有反向的量測：
- 把審查器的每則留言，依 PR 上的人怎麼回應分類：修了、說它錯了、說這是故意的行為、或判斷不重要。
- 拿已知乾淨的 PR 跑審查器，數它多常報出「會讓人做出有害修改」的東西。
- 把優先順序寫下來。原文的順序是：先抓到真的 bug，其次才是減少審查輪數。
- 只關於風格、診斷資訊、程式整理的發現直接丟掉；這些過濾規則他們先在自己的 PR 上做過 A/B 測試才保留。
- 作者是 agent 時，雜訊更貴：人可以幾秒鐘略過一個小意見；agent 會去修它，於是多一個 commit、多一輪審查。
3. 讓審查收斂
agent 作者加上 agent 審查者，可以互相忙到天荒地老：原文有一個 PR 在一夜之間跑了五十多輪審查與修正，直到作者喊停。對反覆被挑出的問題跑 git blame，約 59% 是審查器第一輪時就已經存在的舊程式碼，它很少找到新 bug，只是每輪多找出幾個舊的。
他們加了四條規則：
- 輪數上限：三輪之後，審查器請作者退一步，重新考慮做法。
- 前幾輪之後只審 diff，不再重審整份。
- 指出「這一類」bug，讓作者一次修掉所有實例，而不是一次一行。
- 不重複張貼已經貼過的發現。
結果（Claude Code 內部 PR，原文 2026-10-15）：
| 指標 | 調整前 | 調整後 |
|---|---|---|
| 一輪審查加修正就通過 | 65% | 78% |
| 需要 5 輪以上 | 8.9% | 1.5% |
| 平均審查次數 | 2.08 | 1.32 |
4. 依風險決定審多深
例行變更快速看過，漏掉一個 bug 代價很高的地方才深審。原文的 Code Review 產品讓管理者把每個 repo 設成 Quick、Standard 或 Deep 三種深度。舊程式碼裡的 bug 交給每晚跑的審查 agent 掃，不要塞進每個 PR 的審查裡。
🧪 我實際套用的紀錄
- 2026-10-31：（待填）
⚠️ 注意 / 什麼時候不適用
- 事故評估集需要人力確認：每個案例都要熟悉那段程式的人確認 bug 與位置。事故太少的團隊，可以先用回滾過的 PR 湊案例。這一點是我的推論，原文沒有提到。
- 多跑幾輪不是免費的：原文說他們一度習慣預設多跑幾輪，因為每輪都會多抓到一點東西；這對高風險變更值得，但不是每個 PR 都值得。所以他們把「通過所需的輪數」和抓到率一起追蹤。
- AI 審查的發現要分清是不是這個 PR 造成的：原文把每個發現標成 Important、Nit 或 Pre-existing，避免「PR 沒引入的 bug 看起來像作者的錯」。
- 原文的數字都是 Claude Code 團隊自己的內部數據，不同 repo、不同模型的結果會不一樣。
🔗 相關工具
- 工具-分層把關取代單一審查關卡 —— 這張是其中第 ② 層的調校方法
- 工具-AI系統評估 —— 評估集與 AI 評審的通用做法
- 工具-AI改動的AB對照評測 —— 改審查器時要有對照組
- 工具-把agent犯的錯變成環境改善 —— 同一類發現反覆出現時，改在源頭（CLAUDE.md、lint、skill）