從 vibe coding 到自動化 PR 遞交：解析 Cursor 工程師 Lauren Tan 的 AI Agent 開發體系與軟體工程新範式

本篇研究深度剖析 Cursor 與 SpaceXAI 工程師 Lauren Tan 所建立的 AI Agent 軟體工程開發體系。該體系整合了 Pstack 驗證工具鏈、系統化 Feature Map、基於 Evals 的自動化評估機制，以及專為 Agent 寫作習慣設計的 Dune 極限約束架構。研究發現，透過建立實體執行與監控的閉環驗證機制，並在 CI/CD 管道中導入硬性架構約束，可有效消解開發者對 AI 幻覺的信任危機，使 Agent 能獨立完成代碼自檢並自動合併至主幹，將單一工程師的產出拉升至單月近 1,000 個 Pull Request（PR）。這標誌著 AI 輔助開發已正式從缺乏品質管控的「盲目代碼生成（vibe coding）」階段，跨越至可預測、高併發且具備嚴格約束的現代可信 Agent 軟體工程管理範式。

1. Agentic Coding 的核心困境：從「微觀管理」到「信任曲線」的突破

第一性原理剖析：信任缺失導致的「微觀管理陷阱」

在生成式 AI 工具進入軟體開發流程的初期，工程師面臨的根本瓶頸並非模型生成代碼的速度，而是對生成內容的「信任缺失（Trust Deficit）」。資深軟體工程師通常具備嚴謹的工程品味與長期累積的架構思維，當觀察到 AI Agent 在解決問題時採取憑空猜測、產生自信的幻覺（Hallucination），甚至多次聲稱找到問題的關鍵證據卻始終偏離真實 Bug 原因時，工程師會本能地降級至「微觀管理（Micromanagement）」模式。

在微觀管理模式下，開發者必須全程在場（In-the-loop），盯著 Agent 的每一行輸出、複製貼上報錯訊息、手動補充控制台截圖，並頻繁進行 Prompt 微調。根據 Lauren Tan 在 Vision Sabbat 訪談中的說明：「當你對 Agent 缺乏信任時，你只能處於微觀管理模式，必須盯著每個輸出而無法進行大規模平行作業。」這種模式直接導致人類工程師成為系統中唯一的運算瓶頸，完全無法發揮 AI 的平行化（Parallelization）擴展潛力——當開發者無法信任單一 Agent 的輸出品質時，自然不可能同時啟動數十或上百個 Agent 協同作業。

職責轉型的直覺比喻：工程主管與開發團隊

這種困境與傳統管理學中的「工程主管與開發團隊」動態高度一致。若一名工程主管不信任下屬的技術能力與代碼品質，就必須時刻站在員工身後檢查每一行代碼，防止不良代碼被推送到正式環境（Production）。其結果是主管精力耗盡，團隊規模與產出完全受限。唯有透過建立客觀的驗證機制、測試標準與行為約束，主管才能將權限下放給團隊，進而實現大規模的平行授權與非同步作業。

信任曲線升級與併發產出的量化突破

傳統開發模式以人類工程師為執行核心，工程師手動編譯代碼、執行測試並除錯，過程極度消耗時間。Lauren Tan 提出了「信任曲線（Trust Curve）」的概念。在 5 個月前剛加入 Cursor 時，他同樣處於高度微觀管理的階段，需要監控 Agent 的每一項工具調用；然而透過持續建構驗證技能與極限 CI 約束，他成功攀升了信任曲線。

信任曲線的提升直接轉化為震撼性的量化生產力爆發。Lauren Tan 在前一個月透過 Agent 自動化體系成功遞交並合併了單月 1,000 個 PR；而在採訪當月僅過去 12 天時，他已在主幹合併了近 800 個 PR。如今，他能在每天起床時，直接檢視由 Agent 在夜間自主測試、驗證並自動合併（Auto-merge）至 Main 主幹的 20 個 PR。這種轉變代表開發者角色已從「代碼撰寫者」成功過渡為「系統架構與約束環境的設計者」。

2. 驗證機制與 Feature Map：如何讓 AI Agent 從「盲目猜測」走向「自我調試」

