2026-09-21，Lauren Tan（@poteto）公開了原定在倫敦 Cursor Compile 的分享。影片約 38 分鐘。貼文寫上個月 2,500 個 PR。口播與開場投影片說的是 2,000 個，貢獻圖註記六個月超過 5,000 個。她沒有說明計數區間、這些 PR 是否包含自動開出的變更，或返工比例。數字只標出當時的出貨量級。

同日 Kieran Zhang 的摘要把糾正用的五層稱作 Dune。影片約 15:40 的投影片標題是 whenever you correct your agent。Dune 出現在約 26:40，指 Grok Bot 的架構。本文以這支影片為準。

2026-10-02，Matt Pocock 發布了與 Lauren Tan 的專訪影片（長度 1:06:45，社群常引用 Michael Guo 的摘要）。訪談進一步披露了「每月 2,500 個 PR」背後的關鍵機制：這不是 2,500 個獨立產品功能，而是大量維護、重構、Bug 分流與自動化修復。更重要的是，她揭露了突破人類審查瓶頸的做法——由逐行審查轉為品管抽樣，並透過 Fuzzing 驗證 Agent 實現夜間自治。

我的立場是：能同時交給 Agent 的工作量，取決於每條糾正有沒有落到不靠人記得的檢查。

你看住的 Agent 數量，是信任的結果

她畫了一張示意曲線。橫軸是 Agent 數量，刻度從 1、1 到 5、5 到 10、10 到 20，再到數百與數千。縱軸是信任。這張圖沒有對照實驗。她把自己加入 Cursor 的早期放在 1 到 5。人不在對話裡，工作就停，或做完仍然是錯的。她認為這一段最難離開。信任不夠就開出一百個 cloud agent，得到的是一堆有問題的 PR。

對照的經歷是六個月前加入 Cursor，先處理 Agents Window。內部代號是 Glass。當時 PR 不斷進來，她自己看 Chrome DevTools、performance trace 與 heap snapshot，成為瓶頸。後來她改讓 Agent 自己跑應用、抓 trace、找熱點。她說每個月 2,000 個 PR 本來不是目標，出貨量是這段投資做出來的。

她把這套環境比成米其林廚房，並在口播裡劃掉 software factory。要安排的是線上廚師、設備、訓練，以及誰在收拾。成品仍由設置廚房的人負責。

正確性來自可重跑的 CLI 與 feature map

她把驗收放在一條光譜上。近端是 verification skill，教 Agent 把應用跑起來，用 Chrome DevTools Protocol 這類介面抓 trace 與 heap snapshot。遠端是 Lean、TLA+ 這類形式化方法。她說遠端更難，而且仍是開放問題。多數團隊走不到那裡。verification skill 已經能把「功能有沒有做對」變成收得回來的證據。

她在 Cursor 做的第一個 skill 叫 Control Glass。它後來分成兩塊，都放在 skill 目錄裡。

  • CLI 每次用同一套指令啟動應用、收集 trace 與其他實測。Agent 不必在每個 session 現寫一支 script。
  • Feature map 是她稱為落地的記憶，靈感來自 sitemap。它記錄有哪些功能、使用者怎麼到達、快捷鍵，以及要點的 DOM。

只有 CLI 時，Agent 開得了應用，卻讀不懂內部 Slack 上那種很小的截圖加三個問號。Feature map 補上「使用者指的是哪一個功能」。兩塊合在一起之後，Agent 既能重跑證據，也能對上內部與外部回報。她說這套控制技能變成團隊的關鍵基礎設施，而且有自動化在維護 feature map。

正確性在這裡很窄。她的例子是結帳按鈕會不會真的把購物車結掉。效能要另外看 trace 上的數字。程式怎麼寫，她交給另一組 skills。pstack 是她整理的 Cursor plugin，裝的是她自己的工程 playbook。這支影片沒有展開 plugin。

