010. PR 變多，不代表 review 也會自動變好｜AI 工廠真正卡住的地方
AI agent 讓「開一個 PR」變得很容易。它可以讀 issue、改 code、補測試、推 branch，甚至幫你填 PR 描述。但 Matt Pocock 在這場演講提醒的問題是：開 PR 變容易，不等於開出值得 review 的 PR 也變容易。
來源影片：EP412 - Matt Pocock 怎麼 Code Review？解決海量 PR 的五個心法，由 AI懶人報整理 Matt Pocock 在巴黎演講的重點。
這個差異，會把團隊的瓶頸從「誰來寫」推到「誰有空看」。以前工程團隊的產能被人手卡住；現在 agent 讓產出速度變快，最後堆積的反而是一排沒有人能細看的 Pull Request。
Matt 的說法很工程化：如果你的軟體工廠只有油門，沒有煞車，最後得到的會是一台「垃圾大砲」。它可以高速產出，但產出的東西會塞爆 reviewer，污染 codebase，也讓下一輪 agent 學到更差的樣子。
本文把這支 12 分鐘影片整理成一個更完整的 review 系統：三層煞車、測試測謊、實作與 review agent 分工、單向門判斷，以及把 review 意見回寫成下一輪的開發環境。
021. 要變快，先裝煞車｜把人類 reviewer 放在最貴的位置
Matt 描述的第一層變化，是「軟體工廠」開始自動流動。資料庫慢查詢報告、錯誤紀錄、排程任務，都可能自動觸發 agent 去修、去開 PR。這代表 code 流動速度會越來越快。
問題不在快，而在快到沒有任何制動。影片裡把 review 分成三層：
第一層是自動檢查，例如 lint、測試、型別檢查。這一層最便宜，花的是機器時間。
第二層是 AI review。它適合看測試沒有抓到的洞、掃規範、檢查結構、挑出可能重複出現的問題。這一層花的是 token。
第三層才是 human review。它最貴，因為花的是工程師注意力，而且這種注意力最稀缺。
這三層不是要讓流程變官僚，而是要把人的時間從低價值檢查中解放出來。人不該一遍遍提醒格式、不該手動抓每個顯而易見的 lint 問題，也不該替 agent 重複指出同一類規範違反。那些應該先被前兩層擋下來。
真正值得人的，是「這個改動的風險在哪裡」「這個抽象是不是會害後面的人誤用」「這個系統行為是不是回不去」。這些不是單純 diff 能回答的問題，而是脈絡判斷。
所以第一個可執行動作很簡單：列出你的 PR 現在會經過哪幾層。自動檢查是否完整？AI review 是否只會留言、卻不會修？人的 review 是否仍花大量時間在可機械化的事？哪一層是空的，就先補哪一層。
032. 測試也會說謊｜review 的工作是測謊，不是看綠燈
很多團隊把「測試全綠」當作可以 merge 的訊號。Matt 的提醒更尖銳：測試本身也可能在說謊。
影片裡提到一種 agent 很容易寫出的壞測試：tautological test。中文可以理解成「套套邏輯的測試」，也就是測試只是把實作再斷言一次。程式裡有一個常數是 280，測試就寫「預期這個常數等於 280」。它沒有驗證產品行為，只是把實作細節複製成另一份文字。
這種測試看起來讓覆蓋率變高，實際上會讓 codebase 更脆。因為它綁住的是寫法，不是行為。哪天常數改名、平台規則變動，功能明明沒有壞，測試卻壞了；反過來，真正的行為壞掉時，它也未必抓得到。
Matt 把解法拉回設計本身：用 deep module。深模組把複雜行為藏在小介面後面，外界只能透過穩定介面使用它。測試打在介面上，就更容易測到行為；測試打進實作細節，就更容易變成自我重複。
這裡的 review 重點不是「有沒有測試」，而是「測試到底在證明什麼」。如果測試只是重述實作，就該刪掉或改寫。對 agent 來說尤其如此，因為 agent 很容易照著眼前可見的 code 寫一份看似合理的測試，卻沒有理解真正應該保護的行為。
落地做法可以很具體：
- 規定新測試優先打公開介面，不直接綁私有實作。
- review 時看到「把常數、分支、內部函式重抄一遍」的測試，要當作壞味道。
- 對容易被誤測的模組，先重構成更深的介面，再讓 agent 補測試。
AI 讓補測試變快，但 review 要問的是：這些測試是在保護使用者行為，還是在保護當下這份實作長相？
043. 寫 code 和守規範，不一定要同一個 agent｜把 context 留給對的位置
整場影片裡，最實用的一點，是 Matt 對 context window 的分工判斷。
很多團隊會把 coding standards、命名規則、架構偏好、測試要求全部塞進 AGENTS.md 或 CLAUDE.md，希望寫 code 的 agent 一邊實作一邊遵守。Matt 認為這常常是錯位的。
原因是，負責實作的 agent 已經很忙。它要找檔案、理解現有邏輯、修改、跑測試、修錯。這個 context window 本來就很滿。你再塞一大份規範進去，可能只是讓它更分心；它可能讀了也用不上，甚至根本沒有餘裕好好執行。
反過來，review agent 的工作比較窄。它拿到的是已經產生的 diff，不必到處探索，不必負責把功能從零做到能動。它的腦袋比較空，反而適合塞進厚厚的 coding standards。
這個分工有點違反直覺，因為工程師都希望第一次就寫出好 code。但 Matt 把它拆成兩步：
第一步，實作 agent 讓功能能動。
第二步，review agent 拿規範去修，讓它變好。
這其實很像紅燈、綠燈、重構，只是兩個階段由不同 context window 承擔。寫 code 的 agent 負責綠燈；review agent 負責重構與規範。
因此，規範也不一定該全域載入。AGENTS.md 可以保留專案地圖、重要邊界、必要安全規則；細節型寫法規範可以移到 coding-standards.md，只讓 review agent 在該讀的時候讀。
更進一步，Matt 不希望 review agent 只會留言。因為留言會把工作丟回人類 reviewer：人要讀完、判斷、再決定是否修改。這等於 AI review 幫人增加了工作。
如果 review agent 找到明確問題，預設應該直接修、直接 commit。只有它不確定、涉及產品判斷或高風險決策時，才留言問人。
這個轉換很關鍵：AI review 的價值不是多產生一堆評論，而是把 PR 變成更接近可合併的狀態。
054. 人類只看最該看的門｜單向門與雙向門
即使前三層做得很好，PR 數量仍然可能很多。這時候人的問題不再是「每個 PR 怎麼看得更仔細」，而是「哪些 PR 必須看得很仔細」。
Matt 借用亞馬遜常見的單向門、雙向門框架。
雙向門，是 merge 之後可以輕易回退的改動。出錯了 revert，影響有限，大部分 PR 都屬於這類。
單向門，是一旦出去就回不來，或回來成本非常高的改動。寄出去的信收不回來，刪掉的資料救不回來，大型 migration 跑壞了也不是一句 revert 就能解決。
最麻煩的是，單向門不一定長得很大。一個看似簡單的設定改動，可能讓系統寄信給六萬個人。diff 很小，但 blast radius 很大。
所以人的 review 應該先問：這個改動如果錯了，能不能撤回？影響範圍有多大？會不會碰到資料、金錢、權限、通知、不可逆外部副作用？
Matt 的做法，是把這件事寫進 PR 描述：標註這是單向門還是雙向門，並寫出 blast radius。這讓 reviewer 不用從 diff 裡猜風險，也讓 agent 在開 PR 時先做一次風險分類。
對團隊來說，這是很低成本的改動：在 PR template 裡加一段「合併風險」。
## 合併風險
- 門型：單向門 / 雙向門
- Blast radius：會影響哪些使用者、資料、系統或外部服務？
- 回退方式：如果出錯，怎麼撤回？
雙向門可以快看，單向門要慢看。這不是降低 review 品質，而是把品質用在最值得的地方。
065. Review 的不是這次 code，而是產生 code 的系統
影片最後一個心法，是整套方法的核心：你 review 的不只是這一次的 code，而是在幫 agent 打造下一次工作的環境。
Agent 寫 code 時會看現有 codebase，會讀規範，會受測試和工具回饋影響。換句話說，codebase 本身就是 agent 的工作環境。如果環境裡有壞範例、鬆散介面、錯誤測試，agent 很容易照著再生出下一份壞 code。
因此，同一句 review 意見不要寫第二次。
如果你在兩個不同 PR 裡抓到 agent 犯同一種錯，問題就不只是那兩個 PR，而是產生它們的系統。下一次不該靠人再提醒，而該讓系統自己擋掉。
Matt 提到 retro 這種 skill：把一次對話、一個 PR，或一週的 PR 丟給它，讓它建議應該新增哪個自動檢查、哪條規範、哪個測試，或哪個流程調整。
這裡有一個很實用的優先順序：如果錯誤是機械性的，寫成自動檢查，不要只多寫一條規則。規則 agent 可能沒讀到，檢查每次都會跑。
例如：
- import 排序錯了，交給 formatter。
- 測試命名不一致，交給 lint rule。
- PR 沒寫風險分類，交給 template check。
- 某類 migration 缺回滾計畫，交給 CI 或 review checklist 擋。
- agent 一再測內部實作，就重構模組介面並補上測試指南。
這會把 code review 從一次性把關，變成系統改善迴圈。人的注意力不只用來指出錯誤，而是用來決定錯誤下次要在哪一層被攔下。
076. 明天就能做的五件事｜把 review 改成一套會學習的系統
這支影片最有價值的地方，不是鼓吹 AI review 取代人，而是把人和 agent 的分工講清楚。
AI 擅長在清楚範圍裡把事情做完：查資料、寫實作、照規範修改、補機械性檢查。人要守住的，是決策、不可逆風險，以及系統學習方向。
如果要從明天開始改，五件事已經夠用：
第一，畫出 PR 三層煞車。自動檢查、AI review、人類 review，哪層空，就先補哪層。
第二，review 測試時問「它保護的是行為，還是實作長相？」套套邏輯測試不該因為是 agent 寫的就放過。
第三，把寫作規範從全域提示拆出來。讓實作 agent 專心讓功能能動，讓 review agent 帶著 coding-standards.md 去修到漂亮。
第四，在 PR template 加上單向門、雙向門與 blast radius。人的深度 review 留給回不去、影響大的改動。
第五，每週做一次 retro。同一句 review 意見出現第二次，就把它變成自動檢查、規範、測試或流程。
AI 讓產出變快之後，工程團隊真正要設計的不是「怎麼讓 agent 多寫一點」，而是「怎麼讓 agent 寫出來的東西，經過一套會越來越好的 review 系統」。
這也是 Matt Pocock 這場演講最值得帶走的觀點：Code Review 不只是合併前的最後一道關卡，它是 AI 軟體工廠的回饋迴路。