最近，出于业务需要，参考 v0 的实现，蹬了一个类似 v0 的平台出来。

先看效果：

整体采用 Next.js 做前后端服务，E2B 提供沙箱，Claude Agent SDK 完成代码生成，沙箱提供预览和代码推送部署能力。

ps: 本文不会包含任何的代码(本身也都是 AI 生成的)，只会介绍相关方案的选型、核心的架构和实现原理。同时关于部署的环节，各个公司都有自己的部署流水线，并不具备参考价值，会弱化这个环节的介绍。

方案对比和设计

AI 生成前端代码，一般有这么几种方式：一份 html，一份代码块，以及直接生成项目。

生成 html

生成一份 html，然后增删改查，最终存储 html 即可，不论是预览还是部署，都最为简单。

有很多产品都是这么做的，比如 Claude 的 Artifacts，Google 的 Stitch。

这是最简单，也最轻便的方案。

这里面的关键技术点有几个：

1. 如何让 AI 生成高质量的 HTML？当然这也无非就是需要一些非常优秀的提示词来约束 AI 的行为。

2. 如何增量修改？通过在浏览器侧实现一个支持局部替换的 Edit Tool 即可，这也是很多 cli 工具在本地修改代码的常见策略。

3. 后期的可维护性是这个方案最大的隐患。生成的 HTML 往往是一个几百行甚至上千行的单文件，没有组件拆分，没有模块化，样式和逻辑全部混在一起。如果需要人工介入修改，多年程序员看到这样的代码，大概会有一种被拉回刀耕火种时代的感觉——能改，但很痛苦。这也意味着，一旦走上这条路，后续的迭代就只能继续依赖 AI，项目实际上已经不再适合人来维护。

ps: 这里可能会有人好奇，为什么不是修改某一行某几列的代码，这是因为 AI 对于行号识别不准确，反而直接执行字符搜索并替换更为准确。感兴趣的可以查看 pi-mono 项目中 edit 工具的实现，这也是绝大部分 cli 工具的实现方案。

至于 html 的预览和部署，可谓是极为简单且花费最少了。

生成代码块

另一种方式是：生成代码块，存储在数据库中，预览采用 WebContainer、Sandpack，或者通过 Babel 转 CommonJS 在浏览器端模拟打包等方式来预览前端项目。

这基本是纯前端的方案，不过 WebContainer 要授权，Sandpack 倒是开源，但是加载速度上可能存在一些问题。至于 Babel 转 CommonJS 自行实现编译系统，也是 ok 的，只是要支持 jsx, vue, 要花一点时间，开发的工作量不小。

当然，除了这些建设，如何稳定 AI 的输出，也是这个方案中的一大问题，理想情况下，希望 AI 的产物是 文件名 + 内容 组合成的 json 数组。

一般可以通过几个方案来解决：

1. 换更好的模型
2. 运用 XML 这样的提示词技巧，来让 AI 输出的更符合预期

但是这个方案有几个比较大的问题：

1. 编译工程复杂度比较高
2. 增量替换的方案，输出格式可能不如工具调用那般精准，在耗时和质量上会更低效一点。
3. 对于外部依赖的包，需要提前做编译、告知 AI 用法等，相对不那么自由

直接生成项目

直接生成项目，最终预览和部署都和普通的项目一样。这也是 v0 的方案。

这个方案本质上是给用户准备一个沙箱，这个沙箱中，直接启动一个 claude code 或者 codex 这样的工具，可以是 cli 也可以是 sdk。

同时指定一个工作目录，最终的项目生成和运行，都发生在这个工作目录下。用户输入直接指向 claude code，从而完成项目的生成。

这个方案的灵活度最高，同时由于背后是最顶尖的 AI 生成工具，所以在质量上和效率上，其实都不太需要担心。

但是最大的问题就在于需要给每一个用户都提供一个沙箱，对于运维部署的能力要求比较高。

同时沙箱的内存分配和 cpu 分配，资源上也不能少。

不过好在已经有很多服务商提供这样的服务，比如 E2B、Cloudflare 等服务商。付费调 API 的话，准备一个沙箱也很容易。

对比表格

维度	生成 HTML	生成代码块	直接生成项目
实现复杂度	低	中	高
预览方案	直接渲染 iframe	WebContainer / Sandpack / Babel 转 CommonJS	沙箱内启动 dev server
部署复杂度	极低，存 HTML 即可	低，纯前端方案	高，需要为每个用户分配沙箱
增量修改精准度	高（字符串 Edit Tool）	中（输出格式不如工具调用稳定）	高（Agent SDK 原生工具调用）
AI 输出稳定性	高（单文件，约束简单）	中（需要结构化 JSON 输出，依赖提示词技巧）	高（由 Agent 工具链保证）
外部依赖支持	弱（只能用 CDN 引入）	弱（需要提前编译、告知 AI 用法）	强（npm install 自由安装）
代码可维护性	低（不适合人工维护）	中	高（标准项目结构）
资源消耗	极低	低	高（沙箱需要分配内存和 CPU）
灵活度	低	中	高
代表产品	Claude Artifacts、Google Stitch	Bolt.new（基于 StackBlitz WebContainer）	v0、本文实现

架构设计

整体的架构图如上，分为三块：

1. Next.js 前端：聊天输入框、消息流展示、代码文件树、实时预览 iframe，以及打断/重试等交互控制。

2. Next.js 后端：接收前端消息，维护会话与沙箱的映射关系，将消息转发给对应沙箱内的 Agent，并将 Agent 的流式输出透传回前端。

3. E2B 沙箱：基于自定义模板启动，模板内预装了 Node.js 环境和项目脚手架。沙箱内运行 Claude Agent SDK，负责代码的生成与修改；同时启动 dev server 并通过 E2B 的端口暴露能力对外提供预览。

消息流转

用户操作路径如下：

1. 用户打开平台，发起第一条消息，后端按需创建 E2B 沙箱（冷启动约需几秒）
2. 沙箱就绪后，后端将消息投递给沙箱内的 Claude Agent SDK
3. Agent SDK 开始工作：调用文件读写工具生成或修改代码
4. Agent 的输出以流式事件的形式，经后端透传回前端实时展示
5. 代码变更同步到文件树，预览 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 生成代码 → 沙箱预览"这条核心流程，感兴趣的可以查看：github.com/yuzai/code-…