公開文件裡，同一想法寫成專案內的驗證 skill，段落是 Launch、Doctor、Drive、Evidence、Cleanup，再加上一份 feature map。pstack 的 Verify and ship 寫的是這五段。她公開的範例再規定每個功能檔用四個標題，依序是子功能、使用者怎麼到達、harness 怎麼驅動、常見誤判。verification-skill-example 標成虛構產品 Atlas。形狀可以拿來建檔，名詞不是 Grok Bot 的規格。

任務開始前，把這五欄寫進提示或 skill，讓下一個執行者交證據：

功能與到達方式：使用者從哪裡進入，畫面或指令上怎麼到達？
成功證據：哪個輸出、畫面、DOM 狀態或 trace 算數？
失敗證據：哪種結果代表還沒修好？
驅動方式：用 skill 目錄裡的哪支 CLI，而不是現場再寫一支 script？
糾正落點：這次若要改規則，寫進哪一層？

每次糾正，從程式庫往下找能擋下它的那一層

約 15:40 起是她要觀眾記住的順序。投影片標題是 whenever you correct your agent。Agent 會沿用上下文裡已經打開的檔案，所以程式庫裡的寫法會被下一個 PR 複製。糾正若只留在對話裡，下一次還會再犯。

她排的順序是約束力由強到弱。

1. Codebase

把錯誤變成結構上做不到。資料結構、目錄邊界、合法的 import，都屬於這裡。她把程式庫稱為 Agent 最好的記憶。

2. Static analysis

lint、compiler diagnostic、CI。同一種錯誤反覆出現時，先加一條會失敗的檢查。能改程式庫讓它不可能發生時，她把檢查放在第二。

3. Rules 與 Bugbot

規則與 Bugbot 提供工作時的指引。駕駛 Agent 的人可以略過它們，Agent 也可能沒讀到。她把這層放在硬約束之後。

4. Skills

Skills 教 Agent 依某種工程做法做事，例如除錯或做功能的 playbook。它們處理寫法，仍然可能沒被用到。

5. Style guide

Style guide 只在人審查時生效。她的用法是拿審查留言當缺口清單，再把時間花到上面四層。只靠這層，PR 量上來之後沒有人看得完每一行。

停止規則：一則糾正若只留在審查留言或 style guide，就還沒有提高你能同時看住的 Agent 數量。

GitHub 的 protected branch 可以把狀態檢查設成合併門檻。Bugbot 評語本身不是這道門。要擋下的條件做成 required status check，才對得上她說的第二層。GitHub 的 protected branches 說明

Dune 把捷徑收成唯一路徑

約 26:40，Dune 的投影片標題是 Architecture for agent-sized context。副標寫著，一個窄的局部修改可以對整個 Electron 應用保持正確。這是 Grok Bot 的 client framework。

動機來自 Agents Window 的效能回退。原則是 Agent 愛走捷徑，所以捷徑必須是對的那條。這樣的程式庫對人很囉嗦，對上下文很短的 Agent 反而合適。她點名的駕駛者包括設計師、產品經理與執行長。

五個名詞各自佔目錄裡的一個位置，執行時也只有一件工作。

  • Feature 是一塊產品 UI，放在一個自己的資料夾。
  • Entrypoint 是使用者打得開的一個畫面，角色接近 route。
  • Transcript card 是某一種 entry 在畫面上的內容，由 feature 擁有。
  • Client 是 renderer 上持久的狀態，包在 hooks 與 commands 後面。
  • Host 是常駐行為，包在有型別的契約後面。她說 Host 跑在 Grok Bot 的虛擬機上。

約 27:40 的圖把 renderer 與 serving process 分開。renderer 裡是 Feature UI、Navigation、Client。另一側是 Host extensions 與 Electron main。中間是 typed edge。shared/ 放跨行程型別，每一側只 import 自己被允許的東西。她用 import 與依賴圖在 CI 裡擋下 main process 的程式被拉進 renderer。她給的幀預算是 60 fps 約 16 毫秒、120 fps 約 8 毫秒。重的工作進了 renderer，就會變成畫面上的長任務。

