SpaceXAI 工程師 Lauren Tan：從盯著 agent 到一覺醒來 20 個 PR 已合併，關鍵是信任

SpaceXAI 軟體工程師 Lauren Tan 在一場由 Colin Matthews 主持的分享裡，談她怎麼從「每個 agent 的輸出都要盯著看」，走到「一覺醒來，agent 已經幫她合併了 20 個 PR」。她過去在 Meta 的 React 團隊做 React Compiler，五個月前加入現在的團隊。SpaceX 已和 Cursor 合併，她在演講裡也直接用「Cursor 和 SpaceX AI」來稱呼這個組織。這場分享沒有什麼玄學，核心只有一個字：信任。而信任要靠工程手段一層一層建立起來。

信任曲線：像帶團隊一樣帶 agent

Lauren Tan 用管理來比喻。如果一位工程主管不信任自己的團隊，就只能微管理，整天站在部屬背後檢查有沒有把 bug 推上線。用 agent 寫程式也一樣：agent 一再自信滿滿地宣稱「找到真兇了」，結果第一百次還是錯的，你的信任就會被消耗光，只能緊盯一兩個 agent，根本不可能平行開出一百個。

她畫了一條自稱「不太科學」的信任曲線，對照自己加入後的產出：第一個月還在摸索程式碼庫，幾乎沒什麼產出；上個月合併了一千個 PR，這個月才到 12 號就快 800 個。她也坦白，大家一定會懷疑這些程式碼的品質，這個質疑很合理，所以整場演講就是在回答「她是怎麼走到這一步的」。

最重要的技能是驗證

她認為和 agent 合作時，工具箱裡最重要的能力是「驗證」：讓 agent 自己把程式跑起來，抓 CPU trace、heap snapshot、開 iOS 模擬器，用和使用者一樣的方式操作產品，真的確認它能動。這不保證程式碼寫得好，但至少能保證寫得對，而這正是建立信任的第一步。

她舉了自己的例子。她剛加入時，原本要去 cloud agents 團隊，但因為熟 React，被拉去支援用 React 寫的 agents window，而且一週後就要上線。她只好打開 Chrome DevTools 自己看 flame graph，截圖丟給 agent，agent 也只會含糊地說「看起來是這個」。沒有驗證能力時，人就是驗證者，也是整個流程的瓶頸。

於是她做的第一批 skill 之一，就是讓 agent 能直接操控 agents window（內部代號 Glass）的 control skill。但光能操控還不夠，agent 不知道「左邊側欄很卡」指的是哪裡。她的解法是一份 feature map：把每個功能的位置、子功能、快捷鍵、甚至可以用來選取的 DOM 屬性都寫清楚。內部的回饋頻道裡，常見的回報只是一張截圖加三個問號，有了 feature map，agent 才有足夠的脈絡去理解這到底在說什麼。

Pstack：從 agent 的失敗模式長出來的工具箱

Pstack 的名字很有梗。Y Combinator 的 CEO Garry Tan 做了一個叫 GStack 的外掛，Lauren Tan 跟他同姓但沒有親戚關係，於是取名 Pstack，P 是 potato，她在 X 上的帳號就叫 Potato，順便鬧一下 Garry。

她說自己從沒打算做一整套工具，Pstack 是一個一個 skill 累積出來的。每次看到 agent 出現某種失敗模式，例如沒有真的去讀相關程式碼就下結論，她就把對策寫成一個 skill：別猜，去查程式碼，多用 sub agent。她再次用新人來比喻：一個寫程式很強、但完全沒有業務脈絡的新同事，你要用 skill 教他。skill 只是 Markdown，但高品質的指示能把模型的表現拉到更好的水準。

用 eval 維護 skill

主持人 Colin Matthews 轉達聊天室的問題：產品一直在變，skill 怎麼維護？又怎麼知道驗證夠不夠好？Lauren Tan 的答案是 eval，她把它理解成「給 agent 的單元測試」。Pstack 裡的 Eval playbook 會讓主協調 agent 先訂評分標準，再開出許多 sub agent 去跑，每個 sub agent 的目錄名稱還刻意取得不讓它知道自己在被評估，因為 agent 察覺被測試時會改變行為。也可以找另一個模型當評審，避免偏誤，再用 /loop 讓它一路爬分到 10 分滿分。Cursor 支援很多模型，所以同一個 skill 可以在不同模型上交叉測試。

