修好 PR 瓶頸：Matt Pocock 如何把 AI 軟體工廠變成可 review 的系統

010. 這不是 PR 太多的問題｜而是 review 系統沒有跟上 AI 產能

Matt Pocock 在這場 AIHero / AI Engineer 演講裡，給了一個很直接的開場：組織以前就有大量 PR 躺著沒人 review，AI 只是把這件事放大。Agent 讓開 PR、修 bug、補測試、改檔案都變快，但它沒有自動讓 review 變快。

來源影片：Fixing the PR Bottleneck — Matt Pocock, AIHero，AI Engineer，2026 年 9 月 26 日上傳。

這也是這場演講和許多「AI 幫你寫 code」分享不同的地方。Matt 沒有把焦點放在怎麼讓 agent 一次寫出完美 code，而是把問題移到產線：當 software factory 開始運轉，工作不再全部由人類發起，bug classifier、慢查詢報告、資料庫工具、監控訊號都可能自動觸發 agent 產出 PR。那麼真正會爆掉的，不是寫 code，而是 review。

他用一個很刺耳但精準的詞描述沒有煞車的工廠：slop cannon。如果系統只有油門，最後會得到大量你看不完、碰不了、也不想 merge 的 PR。更糟的是，codebase 本身就是 agent 的工作環境；壞 code 放進 codebase，會讓 agent 下一次參考它，再生出更多壞 code。

所以這場演講其實在談一個更深的問題：AI 軟體工廠不是缺產能，而是缺回饋迴路。

021. 三層煞車｜自動檢查、自動 review、人類 review

Matt 把 PR 流程拆成三層 brake。

第一層是 automated checks。這包括 lint、test、type checking、code quality metrics。它們是 deterministic checks，便宜、可重複，不花人類注意力，也不花 token，只花 CPU cycles。

第二層是 automated review。這一層由 agent 來看 code，抓測試沒有抓到的東西，或檢查 codebase 的結構問題。它比 automated checks 貴，因為要花 token，但仍比人的 review 便宜。

第三層才是 human review。人看 PR，判斷風險、意圖、產品脈絡、系統邊界與不可逆後果。這是最貴的一層，因為花的是工程師最稀缺的資源：注意力。

這三層的目的不是拖慢流程，而是讓人類 review 更快。PR 增加時，直覺反應可能是「人要看更快」。Matt 的答案是：不要把人放在第一線處理低價值檢查，而要把前兩層做厚，讓人看到的已經是比較乾淨的 artifact。

這也改變了我們對「煞車」的想像。煞車不是反效率，它是保護速度的系統。沒有煞車，產線看似很快，實際上把成本轉嫁到後面的 reviewer，最後整條線卡死。

032. 綠色 CI 也會說謊｜Automated checks 需要測謊器

Matt 接著拆掉一個常見幻覺：green CI 不代表 code ready to merge。

Automated checks 很便宜，所以我們應該多用。但它們也會說謊。Human review 和 automated review 的角色，就是替 automated checks 做 lie detector。

第一種謊言是 tautological test：測試只是重述實作。Matt 舉的例子是，實作裡有 X_POST_CHARACTER_LIMIT = 280，agent 寫出的測試只是期待這個常數等於 280。這種測試沒有保護產品行為，只是把內部結構複製成另一份 assertion。

它的問題不是「太簡單」，而是太 structure-sensitive。常數改名，測試會壞；實作重構，測試會壞；但使用者真正關心的行為壞了，它未必能抓到。

第二種謊言更荒謬：為了測 UI 順序，不 render 畫面、不測 DOM，而是把 source file 讀進來，找某段文字是不是在另一段文字之後。這不是測 UI 行為，而是在測 source material 的排列。

第三種是過度 mock。Matt 提到 AudioContext 這類瀏覽器 API 有複雜錯誤模式。如果測試把它 stub 成一組永遠順利的假方法，測試當然會過，但 production 還是會遇到真實 API 的怪錯。

所以 review 要問的不是「有沒有測試」，而是：「這個測試有沒有真的讓錯誤變難混過去？」

043. Deep module 是讓 agent 少作弊的設計｜測行為，不測結構

Matt 對壞測試的解法，不只是叫 agent 寫好一點，而是改 codebase design。

