Cursor 的 $29B 秘密：被刪除的 Shadow Workspace 技術解密

24 個月。$0 到 $1B ARR。$29B 估值。

Cursor 不是「成長快」——它打破了所有人對 SaaS 成長速度的認知。但多數人不知道的是，這家公司早期最核心的技術創新，後來被悄悄從設定中移除了。

但這不是失敗的故事——敢於 kill your darlings，正是他們跑得比誰都快的原因之一。

這篇文章，我要告訴你 Shadow Workspace 是什麼，為什麼它曾經讓 Cursor 碾壓 Copilot，以及它消失的可能原因。

為什麼 Cursor 能在兩年內達到 $1B ARR

2025 年 11 月，Cursor 背後的公司 Anysphere 宣布達到 $1B ARR，估值飆升至 $29.3B。這個速度打破了所有紀錄——Wiz 花了 18 個月從 $1M 成長到 $100M ARR，Deel 花了 20 個月。Cursor 更誇張：產品上線約 12 個月就突破 $100M ARR，然後在接下來一年再加上 $900M。

很多人把這歸功於 AI coding 的風口，但如果只是風口，為什麼 GitHub Copilot 沒有達到同樣的成長曲線？

答案藏在一個架構決策裡：Copilot 是 VS Code 的 Extension，Cursor 是整個 VS Code 的 Fork。

這個決定讓 Anysphere 敢做 Copilot 永遠做不到的事——深度控制編輯器的每一個層面。其中最關鍵的創新之一，就是 Shadow Workspace。

問題：AI 生成代碼的「幻覺迴圈」

如果你用過任何 AI coding assistant，你一定經歷過這種鬼打牆：

AI 生成一段看起來完美的代碼。你貼上去，編譯失敗。你問 AI 修，它給你另一個版本。又失敗。來回三次後，你發現它幻覺了一個根本不存在的 API。

這不是你運氣差。這是結構性問題。

傳統的 AI coding assistant（包括早期的 Copilot）使用一種叫做 Neighboring Tabs 的策略——它只看你當前打開的 Tab 來推測 context。但問題是，打開 5 個 Tab 不等於理解整個 Codebase。AI 不知道你的專案有哪些自定義 Type、哪些內部 API、哪些 Linter 規則。

更糟糕的是，AI 生成代碼的速度遠快於你驗證的速度。每次你接受一個 suggestion，然後發現它壞掉，再問 AI 修，這個 feedback loop 的延遲可能是 30 秒到幾分鐘。累積起來，一天可能浪費你一兩個小時。

Cursor 的工程師也遇到這個問題。他們的解法是：在你看到代碼之前，先在一個「平行宇宙」裡驗證它。

這個平行宇宙，就是 Shadow Workspace。

Shadow Workspace 的設計目標

根據 Cursor 官方的技術 blog，Shadow Workspace 有三個核心設計目標：

1. LSP-usability（語言服務可用性）

AI 必須能夠看到它生成的代碼的 Linter 錯誤、能夠 Go to Definition、能夠使用 Language Server Protocol 的所有功能。這意味著 AI 不是在真空中寫代碼，而是在一個有完整工具鏈支援的環境中寫代碼。

2. Independence（獨立性）

用戶的開發體驗不能被影響。如果 AI 在背景做驗證，用戶的編輯器不能卡頓、不能閃爍、不能出現奇怪的狀態。用戶甚至不應該意識到這件事正在發生。

3. Runnability（可執行性）

這才是真正的終局：AI 應該能夠執行它生成的代碼並看到 output。靜態分析能抓到語法錯誤，但邏輯錯誤只有跑起來才知道。

這三個目標聽起來很直觀，但實現起來極其困難，因為前兩個目標天生矛盾。

LSP 需要真實的檔案系統——Language Server 要能讀取 node_modules、要能解析 tsconfig.json、要能追蹤 import chain。但 Independence 需要隔離——AI 對檔案的任何修改都不能影響用戶看到的內容。

你不能同時擁有「真實的環境」和「完全的隔離」。或者說，你需要非常聰明的工程來接近這個理想。

技術實現：Hidden Electron Window

根據 Cursor 官方 blog，團隊嘗試過很多方案，最後都失敗了：

方案	做法	失敗原因
A	獨立啟動 Language Server（如 `tsc`、`gopls`、`rust-analyzer`）	放棄 VS Code Extension 生態，看不到 Prisma、GraphQL 等 Extension 的 diagnostics
B	複製 Extension Host Process	State synchronization 是噩夢，太複雜
C	Fork 所有主流 Language Server	維護成本太高，每次上游更新都要 merge
最終	Hidden Electron Window	優雅地解決問題

