说实话，Zui近那个叫 v0 的东西火得一塌糊涂，kan着它行云流水般生成代码，哪个前端工程师心里不痒痒？我也一样。前阵子业务上正好有个契机，我就想，与其眼馋，不如自己动手“蹬”一个出来。结果你猜怎么着？从动念到跑通核心流程，也就是一天的事儿。这要是放在没有 AI 辅助的年代，光是调研沙箱方案、搭架构，估计就得耗掉我半条命。

今天不整那些虚头巴脑的理论，直接把这次“狂飙”的底裤扒下来给大家kan。咱们聊聊怎么用 Claude Code 在一天内搞定一个类 v0 的平台，顺便把源码和架构思路dou摊开来讲。对了本文的 POC代码Yi经开源了想kan热闹或者想拿来直接改的，Ke以去 GitHub 上搜 yuzai/code-...，也就是那个跑通了“用户输入 → Agent 生成代码 → 沙箱预览”Zui小闭环的仓库。

一开始，我其实挺纠结的。市面上的方案五花八门，但归根结底，AI 生成前端代码的路径无非就那么几条：要么吐给你一个巨大的 HTML 文件，要么给你一堆代码块，要么直接生成一个完整的项目结构。

Ru果选生成单文件 HTML，那部署和预览确实简单，省心省力。但后期维护简直就是灾难。想象一下AI 给你吐了一个几百行甚至上千行的文件，样式、逻辑、结构全搅和在一起，就像一锅煮烂的面条。要是哪天产品经理说“改个按钮颜色”，你打开代码一kan，估计会瞬间梦回刀耕火种的年代。Neng改吗？Neng。痛苦吗？非常痛苦。这也就意味着，一旦上了这条船，以后迭代你就得死心塌地依赖 AI，这项目基本就告别人工维护了。

所以我还是决定走 v0 的路子：直接生成项目。这样预览和部署dou跟正规项目没两样，虽然麻烦点，但至少像个人写的代码。

在实现过程中，我发现Ru果让一个 Agent 既写代码又Zuo审查，它hen容易精神分裂。上下文一污染，输出质量就直线下降。所以我引入了 Sub-Agents 机制。简单说就是职责拆分，实现关注点分离。有的 Agent 专门负责听懂人话，有的负责写代码，有的负责自审。这样一来每个角色douNeng专注自己的领域，效率反而geng高。

整个系统，我Zui后敲定用 Next.js 来Zuo前后端服务。为什么？因为它全栈，够灵活，而且对于这种需要频繁交互的场景，React 的生态简直是如鱼得水。

核心架构其实就三块：Next.js 前端、Next.js 后端，还有一个至关重要的 E2B 沙箱。

前端这块，别kan它长得像个聊天软件，其实门道不少。除了常规的消息流展示和聊天输入框，我还得搞定代码文件树的渲染、实时预览的 iframe，以及那些打断、重试的交互控制。用户得Nengkan见代码是怎么一步步变出来的，还得Neng实时kan到效果，这体验才完整。

后端的角色相对单纯点，但也少不了。它主要负责接收前端发来的消息，维护好“会话 ID”和“沙箱 ID”的映射关系。然后它就像个传声筒，把用户的话转发给对应沙箱里的 Agent，再把 Agent 的流式输出原封不动地透传回前端。这里有个细节要注意，沙箱是有闲置超时机制的，所以映射层得处理好沙箱的重建和恢复逻辑，不然用户喝口水回来沙箱没了那体验就崩了。

说实话，沙箱方案是整个选型里Zui让我头秃的。WebContainer 虽好，但要授权；Sandpack 倒是开源，但加载速度有时候让人捉急。至于自己用 Babel 转 CommonJS 搞个编译系统，也不是不行，但要支持 JSX、Vue 什么的，那工作量可就海了去了。

Zui后我还是选了 E2B。它基于自定义模板启动，模板里我预装了 Node.js 环境和项目脚手架。沙箱里直接跑 Claude Agent SDK，负责代码的生成和修改。同时启动 dev server，利用 E2B 的端口暴露Neng力，直接把预览丢给前端。这基本是个纯前端的方案，轻便，而且够用。

当然这方案Zui大的坑在于：你得给每个用户dou准备一个沙箱。这对运维和部署Neng力要求不低，而且内存、CPU 资源dou得跟上，钱包得鼓一点。不过好在现在像 E2B、Cloudflare 这些服务商douZuo得不错，付费调 API 的话，搞起来也还算顺手。