他引用 John Ousterhout 的 deep module：把複雜行為藏在小介面後面。外部呼叫者只看見簡單介面，內部實作可以很深、很複雜，但不暴露太多可被誤用的細節。

這對 agent 特別重要。Agent 很容易抓住眼前可見的實作細節，然後把測試寫到那些細節上。當 codebase 露出很多內部結構，agent 就更容易寫出 structure-sensitive tests。

相反地，深模組迫使測試打在介面上。介面比較穩定，測試也比較接近行為。這不是單純美學上的架構整理，而是在降低 agent 寫壞測試的機率。

Matt 也介紹自己的 improve-codebase-architecture skill。它會掃 codebase，找出可以加深模組、降低重複、建立更好測試介面的機會，並輸出 HTML 報告。這類 skill 的價值，不在於它一次把架構變完美，而是替團隊找出「下一個可以讓 agent 更不容易犯錯」的結構改善點。

他還補上一組 codebase design 的共同語言：locality、leverage、seam。這些詞讓團隊能一致地討論架構，而不是每個人拿不同方法論互相撞。對 AI 團隊來說，共同語言也會變成 agent 可讀、可執行的規範。

054. 不要把 coding standards 塞進 implementer｜review agent 才有空間

整場演講裡最反直覺的一段，是 Matt 對 context window 的分工。

很多人會把 coding standards 放進 AGENTS.md 或全域提示，期待 implementer agent 一邊找檔案、一邊改 code、一邊 debug、一邊遵守所有規範。Matt 說這通常是錯的。

Implementer agent 已經 overloaded。它要探索 code、找出改動位置、修改檔案、跑測試、處理錯誤。這些都擠在同一個 context window 裡。你再把大量 coding standards 塞進去，不一定會讓它寫得更好，反而可能讓它更不穩。

Reviewer agent 則相反。它收到 diff，知道變更大概在哪裡；它需要一些探索來理解上下文，但不需要完整實作，也不需要大規模 debug。Review 是 underloaded 的 context window。

因此，Matt 建議把好 code 拆成兩步：

第一步，implementer 讓它能動。

第二步，reviewer 讓它變好。

他把這比成 red-green-refactor。不是同一個 agent 一次完成所有事，而是一個 context window 讓功能跑起來，另一個 context window 讀 coding-standards.md，替它重構、修規範、調整品質。

這有兩個實務結論。

第一，AGENTS.md 不應該無限制膨脹。它可以放專案地圖、重要邊界、導航指標與不可違反的工作規則，但細節型 coding standards 應該拆到 coding-standards.md，讓 review agent 在該讀的時候讀。

第二，automated review 不該只是 comment bot。Matt 批評一種常見做法：review agent 在 PR 底下留很多 verbose comments，結果 human reviewer 還要讀完、判斷、再決定要不要改。這不是減少人類工作，而是把工作改成另一種形式。

他的原則很清楚：reviewer should commit。明確問題就直接修、直接 commit；只有不確定、需要產品判斷或風險取捨的地方才留言。

065. 不要外包 review 的核心判斷｜建立自己的 coding standards

Matt 也談到第三方 automated review 服務，例如泛用 bug bot 或 code review 工具。他不是說不能用，而是提醒：真正有效的 review 很難完全 generic。

如果 review 太 general，就容易給出 false positives，評論看似有道理，卻不符合你的團隊脈絡。若太 specific，又難以跨語言、跨專案、跨架構使用。

所以他建議：不要把 automated review 的核心完全外包。建立自己的 coding standards，讓它隨團隊經驗累積。那些原本躺在文件裡沒人讀的規範，應該變成 review agent 會讀、會執行、會修的材料。

這個觀點對 AI 時代很重要。以前 coding standards 常常是 onboarding 文件，或 code review 時用來引用的共識。現在它更像一段可執行的團隊記憶：review agent 每次拿 diff 來對照它，並把明確問題改掉。

當文件可以被 agent 執行，文件品質就會直接影響 code 品質。這也是為什麼 Matt 一再回到「不要 bloated steering files」：規範不是越多越好，而是越可執行越好。

076. Human-friendly PR｜先標門型，再解釋變更

