VibeSDK应用生成、运行、托管的平台

Cloudflare VibeSDK 能让你仅通过自然语言描述需求，即可创建基于人工智能的网络应用。它是一款开源工具，运行于 Cloudflare 平台之上，可提供安全、隔离的环境，支持一键式快速完成应用的构建、预览与部署。你可以自定义 AI 的行为模式、管控代码范式，同时保障数据隐私。
该工具非常适合企业、初创公司或各类团队 —— 即使团队成员不具备深厚的编码能力，也能借助它搭建应用，既能大幅提升开发效率，也能让非技术人员轻松打造所需工具。此外，该平台还支持实时预览、基于聊天的交互模式，并可与 GitHub 集成，实现流畅的工作流协作。

一套“AI 应用生成 + 运行 + 托管”的完整平台是怎么搭出来的？

在大量 AI 项目还停留在“调模型 API”的阶段时，Cloudflare 开源了 VibeSDK ——一个明显不只关心模型，而是直接瞄准**“AI 产品形态”**的工程级项目。

它不是一个简单的 SDK，也不是单一功能库，而是一整套可自建的 AI Web App 生成平台样板：
从自然语言输入 → AI 分阶段生成代码 → 沙盒实时预览 → 一键部署到 Cloudflare 平台，全流程打通。

本文从源码目录结构出发，拆解 VibeSDK 背后隐藏的系统设计。

一句话理解 VibeSDK 是什么

VibeSDK 是一个“AI 应用生成平台”的完整实现，而不是一个模型 SDK。

它解决的问题不是 AI 会不会生成代码，而是：

如何把 AI 生成的代码，变成一个真正能跑、能预览、能部署、能多租户托管的 Web 应用。

项目由 Cloudflare 开源，底层深度绑定 Cloudflare 的 Workers、Durable Objects、D1、R2、AI Gateway、Workers for Platforms 等能力。

在看源码前，先建立整体系统视角

从 README 和仓库结构可以抽象出 VibeSDK 的 四个核心子系统：

1. Web 控制台（UI）
   用户输入需求、查看生成进度、实时预览、点击部署
2. AI Agent 后端
   把自然语言拆成阶段性任务（planning / build / refine），维护 session 状态
3. Sandbox 运行时
   在隔离环境中安装依赖、运行生成项目，提供 Preview URL
4. 平台化部署层
   将生成应用作为“用户项目”部署到 Workers for Platforms，实现多租户托管

接下来我们直接用源码目录来对照这套结构。

顶层目录总览：每个文件夹对应哪块系统？

从仓库根目录看，VibeSDK 的结构非常“平台化”，而不是普通前后端项目。

一、产品主应用（你真正访问的那个 Web 平台）

src/
public/
worker/

这三者共同构成 VibeSDK 的“主体应用”。

• src/
  前端代码（React + Vite），负责：
  • 用户输入 prompt
  • 展示生成阶段（phase）
  • 显示实时日志、预览 iframe
  • 触发 deploy 操作
• public/
  静态资源，如图标、公共文件
• worker/
  Cloudflare Workers 后端：
  • API 路由
  • AI 调用
  • Session 管理
  • Durable Object 定义
  • 与 Sandbox / 平台资源交互

这一点很重要：VibeSDK 的“后端”不是传统服务器，而是完全跑在 Workers 上。

二、SDK 与共享类型（为二次开发准备）

sdk/
shared/types/

• sdk/
  官方 TypeScript SDK，对外提供类似：const client = new PhasicClient(...) const session = await client.build(prompt) await session.wait.deployable()它暴露的是一个**“阶段型（phasic）会话对象”**，而不是简单的 HTTP 封装。
• shared/types/
  前后端共享的类型定义，保证：
  • API 数据结构一致
  • Session / Phase / Event 类型统一

这说明 VibeSDK 在设计之初就假设：
平台能力是要被“程序化调用”的，而不只是给 UI 用。

三、数据层：D1 + Drizzle 的工程选择

migrations/
drizzle.config.local.ts
drizzle.config.remote.ts

VibeSDK 使用 Cloudflare D1（SQLite）+ Drizzle ORM。

从工程角度看，这是一个非常“平台友好”的选择：

• D1：
  • 边缘原生
  • 部署成本低
  • 足够支撑 session / 项目 / 审计数据
• Drizzle：
  • 强类型
  • 易与 TS 前后端共享模型
  • 迁移文件清晰可控

本地 / 远端两套 drizzle config，通常用于：

• 本地开发生成迁移
• 远端 Cloudflare D1 实例应用迁移

四、Sandbox 与运行时：生成代码不是“写完就算了”

container/
SandboxDockerfile
debug-tools/

这是很多 AI 项目完全没有的一层，但 VibeSDK 明确把它作为核心。

• SandboxDockerfile
  定义“预览运行时”的基础镜像：
  • Node / 包管理器
  • 构建工具
  • 运行权限限制
• container/
  与沙盒运行、预览环境调度相关的实现

为什么一定要这一层？

因为 VibeSDK 不只是生成代码，而是要：

• 安装依赖
• 启动 dev server
• 暴露 preview URL
• 隔离用户代码，避免安全问题

这一步，决定了“生成器”和“产品”的本质差异。

五、工程化与自动化工具链

scripts/
test/
vitest.config.ts
.github/
.husky/

这些目录让 VibeSDK 更像一个可长期维护的平台项目：

• 自动化脚本（本地启动、迁移、部署）
• 测试（Vitest）
• CI / Git Hooks
• 代码规范与质量控制

六、部署与平台配置：真正吃满 Cloudflare 能力

wrangler.jsonc
wrangler.test.jsonc
.dev.vars.example
vite.config.ts
worker-configuration.d.ts

这里是 VibeSDK 最“Cloudflare 味”的部分。

在 wrangler.jsonc 中，通常可以看到：

• Durable Object 绑定（session / agent 状态）
• D1 数据库绑定
• R2 Bucket（模板、生成产物）
• KV Namespace（轻量状态 / 缓存）
• AI Gateway 配置
• Workers for Platforms 的 dispatch namespace

最后这一点，意味着：

用户生成的应用，会被当成“子 Worker”部署到平台上，而不是跑在主应用里。

这正是 VibeSDK 能做成多租户平台的关键。

一次完整调用在系统里是如何流转的？

从源码结构，可以还原一条典型链路：

1. 用户在前端输入一句需求
2. worker/ 创建或恢复一个 session（Durable Object）
3. AI Agent 分阶段生成代码（Planning → Build → Refine）
4. 生成项目被送入 Sandbox 运行
5. 前端实时显示 Preview URL
6. 用户点击 Deploy
7. 项目通过 Workers for Platforms 发布为独立应用

整个过程，没有传统服务器。

VibeSDK 真正厉害的地方

• 它不是 demo，而是平台级参考实现
• 它把 AI 生成问题，拆解为：
  • 状态机
  • 生命周期
  • 隔离运行
  • 平台托管
• 它清晰地回答了一个问题：
  “AI 应用如何规模化、产品化？”

GitHub：https://github.com/cloudflare/vibesdk
油管：https://youtu.be/szm99yk5qXo