來源說明：這篇是我對 Lauren Tan〈How I Shipped 2,000 PRs Last Month — Trusting AI Agents〉的結構化整理與延伸判讀。文中的 PR 數量、GrokBot、Dune 與團隊做法均來自她的分享，不是我的成果。原始影片可在 Lauren Tan 的 X 貼文觀看。
結論先行
這場分享真正值得記住的不是「一個月送出 2,000 個 PR」，而是：不要直接信任 agent，要建立一個能產生信任的環境。
Lauren Tan 描述的系統不是更長的 prompt，也不是同時開更多 agent。她把工程知識逐層放進可以重複執行的 verification tool、feature map、codebase convention、static analysis、CI、rules 與 skills。Agent 的產量只是結果；核心資產是這套讓錯誤更難發生、結果更容易驗證的環境。
我會把她的論點濃縮成一句話：
不要要求 agent 記住正確做法；讓正確做法成為最容易走、也最容易被驗證的路。
PR 數量是結果，不是目標
Lauren 在影片中表示，她前一個月把約 2,000 個 PR 送進 production。但她也特別說，這不是一開始設定的 KPI。真正逐步累積的是 skills、tools 與 codebase changes；當 agent 能自己取得證據，人就不再需要守在每一段對話旁邊。
這個區分很重要。只追求 PR 數量，最容易得到的是大量 review queue、回歸問題與難以維護的小修改。能安全提高 throughput 的前提，是每份變更都有清楚的 scope、驗證證據與失敗邊界。
因此我不會把 PR count 當成 agent workflow 的主要指標。更有意義的問題是：
- PR 有多少比例能帶著可重現的驗證證據？
- CI、效能門檻與 architecture boundary 擋下了什麼？
- 人工 review 花在判斷與產品取捨，還是反覆提醒相同規則？
- 變更是否夠小，可以快速理解、回滾與定位責任？
- 上線後的 regression、revert 與 support cost 是否下降？
社群討論補上的問題
使用者提供的截圖整理了影片下方的一些討論。由於截圖沒有保留每一則原始留言的可追蹤連結，下面只把它們當成讀者提出的問題，不當成逐字引言或已獨立驗證的事實。
誰在 review 自動產生的 PR？
截圖中的討論整理把一則回覆歸於 Lauren：她的 agent 會自行 merge PR，沒有人工 review。這是整串討論裡影響最大的主張，也最需要補充 context。PR count 本身無法說明變更類型分布、平均 diff、merge policy、test coverage、rollback rate 與實際 production impact。
當變更範圍很窄、architecture 已限制 blast radius、verification 足夠強，而且 rollback 已經常態化時，自動 merge 可以是合理選項。但 authorization、金流、schema migration、隱私或跨系統 contract，不應直接套用相同政策。
我會把 merge authority 明確切成不同風險層級：
| 變更類型 | 例子 | 合適的 gate |
|---|---|---|
| 範圍固定 | 文件、generated file、架構邊界內的 mechanical refactor | Automated check 與 evidence 可以足夠 |
| 可觀測 | 有 deterministic verification path 的局部 UI 或 API 行為 | 自動驗證，再搭配抽查或 owner policy |
| 高影響 | Auth、payments、destructive migration、public contract、跨 architecture boundary | Merge 前由明確的人類 owner 核准 |
目的不是所有 PR 都保留人工 review，而是把人的判斷放在目前仍無法由軟體證明的性質上。
PR 數量幾乎沒有品質語意
留言也質疑 headline metric 本身。同樣的 PR 數量，可以代表高度模板化的小改動，也可以代表真正推進產品的功能。沒有 diff 分布、測試覆蓋、regression 與 revert rate、效能變化及 user impact，這個數字很難判斷含金量。
這不會讓分享失去價值，只是改變值得複製的東西：應該學 verification infrastructure 與 constraint design，而不是追逐數字。
這套方法能不能搬到其他 codebase？
另一個合理疑問是可移植性。Lauren 的 workflow 依賴她對產品、工具鏈與 verification surface 的熟悉，也依賴 codebase 已有強 CLI control、trace 與 modular boundary。缺少這些條件的 repository，不會因為安裝同一套 agent tool 就得到相同結果。
有些工作也沒有明確的 automated oracle。UI taste、模糊的產品方向與跨團隊 trade-off，未必能被縮成 trace 或 assertion。在這些工作裡，agent 可以準備選項與證據，但最後的決策仍然需要人負責。
所以真正能移植的是順序，不是產量：
- 先讓工作可觀測；
- 再讓驗證可重現；
- 接著限制 codebase 的合法路徑；
- 前一層穩定後才擴大自動化。
人的工作只是換位置
這些討論裡最可信的解讀，不是工程師可以離場。人的角色會移到設計 harness、維護 verification、清除會被 agent 複製的 pattern，以及決定哪些事情可以委派。這更像帶領一群速度很快、但全局 context 有限的 contributor，而不是工程判斷已經不需要了。
Trust 的基礎是 verification
Lauren 一開始做的是 performance work。手動打開 Chrome DevTools、錄製 trace、查看 heap snapshot，在 PR 持續進來時無法擴展。她因此建立 verification skill，讓 agent 可以自己啟動應用程式、操作介面、收集 trace，並用真實量測判斷是否達到 performance bar。
這類 skill 有兩個互補的部分：
| 元件 | 回答的問題 | 內容 |
|---|---|---|
| Control CLI | Agent 如何穩定地操作與量測？ | 啟動 app、執行流程、收集 trace、snapshot 與結果 |
| Feature map | Agent 要去哪裡、看到什麼才算完成？ | 功能入口、使用路徑、快捷鍵、DOM target 與行為說明 |
只有 CLI，agent 會操作，卻不一定知道使用者截圖裡指的是哪個功能；只有文件，agent 知道產品結構，卻無法取得實際執行證據。兩者組合後，模糊的問題描述才能被轉成可重現的操作與可檢查的輸出。
flowchart LR
R[Issue / request] --> M[Feature map<br/>定位功能與路徑]
M --> C[Control CLI<br/>操作真實應用]
C --> E[Evidence<br/>trace · screenshot · metric]
E --> D{達到驗證條件？}
D -->|否| F[修改並重新執行]
F --> C
D -->|是| P[PR + evidence]這裡的信任不是「我覺得模型應該做對」，而是「我知道它如何證明自己做對」。
把工程知識放到最有約束力的地方
分享裡有一個很實用的排序：當人再次糾正 agent 時，不要只補一句 rule。先判斷能否把這個知識放到更可靠的層級。
| 層級 | 約束力 | 適合放什麼 |
|---|---|---|
| Architecture / data structure | 最強 | 讓不合法狀態或錯誤依賴根本無法表示 |
| Compiler / lint / CI | 強 | import boundary、型別、禁用 API、效能門檻 |
| Verification tool | 強且有證據 | 真實操作、trace、snapshot、integration result |
| Rules / skills / review bot | 中等 | 工作流程、判斷順序、常見任務 playbook |
| Style guide / human memory | 最弱 | 尚未自動化的偏好與例外 |
如果相同問題持續出現，代表知識放得太軟。能用型別表示，就不要只寫在文件；能用 lint 阻止，就不要每次 code review 再提醒；能讓 agent 自己跑 app 驗證，就不要只要求它聲稱「測試完成」。
Codebase 本身是 materialized memory
Lauren 認為 codebase 是 agent 最重要的記憶，因為 agent 會優先延伸 context 裡已存在的 pattern。這同時帶來正面與負面效果：好的 boundary 會被複製，臨時 workaround 也會被複製。
她把理想環境描述成一條 single paved path：feature 放在哪裡、怎麼 import、main process 與 renderer 如何隔離，都有清楚且可執行的限制。Dune 這套 framework 的目標，是讓 agent 走捷徑時仍然走到正確路徑。
這也解釋她提出的 gardener 角色。Gardener 不是逐行代替 agent 寫 code，而是持續清理會被複製的 pattern，把重複 correction 轉成 architecture、lint rule 或 skill，讓 codebase 維持在「下一個 agent 照著抄也安全」的狀態。
「禁止註解」不能脫離脈絡照抄
影片中最容易被斷章取義的例子，是 Dune 禁止 code comment。Lauren 的觀察是，agent 有時會用註解替 workaround 辯護，而不是處理根本問題；一旦這種 pattern 留在 repo，就可能被後續 agent 複製。
我不會把它翻譯成「所有專案都不准寫註解」。真正可移植的原則是：
- 註解若只是在替奇怪 code 解釋，先問能否讓 code 與 type 本身更清楚。
- 無法由 code 表達的外部限制、決策理由與 invariant，仍然值得記錄。
- 團隊應禁止的是會擴散的 workaround pattern，而不是機械地禁止某種 syntax。
這個例子最有價值的地方，不是規則本身，而是她如何從重複行為找出環境層級的修正。
Inner loop 與 outer loop
Lauren 把 GrokBot 描述成 outer loop：它可以接收 Slack、Sentry、Datadog、PlanetScale 等外部訊號，整理 context，再啟動 cloud coding agent。Coding agent 則負責 inner loop：讀 code、修改、驗證與提出 PR。
flowchart LR
S[Slack / alerts / telemetry] --> O[Outer-loop coordinator]
O --> W[選擇 workflow 與 context]
W --> A[Cloud coding agent]
A --> V[Verification + CI]
V --> P[PR with evidence]
P --> T[Human judgment / merge policy]重點不是一定要使用相同產品，而是把「發現工作」和「完成工作」接起來，同時保留 verification gate。沒有 gate 的自動 dispatch，只是更快地製造待審變更。
如果要在一般團隊落地
我會把這套做法縮小成以下順序，而不是一開始就建立 agent fleet：
- 選一個範圍清楚、能重現的 workflow，例如 UI regression 或固定格式的 bug report。
- 提供穩定 CLI，讓 agent 不必每次臨時發明啟動與驗證腳本。
- 建立最小 feature map，描述入口、操作路徑與完成條件。
- 規定 PR 必須附上 test、screenshot、trace 或 metric 等 evidence。
- 把反覆出現的 review comment 升級成 type、lint、CI 或 architecture boundary。
- 只有在單一 agent 的工作可穩定驗證後，才增加 parallelism 與自動 dispatch。
- 用 regression、revert、lead time 與人工 review cost 評估成效，不只看 PR 數量。
我的整理
Lauren Tan 的「米其林廚房」比 software factory 更接近這套方法：人的工作沒有消失，而是從親手處理每個步驟，轉成設計工作台、工具、品質門檻與責任分工。
對我來說，這場分享最重要的轉換是：Agent management 最後仍然是 software engineering。 Verification、architecture、static analysis、observability、small changes 與 rollback 都不是 AI 時代突然出現的新概念；差別是 agent 會把好 pattern 和壞 pattern 都更快放大，因此環境品質變得更重要。
來源
- Lauren Tan（@poteto），How I Shipped 2,000 PRs Last Month — Trusting AI Agents，原始影片。