v0 API 使用教程：把 AI 应用生成能力接入你的产品

v0 API 到底能做什么

v0 API 接收自然语言需求后，交付的是一款可运行的全栈应用，而不只是一段代码建议。它会生成代码，在 Vercel Sandbox 中运行结果，提供安全的实时预览，并可直接将应用部署到 Vercel。

可以把每个 v0 chat 理解成一间只服务于一款应用的独立工作室，chat ID 就是进入这间工作室的钥匙。v0 能读取、修改并运行其中的文件，后续每条消息都会基于当前状态继续处理。例如，第一条消息要求创建问题分流看板，下一条要求增加负责人列，那么第二个请求会直接修改工作台上的现有应用。

真正关键的是这种有状态的迭代闭环。普通代码模型只交付文本，执行环节仍需自行完成；v0 会启动开发服务器、检查正在运行的代码，并在工作过程中发现和修复错误。

新版 v2 API 围绕四个直观概念组织，无需了解内部实现也能掌握：

• **Chats（会话）**保存应用当前的文件、元数据、隐私设置以及关联的 Vercel 项目。
• **Messages（消息）**承载指令与历史记录。按顺序排列的 parts 可以展示文本、思考过程、文件读取、文件编辑、搜索、shell 命令、工具调用和 Agent 操作。
• **Previews（预览）**是由短期 token 保护的运行中构建。
• **Deployments（部署）**会把 chat 的当前状态发布到 Vercel。

这也解释了为什么旧示例容易造成误导。当前 v2 快速入门从 v0 包导入；旧版 v1 示例使用 v0-sdk，而且 v1 的 chat ID 无法用于 v2。

v0 API 怎么用：安全接入的最短路径

最简洁且安全的方案，是在你的界面与 v0 之间增加一条轻量服务端路由。浏览器把用户的 prompt 发给你的服务器；服务器保管 API key、调用 v0、存储返回的 chat ID，再只把界面所需的结果发回前端。

1. 选择合适的接入方式

可以从以下三条路径中选择：

1. 运行 npx create-v0-sdk-app，直接搭建一套完整的应用生成界面。
2. 运行 npm install v0，把服务端 SDK 接入现有产品。
3. 通过远程 v0 MCP server 为现有 Agent 提供访问能力；该方式使用 OAuth，无需在 MCP 配置中写入 API key。

如果想最快看懂完整流程，starter 是最合适的起点。它已经包含 React chat 界面、服务端代理路由、生成文件视图、隔离的预览应用以及 v0 Agent skill。

2. 创建密钥，并且只保存在服务端

在 v0 设置中创建 API key，并将其保存为服务端环境变量 V0_API_KEY。不要把它暴露在浏览器代码中，也不要添加 NEXT_PUBLIC_ 前缀。

本地封装层可以通过 npm run dev 运行，但其中的服务端路由仍会调用托管的 v0 API。这是在本地运行集成代码，并不是在本地复制一套 v0 应用构建系统。

3. 一款应用对应一个 chat

首次调用会同时创建一段对话和一个应用工作区：

import { v0 } from 'v0'

const created = await v0.chats.create({
  message: 'Build an issue triage app for a support team.',
})

if (created.error) throw new Error(created.error.message)
const chatId = created.data.chat.id

const changed = await v0.messages.send({
  chatId,
  message: 'Add a priority filter and an assignee column.',
})

if (changed.error) throw new Error(changed.error.message)

请把 chatId 与你自己的客户、工作区或任务记录一同持久化。元数据也可以按相同标识归类 chat，但它只用于组织信息，不能充当访问控制机制。

初始内容并非只能是一条空白 prompt。创建 chat 时，也可以从 GitHub 仓库、ZIP 压缩包或一组文件开始。

4. 决定任务结果如何返回

调用方可以等待最终结果时，使用同步调用；脚本、webhook 和 CI 任务需要排队并稍后查询时，使用异步调用；有人实时查看，而且界面需要呈现 Agent 读取文件、修改代码、执行命令和汇报进度的过程时，则使用流式返回。

chat 和 message 的响应都包含用量信息，因此每项任务完成后都可以记录 token 数量与 credit 成本。

5. 通过代理展示预览，不要直接暴露

API 会返回预览 URL 和一个短期 token。浏览器中的 iframe 无法安全地自行附加该 token，因此文档推荐的做法是：让 iframe 请求先经过你控制的后端代理。

这个代理应部署在专用于预览的站点上，并与主应用使用不同的可注册域名。生成的预览可能执行不受信任的代码。代理还必须验证当前用户身份，并确认其有权访问所请求的 chat；v0 的预览 helper 不会替你完成这项授权。

6. 完成自己的检查后再部署

应用准备就绪后，调用 v0.chats.deploy({ chatId }) 即可把 chat 的当前状态部署到 Vercel。环境变量属于关联的 Vercel 项目，需要通过 Vercel API 管理，因此数据库凭据和第三方密钥必须另行、明确地配置。

v0 API 如何计费

v0 按 credit 计费，而不是为每款生成的应用收取固定费用。输入 token 包括 prompt、上传内容、chat 历史、源文件以及 v0 读取的其他上下文；输出 token 则是 Agent 生成的内容。因此，随着历史记录和代码库不断增长，持续时间较长的 chat 可能花费更多。

Free 套餐为每月 $0，包含每月 $5 credit，并设有每天七条消息的限制。Plus 套餐为每位用户每月 $30，Business 套餐为每位用户每月 $100；两者均为每位用户提供每月 $30 credit。可用 credit 耗尽后，生成任务会暂停。

