🚨 AI-LECTURER 快訊速報｜2026-10-17｜5 分鐘速讀

🚨 Claude Code 團隊公開:AI 寫了 9 成程式碼,他們怎麼審查?

取材：How the Claude Code team does code review（Hacker News（AI 高人氣））｜完整課同日跟進，見書架
📍 真實場景
小林,一位 5 人新創公司的後端工程師

團隊開始用 AI 助手寫程式,每天多出一大堆待審的 PR(合併請求,也就是『請同事檢查我改了什麼』的申請)

😖 卡住的地方：每個 PR 都逐行讀完,人根本讀不完;但不讀又怕出事,週五晚上被叫起來修線上錯誤
💡 讀完你會知道 Anthropic 的 Claude Code 團隊怎麼把『讀程式』交給機器,並能今天就替自己的團隊設一個最小版的審查流程

⚡ 一句話講清楚

這則消息來自 Claude Code 團隊的官方部落格(在 Hacker News 上拿到 178 分)。他們說,Claude Code 自己的程式碼約 90% 是 Claude 寫的。寫得快,要審的東西就爆量:Anthropic 的大型程式庫 monorepo把很多專案放在同一個程式倉庫裡的做法,每天合併的變更從 5 月的約 2,500 筆,到 9 月超過 30,000 筆。靠人一行一行讀,幾乎不可能。

他們的做法不是『取消審查』,而是『把大部分閱讀交給機器、把人的時間留給只有人能判斷的事』。現在審查像打字時的拼字檢查,是持續進行的:多數變更在人類看到之前,Claude 已經審過並修過至少一次。目標是大多數 PR 最多只需要一位真人參與(甚至可以是作者本人),而且 revert把已經合併的變更撤回、還原成之前的樣子 與事故數不能增加。

成果數字:6 月到 9 月,合併的 PR 數量增加超過一倍,而需要被 revert 的比例反而下降超過 40%。他們用『每個 PR 的人工核准次數、人工留言數、PR 等人看的等待時間』衡量人的負擔,再用 revert 率與 incident線上服務出問題、需要緊急處理的事故 率當『護欄』,避免只是把時間從審查轉移到救火。他們也強調:『有沒有人讀過程式碼』只是個粗糙的替代指標,真正該問的是『這個變更可能出什麼錯、哪一種檢查(自動或人工)最適合抓到它』。

🏃 快速上手三步（今天就能做）

1
先量出你現在的基準花 10 分鐘統計你們倉庫最近 30 天:合併了幾個 PR、其中幾個被 revert(在 GitHub 搜尋 `is:pr is:merged revert` 或看提交紀錄標題含 Revert 的數量)、一個 PR 平均等多久才有人看。這三個數字就是你的『護欄』,之後任何流程調整都拿它比對。
▼
2
加一道機器先審的關卡在 PR 上先跑自動檢查:測試、型別檢查、linter(自動檢查程式風格與常見錯誤的工具),再試用一個 AI 審查工具(例如 Claude Code 的 /code-review 指令或 GitHub 上的 AI 審查機器人)先對 PR 留言。規則是『作者先處理完機器的意見,才請真人看』。用一週觀察真人要改的地方是否變少。
▼
3
規定只有人能判斷的才由人審,並確認能快速還原列出 3 類一定要真人看的變更(例如:資料庫結構、金流、權限設定),其餘低風險變更允許 1 位審查者即可。同時確認你能在 5 分鐘內 revert 並部署回去(練習一次:真的 revert 一個無害的小變更)。判斷標準:一個月後 revert 率與事故數沒有上升,才可再放寬。

🧠 工程思維透鏡（資深工程師看到的是什麼）

🔭 『減少人工審查』的風險落在哪?為什麼文章堅持用 revert 率當護欄?
只看審查時間會誤導:省下的審查時間可能變成事後救火的時間。revert 率與事故數是『結果指標』,能抓到審查品質下降的真實代價。權衡在於這類指標有延遲(問題上線後才看得到),所以必須搭配快速還原機制,讓每個錯誤的影響範圍小、修復成本低,這才是文章『讓錯誤容易還原』的重點。
🔭 AI 審 AI 寫的程式碼,會不會有共同盲點?
有可能:同類模型可能犯相似的錯、也漏掉相似的錯,所以不能把機器審查當成唯一防線。合理的做法是分層:確定性檢查(測試、型別、靜態分析)抓可驗證的錯,AI 審查抓模式性問題與一致性,真人專注在架構、需求是否正確、安全與不可逆操作。而且文章只提供團隊自己的數據,你的程式庫、測試覆蓋率不同,結論需要用自己的 revert 數據驗證,不能直接照搬。