最終方案的精妙之處：

當 AI 需要驗證一段代碼時，Cursor 會 spawn 一個 隱藏的 Electron window（show: false）。這個 window 載入同一個 workspace，但用戶看不到它。AI 在這個隱藏 window 中 apply 變更，然後等待 LSP 回報 diagnostics。

如果有錯誤，AI 會在背景自我修正，用戶完全無感。只有當代碼通過所有靜態檢查後，Cursor 才會把變更展示給用戶。

這個設計的精妙之處在於：

完整的 Extension 支援：因為是真正的 VS Code window，所有 Extension 都正常工作
狀態隔離：用戶的 window 和 shadow window 是完全獨立的 Electron process
資源復用：Shadow window 會被 reuse，不是每次都重新 spawn

用架構圖來表示：

Shadow Workspace Architecture

這就是為什麼 Cursor 的代碼「通常能直接運行」——因為它已經被預先驗證過了。

Runnability：下一個前沿

LSP 驗證解決了「代碼能不能編譯」的問題，但還有一個更深的問題：邏輯正確性。

靜態分析抓不到 runtime error。一個函數可能語法完美、型別正確，但邏輯完全錯誤。要驗證邏輯，你必須真的執行它。

這帶來了新的技術挑戰：

磁碟隔離

如果 AI 可以執行任意代碼，它也可以執行 rm -rf /。Shadow Workspace 需要某種形式的磁碟隔離，讓 AI 的破壞行為只影響沙箱內的環境。

最簡單的做法是把整個專案複製到 /tmp，但這對大型專案不可行——光是 node_modules 就可能有幾 GB，而且複製的 I/O 開銷會直接破壞 fast feedback loop。當你的 Agent 每次驗證都要等 30 秒複製檔案，整個設計就失去意義了。

更進階的做法是使用 VFS（Virtual File System） 或 FUSE（Filesystem in Userspace），實現 copy-on-write 語義：AI 讀取時看到真實檔案，但寫入時只會修改虛擬層，不影響原始檔案。

網路隔離

除了磁碟，AI 執行的代碼也可能發起網路請求。在企業環境中，這可能導致資料外洩。理想的 Shadow Workspace 需要網路層面的隔離，只允許特定的 outbound connection。

根據 Cursor 官方 blog，他們正在探索幾個方向：

Cloud-based Shadow Workspace（對隱私敏感的用戶可能不適合）
基於 Docker 的自動容器化
Kernel-level folder proxy

這些都還在研發中，Cursor 目前的版本並沒有完整的 Runnability 支援。

轉折：Shadow Workspace 從設定中消失了

如果你現在去 Cursor 的設定裡找 Shadow Workspace，你會發現它不見了。

官方沒有正式公告移除，也沒有說明原因。 原本 2024 年 9 月的技術 blog 只提到這是一個「opt-in」功能，會增加記憶體使用——這可能暗示了它被移除的原因。

這個決定讓我思考了很久。一個讓 Cursor 脫穎而出的核心技術，為什麼會被拿掉？

以下是我的推測，非官方說法

1. 記憶體消耗

每個 Shadow Workspace 本質上是一個完整的 VS Code instance。對於開著十幾個 Tab、裝了幾十個 Extension 的重度用戶來說，這可能意味著額外 1-2 GB 的 RAM 佔用。在 M1 MacBook Air 上，這不是小數目。

2. 維護成本與效益不對稱

Hidden Electron Window 的方案雖然優雅，但維護成本不低。每次 VS Code 上游更新，Cursor 都要確保 Shadow Workspace 機制還能正常工作。如果只有 10% 的用戶開啟這個功能，這個 ROI 可能不划算。

3. 替代方案成熟

Cursor 在其他方面持續投資——更好的 RAG、更聰明的 Apply Model、更精準的 context selection。這些改進可能讓 Shadow Workspace 的邊際效益下降。如果 AI 第一次就能生成正確的代碼，你就不需要背景驗證。

4. 戰略重心轉移

Cursor 可能正在開發完全不同的驗證機制。也許是 cloud-based 的方案，也許是更輕量的 local 方案。移除舊功能可能是為新架構騰出空間。

無論原因是什麼，這個決定提醒我們一件事：技術創新不一定能存活下來。產品決策比純技術更複雜。 有時候，kill your darlings 才是正確的選擇。

對你的啟示：自建 Agent 的驗證機制

即使 Cursor 移除了 Shadow Workspace，它的設計思維仍然值得學習。核心 insight 是：

