轉念學 – 敏捷三叔公的學習之旅

Anthropic、Shopify、Google 怎麼重寫 Code Review

敏捷三叔公

瓶頸搬家了：從寫 code 搬到審 code

2026 年最值得注意的軟體工程變化，不是 AI 會寫 code，而是沒有人讀得完它寫的 code。Anthropic 的 monorepo 每天合併的變更，從 5 月的約 2,500 筆成長到 9 月的 30,000 筆以上。Claude Code 自己的程式碼約 90% 由 Claude 寫。Coinbase 說 95% 到 100% 的 code 是 AI 輔助產出，相當於 1,200 名工程師的產量。

寫 code 的速度變成機器速度，審 code 的速度還是人的速度。結果不是「審得慢」，而是審查品質崩盤：資深工程師開始略讀、蓋章式核准，AI 產出的 PR 平均要等 4.6 倍的時間才有人打開。產業數據也不好看：AI 產生的 PR 有 67% 第一次審查就被退，人寫的只有 16%。

這篇整理幾家知名公司和幾位知名工程師的做法。他們的共同結論很一致：不要讓人審得更快，要讓人審得更少。 但怎麼做到「更少」，走出了三條明顯不同的路線。

路線一：機器先審，人只看風險

代表是 Anthropic 的 Claude Code 團隊、OpenAI、PostHog。核心想法是把「有沒有人讀過這段 code」換成「這個變更可能出什麼錯，哪一道檢查最適合抓它」。

Anthropic：七層防線加風險分級

Claude Code 團隊公開了完整流程，2026 年 6 月到 9 月間合併的 PR 數量翻倍以上，需要 revert 的比例下降超過 40%。他們的目標寫得很清楚：大多數 PR 合併時最多只有一個人在迴圈裡，而且這個人可以是作者本人。

一個變更會經過七層：

  1. 開 PR 之前先驗證：Claude 跑測試、build、lint，再由另一個乾淨 context 的 subagent 審 diff。重複出現的 review 意見直接修在源頭：skill、lint rule、CLAUDE.md 或 REVIEW.md。
  2. 每個 PR 都先給 AI 審：多個 agent 平行找 bug，再由另一組 agent 對每個發現投票，夠多同意才貼出來。只關於風格、清理的發現直接丟掉。每個發現都必須回應，修掉或附理由關閉。
  3. 可以擋 merge 的安全審查：bug review 或 security review 有任何 open finding，PR 就不能合併。
  4. CI 檢查：lint、型別、各平台測試、build。PR template 要求寫「怎麼測的」和「怎麼 revert」。
  5. 人審依風險分級：由分類器讀變更內容決定等級，不是看作者。
  6. Merge queue、feature flag、漸進釋出：新功能先給內部員工用，再進 latest channel，stable 殿後。
  7. 快速偵測、快速 rollback：flag 不用 deploy 就能關掉，每次事故都要問「哪一層本來該抓到」。

風險分級是整套的關鍵：

風險例子需要幾個人核准
低文件、文案、內部功能、藏在 flag 後面的新增自動審查和安全檢查過了就不用
中一般產品變更，以及快取、auto-updater、system prompt 等敏感區一人
高最高風險的 code，加上一小組永遠需要兩人的路徑兩人

幾條配套規則值得抄：只有信任名單上的作者能走輕量路徑；agent 的核准永遠不算人的核准；下 prompt 讓 agent 寫 PR 的人算一個必要審查者；核准只對特定 commit 有效，新 commit 進來就要重新核准。

他們還把過去造成事故的 PR 做成 eval set，reviewer 每天對著它跑，改 prompt、工具或模型都要對它評分。另一個教訓是審查必須收斂：曾有一個 PR 在 agent 作者和 agent reviewer 之間來回超過五十輪。後來加了三輪上限、只重審新 diff、不重複已貼過的發現，一輪就過的 PR 從 65% 提高到 78%。

OpenAI：100% 的 PR 先經過 Codex

OpenAI 內部用 Codex 審所有 PR，在人看之前。Codex 掃整個 repo 而不只是 diff，會跑假設驅動的測試。核心模式是 review → fix → re-review 的自動循環，@codex fix 讓 agent 直接修。內部回報因意外 bug 造成的 release 延遲明顯減少。

PostHog：讓 agent 互審，再加一個自動蓋章員

PostHog 的原則是寫 code 的 agent 不能審自己的 code，而且要用多個不同指令、不同模型的 reviewer 互補盲點。工程師 Paul D’Ambra 的 qa-swarm 同時派出四個 reviewer（技術審查、安全稽核、模仿他本人口吻的 reviewer、XP 視角的 reviewer），再由 review-triage 把發現分成「要修」「nit」「模糊」三類，只有模糊的留給人。他說自己 60% 的 token 花在自動化 CI 和 review，一塊錢都不後悔。