約 29:40 的 Host-backed feature blueprint 把一條功能收成 Feature UI、Client、Shared edge、Host extension。圖上寫著，元件不處理 IPC、Host 查詢、重試順序或行程啟動。Agent-friendly 在那張圖上的意思是，改對一個開檔案的編輯，整個應用的不變條件還在。

這些名詞綁在 Grok Bot 的 Electron 行程上。一種工作只留一條慣用路徑，跨邊界的 import 由檢查失敗，原本留在審查留言裡的知識改寫進目錄與 CI。她說花夠久之後，上下文短、推理沒那麼強的 Agent 也能寫出過得去的程式。

園丁刪的是會被複製的 workaround

約 23:40 的圖把一個 workaround 畫成會被連續複製，註記 Each copy makes the next copy likelier。她的說法是，註解或小繞路會在幾天到幾週內變成大家都在抄的寫法。

Dune 因此禁止程式註解。她原先認為註解可以標出邊界情況。後來在 Cursor 的程式庫裡看到 Agent 用註解說明自己為什麼不修真正的問題，只補一個短期解法。禁註解是為了切斷這個複製鏈。

這是 Grok Bot 的選擇。註解若只重述程式，會變成下一個 Agent 的範例。註解若寫下編譯器看不見的不變條件或相容限制，刪掉會讓下一個維護者少一條理由。註解在替「先不修」辯護時，補上缺少的檢查，並刪掉這則辯護。同一種 workaround 出現第二次，就找共同原因。

園丁的三件事，投影片寫成 delete tech debt、keep one paved path、lint against anti-patterns。

  1. 刪掉你不希望被原樣複製的既有債務。
  2. 常見工作只留一條有指引的路徑，Agent 不必猜。
  3. 看到壞模式就先寫 lint，讓它不能再長。她說不必立刻清完。lint 先止血，再排清理。

收尾標準是：這份程式庫若被下一個 Agent 整段抄走，你還願不願意。

外圈自動化排在這套檢查之後

約 30:40 她才講 Grok Bot、cloud agents、automations 與 Agent SDK。Grok Bot 在她的分工裡負責外圈，接到 Slack、Datadog、Sentry、PlanetScale 這類她隨口舉的服務，再決定要不要開 cloud agent。有人把這種彙整叫 company brain。她認為這裡用不到那麼重的系統，因為 Agent 已經會用工具。

Grok Bot routines 可以訂閱 Slack 討論串與 Sentry 告警並自動開工。Cursor automations 與 SDK 則重用同一套 skill 與規則，做更長的任務。約 34:40 的畫面是一則 cloud agent 回報，問題在舊版重現，main 上已經修好。這種回覆省下的是「還要不要發一版」的確認，前提是 Agent 真的把應用跑過。

她把這段放在信任曲線的後段。程式庫、檢查、規則與 skill 還沒有讓你離開 1 到 5 的區間時，外圈同時放大的是還沒被擋下的錯誤。

訪談補充：品管抽樣、夜間自治與雙迴圈分工

在 Matt Pocock 的原訪談中，Lauren Tan 詳盡解答了「每月 2,500 個 PR 的審查瓶頸」與「人離線後如何自治」的底層機制：

1. 品管抽樣取代阻斷式審查（Sampling over Blocking Review）

當 PR 數量來到數百甚至上千時，人類不可能扮演逐行審查的守門員（Gatekeeper）。Lauren Tan 指出，工程師的角色必須轉為米其林廚房的「品管主管（Quality Supervisor）」：

  • 不再每道菜都試吃：日常依靠自動化測試與 Fuzzing 驗收，人類只對產出進行抽樣檢驗（Sampling）。
  • 從個案修復上移至系統免疫：在抽樣中看到 Agent 走了捷徑或寫出壞味道時，重點不是手動修改那幾行程式，而是思考「為什麼目前的廚房環境允許這種壞味道發生？」隨後立即補上新的 ESLint 規則、自訂型別守衛或架構邊界，讓所有 Agent 未來都不可能再犯。