運作機制與技術路徑

要讓 AI Agent 擺脫盲目猜測並具備自我除錯能力，關鍵在於賦予其「實體執行軟體」並取得客觀反饋的能力，此即「驗證能力（Verification Skill）」。

[使用者回報 / 模糊截圖]
        │
        ▼
┌─────────────────────────────────┐
│ Agent 讀取 Feature Map          │ (定位 UI 路徑、快捷鍵與 DOM 選擇器)
└────────────────┬────────────────┘
        │
        ▼
┌─────────────────────────────────┐
│ 執行代碼修復與變更              │
└────────────────┬────────────────┘
        │
        ▼
┌─────────────────────────────────┐
│ 調用 Verification Skill         │ (操作 CDP、錄製 CPU Trace、Heap Snapshot)
└────────────────┬────────────────┘
        │
        ▼
┌─────────────────────────────────┐
│ 取得客觀執行結果與效能數據      │
└────────────────┬────────────────┘
        │
        ├─── [測試失敗] ───► 自我修正代碼並重新驗證 (閉環)
        │
        └─── [測試通過] ───► 自動提交 PR / 自動合併

1. 驗證能力（Verification Skill）的實體接入：Agent 必須能夠超越單純的文本生成，直接操作應用程式的執行環境。這包括透過 Chrome DevTools Protocol（CDP）控制 Web 或 Electron 應用程式、啟動 iOS Simulator、擷取效能 CPU Trace、分析 Heap Snapshot 記憶體快照，或執行 CLI 測試指令。當 Agent 能夠親自啟動開發版應用程式並模擬使用者操作時，便獲得了驗證代碼正確性的閉環反饋。
2. Control Glass 案例與緊急調任背景：Lauren Tan 剛加入 Cursor 第一週時，原本預計加入 Cloud Agents 團隊；但由於他具備豐富的 React 開發經驗，且 Cursor 的內部 Agent 視窗（代號 Glass，基於 React 開發的桌面端介面）距離預定上線時間僅剩 1 週，團隊緊急將他調任支援 Glass 的效能優化。面對全新的代碼庫與極度緊迫的 1 週時限，傳統方式是由人類手動開啟 Chrome DevTools、下載 Trace 檔案或擷效能樹截圖發送給 Agent，過程極度緩慢且容易引發 Agent 的錯誤猜測。Lauren 因而開發了 Control Glass 技能，讓 Agent 能透過 CDP 直接控制應用程式、錄製渲染效能火焰圖（Flame Graph），自主找出造成 UI 卡頓的效能瓶頸。
3. Feature Map（功能地圖）的導航作用：儘管 Agent 具備了執行能力，若缺乏對應用程式整體 UI 結構的理解，仍會在介面中盲目嘗試。Feature Map 是一種專門為 Agent 設計的結構化導航地圖，詳細記錄了應用程式各項功能的導覽路徑、快捷鍵、介面邏輯以及 CDP 選擇器屬性（DOM Selector Attributes）。

閉環驗證的產業價值

根據 Lauren Tan 在 Vision Sabbat 訪談中的說明：「驗證能力閉環雖然不能保證 Agent 寫出完美的代碼，但能確保其寫出的代碼在功能上是正確的。」在日常開發中，內部 Slack 頻道常出現極度模糊的錯誤回報（例如一張 UI 截圖搭配問號）。有了 Feature Map 與驗證技能，Agent 能夠將模糊的自然語言或截圖自動映射至具體的功能模組，開啟開發版應用程式導航至目標頁面，觸發 Bug 並獲取控制台錯誤資料，最終進行修復與驗證。這種閉環驗證提供了客觀的功能正確性保障，是人類工程師敢於授權 Agent 進行自動化 PR 遞交的必要前提。

3. Pstack 與 Evals 評估體系：建構 Agent 技能的單元測試與自動化攀升

工具架構與專有名詞解析

