[情報] Matt Pocock：PR 卡關，先在人看之前把關
如果你的團隊已經讓 coding agent 開 PR，review 卻越排越長，這場可以直接拿來用。Matt Pocock 做過 Total TypeScript 課程，現在在 AI Hero 教工程師用 AI 寫程式，他在 AI Engineer Paris 講了一整套做法，每一步都有對應的 skill。
一、只踩油門，軟體工廠會變成垃圾大砲
現在大家都在講軟體工廠。Matt 的定義是：工作不再全靠人發起，有一部分交給 agent 或程式自動觸發。例如分類器把一則回報變成修正或重現，PlanetScale 的慢查詢報告也能自己觸發下一件事。
這些都會讓 code 越流越快。問題是只有加速、沒有煞車，最後就是一門 slop cannon，爛 PR 多到沒人碰得了、審不了，連看都不想看。
所以煞車守的是 agent 下一輪要參考的那份 code。他說裝了煞車，反而能走得更快。
二、讓人審變快，要靠前面兩層
他的煞車有三層，越往上越貴：
| 層 | 內容 | 花的是 |
|---|---|---|
| 自動檢查 | lint、測試、型別檢查、程式品質指標，每次跑結果都一樣 | CPU |
| 自動 review | agent 看測試沒抓到的問題，還有整個 codebase 的結構 | token |
| 人的 review | 人看 PR | 人的時間 |
速度變快，PR 一定變多。他的目標是讓最上面那層變快，靠的是把下面兩層做厚。他把第一原則叫 stop the slop：送出去的 code 品質高，人要出手的次數就少。
自動檢查最便宜。測試抓到 bug、agent 再花 token 去修，他覺得這筆錢花得值。他認為大部分團隊的檢查都疊得不夠多，用法也不夠有創意。
- 在 repo 裡多疊幾種自動檢查，能交給 CPU 的，就不要留給 token 或人。
三、CI 全綠，不代表可以 merge
測試全部通過，看起來就能 merge。Matt 說不行，自動檢查也會說謊，上面兩層 review 的工作就是測謊。他舉了三種自己抓到的謊：
| 哪種謊 | 他抓到的例子 | 為什麼有問題 |
|---|---|---|
| 套套邏輯 | 程式寫 X_POST_CHARACTER_LIMIT = 280，測試就寫「預期它是 280」 | 只是把實作再抄一次，常數改名測試就壞 |
| 綁死結構 | 要確認畫面上影片區塊排在內容規劃後面，卻不 render，直接讀原始檔比位置 | 原始碼寫法一改就失敗，功能其實沒壞 |
| 根本不會失敗 | useAudioBoost 裡的 AudioContext 被換成假方法 | 真正複雜的錯誤情況測不到，上線才炸 |
他也說 agent 不是故意的。它照你的指令寫測試，只是寫得太貼著程式結構，沒有真的去跑行為。
四、用深模組，讓測試很難作弊
測試會說謊，他的解法是從 codebase 的設計下手。深模組是 John Ousterhout 在《A Philosophy of Software Design》裡的說法：把很多複雜的行為藏在一個很小的介面後面。
介面小，測試只能從介面打進去，綁死結構的測試自然變少。他說你的工作是逼 agent 用那個小介面，不要讓它伸手去測實作細節。
他有一支 skill 可以掃過再亂的 codebase，產出一份 HTML，列出哪些地方可以合併成深模組，你挑一個再動手改。他也整理了一套描述模組的固定說法，像 locality、seam、leverage，讓團隊討論架構時講的是同一件事，對 agent 也有用。
- 要求 agent 的測試只打在模組對外的介面上。
- 拿他掃 codebase 的 skill 找出可以合併成深模組的地方，挑一個改。
五、寫法規範交給另一個 review agent
大部分人把團隊的寫法規範放進 AGENTS.md，讓寫 code 的 agent 一邊寫一邊照做。Matt 認為這樣錯了。
寫 code 的 agent 在同一個 context window 裡要找檔案、改 code、跑檢查和除錯，本來就很滿。再塞規範進去，每件事都會做得比較差。review 的 agent 拿到的是 diff，只需要稍微看一下周邊，不用改 code 也不用除錯，反而很空，可以放一大堆規範。
他的 code-review skill 收一份 diff，讀 repo 裡的 CODING_STANDARDS.md，在子 agent 裡檢查有沒有照做。規範也要自己養。很多人想直接用 Cursor Bugbot、CodeRabbit 這類第三方服務，他自己試過寫通用的 review skill，寫得太泛就一堆不相干的誤報，寫得太專，像只管 TypeScript，寫 Rust 的人又不能用。那些沒人讀的團隊文件，正好可以搬進這份規範。
- 把寫法規範從 AGENTS.md 搬到 CODING_STANDARDS.md，只給 review agent 讀。
- 自動 review 用自己團隊累積的規範，在團隊裡共用。
六、review agent 找到問題就直接改
很多人讓 review agent 在 PR 底下留言。Matt 說這等於幫人增加工作：人要讀完一堆囉嗦的留言，再一則一則決定要不要改。
這樣人打開 PR 時，看到的是已經整理過的成品。他也勸大家別再想著一次就讓寫 code 的 agent 寫出完美的 code。
- 把 review agent 的預設從留言改成直接 commit。
七、人只要仔細看回不去的改動
前兩層跑完，才輪到人。他還在做的 PR skill 第一個原則是：不是每個 review 都一樣重要。分法借用 AWS 的單向門、雙向門。
大部分 PR 是雙向門，merge 之後隨時可以撤回。他說這是軟體工程師的福利，土木工程師做錯了橋就垮了。
單向門不一定長得很大。一個很小的改動，可能不小心寄信給六萬個人；牽涉昂貴的資料遷移或可能掉資料，也算。這種 PR 要看到爛。
另一個要看的是爆炸半徑，也就是出錯時會壞多大。他的 PR 描述最底下有一塊 merge danger，寫這是哪種門、半徑多大。看到「雙向門、影響範圍小」，他就稍微看一下。
- 在 PR 描述最底下加一塊 merge danger，標出單向門或雙向門，還有爆炸半徑。
- 雙向門不用每個都細看，單向門每個都要看。
八、看懂 PR 在做什麼，用圖比用字快
決定要看之後，下一步是看懂這個 PR 在做什麼。他試過很多方法，最好用的是假程式碼。
他特別感謝 HumanLayer skills repo 裡的 show-me，作者是 Dex Horthy。它把大部分文字拿掉，改用圖跟 mermaid 圖表講改了什麼、為什麼改。他舉的例子是一張小圖，一眼看出 CLI 多了一個指令、上面多了兩個 flag。
他的目標是讓人最快搞懂這次為什麼要改。
- 讓 PR 描述用假程式碼或簡單的圖，說明改了什麼、為什麼改。
九、你在 review 的，是生出 code 的那套系統
現在大家都圍著同一批 skill 檔和 steering 檔工作，等於一起在幫 agent 打造工作環境。所以產生 code 的流程，跟 code 本身一樣重要。
他的新 skill 叫 retro。丟給它一次 agent session、一個 PR 加 session，或是過去一週所有 PR，它會建議要加哪些自動檢查、CODING_STANDARDS.md 要怎麼改。它也會看 agent 找資料順不順、要不要在 AGENTS.md 加指路，工具能不能更省 token，steering 檔和 skill 有沒有太肥。
他說這是複利：每做一次人的 review，下一次 review 的品質就更高。
- 定期把 session 或一週的 PR 丟給 retro 回顧。
- 同一句 review 意見出現第二次，就把它寫成自動檢查或規範。
十、明天就能做的事
- 在 repo 裡多疊幾種自動檢查，能交給 CPU 的，就不要留給 token 或人。
- 要求 agent 的測試只打在模組對外的介面上。
- 拿他掃 codebase 的 skill 找出可以合併成深模組的地方，挑一個改。
- 把寫法規範從 AGENTS.md 搬到 CODING_STANDARDS.md，只給 review agent 讀。
- 自動 review 用自己團隊累積的規範，在團隊裡共用。
- 把 review agent 的預設從留言改成直接 commit。
- 在 PR 描述最底下加一塊 merge danger，標出單向門或雙向門，還有爆炸半徑。
- 雙向門不用每個都細看，單向門每個都要看。
- 讓 PR 描述用假程式碼或簡單的圖，說明改了什麼、為什麼改。
- 定期把 session 或一週的 PR 丟給 retro 回顧。
- 同一句 review 意見出現第二次，就把它寫成自動檢查或規範。
以上都是 Matt 在演講裡講到的做法。他那週要出 skills 1.3 版，放在 aihero.dev/skills。
※ 來源：YouTube／AI Engineer，Matt Pocock〈Fixing the PR Bottleneck〉；aihero.dev/skills；mattpocock/skills；show-me 出自 humanlayer/skills。逐字稿以 Whisper 轉寫，並對照 YouTube 字幕校正。開場約 1:50 前音訊有爆音，1:23～1:50 一段兩邊都聽不清楚，沒有寫進內文。非官方圖文整理，內容以原片為準。