How the Claude Code team does code review（Claude Code 團隊怎麼做程式碼審查）

📌 30 秒摘要

這篇在講：Claude 寫了 Claude Code 約 90% 的程式碼之後，審查量大到沒辦法逐行讀，團隊怎麼重新設計審查。他們沒有拿掉審查，而是三件事：

• 把大部分「讀」交給機器：開 PR 前先驗證、每個 PR 都有 AI 審查與資安審查，未處理的發現會擋合併。
• 人工核准依風險分級：由變更內容決定要 0、1 或 2 個人看。
• 大量投資在快速復原：功能開關、先給內部用、分階段發布、一步回滾。

指標是「人花的時間」，護欄是回滾率與事故率。2026 年 6 到 9 月，合併的 PR 增加一倍多，需要回滾的比例反而降了 40% 以上。

🗺 心智圖（Canvas）

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

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

開 PR 前先驗證 貼出輸出，不說「做完了」

⚖️ 誰來核准：依風險分級

工具-依風險分級的審查核准

🎯 什麼情境該想到我

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

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

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 手冊的做法：低風險、可重複的變更預先核准，不必每次送審

變更決定層級，不是作者 agent 核准不算人

🎯 讓 AI 審查器越來越準

工具-調校AI程式碼審查器

🎯 什麼情境該想到我

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

事故當評估集 三輪上限、只審 diff

🧑 人留下來做什麼

決定要不要做、高風險程式碼 讀證據、為結果負責

共享理解：請 Claude 針對那一塊寫說明

Link to original

🎯 為什麼存這篇 / 未來想拿它做什麼

• 團隊開始讓 agent 開 PR 時，拿它的「七層把關」「風險分級表」「導入清單」當藍本，逐項對照自己缺哪一層。
• 它把「審查的目的」換成一個可以量的目標：人的時間，加上回滾與事故當護欄。以後要說服團隊調整審查流程，可以直接用這套指標。
• 調校 AI 審查器的三招（用事故當評估集、看人怎麼回應來量雜訊、限制輪數讓審查收斂）可以直接套到自己的 AI 審查設定。

🧰 這篇給我的工具

• 工具-分層把關取代單一審查關卡 — 當 agent 讓變更多到人審不完，要重新設計整條審查流程的時候
• 工具-依風險分級的審查核准 — 當我想讓部分變更不用人看就合併，要決定「這個變更要幾個人核准」的時候
• 工具-調校AI程式碼審查器 — 當 AI 審查不知道準不準、雜訊太多，或 agent 之間來回改不停的時候

✨ 關鍵重點

• 規模（原文數據，2026-10-15）：
  • Anthropic monorepo 每天合進的變更，從 5 月約 2,500 個增加到 9 月超過 30,000 個。
  • AI 審查進入研究預覽後，拿到實質審查意見的內部 PR 比例從 16% 升到 54%。
  • 1,000 行以上的 PR 多半會有發現，小 PR 多半是乾淨的。
• 問對問題：不是「有沒有人讀過」，而是「這個變更可能出什麼錯，哪一道檢查最適合抓到它」。審查從最後一道閘門，變成像拼字檢查一樣持續進行。
• 開 PR 前就驗證：給 Claude 能執行的東西（測試、build、對照設計的截圖），要它貼出輸出而不是說「做完了」，再讓一個新 context 的 subagent 審 diff。Claude Code 的作者 Boris Cherny 估計，讓 Claude 能驗證自己的工作，結果會好兩到三倍。
• CLAUDE.md 與 REVIEW.md 的分工：
  • CLAUDE.md 說明專案是什麼：技術棧、慣例、目標與非目標。每次審查都會載入，所以要短，用連結指到其他文件。
  • REVIEW.md 由 code owner 寫，告訴審查器自己那一塊什麼最重要。好的 REVIEW.md 很短，內容包括：
    • 說清楚在這個 repo 裡「出錯」長什麼樣子，例如文件出錯是「說謊」、設定出錯是「導錯路」；
    • 限制小意見的數量；
    • 列出要跳過的路徑；
    • 要求以檔案與行號為證據，不准只看名稱就猜；
    • 摘要開頭先寫數量，沒有問題就直說。
• AI 審查：多個 agent 平行找 bug，另一組 agent 對每個發現投票，夠多人同意才張貼。每個發現都要處理：修掉，或寫理由關掉。
• 人留下來做的事：決定要不要做、審高風險程式碼、審會被照抄的架構、讀證據、為結果負責。
• 「誰合進去誰負責」：變更要小、什麼都能復原、依爆炸半徑決定審查強度、回歸要能很快從遙測冒出來。這不是究責，是因為修的人最有 context。
• 共享理解：團隊沒有正式流程，想懂哪一塊就叫 Claude 寫那一塊的說明，有人還會請它做成互動小工具，再加上預設在公開頻道工作。
• 還沒做到的：還沒有「事故數字變動時自動收緊核准」的熔斷機制，工程師希望先有它，再讓更多變更走零人工合併。

💬 原文摘錄

• “We think ‘did a human read the code?’ is an imprecise proxy for ‘what could go wrong with this change, and which check—automated or human—is the right one to catch it?’”
• “Revert and incident rates are the guardrail: if they rise, we haven’t saved human time, we’ve only moved it.”
• “Noise costs more when the author is an agent.”
• “One colleague said slowing down does lower your error rate, but mostly because you’re doing less of everything. We’d rather get faster at noticing and fixing problems.”

🔗 相關

• 程式碼審查準則 —— DevOps 手冊的人工審查準則；這篇是 agent 時代把大部分「讀」移給機器之後的版本
• 同儕審查取代變更審批 —— 同樣把審查交給離變更最近的人與自動檢查，而不是遠端簽核
• 工具-把agent犯的錯變成環境改善 —— 「同一類發現反覆出現就在源頭修」的同一個思路
• Claude Code 深度使用 —— Claude Code 相關的其他筆記