一天時間，用 Claude Code 蹬了一個 v0 出來（附原始碼）
最近，出於業務需要，參考 v0 的實作，蹬了一個類似 v0 的平台出來。先看效果：
整體採用 Next.js 做前後端服務，E2B 提供沙箱，Claude Agent SDK 完成程式碼生成，沙箱提供預覽和程式碼推送部署能力。
備註：本文不會包含任何的程式碼（本身也都是 AI 生成的），只會介紹相關方案的選型、核心的架構和實作原理。同時關於部署的環節，各個公司都有自己的部署流水線，並不具備參考價值，會弱化這個環節的介紹。
方案比較和設計
AI 生成前端程式碼，一般有這幾種方式：生成一份 HTML、一份程式碼塊，或是直接生成完整專案。
生成 HTML
生成一份 HTML，然後做增刪改查，最終存儲 HTML 即可；不論是預覽還是部署，都最為簡單。
很多產品都是這麼做的，例如 Claude 的 Artifacts、Google 的 Stitch。
這是最簡單也最輕便的方案。
這裡面的關鍵技術點有幾個：
- 如何讓 AI 生成高品質的 HTML？當然主要靠一些非常優秀的提示詞來約束 AI 的行為。
- 如何做增量修改？可在瀏覽器端實作一個支援局部替換的 Edit 工具，這也是很多 CLI 工具在本地修改程式碼的常見策略。
- 後期的可維護性是這個方案最大的隱患。生成的 HTML 往往是一個幾百行甚至上千行的單檔案，沒有元件拆分、沒有模組化，樣式與邏輯全部混在一起。若需要人工介入修改，資深工程師看到這樣的程式碼，會有種回到刀耕火種時代的感覺──能改，但非常痛苦。這也意味著，一旦走上這條路，後續的迭代就只能繼續依賴 AI，專案實際上已不再適合人來維護。
備註：這裡可能有人好奇，為什麼不是修改某一行某幾列的程式碼？因為 AI 對行號的識別不夠精準，反而直接執行字串搜尋並替換更為可靠。有興趣的可以查看 pi-mono 專案中 edit 工具的實作，這也是絕大部分 CLI 工具的實作方案。
至於 HTML 的預覽與部署，可說是極為簡單且花費最少的方式。
生成程式碼塊
另一種方式是：生成程式碼塊，存放在資料庫中，預覽採用 WebContainer、Sandpack，或是透過 Babel 轉 CommonJS 在瀏覽器端模擬打包等方式來預覽前端專案。
這基本上是純前端的方案，不過 WebContainer 要授權，Sandpack 則是開源，但載入速度可能有一些問題。至於用 Babel 轉 CommonJS 自行實作編譯系統也是可行的，只是要支援 jsx、vue 等，會花一些時間，開發工作量不小。
當然，除了這些建置，如何穩定 AI 的輸出也是這方案中的一大問題；理想情況下，希望 AI 的產物是以「檔名 + 內容」組成的 JSON 陣列。
一般可以透過幾個方案來改善：
- 換更好的模型
- 運用 XML 類的提示詞技巧，讓 AI 的輸出更具結構性
但這個方案有幾個較大的問題：
- 編譯工程的複雜度較高
- 增量替換方案中，輸出格式可能不如工具調用那樣精準，在耗時和品質上會較低效
- 對於外部依賴的套件，需要提前做編譯、告知 AI 用法等，相對上不那麼自由
直接生成專案
直接生成完整專案，最終預覽和部署都跟一般專案一樣。這也是 v0 的方案。
這個方案本質上是給使用者準備一個沙箱，沙箱中直接啟動像 Claude Code 或 Codex 這樣的工具，可以是 CLI 也可以是 SDK。
同時指定一個工作目錄，最終的專案生成與運行都發生在該工作目錄下。使用者的輸入直接指向 Claude Code，從而完成專案的生成。
這個方案的彈性最高，同時因為背後是最頂尖的 AI 生成工具，所以在品質與效率上，其實都不太需要擔心。
但是最大問題在於需要為每一個使用者都提供一個沙箱，對運維與部署能力的要求比較高。
同時沙箱的記憶體與 CPU 分配，資源上也不能少。
不過好在已有許多服務商提供這類服務，例如 E2B、Cloudflare 等。付費調用 API 的話，準備一個沙箱也很容易。
對比表格
| 維度 | 生成 HTML | 生成程式碼塊 | 直接生成專案 |
|---|---|---|---|
| 實作複雜度 | 低 | 中 | 高 |
| 預覽方案 | 直接渲染 iframe | WebContainer / Sandpack / Babel 轉 CommonJS | 沙箱內啟動 dev server |
| 部署複雜度 | 極低，存 HTML 即可 | 低，純前端方案 | 高，需要為每個使用者分配沙箱 |
| 增量修改準確度 | 高（字串 Edit 工具） | 中（輸出格式不如工具呼叫穩定） | 高（Agent SDK 原生工具呼叫） |
| AI 輸出穩定性 | 高（單檔，約束簡單） | 中（需要結構化 JSON 輸出，依賴提示詞技巧） | 高（由 Agent 工具鏈保證） |
| 外部依賴支援 | 弱（只能用 CDN 引入） | 弱（需提前編譯、告知 AI 用法） | 強（可自由使用 npm install） |
| 程式碼可維護性 | 低（不適合人工維護） | 中 | 高（標準專案結構） |
| 資源消耗 | 極低 | 低 | 高（沙箱需分配記憶體與 CPU） |
| 彈性 | 低 | 中 | 高 |
| 代表產品/實例 | Claude Artifacts、Google Stitch | Bolt.new（基於 StackBlitz WebContainer） | v0、本文實作 |
架構設計
整體架構如上，分為三個部分：
- Next.js 前端：聊天輸入框、訊息流展示、程式碼檔案樹、即時預覽 iframe，以及中斷 / 重試等互動控制。
- Next.js 後端：接收前端訊息，維護會話與沙箱的對應關係，將訊息轉發給對應沙箱內的 Agent，並將 Agent 的串流輸出透傳回前端。
- E2B 沙箱：基於自訂範本啟動，範本內預裝了 Node.js 執行環境與專案腳手架。沙箱內運行 Claude Agent SDK，負責程式碼的生成與修改；同時啟動 dev server，並透過 E2B 的端口對外暴露以提供預覽。
訊息流轉
使用者操作流程如下：
- 使用者開啟平台，發起第一條訊息，後端按需建立 E2B 沙箱（冷啟動約需數秒）
- 沙箱就緒後，後端將訊息投遞給沙箱內的 Claude Agent SDK
- Agent SDK 開始工作：呼叫檔案讀寫工具生成或修改程式碼
- Agent 的輸出以串流事件的形式，經後端透傳回前端即時展示
- 程式碼變更同步到檔案樹，預覽 iframe 直接載入沙箱暴露的端口
會話與沙箱管理
在多使用者情境下，每個會話對應一個獨立的沙箱實例，天然具備隔離性。
上下文的維護完全交給 Agent SDK，後端只需持久化「會話 ID → 沙箱 ID」的映射即可。考量到沙箱會有閒置超時機制，需要在映射層做好沙箱的重建與恢復邏輯；一般沙箱服務商基本都會內建這些能力。
部署發佈
程式碼的部署與發佈，一個比較通用的方案是在沙箱內完成 Git 提交，推到遠端倉庫後觸發 CI/CD 流水線，從而完成專案上線。由於這部分高度依賴各公司自身的發佈體系，本文不做展開。
整體來說技術卡點並不多。最核心的 AI 程式碼生成能力，靠 Agent SDK 就能完成，品質與直接使用 Claude Code 不相上下。沙箱管理與前端頁面反而是 AI 最不擅長的部分，實作起來壓力不大。
心得體會
整體上蹬一個 v0，讓 AI 寫程式碼實際花的時間並不多，大約一天左右就能跑出來。
但實話說，這個方案其實來來回回跟 AI 拉扯了好幾天：從生成 HTML、生成片段程式碼，到最後選定沙箱方案；而小到增量更新的解法、Babel 轉義的優劣，都是需要考量的項目。
包括是用 Agent SDK，還是直接用 Claude CLI，也是經過多方權衡後的決定。
一切方案落定，Plan Mode 開啟，Opus 一開，反而是最輕鬆的時刻。
基本上第一次的產物，就能達到最小 demo 的效果。
至於互動上的細節，比如中斷輸入、補充說明、向使用者提問以明確需求，這些細節的打磨也只是花點心思就能解決。
整體而言，在沒有 AI 介入之前，其實不太可能這麼快完成一個系統。單是沙箱方案的選型，可能就要花好幾天，例如沙箱的暫停與恢復、費用比較等等，這些也是 AI 輔助決策的結果；有了決策後，實作又是幾天，確實在效率上提升非常明顯。
在這個過程中，我自己也直接退訂了 Cursor，因為完全不需要再手動修程式碼；就執行這塊而言，AI 的效能確實非常強。
很難說不焦慮，但又覺得不必過度焦慮。這次最大的體感不是「AI 寫程式碼很快」，而是整個過程中，花時間最多的仍然是人在做的事──判斷方案的取捨、理解各種工具的邊界、決定什麼值得做、什麼可以砍掉。執行層 AI 確實很猛，但在執行之前的那些決策，AI 只是參謀，拍板的還是人。
所以與其焦慮被取代，不如想清楚自己在一件事中到底在做什麼。畢竟 AI 還是需要有人去「蹬」，至於蹬到哪裡去，這個問題 AI 替不了你。
原始碼
本文的 POC（Proof of Concept，概念驗證）程式碼已開源，以最小實作跑通「使用者輸入 → Agent 生成程式碼 → 沙箱預覽」這條核心流程，感興趣可以參考： https://github.com/yuzai/code-gen
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
