SpaceX AI 工程師 Lauren Tan 以 10–20 個 AI 智能體處理約九成例行工作

一段一小時的深度程式開發訪談，過去兩星期，竟在科技社群之中瘋傳。 SpaceX AI 工程師 Lauren Tan（網名 poteto）的一次訪問透露；自己工作時同時運行 10 至 20 個 AI 代理，包括一個幕僚長「Chief of Staff」統籌全局，餘下三位 manager 與十一個 worker。她稱這些代理，竟處理了約九成例行工作——寫碼、測試、協調——她作為程式開發的工作，已變成審閱程式碼，並控制代理工作質素。

更具體的工作成果，就是她上月竟合併約 2,500 個 pull request（PR）。雖然說，數字可能包含大量維護改動，不等於說 2,500 個新功能；但即使打折，這個產出規模仍然驚人，只說明了一個事實：代理編排（agent orchestration）從實驗，已變成部分軟件工程師日常工作，重新定義了程式員的工作方式。

一位 Chief of Staff，三位 manager，十一個 worker

她的系統，不再是開個聊天視窗，然後叫 AI 寫碼，而是有分工的 Agent 組織。Chief of Staff 代理知道其他代理存在與狀態，負責分派與協調；三位 manager 各管一條工作線；十一個 worker 負責實際改動。上述組織結構的優點：一項任務需要多個步驟，協调不需要逐個對話框切換，而是代理之間互相傳遞，虛擬世界中分工合作。

支撐組織的是一套叫 pstack 技能庫。這個放在 Cursor 的 plugin marketplace，內容不是提示詞範本，而是工作順序：先理解現有程式碼、再選設計、然後驗證結果、審閱 diff，最後才回報完成。每一類工作有對應 playbook；每次改動要留下決策紀錄，寫明做了什麼、為什麼、證據是什麼，。

SpaceX 在 2026 年 6 月宣布以 600 億美元全股票收購 Cursor ，8 月完成交易。Lauren Tan 曾在 Cursor 工作，現在在 SpaceX AI，參與 Grok Bot 代理應用的工程。工具、模型與用戶，現在在同一個集團之內——這對她的工作方式有直接影響。

真正的瓶頸不是寫碼，而是驗證

她在訪談中反覆討論，並不是如何叫 AI 寫程式碼更快，而是如何讓 AI 自己證明做對了。pstack 指南有一句話，驗證是多數代理最慢的一步，因為通常要等人；讓代理自己做到，就不再是瓶頸；跳過它，開更多代理只會獲得到更多未經檢查的 diff。

這句話解釋了，為什麼10 至 20 個代理協同，以往不是每人都能複製。若代理不能自己跑測試、看指標、比對行為，那麼再開十個代理，只是把十份未檢查改動排在面前。她的做法是把「什麼算驗證通過」寫成規則：要看什麼證據、測試本身有沒有在驗測、數字是否可重現、誰有資格說通過。只有當驗證強到可取代人工審閱，PR 才可能自動合併。

對多數團隊而言，這是順序問題：先建立驗證能力，再增加代理數量。反過來做，很快就會碰壁撞牆——原因並非模型不夠強大，而是審閱容量不夠仔細。

2,500 個 PR 應該怎樣讀

第一，區分「改動」與「價值」。維護性 PR（改動依賴、修 lint、補測試、改文件）可以很多，但對產品價值貢獻有限；她的標準包括第二，區分「合併」與「品質」。自動合併的前提是驗證可靠；若驗證有漏洞，數量只是把風險放大。第三，區分「個人產出」與「團隊產出」。 workflow 依賴 Cursor、Grok Bot 與 pstack，這些工具與平台本身是團隊成果。

有工程師公開表示，以上方式可讓代理每日交付數十 PR；亦有報道指有團隊以代理驗證 + 隔離環境把產出推到每月二千個 PR 級別。數字計算方式不一，共同點是檢驗了產出的上限，果然取決於驗證與隔離，而不是模型的速度。

Agent orchestration 正在進入主流