更有意思的是 StampHog。工程師在 PR 上貼 stamphog label，agent 檢查：沒有衝突、沒有 changes requested；diff 不碰 deny-list 關鍵字（auth、secrets、billing、public API）；500 行、20 個檔案以內；再加一個簡單的 LLM 檢查。通過就給一個乾淨的 approval。一個月處理了 1,600 個 PR，等於少了 1,600 次 Slack 打擾。重點是：用確定性的規則把敏感 code 路由給人，LLM 只能收緊閘門，不能放寬。

路線二：審查比生成更值得燒錢

代表是 Shopify。CTO Mikhail Parakhin 的論點和多數人直覺相反：好模型平均寫出的 bug 已經比人少，但因為它寫得太多，流進 production 的 bug 總量反而增加。所以 PR 審查必須是整條流水線上「很窄的腰」。

他最在意的指標不是用了多少 token，而是生成花的 token 和審查花的昂貴 token 的比例。審查要用 GPT-5.4 Pro、Gemini Deep Think 這個等級的模型，讓幾個不同模型輪流批評、重做、再批評。這種設計 token 不多但很慢，工程師不喜歡等，可是 code 品質高很多。他說跑一堆 agent 平行工作、彼此不溝通，是燒 token 最沒效率的反模式。

市面上的 review 工具他一個都看不上，理由很坦白：這些產品的商業模式不允許在每個 PR 上燒 Pro 級模型跑一小時。所以 Shopify 自己做了 PR review 系統，搭配 Graphite 的 stacked PR。

為什麼讓模型審一小時是划算的？因為現在真正的瓶頸不是等審查，而是 code 太多之後，測試失敗的機率上升，要找出肇事的 PR、踢掉、重測、重新部署。把時間花在前面的深度審查，整體部署時間反而更短。他甚至半開玩笑說，自己一輩子反對 microservices，現在覺得它可能會因為 agent 寫 code 的速度而復活。

路線三：減少審查的輸入，而不是審查者

前兩條路線都在改「誰來審」。第三條路線動的是「送來審的東西」：讓 PR 更小、更透明、更容易驗證，審查自然就輕了。

Google：攻的是作者回應 comment 的時間

Google 的切入點和別人不同。他們量到作者平均要花 60 分鐘處理 reviewer 的 comment，而且這個時間隨 comment 數量幾乎線性成長。於是從 2023 年起，用 ML 預測 reviewer 留言需要的程式碼修改，作者在 Critique 裡一鍵套用。上線後約 7.5% 的 reviewer comment 直接由 ML 建議的 edit 解決；以 Google 一年幾千萬則 comment 的量級，等於自動處理了幾十萬則。思路不是減少人審，而是減少「審完之後」的往返成本。

Stacked PR：把大改動拆到可以一眼看完

Meta 和 Google 很早就用 stacked diff，現在 Shopify 和 PostHog 都靠 Graphite 做同樣的事。PostHog 工程師 Daniel Visca 的做法是指示 agent 把大功能拆成一疊小 PR，每個 400 行以內、只做一件事、只建立在下方的 PR 上，而且每個 PR 都要附上「跑哪個指令、預期看到什麼輸出」。由下往上合併，每一層都建立在已經驗證過的行為上，早期的錯誤不會累積。

用觀察取代推理

PostHog 的另一條原則：agent 很會解釋自己的 code 為什麼能動，解釋常常很有說服力，也常常是錯的。所以不要接受「這段 code 可以」的論證，要能看著它跑：送一個真實的 API request、讀回應、截圖、錄 GIF。看不懂 3,000 行的 PR 時，解法不是讀更多 code，而是把它拆到每一塊都能被觀察。他們的結論是一句話：觀察比審查更能規模化。

這一條和我在探索性測試系列裡談的「驗證瓶頸」是同一件事：AI 時代最稀缺的不是產出，而是能快速確認產出是對的手段。

大神們反而更保守

公司在想辦法把人拿掉，知名工程師個人卻在把自己放回去。這個落差本身就值得注意。

Mitchell Hashimoto（Ghostty 作者、HashiCorp 創辦人） 審了幾百個 AI 產出的 PR，結論不是減少審查，而是減少「值得審」的 PR。他在 Ghostty 的貢獻指南加了一條：每個 PR 必須揭露是否用了 AI。理由很務實：以前半年遇到一個爛 PR，現在每兩週一個。揭露是為了讓維護者決定要花多少心力；如果對面只是一個 AI，他就不需要耐心教。幾週內約一半的 PR 附上了揭露。

他的名言是 AI 的輸出是噪音，他要看的是貢獻者的思考過程：prompt、決定、修正。他對自己的鐵律是不理解的 code 不 commit，看不懂就停下來研究，試著自己重寫到同一個 diff。他想要的工具是「prompt blame」：指著一行 code，能看到是哪個 prompt 生出來的、人在哪裡介入。他認為這是 Git 之後最大的版本控制機會。