這種工作模式之所以成立，是因為軟體工程具備高度的「程式化可驗證性（Programmatic Verifiability）」。不同於法律或高風險金融，軟體變更絕大多數是可輕易還原的「雙向門（Two-way doors）」；只要環境具備足夠的自動測試與回滾機制，團隊就能安全地將審查從前置阻斷放寬為後置抽樣。

2. 黑燈工廠不是忘記程式碼，而是雙迴圈與高強度 Fuzzing

Matt Pocock 追問這是否等同於 Andrej Karpathy 提出的「Vibe Coding 黑燈工廠（Dark Factory，程式碼幾乎不復存在）」。Lauren Tan 明確反駁了這一點：程式庫與環境依然是決定品質的根本（Garbage in, garbage out）。

夜間自治之所以能讓工程師安心睡覺，依賴的是緊密分工的雙迴圈架構：

  • 外迴圈（Outer Loop，Grok Bot）：連接外部世界（Slack、X、Sentry 告警）。但外迴圈「發現問題」與內迴圈「動手修改」有著不同的節奏。外迴圈先將問題聚類至任務緩衝區（Buffer），避免每見到一個症狀就立即開出修復 Agent，造成代碼衝突或頭痛醫頭的局部補丁。
  • 內迴圈（Inner Loop，Cursor Projects / Coordinator Agent）：協調者將聚類後的任務分派給具體 Agent。當觸發 Autopilot 時，系統會為每個 PR 啟動專門的驗證 Agent，實際將應用跑起來，模擬真實使用者行為進行隨機點擊與操作（Fuzzing），主動尋找回退與異常，反覆自我修復直到確認無誤才進入合入流程。

3. 巡查紀錄與任務授權分離

以下是結合訪談概念設計的巡查紀錄格式，將「觀察到的症狀」與「產品修改授權」嚴格拆開：

finding:
  symptom: "離開頁面後仍有背景輪詢"
  entrypoint: "搜尋頁 → 離開 → 再次進入"
  evidence: "待填：對應提交與實際 trace"
  suspected_boundary: "頁面生命週期與共用訂閱管理"
  action: "record-only"
  product_edit_authorized: false

record-only 是工作授權；evidence 是判斷材料。找得到相似程式碼，只足以提出待查問題。若幾份 trace 指向同一個訂閱擁有者，再開一個有範圍與回歸條件的修復任務。這樣能把人的時間用在「是否同一個原因」，而非逐一批准長得很像的補丁。

安裝 pstack 後，驗證技能本身還要跑過

截至 2026-10-03，pstack README 的固定版本列明，control-cli 與 control-ui 放在另一個 cursor-team-kit plugin。安裝 pstack 並不表示當前專案已具備可操作的應用環境。

更具體的要求在 create-verification-skill。它要求從 repository 找出啟動命令、就緒訊號、真實操作入口、證據位置，以及多個實例能否隔離。生成技能後，還要依照技能自己的說明，完整啟動、檢查環境、操作一個已列出的功能、收集證據，再清理實例。清理後，證據必須仍在指定位置。

這裡有兩種不同的驗收範圍。第一次跑通一個功能，證明的是這份驗證技能至少有一條可用路徑，並不代表整個產品通過。後續 maintain-verification-skill則要求 feature map 中每個已列出的功能都有原始碼與實際操作覆蓋，並區分文件過期、harness 缺口與產品回歸；它的修改範圍限於驗證技能自己的目錄，不能順手改產品。

對導入者的驗收，我會保留四件事：

  • 記下被測的提交、實例與前置條件，避免操作到別人的服務
  • 保留使用者動作及其結果，不能只交一張看起來正常的最後畫面
  • 檢查應有的副作用，例如檔案、資料列或事件；測試模式省略的副作用要另列
  • 清理後重新讀取證據，確認交給下一個人的路徑仍然可用

這是對官方流程的工程化採用建議，本文沒有安裝 pstack 或測量它的成功率。停止規則：驗證入口跑不通，就回報缺少的前置條件；不能把「已生成 SKILL.md」算成環境完成。

驗收要對準最後的 patch，合併權限要另外說清楚

