ClaudeCode團隊CodeReview圖解

圖解 · 搭配中文導讀一起看

Claude Code 團隊怎麼做 Code Review

一句話：code 多到人看不完，所以讓機器一層一層先篩，人只看機器不擅長、又真的危險的地方。底線是出包不能變多。

內容依據 原文（2026-10-15）。圖都是重畫的示意圖，不是原文的圖。

機器做的事 人做的事 出問題

先看結果：他們做到了什麼

~90%Claude Code 自己的 code 是 Claude 寫的

×2 以上6 月到 9 月，合併的 PR 數量

−40% 以上同期需要 revert 的比例

產量翻倍，出包反而變少。下面一張一張看他們怎麼做到的。

1. 以前和現在差在哪

重點不是「有沒有人看過」，而是「這個改動可能出什麼事，該由哪一關擋」。人的時間只花在機器擋不住的地方。

2. 一個改動從寫到上線的路線

整條路上只有一格是橘色（人）。其他都是機器自動跑，人的注意力只放在有風險的那一步。

3. 為什麼要疊這麼多層

每一層都會漏，這是預期中的。靠的是「很少有問題能穿過全部」，最後再由回退兜底。所以他們不追求單一關卡完美，而是追求出事能很快發現、很快撤。

4. AI review 裡面在做什麼

多個 agent 各自找，再由另一組投票過濾，是為了壓誤報。作者是 agent 時，誤報特別貴：人看到雞毛蒜皮會略過，agent 會真的去改，多改一次就多一輪 review。

5. 要幾個人簽：看改了什麼，不看誰改的

由分類器看「改了什麼」決定等級。另外幾條硬規定：AI 的 approve 不算人的；指揮 AI 改的人要負責；簽的是某一個 commit，之後再推新 commit 要重簽。

6. reviewer 怎麼越變越準：事故變考題

另外兩個量噪音的方法：看作者怎麼處理每則 comment（修了／說它錯／說是故意的／說不相關），以及拿已知乾淨的 PR 去跑，看會不會亂報。

7. 不能無限來回：review 要能收斂

他們的四個對策：

輪數上限超過 3 輪，reviewer 請作者退一步重想做法。

後面只看新 diff前幾輪之後，不再整份重審。

一次點出整類 bug讓作者把所有同類位置一起修掉。

不重複報已經報過的不再報一次。

原文的實際數字：做了收斂改善之後，大多數 PR 一兩輪就過，很少再出現來回拉鋸。

8. 機器做什麼、人做什麼

交給機器

• 逐行讀 diff、找 bug
• 安全掃描
• lint、型別、各平台測試
• 合併前用最新 main 重跑
• 低風險改動直接放行

留給人

• 這東西該不該做（方向、範圍）
• 高風險 code：計費、自動更新、CI
• 之後會被別人照抄的架構
• 看證據判斷：檢查會漏掉什麼？說不出來就要求真的 review
• 為結果負責：誰下指令讓 AI 改的，誰負責

他們把資深工程師從「每個 diff 都讀」改成「只做機器不擅長的決定」。為了例行小錯把資深的人拉進來，成本比自動 review 高太多。

9. 配套的團隊習慣

你合的，你修改動合進去後壞了，通常由作者修，因為作者最有脈絡。不是在究責。

改動要小、要能撤影響範圍越大，檢查越嚴。

想懂某塊 code，請 Claude 寫說明不靠讀別人的 diff 學 codebase，幾分鐘就有一份照現況寫的說明。

方向不對就早點講agent 寫 code 很快，關掉一個 PR 不可惜。不要等寫完才用擋 merge 的 comment 反對。

圖為依原文內容重畫的示意圖。數字（90%、翻倍、−40%、65%→78%、8.9%→1.5%、2.08→1.32、59%、50 多輪、3 萬個改動）來自 原文；圖 3 的長度是示意。