Andrej Karpathy 2025 年初創造了 vibe coding 這個詞，年底做 nanochat 之後承認這種方式只適合丟棄式的週末專案。Simon Willison 因此提出 vibe engineering：用 AI 寫，但人要維持工程紀律。

Coinbase 介於中間：95% 到 100% 的 code 由 AI 輔助產出，資深工程師從寫 code 變成管多個 agent，但所有 AI 產出仍強制人審。差別在分區：dashboard 類功能可以放鬆，核心密碼學和私鑰相關的部分人要盯得很緊。

三條路線其實指向同一件事

路線代表動的是什麼人留在哪裡
機器先審，人只看風險Anthropic、OpenAI、PostHog誰來審高風險 code、架構、該不該做、對結果負責
審查比生成更值得燒錢Shopify審查的深度和成本設計審查系統、決定預算比例
減少審查的輸入Google、Hashimoto、stacked PR送來審的東西看證據而不是看 code、要求透明

沒有一家放棄「人對結果負責」。Anthropic 寫得最直白：下 prompt 的人就是作者，你 land 它，你就擁有它。Coinbase 保留強制人審。Hashimoto 要求揭露和理解。

他們放棄的是另一件事：人逐行讀 code。Anthropic 說團隊裡沒有人腦中有完整的 Claude Code mental model，也不需要有；想理解某一塊，就請 Claude 寫一份只講那一塊的 explainer，幾分鐘就好，而且反映的是今天的 code。

把人從「讀每一行」移到「讀證據」，是這三條路線的共同底層。證據是什麼？測試輸出、跑了什麼指令回了什麼、截圖、reviewer 的發現。Anthropic 的判斷標準是一句話：如果你說不出自動檢查會漏掉什麼，就該要求真正的審查，而不是快速核准。

反方聲音：這是 lab 才玩得起的遊戲

Anthropic 那篇文章在 Hacker News 拿到 456 分、449 則留言，反對的聲音很集中。

第一種：這是 Google 基礎建設部落格的翻版，只有他們的規模才適用。Anthropic 有近乎無限的 token 和自家可以調的模型，其他人照抄會變成永遠依賴 token 供應。只要不是在 lab 工作，就該繼續讀 code，別讓「每個工程師三萬個 PR」變成常態。

第二種：用 explainer 取代讀 code，得到的不是知識，是搜尋。你對 diff 的理解被餵過同一套已經審過並核准它的系統，人建立 context 的那部分被低估了。

第三種最直接：讓 LLM 寫文件而且沒人讀，這是瘋了。一天三萬次 commit，還有什麼東西能稱為 review？

Shopify 的 Parakhin 自己也承認，現在大家都只是勉強把頭浮在水面上，CI/CD 流水線在吱吱作響，漏過去的 bug 在增加。Hashimoto 擔心的是另一個方向：理解債。你 ship 了你不理解的 code，債總有一天要還。這些質疑不會讓三條路線失效，但它們指出同一個前提：這些做法都建立在「出錯可以很快被發現、很快被 revert」之上。你的團隊如果沒有這個底，先別急著把人拿掉。

台灣團隊可以抄什麼

按成本由低到高排，前兩級幾乎任何團隊都做得到。

第一級：零成本，今天就能做

  • PR template 加三個欄位：怎麼測的、風險等級、怎麼 revert
  • 每個 PR 揭露 AI 使用程度（Hashimoto 的做法），讓 reviewer 決定花多少心力
  • 寫一份 REVIEW.md：這個 repo 什麼叫壞掉、哪些路徑不用看、nit 上限幾個
  • 寫 code 的 agent 不能審自己的 code，換一個乾淨 context 或換一個模型

第二級：一天可以設好

  • 在一個 repo 上加 AI reviewer（Claude Code GitHub Action、Codex 或 CodeRabbit），tune 幾週再擴大
  • 要求每個 review thread 都要關閉才能 merge，修掉或附理由
  • 審查輪數設上限，三輪之後只重審新 diff
  • 用 CODEOWNERS 和 branch protection，讓 auth、billing、CI workflow、installer 永遠需要人

第三級：需要投資

  • 寫下風險分級，由變更內容決定等級而不是作者；從嚴開始，有證據再放寬
  • 做一個 StampHog 式的自動蓋章員：用確定性規則決定什麼叫低風險，讓 agent 把這類 PR 的核准接走，人只處理被它退回來的。
  • 把每次事故和 revert 變成 eval set，每次改 reviewer 都對它評分
  • Feature flag、merge queue、一步 rollback，這是前面所有做法的前提

最後一條其實該放第一條：先量你的 revert 率和事故率，再開始減少人審。 這兩個數字不升，才算真的省了人力；升了，就只是把時間從審查搬到救火。

參考資料

發佈留言

探索更多來自 轉念學 - 敏捷三叔公的學習之旅 的內容

立即訂閱即可持續閱讀，還能取得所有封存文章。

繼續閱讀