Michael 的摘要把人離線後的工作列為訪談主題。要判斷它能否照搬，pstack 的 Run work while you sleep提供了比「讓 Agent 自己跑」更精確的分界。

autopilot-full 面向彼此獨立的 PR，每個 PR 有一位 owner。owner 不能只靠自己的通過判定合併；從 code-ready head 開始，每次後續 push 改變 patch，都要再開一輪新的驗證。允許合併的乾淨 verdict，必須對應實際要合併的 patch。

autopilot-stack 則建立一串線性的 base-branch stack，附上每一層的驗證判定，交由人審查與合併。文件明說它不負責出貨。兩種模式共享執行與驗證能力，交付權限不同。

我的採用方式會把完成條件拆成三個可讀欄位，而不只寫「CI 綠燈」：

工作完成：目標行為已完成，未解項目逐一列明
驗證完成：證據與 verdict 指向目前的 patch，後續修改已重驗
交付權限：本次只交審查，或已明確授權合併／部署

最後一欄不能由前兩欄自動補成「可以」。測試通過不會擴大原先授權；新 push 也不能沿用舊 patch 的通過判定。對資料遷移、權限或其他難回復的修改，團隊仍須自行制定審查與回復條件，這份 playbook 沒有替所有風險提供通用答案。

因此，第一輪導入可以交付已驗證、待人審查的 stack。等證據格式、更新後重驗與停止條件確實能運作，再針對範圍明確的任務授予合併權限。PR 數量不參與這個授權判斷。

技能的本質：將思考流程物質化為語言

在訪談尾聲，Matt Pocock 與 Lauren Tan 討論了技能（Skill）的演進與本質。

  • 從程式碼模板到步驟契約：早期的技能多半在告訴模型「特定功能用什麼語法寫」；隨著前沿模型推理能力大幅提升，實作細節已不再是瓶頸。現代技能的重點是**「將工作流程與約束物質化為語言（Process materialized into words）」**——它只規定思考步驟、查驗順序與停止條件，去除死板的程式碼範本。
  • 歷史對話是專案的改善金礦：Lauren Tan 提到她在 pstack 製作的 recall 技能。當你在工作流中一再對 Agent 重複相同的指引或糾正，那個反覆出現的脈絡就具備被壓縮的價值。你可以將它壓縮成一個專案自訂的 Skill；若該條件足以客觀判定，更應進一步下沉為剛性的 ESLint 規則。

因此，各家開發者（例如 Matt Pocock 的 TypeScript 規格技能與 Lauren Tan 的執行驗收技能）不需要互斥。技能極具延展性（Malleable），團隊應根據自身的信任程度與專案需求自由拆卸、組合，甚至偷師吸收為自己的工程標準。

下一步：替最近一次糾正指定落點

翻出你最近打給 Agent 的一則糾正。填上成功證據、驅動用的 CLI，以及它現在落在五層的哪一層。若落在 rules、skills 或 style guide，寫下下一個要上移的檢查，指出哪一個目錄邊界、型別或 lint 會讓同樣的錯誤直接失敗。那個檢查進了 CI 之後，再考慮多開一條工作線。若驗證技能還沒完整跑過，這次先交出一個功能的可重跑證據，並在任務上寫清楚「交審查」或「可合併」。

若下一個問題是多個 Agent 的任務狀態與 review 排程，接著讀 Grok Bot 的工程管理迴路。若要從任務契約、狀態、權限與 trace 建立 Harness，參考 Harness Engineering 的七個控制面。

驗收能跑之後，下一個問題是怎麼決定要做什麼。她在 pstack 指南第二篇改用原型與型別草圖規劃，整理在Agent 的計畫要能被程式推翻。

若你已能把單條工作線做成可驗收結果，接下來可讀如何把多 Agent 工作從 Session 搬到可交接任務，看執行者、狀態與審查入口如何一起改變。

要把這些條件用在第一次導入，可接著讀 在 Cursor 導入 pstack 的第一個可重跑修復，逐項檢查官方 plugin 的模型配置、工具權限與本機驗收紀錄。

參考資料