pstack 是 Lauren Tan 公開的 Cursor 外掛，她自述 2026 年 8 月靠它讓 AI 代理合併約 2,500 個 PR，而且不逐一審查。 她在 Matt Pocock 2026 年 10 月 2 日的直播訪談裡把做法講得很細：代理半夜自己合併，她隔天早上翻提交紀錄抽查。聽起來像是把程式碼審查丟掉，但 pstack 的文件寫得比這句話嚴格。寫程式的代理不能憑自己的判斷合併，每一輪都要另一批沒參與撰寫的驗證代理給出乾淨結論，而且持續整合（CI）要先過。
她換掉逐一審查的東西有三樣：驗證技能、lint 規則，以及另一批專門找錯的驗證代理。一般團隊做不做得出來，要看成本和變更能不能撤回。
2,500 是她自己報的數字，而且多半是維護工作
Tan 在 2026 年 9 月 21 日公開的演講錄影標題是「我上個月把 2,500 個 PR 送上正式環境」，上個月指的是 8 月。科技媒體 The Neuron 在 2026 年 9 月 10 日的 pstack 解析引用她自己的教學文件，寫的是 8 月結算 2,462 個。流傳很廣的「每月約 2,000 個 PR」也出自她本人。The Neuron 引述她 2026 年 8 月 31 日發布的 pstack 指南第一部，說 pstack 讓她每月送出約 2,000 個 PR。幾份摘要沿用的就是這個說法。她在訪談裡的口氣更鬆，說的是「兩千個，或者不管實際是幾個」。這些都是當事人自己報的數字，目前沒有第三方稽核。
她也主動幫這個數字降溫。訪談中她說這些 PR 顯然不是 2,500 個功能，很大一部分是她稱為園藝的工作：整理程式碼、清掉代理會照抄的壞模式。讀到這個數字的人如果直接換算成 2,500 個新功能，會高估很多。
| 項目 | 數字 | 出處與日期 |
|---|---|---|
| 指南第一部的說法 | 每月約 2,000 個 PR | Tan 本人（The Neuron 引述），2026 年 8 月 31 日 |
| 演講標題的說法 | 2,500 個 PR | Tan 本人，2026 年 9 月 21 日 |
| 8 月結算 | 2,462 個 PR | The Neuron，2026 年 9 月 10 日 |
| 訪談中的說法 | 兩千個上下 | Matt Pocock 訪談，2026 年 10 月 2 日 |
| pstack 版本 | 0.15.9 | pstack 儲存庫，2026 年 10 月 5 日讀取 |
| pstack 內容 | 26 個工作流技能、24 條原則、23 份劇本、2 個子代理 | 同上 |
Tan 在 Meta 的 React 團隊待過，pstack 的說明文件寫她還在 React 核心團隊維護 React Compiler。她在訪談裡說自己 2026 年 3 月加入 Cursor，現在做 Grok Bot。Grok Bot 是 SpaceXAI 的常駐代理產品，依 The Next Web 2026 年 8 月 11 日的報導在當天進入測試版；同一篇報導提到 SpaceX 在 2026 年 6 月談定以 600 億美元全股票交易買下 Cursor 的母公司 Anysphere。
驗證技能先讓代理看得到自己改了什麼
Tan 說，就算完全不用 pstack，每個人的工具箱裡最該有的也是驗證技能。意思是讓代理能把程式跑起來，像一般使用者那樣操作一遍，還能自己抓追蹤紀錄和記憶體快照來除錯。
這個結論是她吃過虧換來的。2026 年 4 月初她在 Cursor 處理代理視窗卡頓，一開始全靠手工：自己看火焰圖和堆積快照，再把看到的東西轉述給代理。她形容自己是卡在代理和 Chrome DevTools 中間的人肉轉接頭。她在 Cursor 寫的第一個技能就是驗證。有了它，代理改完可以自己看結果，不滿意再改，迴圈才真的成立。
pstack 把這件事做成一個產生器。/create-verification-skill 的技能檔要求代理先讀儲存庫，再替專案寫出一份在地的驗證技能，裡面固定有六段：
- 啟動：用哪個指令把 App 開起來，怎麼判斷它已經就緒
- 健檢：一個唯讀檢查，回答這個執行個體值不值得操作
- 操作：用儲存庫裡真實的選擇器和指令，不用範例
- 證據：要截什麼、存在哪裡，而且要走真實使用者路徑
- 清理：只關掉自己開的東西，證據不能被清掉
- 輔助腳本：技能附的腳本必須可以直接執行
文件還有一句很硬的話：產生出來的技能如果從沒被實際跑過，只算草稿，不算交付物。
她順帶講了一條原則，我覺得比驗證本身更容易被忽略。工作裡需要判斷的部分留給代理，照表操課的部分寫成固定程式。起因是她發現每個代理驗證前都要重寫一次測試用的小腳本，各寫各的，有的能跑有的不能，用完就丟。她把這段做成技能內建的命令列工具，底層只是 Playwright 和 Chrome DevTools Protocol 的黏合，所有代理直接呼叫。
代理重複犯的錯，改的是環境
Grok Bot 最早幾版的程式碼擠在八個巨大的檔案裡，Tan 說每個至少一萬行。代理加功能時就繼續往裡面塞。她後來在內部框架 Dune 裡訂了很嚴的慣例：每個功能放自己的目錄，一件事只留一種寫法，不合規矩的寫法由 lint 擋下來。Dune 沒有開源，她的形容是給 Electron App 用的內部版 Next.js。
她的習慣是盯著代理在哪裡出錯，每看到一次就問同一個問題：這能不能變成一條 lint 規則，讓這種錯以後根本寫不出來。
pstack 在 2026 年 10 月 3 日、也就是訪談隔天加進的 /correct 技能，把這個習慣寫成順序。同一類錯誤出現兩次就算數，修的時候從最高層級開始試：
- 用架構消掉它：每份狀態一個擁有者，每件事一條支援的做法，刪掉代理會照抄的舊寫法
- 用型別讓壞狀態寫不出來；還是編得過，就加 lint 或 CI 檢查，錯誤訊息要直接說該改用什麼
- 測行為：任何在函式全部回傳空值時還會通過的測試，改掉或刪掉
- 文件和代理規則放最後，只留給需要判斷的事，因為代理跳過它們時什麼都不會壞
每一條新檢查都要證明它擋得住一個真實發生過的錯。這個順序跟多數團隊的直覺相反。大家習慣先在 AGENTS.md 多寫一句提醒，/correct 把那一步排在最後。
半夜自動合併之前，pstack 文件要求過這些關卡
外界轉述這套做法時常說成 AI 自己檢查、自己合併。讀 autopilot-full 劇本會發現分工切得更細：每個 PR 有一個擁有者代理從建置負責到合併，但合併的許可來自根代理彙整的驗證結論，擁有者自己說了不算。
| 關卡 | 劇本的要求 |
|---|---|
| 誰能合併 | 每個 PR 一個擁有者代理；操作者點名保留的項目，代理不得合併 |
| 驗證時機 | 擁有者宣告程式就緒的那個提交，以及之後每次改動補丁的推送，都要重跑一輪 |
| 驗證內容 | 多個獨立驗證代理平行檢查：重跑檢查、在真實介面上證明行為、稽核差異且不採信 PR 說明 |
| 合併條件 | 補丁與驗證結論相符，重新變基到主幹後 CI 通過 |
| 稽核與喊停 | 根代理每小時稽核所有擁有者代理；操作者喊停時，所有代理立刻停止寫入 |
Tan 在訪談裡的說法是，全自動模式會替每個 PR 派出一批驗證代理，實際把 App 打開到處點，找回歸和實作上的錯，找到就修，反覆到可以合併為止。她早上看提交紀錄，發現不對就撤回或修改，再補一條 lint 規則。
過夜執行的指南把交辦寫成一份合約，要有目標、完成條件、權限和退場機制。下面是把官方範例改寫成中文的版本，指令名稱照原樣保留：
/poteto-mode 我要去睡了。在從 <base> 開出的全新 worktree 裡，把所有呼叫端遷移到新的 parser。
完成的定義：舊呼叫端歸零、所有 parser fixtures 通過、舊 API 已刪除。
保留決策紀錄。提交前不用問我。
/loop 直到完成。如果卡了幾個小時仍然無解，就停下來寫清楚原因。
指南特別提醒，時間長度不能當完成條件。叫代理做四個小時，早上只會看到四個小時的動作，看不到結果。
pstack 的原則裡還有一條是不要卡在人身上：先做、交結果、讓人事後修正，但不可逆的動作保留給人確認。這句但書很重要，下一段會回來談。
2,500 個 PR 的工作，來自她不再當傳話的人
這些 PR 不是她開了 2,500 次對話換來的。使用者回報的問題散在 Slack、Linear 和社群平台，以前要她自己去看，再轉述給代理。現在她讓幾個 Grok Bot 訂閱這些管道，一看到新的錯誤回報，就送進 Cursor 的 Projects。
Projects 是 Cursor 2026 年 9 月 10 日更新日誌列出的功能，官方描述是能跨月保留脈絡、把任務派給大量子代理、不用提示就執行例行工作。Tan 把裡面的協調代理叫做幕僚長：它自己不寫程式，只負責拆任務、派工、盯進度。她說自己同時開著十個以上的幕僚長，一個管 Grok Bot 桌面版的效能，一個修使用者回報的錯，各管一攤。
為什麼不乾脆一個錯派一個代理去修。她的理由是一批回報常常出自同一個根源，分開修會重工，也看不出毛病真正在哪一層。
另一個細節我很喜歡。她有個代理專門掃 React 的危險寫法，但她不讓它直接修，只讓它把發現寫進一份文件。她每隔幾天看一次，常常發現那一串其實是同一件事。全速消化工單的時候，人和代理都容易漏掉大圖，留一個緩衝區反而比較快。
這套做法有帳單，也有做不到的地方
第一筆是 token。Tan 自己說全自動模式相當吃 token，可以調，例如把十個驗證代理降成一個。The Neuron 引用 Rob O'Shaughnessy 的對照測試：同一個專案，不用 pstack 大約 30 分鐘，用了大約一小時。差別是 pstack 那一輪抓到代理在開發過程中自己編出來的三個假結論。花兩倍時間換三個沒被合進去的錯，划不划算要看那三個錯上線後的代價。
第二筆是時間。她在訪談裡明講，走到這一步非常難，她不想把它講成裝了 pstack 就能做到的事。要花大量時間看代理在哪裡失敗，再一條一條補上護欄。
第三是邊界。Matt Pocock 問她，如果大多數 PR 都是單向門，合了就收不回來，例如會掉資料，或是醫療和金融這類領域，怎麼辦。她回答這取決於工作成果能不能被程式驗證，軟體大多可以，很難用程式驗證的領域就很難走到這一步，並且說這是個她沒有答案的好問題。
不逐一審查沒有省掉品管，只是把品管的成本從人的閱讀時間搬到 token、lint 規則和驗證腳本上。搬得動的前提是變更可以撤回，而且行為可以被機器驗證。
還沒有驗證技能的團隊，先做哪一步
還沒有驗證技能的團隊，可以照這四步導入 pstack 的做法：先做驗證技能，最後才開全自動合併。
- 先替一個 App 做出驗證技能，並且真的跑過一次。沒有這一步，後面全部不成立。
- 翻自己和代理的對話紀錄，找出反覆糾正的地方。Tan 的 recall 技能就是這樣來的，她每次開新對話都得把上一段的背景重講一遍；pstack 另有 /automate-me 會從紀錄草擬一份你自己的模式技能。
- 把出現兩次以上的錯誤，照 /correct 的順序往上修，文件排最後。
- 想過夜執行時，先用 autopilot-stack。它跑同一套擁有者迴圈但什麼都不合併，早上留一串每一節都有驗證結論的提交讓你自己看、自己合。
主持人和來賓都同意技能沒有什麼神祕，只是把流程寫成文字。Matt Pocock 自己的技能庫在 2026 年 10 月 5 日有 276,225 顆星，Tan 仍然建議每個人最後都要有一套自己的。她還說了一個趨勢：去年的技能要寫清楚該下哪條指令，現在這些可以刪掉，只留流程，技能會越寫越短。
常見問題
pstack 是什麼，可以直接讓 AI 代理不經審查合併 PR 嗎？
pstack 是 Lauren Tan 以 MIT 授權公開的 Cursor 外掛。2026 年 10 月 5 日的版本是 0.15.9，內含 26 個工作流技能與 23 份劇本。pstack 的 autopilot-full 劇本可以讓代理把 PR 一路做到合併，但條件是另一批驗證代理對同一份補丁給出乾淨結論，而且 CI 通過。Tan 本人在 2026 年 10 月 2 日的訪談裡說，光裝 pstack 做不到她的程度。
pstack 只能在 Cursor 用嗎？
pstack 的說明文件只寫了 Cursor 的安裝方式，指令是 /add-plugin pstack，並且依賴 Cursor 內建的 /loop 與雲端代理。pstack 的技能本體是 Markdown 檔，採 MIT 授權，文件鼓勵使用者分支修改；至於在其他代理工具上能不能完整運作，文件沒有寫。
pstack 的全自動合併適合金融或醫療系統嗎？
Lauren Tan 沒有說 pstack 的全自動合併適合金融或醫療系統；她在 2026 年 10 月 2 日的訪談中說，這取決於成果能否被程式驗證。對於多數變更無法撤回的系統，她表示自己沒有答案。pstack 的原則也寫明，不可逆的動作要保留給人確認。
pstack 的驗證代理會花多少 token？
pstack 的文件沒有公布 token 用量。Lauren Tan 只說全自動模式相當吃 token，驗證代理的數量可以從十個調到一個。The Neuron 在 2026 年 9 月 10 日引用的一次對照測試顯示，同一個專案用 pstack 的時間約為不用時的兩倍，約一小時對 30 分鐘。
主要來源
- Matt Pocock：LIVE: Poteto (creator of pstack) on shipping 1,000's of PR's a month at SpaceX
- Lauren Tan：how i shipped 2,500 PRs last month to production（演講錄影）
- Lauren Tan：The Complete Guide to pstack Pt. 1
- cursor/plugins：pstack README
- cursor/plugins：pstack autopilot-full playbook
- cursor/plugins：pstack create-verification-skill
- cursor/plugins：pstack correct skill
- cursor/plugins：pstack guide, Run work while you sleep
- Cursor Changelog：Cursor Projects
- The Neuron：pstack explained: Lauren Tan's system for trustworthy AI agents
- The Next Web：SpaceXAI launches Grok Bot as the agent race moves to office work
- GitHub：mattpocock/skills
Author Insight
多數團隊該學的是 autopilot-stack，全自動合併可以晚一點。理由在 Tan 自己給的條件裡：她敢讓代理半夜合併，是因為每個 App 都有驗證技能，錯了可以撤回，而且她接受驗證代理的 token 成本，她自己也說全自動模式相當吃 token。三個條件只要缺一個，例如資料庫遷移這種單向門占了變更的多數，或是團隊連一份跑得起來的驗證技能都還沒有，那就讓代理把工作做到可以合併為止，合併鍵留在人手上。等到早上抽查連續幾週都找不到需要撤回的提交，再把那個鍵交出去也不遲。
術語表
- PR（pull request）：把一組程式碼變更送進主幹前的合併請求。
- 驗證技能（verification skill）：教代理啟動 App、像使用者一樣操作並留下證據的技能檔。
- 技能（skill）：用 Markdown 寫給代理看的流程說明，可以附腳本。
- 劇本（playbook）：pstack 裡對應特定任務類型的步驟清單，例如修錯、重構、過夜執行。
- 擁有者代理（owner）：autopilot-full 裡負責單一 PR 從建置到合併的代理。
- 驗證代理（verifier）：沒有參與撰寫、專門檢查變更的代理。
- 協調代理（coordinator）：自己不寫程式，只負責拆任務、派工與追進度的代理。
- lint：靜態檢查工具，在程式執行前擋下不合規則的寫法。
- 持續整合（CI）：每次推送後自動跑建置與測試的流程。
- 單向門（one-way door）：做了就難以撤回的變更，例如會遺失資料的操作。
- 變基（rebase）：把分支的提交重新接到主幹最新位置上的 Git 操作。