為了系統化地建立與維護 Agent 的各項技能，Lauren Tan 開發了名為 Pstack（Potato Stack）的套件（名稱幽默回應 Y Combinator 執行長 Gary Tan 所推出的 GStack）。Pstack 內建了兩項關鍵的核心技能管理工具： * create verification skill：自動探索目標代碼庫，生成初始的 Feature Map 與驗證腳本。 * maintain verification skill：隨著應用程式功能迭代，自動同步與維護既有的 Feature Map 與驗證邏輯。

在這套體系中，核心的概念是 Evals（Agent 技能評估系統）。Evals 之於 Agent 技能（Skills/Prompts），就如同單元測試（Unit Tests）之於傳統軟體代碼。在 Pstack 中，Eval 測試機制被封裝於 potato mode 命令下的 Eval Playbook 之中。

Evals 的自動化執行流程與模型行為學洞察

Pstack 透過 potato mode 下的 Eval Playbook 實現了高度嚴謹的單元測試流程：

┌────────────────────────────────────────────────────────┐
│ 1. 協調者 Agent (Coordinator Agent)                    │
│    建構評估規準 (Rubric)                               │
└──────────────────────────┬─────────────────────────────┘
                           │
                           ▼
┌────────────────────────────────────────────────────────┐
│ 2. 子 Agent 陣列 (Sub-agents)                          │
│    在隔離且匿名命名的目錄中平行執行任務 (避免行為偏見)  │
└──────────────────────────┬─────────────────────────────┘
                           │
                           ▼
┌────────────────────────────────────────────────────────┐
│ 3. 裁判 Agent (Judge Agent)                            │
│    調用交叉模型進行盲測評分 (消除單一模型偏見)         │
└──────────────────────────┬─────────────────────────────┘
                           │
                           ▼
┌────────────────────────────────────────────────────────┐
│ 4. Hill Climbing 爬山演算法優化                        │
│    執行 Cursor /loop 指令持續迭代，直至達到 10/10 滿分   │
└──────────────────────────┬─────────────────────────────┘

1. 協調者 Agent（Coordinator Agent）：分析目標技能，定義具體的測試標準與評分的規準（Rubric）。
2. 子 Agent 陣列（Sub-agents）與匿名隔離目錄：系統會啟動多個子 Agent，並在完全隔離且經過匿名化命名的目錄（Anonymized Directories）中執行測試。這裡存在一個深刻的模型行為學洞察：AI Agent 具備極強的情境感知能力，當 Agent 察覺到目錄名稱包含 test 或 eval 等字樣而意識到自己正在接受評估時，會主動改變行為模式（甚至採取作弊或迎合評分規準的策略）。因此，透過匿名目錄進行隱蔽測試是獲取 Agent 真實能力資料的必要手段。
3. 裁判 Agent（Judge Agent）：為了消除單一 LLM 模型的自我偏見，評估體系會採用不同的模型作為裁判，針對各子 Agent 的執行結果進行交叉比對與客觀打分。
4. Hill Climbing（爬山演算法）自動優化：利用 Cursor 的 /loop 自動化指令，讓 Agent 在 Eval 評估體系中進行自我迭代循環，持續修訂 Prompt 與指令細節，直到該項技能的測試評分達到 10/10 的滿分標準。

管理思維轉型：從「獨立廚師」到「餐廳主廚」

根據 Lauren Tan 在 Vision Sabbat 訪談中的說明：「軟體工程師的角色正在轉型，就像餐廳的主廚一樣，不再親自烹飪每道菜餚，而是專注於設計廚房環境與工作流程。」在傳統模式中，工程師是親自下廚的線廚（Line Cook）；但在 Agentic Coding 時代，工程師成為了 Head Chef。其核心職責不再是撰寫每一個函數，而是設計廚房的工作站（動態環境）、提供高品質的食材（Context 與資料庫）、編寫作業標準書（Skills/Prompts），並透過 Evals 進行嚴格的品質控管。

4. Dune 架構與極限 CI 約束：專為 AI Agent 設計的軟體工程新範式

專案背景與「有機雜亂架構」的危機