前兩層做好後，PR 到人類手上時，仍然需要讓人快速理解。Matt 正在做一個新的 PR skill，核心是讓 PR body 對人友善。

第一個原則是：有些 review 比其他 review 更重要。不是每個 PR 都值得同樣深度的注意力。

他借用 AWS 的 one-way door / two-way door。大部分軟體 PR 是 two-way door：merge 後可以 revert，出錯可以退回。這和土木工程不同，土木的橋錯了可能就塌了；軟體多數改動可以回頭。

但不是所有小 diff 都安全。Matt 舉例，一個看似簡單的改動如果意外寄信給 60,000 人，那就是 one-way door。涉及昂貴 migration、資料損失、不可逆外部副作用，也都是 one-way door。

因此，PR body 應該清楚寫出 merge danger：

## Merge danger

- Door type: one-way / two-way
- Blast radius: localized / service-wide / customer-visible
- Rollback: how do we recover if this goes wrong?

這段不是形式主義。它是把人的注意力導向真正該看的地方。Two-way door 可以快速掃過；one-way door 要仔細看。

第二個原則是讓 reviewer 快速理解「這個 PR 到底做了什麼」。Matt 喜歡用 pseudo code、Mermaid、UML 或簡單 diagram。好的 PR body 不只是描述，而是展示。當 reviewer 能在幾秒內看懂流程、入口、變更點與風險，human review 就會輕很多。

087. Human review 的任務不是多寫 comment｜而是改善下一次產出

Matt 最後把視角再拉高一層：我們不是只在 review code，而是在 review 產生 code 的系統。

當團隊開始共同維護 skill files、steering files、coding standards、PR templates、automated checks，這些東西合起來就是 agent 的工作環境。人類每次 review 看到的錯誤，都應該問：這是一次性問題，還是系統問題？

他的原則是：不要寫同一句 comment 兩次。

如果你在兩個 PR 裡抓到 agent 犯同一種錯，就不該期待第三次靠人類再提醒。那代表系統缺了一個檢查、規範、導航指標或工具。

這就是 retro skill 的位置。它可以回顧單次 agent session、一個 PR 加上 session，或一週的 PR 和 review，然後建議：

• 新增 automated checks。
• 更新 coding-standards.md。
• 在 AGENTS.md 加 navigation pointers，讓 agent 下次更容易找到資訊。
• 改善 tool economy，用更省 token 的工具或流程。
• 找出 bloated steering files / skills，減少無效 context。

這裡最值得注意的是 tool economy 和 bloat。很多 agent 失敗不是因為模型笨，而是工具選擇太貴、文件太腫、導航太差。人類 review 如果只指出 code 問題，沒有回饋到這些上游環境，下一次還會再犯。

098. 這套方法的真正目標｜讓 human review 變少、變快、變重要

Matt 的結論不是「人不需要 review」。剛好相反，他把人的 review 放在最高價值的位置。

Automated checks 負責便宜、確定、可重複的檢查。Automated review 負責讀 diff、套 team standards、修明確問題。Human review 負責 one-way door、blast radius、產品判斷、資料風險、不可逆副作用，以及把重複錯誤回饋到系統。

這讓 human review 變得更少，但也更重要。人不再被每個 typo、每個格式問題、每個泛泛 comment 淹沒，而是把注意力放在 agent 還不該獨自決定的地方。

所以「修好 PR 瓶頸」不是單一工具問題，而是一套設計：

1. 讓自動檢查更厚，但知道它會說謊。
2. 用 deep modules 讓測試更難作弊。
3. 把 implement 和 review 分給不同 context window。
4. 建立自己的 coding-standards.md，讓 review agent 真的 commit。
5. 用 PR body 標出 one-way door、two-way door 和 blast radius。
6. 用 retro 把重複 review 意見回饋成下一次的檢查、規範與導航。

AI 讓寫 code 的速度上升後，最危險的做法，是繼續用舊的人肉 review 方式硬扛。Matt 的答案更像工程系統設計：把 review 變成分層、可學習、可回饋的產線。

這也是這場演講最值得帶走的一句話：codebase 是 agent 工作的環境；review 的最終目的，是把那個環境變得更適合下一次產出好 code。