如果产品直接面向客户，请记录每次 chat 和 message 调用返回的用量。为每个租户设置预算、任务上限，或同时设置两者。否则，一个异常庞大的仓库或无休止的修改循环，就可能耗尽共享余额。

七类应用场景：按受益程度排序

最值得采用 v0 的场景，通常是把它嵌入现有工作流：产品已经了解用户、数据，以及需要构建哪一类应用。

如果正在判断 v0 应该充当底层引擎，还是它本身就是你需要的完整产品，可以参考这份 2026 年最佳 AI 应用生成器对比。区别很重要：当你希望掌控客户体验、规则、计费和审核流程时，API 才真正有价值。

三个值得落地的产品方向

市场确实有需求，但通用应用构建器赛道已经非常拥挤。机会不在于再做一个空白 prompt 输入框，而是打造一个对某项高价值工作理解得格外深入的构建器。

1. 最优选择：嵌入现有 SaaS 的垂直应用构建器

面向单一职业打造受约束的生成器，并作为附加功能卖给已经在使用相关软件的客户。物业管理平台可以生成业主门户，物流平台可以生成运输异常看板，特许经营平台则可以生成门店开业进度跟踪器。

需求规模足以支撑这一品类。ai app builder 在美国 Google 的月搜索量约为 12,100，数据集显示同比增长 50%。用户每月大约会向 AI 助手提出 392 次 build an app with ai，高于 2025 年八月的 231 次，增幅约为 70%。现有应用构建器的月费已经达到 $16 至 $160，这说明买家愿意为这项工作持续支付软件订阅费。

最小可售版本需要两到三种经过批准的应用类型、一份结构化需求表单、每款客户应用对应一个 v0 chat、流式审核界面、安全的预览代理，以及由人工控制的部署按钮。真正的壁垒来自宿主产品的数据模型、权限、模板和分发渠道。

这里有一个残酷却实用的判断标准：通用封装几乎没有防御力。如果无法明确说出，产品对客户业务的哪些了解是 v0 单独无法掌握的，那就不要做。

2. 面向代理商的白标网站与营销活动构建器

为代理商提供带品牌的客户需求入口、固定页面类型、自有设计系统 skill、修改队列和部署交接。客户接触到的是代理商自己的体验，v0 则在幕后负责应用工作区与实时预览。

ai website builder 在美国 Google 的月搜索量约为 40,500，数据集显示同比增长 49%。这是本次研究中可见规模最大的需求池，也意味着市场上已有大量实力不俗的竞争者。真正有效的切入点不是“生成任意网站”，而是“使用这套技术栈、这些组件和这套审批流程，做出符合这家代理商风格的网站”。

MVP 需要一套品牌配置、三种页面模式、素材上传、预览评论和部署审批。难点在于支持服务：当生成的文案、布局、无障碍体验或集成需要修正时，客户追责的是代理商，而不是 v0。

3. 面向产品团队的“功能需求转预览”Bot

把已批准的 issue 转成可运行的候选改动。GitHub App 或内部 webhook 导入仓库，启动异步 v0 chat，记录 chat ID，再把预览回传到 ticket。任何合并或部署都必须先经过人工审核。

Google 记录的 how to build an app with ai 美国月搜索量约为 390，数据集显示同比增长 86%。2026 年七月，AI 助手上的 build an app with ai 月度提问量达到 392 次。这些数据证明用户对完整可运行应用感兴趣，但不足以证明存在一个独立的 CI 市场。因此，更适合把它作为团队功能或开发者平台附加能力，而不是面向大众的自助式产品。

MVP 包括 webhook、仓库 allowlist、异步任务 runner、v0 chat 存储、隔离预览和审批状态。风险是这里最大的难点：生成的预览代码不受信任，仓库访问权限高度敏感，一个看起来可信的 demo 也不能证明测试、安全、迁移和边界情况都正确。绝不能把生产部署设为默认操作。

如需更全面地了解它在 coding Agent 和 prompt-to-app 工具中的位置，可以阅读 2026 年最佳 vibe coding 工具对比。

v0 API 无法替你解决什么

API 提供的是一个应用构建 worker 及其工作间，外围产品仍由你负责。

• 它不会决定应该构建什么。 模糊需求依然可能产出一个精致却方向错误的结果。需求采集、模板、约束和审核关卡都很重要。
• 它不会替你为客户授权。 预览 helper 会转发预览流量，但谁能访问每个 chat，必须由你的应用自行判断。
• 它不会让生成代码自动变得可信。 请在不同可注册域名的预览专用站点上提供预览，并在代码进入生产环境前完成审核。
• 它不会把 v1 chat 迁移到 v2。 需要先选定一个 v1 版本，将其下载为 ZIP，再从该状态创建新的 v2 chat。
• 它不会取代 Vercel API。 环境变量和多项项目操作仍位于关联的 Vercel 项目中。
• 它不会让成本固定。 源文件、对话历史、prompt 与输出都会计入 token 用量。
• 它不是本地应用构建引擎。 集成层可以在本地运行，但文档中的流程会调用 v0 托管 API，并在 Vercel 基础设施中运行预览。

我的判断是：当可运行预览和有状态迭代构成产品优势时，v0 值得采用。如果只需要代码片段、一次性组件或严格确定性的文件转换，那么额外引入工作区、代理、credit 核算与部署机制并无必要。

如果希望为自己的业务设计并加固一套基于 v0 的构建器，我可以为你打造生产级 AI 系统。