Cursor 團隊推出的最新應用程式 Grockbot（一套具備多 Agent 身份編排能力的協同工具），在開發初期作為原型產品時，經歷了快速的 vibe coding 過程。大量由 AI 快速生成、人類未曾逐行審閱的代碼迅速堆疊，導致代碼庫出現「有機雜亂架構（Organic Architecture）」。當 Agent 在缺乏明確邊界與約束的代碼庫中工作時，往往會選擇最快捷但最不具可維護性的實現方式，導致專案的複雜度與維護成本呈現指數級升級。

Dune 架構的核心哲學與極限硬性約束

為了徹底解決此問題，Lauren Tan 為 Electron 應用程式設計了名為 Dune 的新型架構（可理解為專為 Electron + Agent 開發模式打造的 Next.js 框架）。Dune 的核心設計哲學在於：讓最捷徑的開發路徑（Shortest Path）同時成為最佳的工程實踐路徑。由於 Agent 天生傾向採用最直接的方式解決問題，架構設計必須確保這條捷徑符合嚴格的工程規範。

Dune 導入了單一功能目錄封裝（Colocated Feature Directory）原則，將單一功能的所有代碼、組件與邏輯完全封裝在同個目錄下。這種設計大幅簡化了 Agent 的上下文搜尋，Agent 不需要跨目錄搜尋（Grep around），即可在局限的上下文空間內完成 80% 以上的開發任務，極大地降低了模型的思考負擔。

同時，Dune 在 CI/CD 管道中導入了極嚴格的硬性約束（Hard Constraints）：

┌────────────────────────────────────────────────────────┐
│ Dune 架構 CI/CD 硬性檢查關卡                           │
├────────────────────────────────────────────────────────┤
│ [關卡 1] 靜態檢查：全域禁止 React `useEffect`          │
│ [關卡 2] 代碼風格：全域禁止原始代碼註釋 (Comments)      │
│ [關卡 3] 邊界檢查：主進程 / 渲染進程依賴樹隔離度驗證   │
└──────────────────────────┬─────────────────────────────┘
                           │
             ┌─────────────┴─────────────┐
             ▼                           ▼
        [檢查失敗]                  [檢查成功]
     CI 阻斷並退件               准許自動併發合併

1. 全面禁用 React useEffect：useEffect 是 React 開發中最容易引發無效重繪（Re-render）與效能倒退的來源。Dune 在靜態檢查中直接禁用 useEffect，強迫 Agent 採用可預測的狀態同步機制。
2. 全面禁用代碼註釋（Code Comments）：Agent 在撰寫代碼時，極易產生無意義或誤導性的歷史紀錄註釋（例如把人類在 Code Review 時的臨時指示寫成永久性的代碼註釋）。禁用註釋可強制代碼達到自解釋（Self-documenting）標準，並避免 Agent 被過時的歷史註釋干擾。
3. 進程架構嚴格隔離與 16ms 影格時間保障：Electron 包含主進程（Main Thread）與渲染進程（Renderer Thread）。為了維持 UI 的順暢度（60 fps，即每影格預算上限為 16 毫秒 ms），複雜的大量運算與 I/O 操作絕不能阻塞渲染線程。Dune 將目錄嚴格劃分為 electron/main 與 electron/renderer，並透過 CI 依賴樹分析工具進行靜態檢查。一旦發現渲染進程非法引用了主進程的高消耗模組，CI 檢查將立即退件。

軟體工程約束的五個層次

根據 Lauren Tan 在 Vision Sabbat 訪談中的說明：「如果僅依賴 Prompt、Rules 或 Code Review 等軟性約束，代碼庫隨時間推移必然會惡化為垃圾代碼。」軟體工程約束可劃分為以下五個層次：

[層次 1] 架構約束 (Dune 框架/單一功能目錄封裝) ──┐
                                             ├─► 硬性約束 (Hard Constraints)
[層次 2] 靜態分析與編譯器 (Lints / CI 檢查)  ──┘   (CI 強制阻斷，Agent 無法規避)
────────────────────────────────────────────────
[層次 3] 自動化檢測工具 (Bugbot / CI Review)  ──┐
                                             │
[層次 4] Agent Prompt 與 Skills 指引        ──┼─► 軟性約束 (Soft Constraints)
                                             │   (Agent 可能遺忘或不穩定忽視)
