Claude Code 團隊怎麼做程式碼審查

🎯 什麼情境該想到我

當 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 能執行的檢查」

🎯 什麼情境該想到我

當你想讓一部分變更「不用人看就合併」，但又怕哪天合進一個不該合的東西，需要一套規則決定「這個變更要幾個人核准」的時候。

⚙️ 怎麼用（步驟 / 公式）

1. 先寫下風險分級

原文 Claude Code 團隊的分法（2026-10-15）：

風險	例子	需要幾個人核准
低	文件、文案、只給內部用的功能、藏在功能開關後面的新增	0 人（自動審查與資安檢查都過了才行）
中	一般產品變更；敏感區域如快取、自動更新、系統提示詞	1 人
高	風險最高的程式碼，以及少數固定要兩個人的路徑	2 人

2. 讓「變更」決定層級，不是讓「作者」決定

• 分類器讀變更內容來判斷層級。
• 第二個分類器再問一次：這個變更就算層級說不需要，是不是也該多一個人看？
• 有些路徑永遠要人：owner 列為敏感的路徑，以及任何 CI workflow 檔。實作上用 CODEOWNERS 加分支保護。

3. 用四條規則堵住漏洞

• 只有受信任的作者能走較輕的路徑：名單上多半是負責這個 repo 的團隊，其他人一律要第二個人核准。
• agent 的核准永遠不算人的核准：自動審查可以放行低風險變更，但不能填補「需要一個人」的那個位置。
• 下指令的人就是負責人：agent 寫的 PR，指揮 agent 的那個人算一位必要的審查者，就像他自己打的 code 一樣。
• 核准綁在特定 commit 上：之後又進來系統無法擔保的 commit（agent 的 push、某人手動解的 merge），就要重新核准。

4. 先嚴再鬆，用證據放寬

一開始從嚴，靠回滾率與事故率當證據，一步步把更多類型移到較低的層級。原文的方向是讓 owner 自己決定哪些低風險變更可以只靠自動檢查合併，而這條線還在持續移動。

🧪 我實際套用的紀錄

• 2026-10-31：（待填）

⚠️ 注意 / 什麼時候不適用

• 0 人核准的前提是事後能快速發現並復原：功能開關、分階段發布、一步回滾、值班與回滾儀表板。沒有這些，低風險的定義要收得更窄。
• 分類器會分錯，所以才需要「永遠要人的路徑」當底線，以及第二個分類器做反向檢查。不要讓分類器成為唯一的一道判斷。
• Anthropic 對外的產品比內部更保守：Code Review 產品只張貼發現、不給核准，核准仍然是人的事。內部 repo 才讓 owner 決定哪些變更可以只靠自動檢查合併。
• 自動化程度和團隊信任度綁在一起：跨團隊、外部貢獻者的變更，不適用較輕的路徑。

🔗 相關工具

• 工具-分層把關取代單一審查關卡 —— 這張是其中第 ⑤ 層
• 同儕審查取代變更審批 —— 同樣反對「一律送高層簽核」，改成依風險決定誰看
• 把變更重歸類為標準變更 —— DevOps 手冊的做法：低風險、可重複的變更預先核准，不必每次送審

🎯 什麼情境該想到我

當你已經在用 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）