驗證比生成更重要。

如果你正在構建自己的 AI Coding Agent，這裡有幾個可以立即實踐的方向：

1. 使用 Git Worktree 實現環境隔離

Git Worktree 讓你在同一個 repo 下擁有多個 working directory，共享 .git 歷史。這是實現 Shadow Workspace 最輕量的方式：

# 為 Agent 創建獨立的工作環境
git worktree add ../agent-workspace -b agent/fix-bug-123

# Agent 在這個目錄裡自由發揮
# 所有修改不影響主目錄

# 完成後清理
git worktree remove ../agent-workspace

相比於完整複製專案，Worktree 只佔用極少的額外磁碟空間，因為它共享 Git objects。

注意：Worktree 不會複製 .gitignore 裡被忽略的檔案（如 .env、node_modules）。你需要在新的 worktree 裡重新跑 npm install 或 pip install，並確保環境變數正確設定。如果你的專案有 .env.example，記得在 Agent 的 bootstrap script 裡處理這件事。

2. Docker + LSP 實現安全執行

把 Worktree 掛載到 Docker container 內，在容器裡跑 Language Server 和測試：

docker run -v /path/to/worktree:/app \
           --network none \  # 網路隔離
           my-agent-runtime \
           npm test

--network none 確保 Agent 執行的代碼無法對外發起請求。

3. 實現 Self-Correction Loop

不要讓 AI 只生成一次。設計一個迴圈：

def generate_and_validate(task: str, max_attempts: int = 3) -> str:
    for attempt in range(max_attempts):
        code = agent.generate(task)

        # 在 Shadow Environment 中驗證
        diagnostics = shadow_env.get_diagnostics(code)

        if not diagnostics.has_errors():
            return code

        # 把錯誤訊息餵回給 Agent
        task = f"""
        Previous attempt failed with errors:
        {diagnostics.format()}

        Original task: {task}

        Please fix the errors.
        """

    raise ValidationError("Max attempts exceeded")

這個模式簡單但有效。根據我的經驗，80% 的「第一次失敗」可以在第二或第三次嘗試中修正。

4. 從 Worktree 開始，逐步加碼

如果你剛開始構建 Agent 系統，我的建議是：

Week	目標
1	用 Git Worktree 實現基本隔離
2	加入 Linter/Type Checker 驗證（不需要完整 LSP）
3	加入 Docker 做 runtime 隔離
4	實現 Self-Correction Loop

不要一開始就追求完美。Shadow Workspace 是 Cursor 團隊幾年迭代的結果，而且即使是他們，最後也選擇了暫時移除。

結語

Shadow Workspace 是一個精彩的工程創新——它展示了如何在不影響用戶體驗的前提下，讓 AI 擁有完整的開發環境存取能力。雖然這個功能已經被移除，但它背後的設計思維對任何構建 AI Agent 的人都有價值。

如果你只記得一件事：

驗證比生成重要。在 AI 的 output 到達用戶之前進行驗證，是提升體驗的唯一可靠方法。Git Worktree + Docker 是你今天就能實現的「窮人版 Shadow Workspace」。

其他 takeaways：

隔離是必要的：AI 需要真實的環境來驗證，但不能污染用戶的工作空間
工程現實：即使是優秀的技術，也可能因為成本、維護、戰略等原因被放棄——這不是失敗，是產品紀律
從簡單開始：別想一步到位，迭代才是王道

下一篇，我會談 AI Agent 架構的另一個核心問題：記憶。驗證解決了「代碼能不能跑」，但還有一個更根本的問題——AI 記不住你是誰、記不住你的專案歷史、記不住上週你們討論過的 coding style。

我們來聊聊怎麼讓 AI 不再是那個每天早上都要重新自我介紹的同事。

參考資料

Cursor Blog: Shadow Workspace — 官方技術 blog（2024 年 9 月），由共同創辦人 Arvid Lunnemark 撰寫，詳細解釋設計目標、失敗嘗試和最終實現，包含設定截圖
Anysphere - Wikipedia — $29.3B 估值、$1B ARR 相關數據來源
GitHub Blog: How GitHub Copilot is getting better at understanding your code — Neighboring Tabs 技術說明
Wiz Blog: $100M ARR in 18 months — SaaS 成長速度比較數據
SaaStr: Cursor Hit $1B ARR in 24 Months — Cursor 成長數據分析

這是「AI Agent 架構實戰」系列的第一篇。下一篇：AI Agent 的記憶革命——從 Stateless 到 26% Accuracy Boost

Android 16 與 AVF：一場 EL2 的權力遊戲