這段還有個小插曲：分享到一半，她的畫面被觀眾畫得一片紅，她笑說自己被整了，只好請大家別再在螢幕上畫圖，主持人也在一旁教她怎麼清掉。

她也提醒，維護 skill 需要品味和觀察力，要像結對程式設計時那個愛在旁邊碎念的同事一樣，打開 agent 的每個 tool call 和思考過程，看它在哪裡失敗。她把工程師的新角色比喻成餐廳主廚：你不再自己炒每一道菜，而是設計廚房、分派各個工作站。

先在本機建立信任，再放到雲端

主持人追問實際該從哪裡開始。Lauren Tan 建議先在本機做，因為看得到 agent 怎麼和應用程式互動。等信任建立了，她自己幾乎全面改用 cloud agents。好的 verification skill 不只讓一個工程師變強，而是讓整個團隊、整間公司受惠。例如內部一個叫 Benny 的 agent，會自動接下每個 bug 回報，在雲端自己的電腦上開 Cursor 重現問題，有時還會直接回報「這個 bug 在 main 上已經修好了，只要發新版」，省下一個人陪 agent 摸索一小時的時間。

但她也強調沒有捷徑。還在信任曲線前段的人，不要一口氣開上千個 cloud agent，只會浪費一大堆 token。如果你信任她、信任 Pstack，或許可以藉此更快信任自己的 agent；但她也說，不要盲目信任她，最好 fork 下來改成自己的版本，因為每個團隊的工程標準都不一樣。

為 agent 重構，也替自己踩剎車

談到「該不該重寫」這個業界老問題，她倒是站在支持重寫的一方。她觀察到，很多大科技公司的問題，現在變成每個人的問題。在 Meta 有幾萬名工程師在同一個 monorepo 裡寫程式，程式碼品質其實沒有想像中好，她開玩笑說：「在 AI slop 之前，我們有 human slop。」大公司的基礎設施本來就是為了照顧最不熟悉系統的工程師而設計，有框架、慣例、權限限制，確保實習生不會刪掉正式資料庫。這種程式碼庫，agent 已經能做得不錯。

風險最大的反而是全新專案。GrokBot 一開始就是 vibe coding 快速做出來的原型，人類完全沒讀過程式碼，agent 用最方便的方式解每個任務，程式碼庫就逐漸失控。她花了超過 600 個 PR，把 GrokBot 重構到一套新架構上，現在她幾乎不再看程式碼了。她特別補一句：這麼說不是為了賣 token，而是她真的花了很多 token 才走到這一步。

Dune：讓最短的路就是最好的路

這套為 GrokBot 打造的架構代號叫 Dune，可以想成「給 Electron app 用、專門讓 agent 寫的 Next.js」。它的 CI 規則多到「很煩」，但煩人的部分都由 agent 吸收。幾個例子：

• 禁用 React 的 useEffect，因為那是 React 最大的地雷之一。
• 禁止寫程式碼註解。她發現 agent 寫的註解 99% 是無關的歷史紀錄，還曾經出現「Lauren 說絕對不能這樣做」這種註解，但她當時只是說「這個 PR 很爛，改掉那一段」，不是什麼全域規則。
• 用 CI 檢查 Electron 的 main 與 renderer 目錄之間的依賴關係，避免重運算或 I/O 不小心跑進 renderer，讓畫面無法維持每幀 16 毫秒、變得卡頓。agents window 就常吃這種虧，她打算把這套經驗搬回去。

每個 feature 的程式碼都集中在同一個目錄，agent 不必到處翻。她的核心原則是「最短的路就是最好的路」：agent 天生愛走捷徑，那就讓捷徑剛好是正確的做法。