[層次 5] 人類代碼審查 (Human Code Review)    ──┘

其中，Bugbot 被明確定義為 Cursor 團隊內建於 CI 管道上的 AI Code Review 工具，屬於層次 3 的自動化檢查。硬性約束（層次 1 與 2）是確保代碼庫不被 Agent 毀壞的鐵壁；若過度依賴軟性約束（層次 3 至 5），系統終將因 Agent 的不穩定性而陷入品質崩潰。

5. 從 Human Slop 到 AI Slop：綠地與黃地專案的重構與 ROI 算子

代碼品質的再定義：Human Slop vs. AI Slop

在生成式 AI 普及之前，軟體工程界早已充斥著由人類寫出的劣質代碼，即「人類垃圾代碼（Human Slop）」。大型科技公司（如 Meta 或 Google）的 Monorepo 資料庫中，同樣存在大量品質平庸的代碼。因此，大型科技公司的基礎設施（Guardrails，如嚴格的權限控管、靜態分析與 CI 檢查）本就是為了防止低階工程師破壞生產環境而設計。

這種具備完善 Guardrails 的既有專案（黃地專案/Brownfield），天然地極度適合 AI Agent 直接介入。因為既有的硬性邊界能完美限制 Agent 的破壞力，使其在安全的框架內高效產出。

綠地專案（Greenfield）的失控風險與架構重構

相反地，全新開發的專案（綠地專案/Greenfield）具備最高風險。開發者往往為了追求驗證速度而進行 vibe coding，導致專案缺乏架構約束。Lauren Tan 為了將 Grockbot 從有機雜亂狀態轉移至 Dune 架構，個人執行並合併了超過 600 個重構 PR。雖然重構過程耗費了大量的 Token，但此舉徹底清除了專案中的 AI Slop，建立了極度穩固的開發底座。

Token 成本與 ROI 算子：前置資本支出（CapEx）與邊際營運成本（OpEx）的經濟學對比

從 DeepValues Research 投資策略分析師的角度切入，大量消耗 Token 進行代碼重構與建構驗證體系，本質上是一筆極其划算的算力投資。

根據 Lauren Tan 在 Vision Sabbat 訪談中的說明：「前期重構與建立驗證體系雖然消耗大量 Token，但能讓整個團隊包含 PM 與設計師都能安全地直接遞交代碼。」

[傳統模式成本結構]
高額資深工程師薪資成本 + 冗長的人工 Code Review 時間 + 跨部門溝通協調開銷
  VS.
[Agentic Coding 成本結構]
前置資本支出 CapEx (重構 600+ PR 與建構 Dune/CI) ──► 邊際營運成本 OpEx 趨近於零 (非技術人員零溝通成本提交代碼)

我們可將前期消耗大量 Token 進行 600+ 個 PR 的重構與 CI 工具建置，視為前置資本支出（CapEx）。一旦這套硬性防護網建構完成，後續的邊際營運與溝通成本（OpEx）將會大幅降至趨近於零。非技術人員（如產品經理 PM、UI/UX 設計師、GTM 團隊）能夠直接透過自然語言介面（如 Grockbot）提出需求或修復 Bug。在 Dune 架構的 CI 硬性阻斷機制下，非技術人員遞交的代碼若引發效能倒退（Performance Regression），將在 CI 階段被自動擋下並由 Agent 修正，完全無需消耗資深工程師的 Review 時間與溝通成本。

此外，隨著最新模型（如 GRO 4.6）的發布，其在維持與前代 GRO 4.5 相同的每 Token 推理成本下，基準測試智力顯著提升。這意味著企業在不增加算力預算的前提下獲得了更高階的 Agent 思考能力，使整體投資報酬率（ROI）算子呈現指數級擴張。

6. 限制與未解難題：代碼庫邊界與軟體工程師的角色轉變

當前體系的工程限制與挑戰

