從每月 1,000 個 PR 談起：SpaceXAI 工程師揭秘如何讓 AI Agent 真正為你工作
許多工程師最近都開始使用 Cursor、Claude Code、Copilot 或各種 AI Agent 協助寫程式。但現實往往不如想像美好。
原本期待 AI 幫自己省下大量時間，結果卻發現每天都在盯著螢幕檢查 AI 是否產生幻覺、修正錯誤，甚至還要手把手教它怎麼使用開發工具。最後，自己反而成了整個開發流程的瓶頸。
前 Cursor 工程師、現任職於 SpaceXAI 的 Lauren 也曾經歷過相同的挫折。但在建立一套完整的 AI 協作系統後，他現在每月能處理 800 至 1,000 個 Pull Request（PR）。
這並不是因為 AI 突然變得完美，而是因為他改變了思維。
工程師的角色不再只是寫程式，而是開始扮演系統設計師與團隊管理者。
別把 AI 當工具，而是把它當成一支工程團隊
Lauren 提出了相當有趣的概念，稱為 Trust Curve（信任曲線）。很多人剛開始使用 AI Agent 時，都處於低信任狀態。
他們會不斷檢查 AI 的每一行程式碼、每一次修改、每一個決策。
結果就像管理一位剛入職的新員工：
- 交代工作後不放心。
- 五分鐘查看一次進度。
- 隨時出手修正。
- 所有決策都要自己核准。
雖然安全，但完全無法發揮 AI 最大價值。
Lauren 認為，真正的生產力爆發發生在你開始信任 AI 的時候。
當信任建立後，你的目標不再是管理「一個 Agent」，而是同時調度數十個甚至上百個 Agent。
因為真正的槓桿來自於平行作業（Parallelization）。
當 AI 可以同時處理大量任務時，個人生產力就會出現巨大的躍升。
建立信任的關鍵：讓 AI 學會驗證自己
那麼問題來了。你憑什麼相信 AI？
Lauren 的答案很簡單：
不要讓 AI 猜測，要讓 AI 驗證。當年他在 Cursor 開發內部專案「Glass」時發現，人與 AI 最大的溝通問題來自於資訊不對稱。
例如工程師正在觀看 Chrome DevTools 的效能分析畫面，但 AI 卻看不到。
你只能用文字描述：
「這裡有個 Flame Graph 看起來怪怪的。」
但 AI 根本無法理解你看到什麼。
於是 Lauren 的解法是：
不要描述畫面，直接給 AI 工具。
他讓 AI 擁有以下能力
- 透過 Chrome DevTools Protocol（CDP）直接操作瀏覽器。
- 控制 iOS 模擬器進行測試。
- 自動擷取 CPU Trace。
- 分析 Heap Snapshot。
- 執行自動化驗證流程。
因為 AI 不再只是「寫出程式碼」，而是能夠「執行程式碼並驗證結果」。
當驗證形成閉環（Closed Loop）之後，工程師需要人工檢查的工作就大幅減少。
AI 最大的痛點：找不到東西
如果你曾使用過 AI Agent 處理大型專案，應該有類似經驗。你明明說：
「請幫我修改會員中心的按鈕樣式。」結果 AI 花了十分鐘還在代碼庫裡迷路。
找不到畫面。
找不到元件。
找不到功能入口。
Lauren 將這種現象稱為：
Flailing（無效掙扎）
AI 把大量時間浪費在定位問題，而不是解決問題。
Feature Map：給 AI 一張導航地圖
為了解決導航問題，Lauren 提出了 Feature Map（功能地圖） 的概念。它可以理解成專門為 AI 設計的 GPS。
Feature Map 包含什麼？
- UI 元件對應的 DOM Selector。
- 功能對應的程式碼位置。
- 頁面導航路徑。
- 快捷鍵操作流程。
- 滑鼠操作步驟。
？？？AI 仍然能快速找到對應畫面、定位程式碼並開始修復。
這就像把一位新進工程師瞬間變成熟悉系統三年的老鳥。
Dune 架構：讓 AI 的偷懶變成優勢
Lauren 之後為 GrokBot 設計了一套新的系統架構，名稱叫做 Dune。而這套架構最有趣的地方在於：
最短路徑就是正確路徑。因為 AI 天生喜歡找捷徑。
如果架構設計不良，AI 就會選擇最快但錯誤的方法。
但如果系統設計得夠好，最快的方法恰好就是最佳實踐。
那麼 AI 的偷懶反而變成優勢。
Dune 的幾項核心規則
- 禁止使用 useEffect。
- 禁止撰寫程式碼註解。
- 強制依賴圖規範。
- 隔離 Renderer 與 Main Process。
- 違反規則直接 CI Fail。
但 Lauren 認為：
任何需要靠 Code Review 才能糾正的規則，本質上都是系統設計失敗。如果規範重要，就應該自動化。
不要依賴人工提醒。
不要依賴大家記得。
直接讓系統阻止錯誤發生。
為了 AI，他們重構了 600 個 PR
很多團隊期待：導入 AI 後即可立即提升效率。但 Lauren 的做法完全相反。
他先投資大量時間改善系統架構。
甚至完成超過 600 個 PR 的大型重構。
目的只有一個：
打造 AI 友善的開發環境。
因為如果底層架構混亂，再強大的 AI 也只是放大混亂。
Token 成本 vs 人力成本，你該怎麼選？
許多人看到大型 AI Agent 團隊後，第一個反應都是：這樣 Token 不會很貴嗎？Lauren 的看法很務實。
Token 並不是成本問題，而是投資問題。
真正應該比較的是：
- 每月 AI 成本。
- 每月工程師成本。
- 整體產出價值。
更有趣的是，在 Dune 架構下：
- PM 可以直接修 Bug。
- 設計師可以提交 PR。
- 非技術人員也能完成簡單開發工作。
未來工程師的角色：從程式設計師變成總廚
Lauren 用了一個非常貼切的比喻。未來的工程師更像是餐廳總廚。
總廚不需要親自下場炒每一道菜。
他的工作是：
- 設計廚房流程。
- 制定作業規範。
- 管理食材品質。
- 優化工作動線。
- 確保團隊穩定產出。
而是設計一套讓 AI 可以高品質運作的系統。
當架構足夠成熟、護欄足夠完善、驗證能力足夠強大時，即使是最普通的 AI Agent，也能持續產出高品質成果。
結語：真正的競爭力不是 AI，而是系統
很多團隊都在比較：- Claude 比較強？
- GPT 比較強？
- Grok 比較強？
- Cursor 比較好用？
真正的差異不在模型本身，而在於你是否建立了讓 AI 成功的環境。
沒有驗證機制，AI 只會產生更多錯誤。
沒有導航系統，AI 只會不停迷路。
沒有硬性規範，AI 只會把技術債放大。
未來最有競爭力的團隊，不一定擁有最強的模型。
但一定擁有最適合 AI 工作的系統。
而當你的代碼庫真的能夠讓 AI 自動完成、驗證並合併 PR 時，工程團隊的生產力將不再是線性成長，而是指數級擴張。
你怎麼看？
如果你的代碼庫今天就能做到 AI 自動驗證、自動修復、自動合併 PR，你認為未來一年你的團隊能夠打造出什麼樣的產品？歡迎在留言區分享你的看法。
參閱X中的貼文影片a SpaceXAI engineer walks through building a team of agents that keeps working.
古月部落格 https://readgotw.blogspot.com