她把約束分成幾層：架構與目錄慣例、會讓 CI 變紅的靜態分析與 lint、編譯器診斷，屬於硬約束；rules、skills、Bugbot 與風格指南屬於軟約束，agent 還是可能忘記。只靠軟約束，程式碼庫遲早會變成一團垃圾。這也是 Rust 再度走紅的原因之一，嚴格的編譯器讓人可以相信「能編譯，大概就沒問題」。最糟的狀態是所有規範都靠人在 code review 裡手動提醒，每次你在 PR 上留同樣的評論，都該問自己：這能不能變成 lint 規則或 CI 失敗？

PR 大小沒有硬性上限，從幾十行到上千行都有，但她會要求 agent 把工作拆成多個 PR，因為 git 歷史是很好的脈絡來源，出 bug 時也容易找到、容易回滾，而不是埋在一個四萬行的 PR 裡。

Token 很貴，那 ROI 呢？

聊天室最常問的是 token 成本。Lauren Tan 坦白，她在一個 token 幾乎無限的 AI 實驗室工作，不能說每個人都該照她的方式做。但對工程主管或新創創辦人來說，這是 ROI 問題：重構與建立約束前期很燒 token，可是如果未來程式碼都由 agent 來寫，你不會想變成一個一萬人的工程組織，背負大量規劃與協調成本。過去她一個人要花好幾年才做得完這套框架與重構，換算她的薪水，花 token 讓「最笨的 agent 也能寫出好程式碼」反而划算，而且之後不必用最大的模型也能寫得很好。

她也順帶興奮地分享 Grok 4.6 當天發布，據她理解每個 token 的價格和 4.5 一樣，等於同樣的成本拿到更多智慧。她說 Cursor 和 SpaceX AI 追求的是成本與智慧的最佳平衡點，不一定要做最大的模型。xAI 是 SpaceX 的子公司，SpaceX 已經上市（SPCX）。

GrokBot 讓非工程師也能把功能做出來上線

最後一題來自產品端：工程師上線功能這麼快，產品團隊跟得上嗎？她認為這正是 GrokBot 最有威力的地方。過去 Cursor 只有 agents window、CLI 和 IDE，都是給開發者的重度工具；GrokBot 介面像 iMessage，可以替每個 agent 取個有趣的名字，像帶一群人一樣調度。PM 可以叫 agent 總結她前一晚做了什麼，也會自己修 bug 送 PR，她看完覺得完美，直接蓋章通過。她認為這說明 Dune 的嚴格約束撐住了，讓不是工程專家的人也能高品質地貢獻，設計師和 PM 現在可以直接把功能做出來上線，GrokBot 團隊也因此推進得非常快。

這對讀者代表什麼

這場分享最實用的地方，是把「信任 agent」從感覺變成工程問題。想讓 agent 產出更多，先別急著開更多 agent，而是先讓它能自我驗證，再把團隊的工程標準寫成 skill、eval 和 CI 規則。對個人工程師來說，價值正從「自己寫程式」移到「設計讓 agent 不容易出錯的環境」；對主管來說，前期燒在重構與約束上的 token，換來的是整個團隊，甚至 PM 與設計師，都能安全地推出新功能。

未來投資可以留意的方向

• AI 寫程式工具與平台：Cursor 已併入 SpaceX，SpaceX（SPCX）的 AI 業務，包括 Grok 模型與 GrokBot 的採用度，是觀察重點。
• 模型的成本與智慧比：同價更聰明的模型，會直接影響企業導入 agent 的 ROI。
• 雲端 agent 的運算需求：從本機一兩個 agent 走到雲端大量平行，帶動推論與雲端沙盒算力。
• 驗證、測試與 CI 工具：靜態分析、lint、程式碼審查與 eval 工具，會隨著 agent 寫的程式碼變多而更重要。
• 嚴格型別與編譯器的語言生態：例如 Rust，因為能提供機器可檢查的信任。

---

來源（聽後整理）

• 影片：https://www.youtube.com/watch?v=I_oMJk6barY
• 主持人：Colin Matthews
• 受訪者／來賓：Lauren Tan（Software engineer, SpaceXAI）
• 非逐字翻譯、觀點整理，不構成投資建議