儘管 Lauren Tan 的 Agent 開發體系展示了極高的生產力，但在實際落地時仍面臨以下客觀限制： 1. 軟性約束的機率性失效：未被納入 CI 硬性檢查的規範（單純依賴 Prompt、Rules 或 Bugbot 的軟性約束），Agent 仍有一定機率會遺忘或忽略，無法達到 100% 的確定性。 2. 硬性驗證工具與 CI 的建置門檻極高：編寫如 Control Glass、CDP 介面監控以及依賴樹檢查工具，需要開發者具備極深厚的系統架構經驗與工程品味（Engineering Taste）。缺乏經驗的團隊難以在初期設計出高效的驗證閉環。 3. Token 資本門檻：在進行大規模重構（如 600+ 個 PR）或運行全自動化 Evals Hill Climbing 循環時，Token 的消耗速度極快，對於資金有限的初創團隊或個人開發者而言，仍是一筆不可忽視的短期財務負擔。

軟體工程師的核心價值轉型

隨著 Agent 承擔了絕大部分代碼的撰寫工作，軟體工程師的職業邊界正在發生根本性的重塑： * 舊範式：工程師的核心價值在於語法熟練度、演算法實作、手動除錯速度與撰寫代碼的行數。 * 新範式：工程師的核心價值轉移至設計 Agent 的極限約束環境、編寫客觀的靜態檢測規則、構建閉環驗證系統（Verification Skills），以及在 Evals 體系中扮演具備高工程品味的審查者。代碼本身退化為中間產物，而系統架構與約束條件成為了真正的核心資產。

關鍵數字

以下條列本文研究資料中所提及的所有具體數字與指標：

• 5 個月前：Lauren Tan 加入 Cursor 的時間點（剛加入的第一個月因熟悉代碼庫，產出速度較慢）。
• 單月 1,000 個 PR：Lauren Tan 在訪談前一個月透過 Agent 體系成功遞交並合併至 Main 主幹的 Pull Request 總數量。
• 12 天內近 800 個 PR：當月前 12 天內，Lauren Tan 透過 Agent 自動化系統完成並合併的 PR 數量。
• 單夜 20 個 PR：Lauren Tan 一覺醒來時，發現 Agent 已自動完成測試、驗證並成功合併至 Main 主幹的 PR 數量。
• 600+ 個 PR：Lauren Tan 為了將 Grockbot 從有機雜亂代碼庫完全重構至 Dune 架構所執行的 PR 總數。
• 16 毫秒（ms）/ 60 fps：Electron 應用程式渲染線程（Renderer Thread）為維持順暢 UI 體驗，每個影格允許的最大渲染時間上限。
• GRO 4.6：最新發布的模型版本（維持與 GRO 4.5 相同的每 Token 推理成本，但在基準測試中智力顯著提升）。

什麼情況會改變這個局面

基於本文資料事實進行推論，以下為值得觀察的具體前沿發展方向：

1. 編譯器與靜態分析工具對 AI Agent 的深度整合：若 Rust 等具備極度嚴格借用檢查（Borrow Checker）的系統級語言進一步普及，編譯器本身的硬性檢查將能直接替代大部分自建的 CI 工具，使 Agent 在極低的人為干擾下寫出具備記憶體安全與高效能的代碼。
2. 雲端自主 Agent（Cloud Agents）的跨團隊普及：如 Cursor 內部的 Cloud Agent（如 Benny）能自主拉取 Slack 錯誤回報、自動開立雲端桌面環境重現 Bug 並進行修復，這種模式若全面普及，將把個體工程師的高產能擴展至全公司 PM 與設計師皆可非同步協同的開發流。
3. 無代碼註釋與極簡前端架構（如 Dune / Pretext）成為開源新標準：專為 AI Agent 寫作習慣設計的極限約束框架（如禁用 useEffect 與註釋、強制進程隔離）若進一步開源並成為業界標準，將徹底翻轉現有的前端開發習慣與主流 React 開發範式。

---

歡迎造訪 DeepValues Research 官方網站閱讀更多關於 AI 軟體工程與前沿技術的開源研究報告，或立即體驗 DeepValues App。

資料來源

• Vision Sabbat - Lauren Tan - SpaceXAI engineer (YouTube Transcript)