既然是用 Claude Code，那环境得先搭好。这步虽然基础，但也是Zui容易卡人的地方。

确保你的 Node.js 版本在 18.0 以上，这没什么好商量的。Ru果你是 Mac 用户，直接 brew install --cask claude-code 或者用那个一键脚本 curl -fsSL https://claude.ai/install.sh | bash dou行。Windows 用户就geng简单了去官网下个安装包，一路 Next 就完事。

装完别急着兴奋，先在终端敲一下 claude --version。要是蹦出了版本号，恭喜你，第一步迈出去了。要是没反应，回头检查一下环境变量或者是不是装到了奇怪的地方。

接下来是配置。这步有点繁琐，但为了后面省心，还是得耐着性子Zuo。去你的用户目录下找 setting.json，没有就自己建一个。里面得填点东西，比如 API Key。Ru果你不用官方接口，想用第三方的，记得把 base_url 改一下。大概配置长这样：

{
  "claudeCode.environmentVariables": ,
  "claudeCode.selectedModel": "default"
}

这里有个小坑，因为咱们大部分人用的是第三方大模型，导致 Claude Code 那个自动保存代码版本的功Neng有时候不太好使。不过也没事，咱们这个 POC 主要是验证流程，版本控制这种高级功Neng，后续慢慢磨就是了。

hen多人好奇，AI 生成了代码之后怎么改？是让它直接改第几行第几列吗？千万别。AI 对行号的识别感人的时候居多，你要是信它，代码Neng给你改崩了。

Zui靠谱的方案其实是“字符搜索并替换”。我在浏览器侧实现了一个支持局部替换的 Edit Tool。这跟hen多 CLI 工具在本地修改代码的策略是一样的。你让 AI 去找那段代码的特征，然后替换掉，比数行号准得多。感兴趣的Ke以去kankan pi-mono 项目里 edit 工具的实现，基本就是这个路子。

Zuo完这个项目，我Zui大的感触其实不是“AI 写代码真快”，而是另一种geng深层的思考。

在这个过程中，我甚至直接把 Cursor 给退订了。因为在这个系统里我完全不需要自己上手写代码。单说执行这块，AI 确实是“夯爆”了人类根本没法比。

但是这并不意味着我们Ke以躺平了。相反，焦虑感依然存在只是形式变了。以前焦虑的是代码写不完，现在焦虑的是方案选不对。在这个项目里花时间Zui多的从来不是写代码，而是Zuo决策。沙箱选哪个？Babel 转义好不好用？增量geng新怎么Zuo？这些dou需要人去拍板。

AI 充其量是个超级参谋，它Neng给你十个方案，但选哪个，砍哪个，还是得靠人。执行层 AI Yi经无敌了但执行之前的那些战略判断，AI 替不了你。所以与其焦虑被替代，不如想清楚自己在一件事里到底在Zuo什么。毕竟方向盘还是得有人握着，AI 只是那个踩油门的。

这套方案，本质上就是给用户准备一个沙箱，里面直接启动一个 Claude Code 或者 Codex 之类的工具。它Ke以是 CLI，也Ke以是 SDK。上下文的维护完全扔给 Agent SDK，后端只管存个映射关系。

至于部署，通用的Zuo法是在沙箱里完成 Git 提交，推到远程仓库触发 CI/CD。这部分每家公司dou有自己的流水线，参考意义不大，我就不多废话了。

整体来讲，技术卡点其实不多。Zui核心的 AI 代码生成，有 Agent SDK 撑着，质量跟直接用 Claude Code 没差。沙箱管理和前端页面反而是 AI Zui擅长的，我“蹬”起来几乎毫无压力。

一切方案落定，Plan Mode 一开，Opus 模型一跑，反而是Zui轻松的时刻。kan着屏幕上代码自己流淌出来那种感觉确实有点魔幻。第一次产物出来的时候，基本就Neng达到Zui小 demo 的效果了。

Zui后还是那句话，感兴趣的Ke以去kankan源码。虽然本文不会包含具体的代码片段，但核心的架构和实现原理，我douYi经毫无保留地倒出来了。至于交互上的细节，比如打断输入、补充说明、向用户提问明确需求，这些只要花点心思，douNeng打磨得不错。

这就是我和 Claude Code 狂飙 24 小时的故事。不难，但挺震撼。希望这篇复盘Neng给你带来点启发，哪怕一点点，也值了。