一個人、一個月、兩千多個 PR
Lauren Tan 是 Cursor（現已併入 SpaceX AI）負責 Grokbot 的工程師。她在一場演講裡開頭就丟出一個數字：上個月，她一個人送了兩千多個 pull request 進 production。
這不是靠熬夜，也不是靠開一百個 agent 亂槍打鳥。她自己說，這從來不是目標。回頭看，過去六個月做的每一件事——寫 skill、做工具、改 codebase——其實都在回答同一個問題：我要怎麼在不盯著的情況下，信任 agent 做出高品質的工作？
這篇文章整理她的完整論述。對正在導入 AI coding 的台灣團隊來說，它的價值不在那個驚人的數字，而在她把「信任」拆解成可以逐層施工的工程問題。多數團隊卡在的地方，她都走過。
不是軟體工廠，是米其林廚房
Lauren 刻意不用「軟體工廠」這個詞，甚至在投影片上把它劃掉。工廠的意象是裝配線、大量複製同一個零件。但軟體開發從來不是這樣——它是創造性的工作，是在「做出一個產品」，某種程度上是藝術。
她偏好的比喻是米其林廚房。有了 agent 之後，我們不再親手烹調進入成品的每一個元件，但我們仍然要對最終端上桌的那道菜負責。而決定那道菜品質的，是廚房怎麼設置：線廚和副主廚的分工、他們受過什麼訓練、用什麼設備、洗碗工和線廚的比例。
這個比喻貫穿整場演講。她後面講的每一件事——驗證技能、lint rule、框架設計——都可以翻譯成「廚房設置」：你怎麼安排環境，讓廚師（agent）在你不在場時也能做對。廚房裡若有人老是被同一個東西絆倒，你要做的不是罵他，而是把那個東西移走，確保其他人也不會再絆到。
她的起點故事。 六個月前她剛加入 Cursor，接手新 Agent Window 的效能問題。她之前在 React 團隊待過，看起來是合適人選。但她很快發現這件事多麼手動：打開 Chrome DevTools、跑 performance trace、抓 heap snapshot，一個一個看。問題是 PR 進來的速度像一堵推不倒的牆，她根本無法得知應用的效能是不是正在退化。
挫折到一個程度，她想到：「等等，我們明明有 agent，我在幹嘛？」如果 agent 可以自己跑應用、自己抓 trace、自己讀懂 trace 找出熱點，然後自動朝更好的效能爬升呢？這個念頭成了她第一個驗證技能的起點，也成了整套方法的起點。
保母階段：為什麼從 5 個 agent 跳到 100 個這麼難
Lauren 用一張「信任曲線」描述使用 agent 的旅程。橫軸是你同時能放心運作的 agent 數量，縱軸是信任程度。絕大多數人卡在最左邊：同時操作 1 到 5 個 agent 的階段。
這個階段的特徵你一定認得：每一個對話都得盯著，不斷糾正、介入、調整方向。你一離開，事情就停擺，或者 agent 開始做錯的事。她稱這是「保母階段」。
她的判斷是：這是整段旅程中最難突破的一關，因為出口在哪裡並不明顯。多數人以為瓶頸是工具不夠好、模型不夠聰明，或自己 prompt 寫得不夠好。
她的答案很單純：你無法從 5 個跳到 100 個，是因為你還不信任 agent 的產出。沒有信任就硬開一百個 sub-agent 或 cloud agent，結果只會是一堆品質低落的 PR、一堆 regression、一堆 bug 進到 production，然後沒有人開心。
所以問題不是「怎麼開更多 agent」，而是「怎麼讓自己更信任 agent」。而信任不是心理狀態，是可以施工的東西。她的施工從驗證開始。
驗證技能：讓 agent 自己拿出證據
信任的第一塊磚是驗證（verification）。Lauren 說驗證有一道光譜：
- 門檻低的一端：教 agent 自己跑應用程式，透過 Chrome DevTools Protocol 之類的除錯協定抓效能 trace、heap snapshot，像工程師一樣除錯。
- 門檻高的一端：形式化驗證——用 Lean、TLA+ 這類工具證明商業邏輯的不變量永遠成立，應用永遠處於正確狀態。這仍是開放問題，很少團隊真的做得到。
她的立場是：就算沒有形式化方法，光靠驗證技能就能走很遠。
第一個 skill：讓 agent 操控應用
她進 Cursor 後建的第一個 skill 叫 control glass，教 agent 跑起應用、用 CDP 抓 trace。經過反覆迭代，她發現一個好的驗證技能有兩個組成，缺一不可。
第一是 CLI。 你希望 agent 每次都能用同樣的方式、可重現地跑應用、收集證據——證明程式碼有效、效能達標的實證。關鍵決定是：不要讓 agent 每次自己寫腳本。每個 session 寫出來的腳本都不一樣，結果也就無法比較。改為把一支 CLI 放進 skill 目錄裡，agent 每次就用它。然後持續投資把這支 CLI 做好，讓它能處理各種使用情境。
第二是 Feature Map。 這是她自創的詞，靈感來自網站的 sitemap。起因是一個很實際的困境：Slack 上常有人貼一張很小的 UI 截圖，附三個問號，就這樣。agent 有了 CLI 能跑應用，但完全不知道使用者在指什麼，只能用猜的。
Feature Map 是一種「具體化的記憶」：這個應用有哪些功能、使用者怎麼到達每個功能（快捷鍵是什麼、該點哪個 DOM 元素）、每個功能做什麼。它存在 skill 目錄裡、跟著 codebase 走，並且有自動化流程持續維護。
為什麼兩者合起來威力這麼大
CLI 給 agent「手」——可重現地操控應用、抓 trace。Feature Map 給 agent「地圖」——看懂內部和外部使用者模糊的回報。兩者合起來，agent 就能從一張截圖加三個問號，走到重現問題、抓出證據。
Lauren 說這套東西很快就變成團隊的關鍵基礎設施，持續有人維護。agent 能驗證自己的工作這件事，是建立信任最有力的一步。
對照台灣團隊常見的做法：很多人讓 agent 寫完程式後跑 npm test 就算驗證。那只是驗證光譜的最底層。她的做法是讓 agent 真的把產品跑起來，像 QA 一樣操作，像效能工程師一樣抓數據。
從「正確」到「高品質」：教 agent 像工程師一樣工作
驗證解決的是正確性問題。Lauren 對正確性的定義很直白：功能是否做到你要它做的事——結帳按鈕按下去，購物車真的結帳了嗎？驗證技能給你這件事的實證。
但正確不等於好。驗證不會告訴你這段程式碼的效能如何、品質如何。一個會動但寫得很糟的功能，照樣通過驗證。
這就是第二類 skill 的用途：教 agent 用真正的軟體工程師的方式工作。她做了一個叫 PAC 的 plugin，是一組 skill 的集合。靈感來自她多年工程生涯中，針對各種任務累積的工作流——除錯有除錯的 playbook，功能開發有功能開發的，原型有原型的。這些 playbook 教 agent「用你希望的方式」寫程式。
她特別點出一件事：團隊裡資深工程師的價值在這裡可以放大。他們應該貢獻一個團隊共用的 skill repository，把自己腦袋裡的做事方法寫下來，讓所有 agent 變聰明。
把這兩類 skill 疊起來，agent 不只能確認「做對了」，還能確認「做得好」。而且因為有驗證技能，你拿到的是真實數字——真正的效能指標、統計、遙測資料，而不是 agent 說「我覺得應該沒問題」。
換句話說，資深工程師的隱性知識，過去只能在 code review 時一句一句留言傳遞；現在可以變成 skill，一次寫下來，每個 agent 每次都用。
信任的五層階梯：把糾正變成環境
Lauren 認為，如果你真的相信未來程式碼都會由 agent 來寫，那最重要的工程投資就是：重新設計 codebase，讓 agent 預設就做對。她把建立信任的手段排成五層，強制力從上往下遞減。
| 層次 | 手段 | 強制力 | 說明 |
|---|---|---|---|
| 1 | Codebase 本身：架構、資料結構、慣例 | 最強，結構上不可能犯錯 | agent 的最佳記憶。它只會延伸眼前看到的模式 |
| 2 | 靜態分析：linter、編譯器診斷、CI | 強，自動擋下 | 同樣的錯一再出現時，寫成 lint rule |
| 3 | Rules（如 .cursorrules、CLAUDE.md） | 中，屬引導 | agent 可能忘了讀，操作者也可能忽略 |
| 4 | Bugbot 等自動 review | 中，屬引導 | 事後抓問題，而非事前防止 |
| 5 | Skills | 中，屬引導 | 教方法，但 agent 不一定每次都用 |
| （6） | Style guide、人類 code review | 最弱 | 只有人盯著才有效，PR 量一大就失守 |
為什麼 codebase 排第一
她反覆強調一個觀察：agent 喜歡延伸既有模式。這是 LLM 的本性——它傾向用 context window 裡已有的東西來做改動，而它讀開的檔案就是 context window 的一部分。agent 不會在每個 PR 順手幫你重構，它只會看現在有什麼，然後照著延伸。
所以 codebase 就是 agent 的記憶，而且是最可靠的一種。rules 和 skills 可能被跳過，但 agent 不可能不看程式碼。
糾正 agent 時該問的問題
當你發現自己又在糾正 agent 同一個錯誤，不要只是再糾正一次。她建議的順序是：
- 能不能改 codebase、改架構或資料結構，讓這個錯誤在結構上不可能發生？
- 不行的話，能不能寫一條 lint rule 或 CI 檢查自動擋下？
- 再不行，才疊上 rules、bugbot、skills 這些引導性的手段。
Style guide 是個大洞
她對 style guide 和人類 code review 的態度很明確：那是起點，不是終點。看人類 reviewer 在留什麼言，可以告訴你前四層還缺什麼。但如果你只靠 style guide，review 流程就有一個大洞——人得逐行看每個改動、記得留言，而以現在 PR 進來的速度，這根本不可能。
一句話總結這五層：每一次你糾正 agent，都是一次把知識編碼進環境的機會。 編碼得越靠上層，越不需要你再出現。
反模式像病毒：園丁、Dune 框架，以及禁止註解
「codebase 是 agent 的記憶」這句話有個反面，而且很危險。
你可以花時間把 codebase 設計成壞模式無法存在。但反過來，如果 codebase 裡已經有反模式——一個小小的 workaround、一行解釋 workaround 的註解——agent 會非常樂意複製它。幾天到幾週之內，那個 workaround 會散布到整個 codebase，變成所有 agent 的「事實標準」。Lauren 說這就像病毒。
她的第二個比喻因此出現：codebase 是一座花園。看起來無害的小東西，因為 agent 的複製本性，會長成一片雜草。等你發現時，已經是一個 vibe-coded、難以維護、效能一團糟的 codebase。
每個團隊都需要一個園丁
所以她主張每個團隊都需要一個角色，她稱之為「園丁」（gardener）：有人專門盯著那些會偷偷長進來的東西——雜草、害蟲——在它們擴散之前就剷除。這個角色的工作不是寫功能，而是維持 codebase 處於「你樂見 agent 照抄」的狀態。
Dune：為 agent 設計的框架
Grokbot 的客戶端建立在一個他們自建的框架上，叫 Dune。它的設計原則來自 Cursor Agent Window 的效能教訓，核心是一句話：agent 愛走捷徑，那就把捷徑設計成正確的路。
這樣的 codebase 有個奇特性質：它對人類很煩。限制很多、能做的事很少、到處都是慣例。但對 agent——尤其是 context 很少、推理能力普通的 agent——它是完美環境。
為什麼要照顧 context 很少的 agent？因為現在進 codebase 出貨的不只是工程師。設計師、PM、甚至 CEO 都可能操作 agent 去改程式。這些人很忙，沒有脈絡，你必須讓他們操作的 agent 也能預設做對。
Dune 的三個原則：
- 刪除既有技術債。 留著的技術債會被複製。
- 只留一條鋪好的路。 每件事只有一種受祝福的做法，agent 不需要猜。codebase、CI、lint rule 裡要有足夠引導，把 agent 帶上那條路。
- 看到壞模式，本能反應是寫 lint rule。 不一定要立刻清乾淨，但 lint rule 至少能止血——不解決問題，但阻止它長大。之後再派 agent 去清理。
具體做法上，Dune 有大量關於「程式碼該放哪、怎麼 import」的慣例。功能集中在單一資料夾，entry point、transcript cards、host、client 各有嚴格邊界。一個例子：Electron 主程序的程式碼禁止跑在 renderer thread。這條規則來自 Cursor 曾發生的真實事故——慢程式碼意外被 import 進 renderer，UI 開始卡頓。要維持 60fps，每個任務得在 16 毫秒內完成；120fps 則是 8 毫秒。Dune 透過 import 和依賴圖強制這個邊界，讓這類效能問題從架構上消失。
最反直覺的例子：禁止註解
Lauren 說她最好的例子，是一個看起來無害、想清楚卻很糟的模式：agent 在程式碼裡留註解。
她一開始也覺得這沒什麼。人類工程師也會在邊界條件、workaround、特別棘手的地方留 note 給自己或同事。agent 這樣做好像很合理。
但她在 Cursor 的 codebase 裡觀察到的是另一回事：agent 把註解當成藉口。它用註解說明為什麼不去解決真正的問題，然後貼一個 OK 繃、做一個短期方案了事。註解成了「我知道這裡有問題，但我選擇繞過」的正當化工具——而下一個 agent 會照抄這個做法。
所以 Dune 直接禁止註解。這不是程式碼風格的偏好，是防止一種「合理化逃避」的模式在 codebase 裡傳染。
外迴圈：環境夠可信之後，agent 就能自己開工
前面所有投資——驗證技能、工程 skill、鎖緊的 codebase、lint rule、rules、bugbot——疊在一起之後，會到一個臨界點：codebase 緊到幾乎不可能寫出壞程式。到了這裡，即使是 context 很少、推理能力普通的 agent，進來也能寫出好程式。
這時候才談得上規模化。Lauren 把這叫「外迴圈」（outer loop）。
Grokbot 可以連接 Slack、Datadog、Sentry、PlanetScale 等各種服務，把這些資訊聚合起來自己做判斷。有人把這叫「公司大腦」，她覺得不需要那麼複雜——agent 本來就很會用工具，把工具接上就好。
實際運作方式是：透過 Grokbot routines 訂閱 Slack thread 或 Sentry alert，事件一來就自動觸發 cloud agent。再加上 Cursor automations 和 SDK，可以再建更多 bot，重用同一套 agent 基礎設施去做更複雜的任務。
她秀了幾張截圖：自動重現 bug 回報、自動開 PR。重點不是這些功能本身，而是它們不需要額外蓋很多基礎設施——因為前面那些層次會複利疊加。你在 codebase 和 skill 上做的每一分投資，都讓後面的自動化更可信、更不需要人介入。
她在這裡又一次把「軟體工廠」劃掉，改稱「個人米其林廚房」。你不需要一座工廠，你需要一間設置得夠好的廚房。
結語：唯一要帶走的一張投影片
Lauren 說，如果整場演講只記得一件事，就記這個：每當你發現自己在糾正或介入 agent，停下來，從五個層次想一遍，找出最有效的切入點——
- 透過 codebase、架構、資料結構，讓這個錯誤變得不可能
- 靜態分析：lint、編譯器診斷、CI
- Rules
- Bugbot
- Skills
順序很重要。越往上，越不需要你再出現。
做完這些，再花時間用 skill 投資程式碼品質，你就會到一個境界：你對環境的信任夠深，agent 可以自由發揮，而你可以平行處理工作、讓整個團隊站在這套基礎設施上。她說這不是什麼祕密，就是大量的苦工。
給台灣團隊的三個提醒
一、瓶頸是信任，不是工具。 很多團隊在比較哪個 AI coding 工具好、哪個模型強。Lauren 的經驗說明：從 5 個 agent 到 100 個的差距，不在工具，在你有沒有把「怎麼判斷做得對不對」交給 agent。
二、每一次糾正都是在浪費或投資。 在 chat 裡再糾正一次是浪費；寫成 lint rule 或改架構是投資。資深工程師的時間應該花在後者。
三、codebase 現在是給 agent 讀的，不只是給人讀的。 既有的 workaround、TODO、「先這樣」的註解，過去頂多是技術債；現在是會傳染的病毒。導入 agent 之前，先派人當園丁。
來源
本文整理自 Lauren Tan（Cursor / SpaceX AI，Grokbot 工程師，X 帳號 @poteto）的演講：
發表迴響