一個工程師，一個月把 2,500 個 pull request 合併進 production。這不是打錯字，也不是團隊的數字，是她一個人的。
她叫 Lauren，網路上大家叫她 potato。她以前在 Meta 的 React 團隊，現在在 Cursor（已併入 SpaceX AI）負責 agents window 和 Grokbot。她把這段經驗做成一場演講，在 X 上拿到三百萬次觀看。Matt Pocock（Total TypeScript 的作者）後來邀她對談一小時，把演講裡沒講完的細節問清楚。
這篇文章把那一小時對談整理成白話版。你不需要用過她的工具（PAC skills）或 Cursor，因為真正值得學的不是工具，而是她怎麼想這件事：
• 為什麼模型越強，瓶頸反而越在人身上？
• 怎麼從「盯著一個 agent 改 code」走到「睡覺時 agent 自己合併 code」？
• 2,500 個 PR 到底怎麼 review？答案是：不逐一 review。
先講結論：她能做到這件事，不是因為她的 AI 比較聰明，而是因為她花了大量時間把「廚房」整理好。接下來一節一節拆。
瓶頸不是 AI，是你說不清楚自己要什麼
很多人覺得 AI 越強，專業知識就越不值錢。Lauren 的看法完全相反：專業知識比以前更重要。
她的理由很簡單。當模型已經強到可以完成大部分任務，卡住進度的就不再是模型，而是你能不能把「我到底要什麼」講清楚。一個懂醫療、懂法律、懂某個產業的人，只要稍微會用 agent，就能做出很好的產品，因為他腦中的畫面很清楚。反過來，一個不懂領域的人，再會下 prompt 也只是在猜。
兩人都提到一個觀察：語言本身就是槓桿。有些詞彙是高度壓縮的，一個詞裡面塞了大量的意圖。例如：
• 叫 agent 用 TDD，重點不是它有沒有嚴格照步驟做，而是它會開始先想測試、用不同的順序思考問題。
• 叫 agent 刪掉 tautological tests（白話說就是「怎麼寫都會過」的測試：例如預期值直接抄自實作，或 mock 回傳什麼就斷言什麼，程式寫錯了它也抓不到），一個詞就讓它知道哪些測試是垃圾。
所以她花很多時間在想：怎麼把我的經驗抽出來，變成 agent 看得懂的文字。這就是 skill 的起點。她一開始的目標只是「教 agent 寫 code 寫得像我、做事做得像我」。
換句話說，你多年累積的判斷力沒有被 AI 取代，它只是換了一個出口：從你的手，變成你的語言。
別叫它工廠，叫它米其林廚房
最近「軟體工廠（software factory）」這個詞很紅，但 Lauren 不喜歡它。工廠讓人聯想到量產、便宜、不講究，可是她和大多數做產品的人一樣，很在乎品質和手藝。她改用的比喻是米其林廚房。
這個比喻好用的地方，在於它剛好對應她說的「信任階梯（trust ladder）」：
- 家庭廚師：你一個人煮，切菜、備料、洗碗全包。這就是大部分人現在用 AI 的樣子，一個 agent，你盯著它，什麼都要自己確認。
- 多了幾個人進廚房：想像你的家人全部跑進廚房要幫忙，大多數人只會更緊張，因為他們不知道東西放哪、流程是什麼。這就是很多人一開多個 agent 就失控的原因。
- 主廚：主廚不一定自己煮，他的工作是設計整個廚房怎麼運作：什麼時候進貨、怎麼存放、誰負責什麼、每個工作站的動線。這相當於 tech lead。
- 開連鎖餐廳：廚房制度建好之後，你可以開第二家、第三家，自己只在各家之間巡視。這就是她同時跑十幾個專案的狀態。
她特別強調一件事：就算你不再自己寫 code，你的名字還是掛在成果上。所以 skill、環境、codebase 的設計，就是新時代的食材和刀具。
她還有一個很實際的提醒。很多人卡在階梯最底層，只能靠「盯緊 agent」來撐。這很耗時，耗到你根本沒空去想怎麼讓自己更有效率，就像一個只用過記事本、沒聽過 Git 的工程師，每天都在趕工，永遠沒時間磨刀。刀鈍，什麼都慢，越慢越沒時間磨刀。她認為工程師的新工作，就是先把時間花在磨刀上。
讓 AI 有手有眼：驗證才是最重要的 skill
如果整場對談只能記一句話，Lauren 會選這句：你的工具箱裡最重要的 skill 是驗證（verification）。就算你完全不用她的 skill 庫，這一個也要自己做。
什麼叫驗證？用她的話說，就是給 agent「手和眼」。agent 不只會寫 code，還能：
• 真的把程式跑起來
• 像一般使用者一樣去點、去操作
• 需要時抓 trace、抓 snapshot 來 debug
她剛加入 Cursor 時負責修 agents window 的效能問題，天天在看 flame graph 和 heap snapshot。做了一陣子她很煩：agent 看不到結果，所以每次都是她去 Chrome DevTools 看，再把看到的東西轉述給 agent。她形容自己是 agent 和瀏覽器之間的「人肉代理（meat proxy）」。
驗證 skill 就是為了把她自己從這個位置拿掉而做的，也是她做的第一個 skill。她試過的其他 skill 再好，都沒讓她真正往信任階梯上爬，因為人還卡在中間。
為什麼驗證這麼關鍵？大家常講 agent 要有「loop」，但很多人講不清楚 loop 是什麼。她的定義很直接：一個 loop 之所以能成為 loop，是因為 agent 能自己驗證自己的工作。看不到結果，就不可能迭代；看得到結果，才能一次次修正，甚至做到「hill climbing」：給它一個評分標準，讓它自己不斷嘗試把分數推高。
現在 Cursor 內部每一個 app 都有自己的驗證 skill，而且是自動維護的。她說這已經變成團隊的基礎建設，所有人都靠它。
確定的事交給程式，判斷留給 AI
Lauren 的驗證 skill 裡面有一支自己寫的 CLI，包了 Playwright 和 Chrome DevTools Protocol。她說這支 CLI 本身一點都不厲害，就是一堆 API 的膠水。但它背後的想法很重要。
她把 agent 要做的事看成一條光譜：
• 一端是需要判斷的事：要整合多個 context、要思考、每次情況都不同。
• 另一端是純機械的事：例如把 code 從舊 pattern 改成新 pattern，步驟固定，不需要 agent 每次「重新發明」。
她的原則是：把確定性的部分抽出來寫成程式，只把真正需要判斷的部分留給 agent。skill 本身只是一層薄薄的包裝，說明這些工具怎麼用。
為什麼要這樣做？她觀察到，沒有 CLI 的時候，每個 agent 驗證前都會自己從頭「重建世界」：寫 script、測試、失敗、再寫。上一個 agent 寫好的東西，下一個 agent 不會沿用，又重來一次。這不只浪費 context，更浪費時間，而且每個 agent 做出來的都不一樣。抽成 CLI 之後，所有 agent 共用同一套工具，行為一致。
一開始她這麼做是為了省 context window（那時 compaction 還不成熟，大家都相信「壓縮過一次 agent 就變笨」）。現在 harness 進步了，省 context 的理由弱了，但「讓機械的事情穩定、讓 agent 專心在非確定性的部分」這個理由還在，而且她認為這才是 agent 被訓練出來擅長的事。
同樣的想法也用在技術遷移上。要把 codebase 從一種技術搬到另一種，大部分工作其實可以用 codemod（直接操作抽象語法樹的轉換腳本）機械化完成，不需要 agent 一個檔案一個檔案「想」。
Matt 補了一個觀察：這其實也是一種資訊隱藏。把複雜的確定性邏輯藏進 script，skill 就能保持很小，agent 讀到的指令少，反而做得更一致。
用環境取代嘮叨：讓犯錯變得不可能
很多人覺得 agent 是模型廠商調好的黑盒子，自己改不了什麼。Lauren 和 Matt 都反對這種想法：你改不了模型，但你可以改它工作的環境。
Matt 給了一個「好 codebase」的定義：好的 codebase 就是容易改、改了不容易壞的 codebase。意思是它有很多護欄，人或 agent 都被限制在很窄的路上走。
Lauren 的做法是一個固定的反射動作：每次看到 agent 犯錯，不是去修那一次，而是退一步問「怎麼讓這個錯誤變成不可能發生？」 具體的手段有：
• 寫一條新的 lint rule
• 用型別系統把不合法的狀態擋掉
• 用目錄結構和慣例限制 code 只能放在一個地方
她在 Cursor 內部做了一個叫 Dune 的框架（沒開源），她形容是「Electron app 專用的內部版 Next.js」。它的特色是 lint 規則極度嚴格，而且 codebase 設計成只有一種做法：每個 feature 有自己的目錄，用 registry 自動掃描註冊。這樣 agent 要加功能時根本不用想「放哪裡」，只會乖乖開一個新目錄，不會把東西塞進某個巨大的 god file。
這個設計是被逼出來的。Grokbot 最早的版本只有八個檔案，每個至少一萬行。她不得不把它拆開，拆的過程中才建立起這套約束。
她把這件事連到自己的 TypeScript 背景。她最喜歡 TypeScript 的「型別收窄（type narrowing）」：從一個什麼都可能的寬型別，透過 type guard 一步步縮小到「這不只是 string，是某個特定的常數」。環境的約束是同一個道理：把「可能發生的事」的空間縮到最小，你就能精確知道自己在跟什麼打交道。
好處是雙向的。agent 不用把一堆規則記在 context 裡，它只是在環境裡「撞到」規則；你也不用一直嘮叨。Matt 的說法是：規則不在 prompt 裡，在環境裡，agent 走到那一步自然會碰到。
還有一個附帶好處：這種環境不只幫 agent，也幫新進的人類工程師。一個沒有 context 的新人進來，如果環境夠好，第一天就能交出像樣的 PR，不會先開一堆低品質的 PR。
內循環與外循環：讓 AI 自己去找資訊
環境整理好之後，2,500 個 PR 是怎麼跑出來的？Lauren 說，她當然不是自己開了 2,500 個對話。她用兩個 loop 來解釋。
內循環（inner loop）：agent 工程師針對你的意圖寫 code。問題是，你交給它的意圖是一個「快照」，而快照會過期。新的 bug 回報、新的需求、後端的限制，這些資訊一直在 Slack、Linear、X、email 裡冒出來，而 agent 看不到。
外循環（outer loop）：負責把外部世界的資訊拉進來。過去這件事是她自己做的：去 Slack 看、去 X 看，再把看到的東西轉述給 agent。她又變成了人肉代理。
她的解法是把兩個 loop 接起來，讓 agent 自己拿 context：
• 外循環用 Grokbot：這類帶 connector 的個人 agent 可以訂閱 Slack 頻道、X、email、Linear。她會下這種指令：「盯著 Grokbot 桌面版的 bug 回報，發現就送到我的 Cursor project。」
• 內循環用 Cursor Projects：每個 project 有一個雲端的 coordinator agent，有自己的電腦。它不自己寫 code，像行政主廚或參謀長一樣，負責拆任務、派給 sub-agent、追蹤進度、傳遞 context。
外循環 → 內循環 → 自動合併 → 抽樣修環境
外部資訊由 Grokbot 拉進 Cursor Project，coordinator 派給 sub-agent 做，verifier 驗過才合併；人只在最後抽樣，把問題修回環境裡。
為什麼要用 coordinator，而不是一個 bug 開一個 agent？她舉了一個例子：假設一次湧進 30 個效能相關的 bug。一個 bug 一個 agent，每個 agent 只看到自己那一小塊，會重工，也看不到共同的根因。交給同一個 coordinator，它才能退一步看出「我以為問題在這裡，看完其他 bug 才發現其實在上面那一層」。
她把這套管理哲學連到以前在 Netflix 聽到的一句話：context, not control。你當然可以靠微管理逼出結果，但真正該做的是給足 context，讓工程師（和 agent）自己有辦法做決定。
她的日常就是一直問自己：這個流程裡，哪裡還需要我？agent 為什麼要問我這個問題？ 然後想辦法讓 agent 自己找到答案，而且是用真實資料，不是猜的。有人把這叫「公司大腦」或「context graph」，她覺得這些詞太複雜了，說穿了就是：把我本來要親手傳給 agent 的資訊，教它自己去拿。
除了 bug 回報，她還有「園藝（gardening）」型的例行任務。例如一個 agent 固定掃描 React 的常見陷阱。有趣的是她不叫它直接修，而是先把發現寫進一份文件。隔幾天她去看，常常發現「這十個其實是同一件事」。她的心得是：有時候留一個緩衝佇列，比立刻派一堆 agent 去修更有效，因為純執行模式會讓你看不到大局。
抽樣，不是逐一審查
每個人聽到 2,500 個 PR 的第一個反應都一樣：你怎麼 review？你的團隊一定恨死你。
Lauren 的答案是：我不逐一 review，我抽樣。
用廚房比喻，你不可能每一道出菜都親口試過，尤其當你有好幾家餐廳。她說這裡反而是「工廠」比喻比較貼切：品管主管不會檢查每一件產品，他每天進廠抽幾件，仔細看。她每天會去看 agent 寫的 PR、看它們的 code，很嚴格地挑毛病：有哪些沒效率的地方、哪些壞 pattern。
關鍵在於接下來做什麼。如果只是某個 agent 偶發的一次失誤，可以不管。但如果發現好幾個 agent 都在走同一條捷徑、都在到處複製同一個 workaround，那就是訊號：該回去修廚房了。修的是 skill、lint、型別、約束，不是那一個 agent。
這件事做夠多次之後，環境會約束到一個程度，讓你可以真的走開。
她現在的做法是 full autopilot，流程大概是這樣：
- agent 做完一個 PR。
- 系統為這個 PR 開出多個 verifier agent（可以設 10 個，也可以只設 1 個）。
- verifier 會做 fuzzing：真的把 app 跑起來、到處點、像真人一樣用，找 regression 和 bug。
- 找到問題，agent 自己修，再驗一次，直到 PR 可以合併。
- 合併。
她則是隔天早上看 commit history。看到問題就回頭處理：revert、修改、加新的 lint rule。她說她現在是「PR 合併之後才 review」。
這很耗 token，她承認。但她更強調另一件事：這不是裝一個工具就能做到的，她不想把它包裝成「用了 PAC 就有」。要走到這一步，得花很多時間看 agent 在哪裡失敗，然後很有意識地去設護欄，讓它預設就做對的事。
她也坦白說，第一天打開「黑暗工廠」模式時非常害怕，怕半夜弄壞什麼。她說那需要一點勇氣。但現在她的 agent 在她睡覺時工作，她說自己反而睡得更好了。
關於「黑暗工廠」這個詞，Matt 補了一個區分：Karpathy 原本講的 vibe coding 是「忘記 code 的存在」，但 Lauren 的做法剛好相反，code 和環境是一切的基礎，環境爛，產出就爛。所以這比較像一盞可以調亮度的燈，而不是全黑。你還是會偶爾走進餐廳嚐一口，只是不再站在每一道菜旁邊。
什麼時候不能這麼做：單向門與領域可驗證性
Matt 問了一個很尖銳的問題。有些 PR 是「雙向門」：合併了不對，revert 就好，便宜。但有些 PR 是「單向門」：會造成資料遺失，或做了無法輕易回頭的事。醫療、法律、金融這些領域，大部分的 PR 可能都是單向門。這套方法還適用嗎？
Lauren 說這是個好問題，而且她沒有完整答案。她的回答繞回同一個核心：一切取決於你能從 agent 身上得到多高品質的驗證。
• 在可驗證的領域，單向門會變成雙向門。因為在合併之前，你已經能用程式確認它是對的。
• 在很難用程式驗證的領域，你就很難走到自動合併這一步。這不是工具的問題，是領域本身的問題。
軟體工程剛好是一個相當可驗證的領域，雖然不是百分之百。數學也是一個例子：寫成證明的部分就可以被驗證。
她對未來的預測是，會出現越來越多「為 agent 設計的程式語言」。她最感興趣的是一個叫 Bend 的語言，它把程式和證明結合在一起。過去你要形式驗證，得另外用 Lean 或 TLA+ 這類語言寫證明，再用 solver 確認所有情況都涵蓋、沒有 race condition。如果語言本身就能證明程式正確，那合併就不再需要人：編譯過了、證明過了，為什麼不合併？
她的結論很誠實：這是整個產業和所有工程師接下來要一起想清楚的事，現在還沒有答案。
Skill 沒有魔法：從對話紀錄挖出自己的流程
兩人都有很多人用的 skill 庫，所以常有人問：該用 Matt 的還是 potato 的？怎麼混用？
他們的共識是：skill 就是流程寫成文字，沒有魔法，就是 markdown。如果裡面有什麼厲害的地方，也只是用字的選擇，和把抽象流程翻譯成語言時做過的思考。所以當然可以混搭，拿 Matt 的 grill-me 配 PAC 的執行 skill，或拿 wayfinder 配 potato mode，自己拼出一個新的模式。
但 Lauren 更強調另一件事：每個廚師都要有自己的一套刀。廚師換餐廳，刀是帶著走的。信任，說到底是對自己工具的信任；你花時間磨過、摸透的工具，才能做出好東西。每個人的 skill 組合都會不一樣，這是正常的。
那自己的 skill 從哪裡來？她最推薦的做法，也是 Matt 當天分享的技巧：回頭看你過去的對話紀錄。那裡面有你每一次糾正 agent、每一次不得不介入的紀錄。把這些反覆出現的介入抽成更高層次的規則，變成 skill 或 lint rule，agent 就不會再犯同樣的錯。
她把過去的對話形容為「context 的寶庫」，因為那是流程的實體化：不是你腦中的抽象想法，是真實發生過的流程，可以直接從裡面提取。她的 PAC 裡有一個叫 recall 的 skill，起點就是這樣。當時她在修 Cursor 的虛擬化相關 bug，每次開新對話都覺得「上一個對話有好多有用的 context，怎麼帶過來？」一開始是手動去翻 transcript，後來把這個動作壓縮成一個 skill，不用每次寫一篇長文叫 agent 去看哪些對話。
最後一個觀察：skill 會越來越短。去年的 skill 很像實作細節，裡面寫滿「用這個指令、那個 script」。現在模型夠強，這些可以直接刪掉，只留工作流程本身，一連串的步驟。隨著模型進步，skill 會越來越精簡。
結語：明天就可以開始的三件事
2,500 個 PR 聽起來很遠，但 Lauren 走過的路其實很清楚，而且每一步都可以從小做起。
- 先做驗證 skill。不管你用什麼工具，先想辦法讓 agent 能自己跑程式、自己看結果。這是整座階梯的第一階，沒有它，其他都是空談。
- 每次 agent 犯錯，問一次「怎麼讓它不可能再發生」。答案通常是一條 lint rule、一個型別、一個目錄慣例。不要只修那一次。
- 翻你過去的對話紀錄。找出你一直在糾正的事，把它寫成 skill。那就是你的第一把刀
她自己也說，這條路很花時間，而且第一次放手的時候會很害怕。但她的結論值得記住：瓶頸從來不是 AI 不夠聰明，而是你有沒有把廚房整理好。
發表迴響