Lauren Tan 一語道破工具鏈成熟後，Cursor、Claude Code、Codex 等工具在 2026 年陸續加入了多代理、背景任務與技能機制；開發人員從「寫提示詞」轉向「設計流程與驗證」。與此同時，企業把代理當成治理對象：誰能建立代理、代理能存取什麼、輸出如何審計。

這也是為什麼她的訪談網上瘋傳：Lauren Tan將一個抽象口號——代理會改變軟件工程——變成可觀察的日常：一位 Chief of Staff、幾個 manager、一群 worker，加上一條不能妥協的驗證線。大家看到一個已經在運作的組織圖。

pstack 為何成為一夜爆紅？

Lauren Tan 訪談瘋傳，很大程度展示一套可複製的工具 pstack。pstack 是 Cursor 官方插件庫內的技能包（Cursor marketplace，由 Cursor 建立並驗證）；功能頁面寫得清楚：「if you want to go fast, go deep first」——想快，先深入。pstack 目標不是寫更多源碼，而是寫更少、質素更高的源碼，代理工作流可並行而不失控。

pstack 由幾層組成：router 決定用哪個 playbook；每個 playbook 規定工作順序（理解、設計、驗證、審閱）；技能包括 /poteto-mode、負責派工的 poteto-agent、專門挑註解的 comment-sicko，以及用來清除 AI 味（slop）的 unslop。這種設計令驗證不再是人手步驟，而是流程的一部分。

訪談播出後，開發者湧到 GitHub 與社交平台尋找、複製她的工具。Cursor 官方插件庫累積約 1.46 萬星；社群移植版 pstack-claude 約 3,600 星，同一套技能樹已連接 Claude Code 與 Codex，並覆蓋 Copilot、OpenCode、Gemini 等環境；另一個 open-pstack 約 540 星，同樣以 Claude Code 與 Codex 為安裝目標。

「If you want to go fast, go deep first」成為開發人員的共享 meme，意思是寧願慢點，也先建立可驗證深度，才談並行執行與速度——回應外界對於 AI 產生 slop（低質素生成碼）的焦慮。

對香港 Lauren Tan 談話還有額外意義：Anthropic 與 OpenAI 的官方服務並不覆蓋香港（兩者的支援地區名單均不含香港；ChatGPT 亦封鎖香港 IP 與 +852 帳戶），而 Cursor 在香港可直接使用，Cursor 社群曾在香港舉辦工作坊。本地開發者更依賴 Cursor 這類可用環境，本平台就是由 Cursor 再加上 DeepSeek 等 Agent 建立的成果，因為編輯流程涉及多個系統，從寫作、數據蒐集、上網都不能一步完成；pstack 的移植版則讓香港用戶，包括有條件採用 Claude 或 Codex 開發的團隊，沿用這套驗證流程。大家工具因地而異，pstack 卻顛撲不破，萬應萬靈。

對香港團隊的建議

第一，要先把「完成」定義寫清楚。不是「代理說做完」，而是測試通過、指標達標、diff 可審查。第二，團隊的 SOP 要變成技能檔：每類任務擁有一個 playbook，代理按同一順序做事，而不是每次靠提示詞即興辦事，寫程式碼不是隨心所欲。第三，設審閱預算：以每週可審閱的 diff 數量，反推論出可同時執行的代理數目，不是說加就加。第四，保留決策紀錄：哪個代理、用哪個模型、改了什麼、證據在哪裡——作為審計與事故調查基礎。第五，安全與權限：代理能碰哪些 repo、能不能部署、憑證有效期多長，先定規則，再放大執行。

結語：Lauren 不是不寫程式，只不過是換了位置

Lauren Tan 描述容易被解讀成「工程師被取代了」，但她說的正好是相反：把時間從打字移到定義問題、設計驗證、審閱與決策。代理做的是重複部分；人做的是判斷。這種分工能否成立，取決於一個很樸素的條件——每個代理都要能證明自己的工作。沒有這個先決條件，10 至 20 個代理，只是 10 至 20 倍的待審清單。