v0:把「生成代码」升级成「自己打开自己写的 app 去用它」的发布型 agent
v0-dev
Vercel 的 v0 是闭源全栈生成工具里 agent 闭环做得最完整的一条:联网检索带可点击来源、浏览器实际操作自己生成的 app 并回传截图、沙箱内跑终端与单测、自带 MCP 接外部工具,2026-09 起 GitHub 项目一键 Publish 走完 PR→merge→部署。它的边界同样明确:默认栈锁 Next.js+shadcn、最短路径锁 Vercel、credits 随迭代轮次线性涨,且没有任何公开的正确性基准。
- 置信度
- 厂商宣称
- 只有官方模型卡/发布会,无独立复测
- 关键指标
- GitHub 项目发布链路
- 厂商宣称 · 2026-09
- 成熟度
- 产品
- 研究 → 演示 → 产品 → 生产
编辑判断全栈生成这条赛道里,「能生成」早就不是差异点了,差异点在生成之后谁来验收。v0 把验收做进了 agent 自己:它打开自己写的 app、点一遍流程、看着截图批评设计、再回去改。这是多数开源 harness 需要用户自己接 playwright 才有的闭环,而 v0 让它成为默认路径。这是把它列进 code 域梯顶的核心理由。
第二点是它对既有工程制度的态度。2026-09 的一键 Publish 看着像「让 AI 直接合并代码」,但官方文档明确写了 required checks、review、merge 限制照常生效,规则需要人介入时 v0 暂停并给出 PR 链接而不绕过。在合规团队里,「会不会绕过 review」比「生成得快不快」重要一个数量级,这条行为是它能进企业流程的实际闸门。
三点如实说明。第一,没有任何公开基准:文档给的是能力清单和角色场景,没有 SWE-bench 之类可读数字,所以卡片置信度是 C 级(厂商宣称)。第二,栈与基础设施都有立场,默认 Next.js + Tailwind + shadcn/ui、零配置 AI Gateway 与一键部署都指向 Vercel,已有异构栈的团队收益打折。第三,成本结构随迭代次数走,而 agent 自校验本身就是多轮调用;Fix with v0 的免费额度还要求代码未被手工改过——人一旦介入,修错也开始计费。尚未复测单位成本。
它到底交付什么
v0 官方对自己的定义只有一句:「an AI agent that helps anyone create real code and full-stack apps and agents」。区别于截图式原型工具的地方在于交付物是能跑在 Vercel 生产环境上的 Next.js 代码——默认栈是 Next.js + Tailwind + shadcn/ui,后端能力靠集成补:Neon / Supabase / Upstash / Blob 做数据与存储,Stripe 做支付,Vercel AI Gateway 做模型调用。
2026-08-28 之后有一处结构性变化:v0 生成的应用默认通过 Vercel AI Gateway 零配置接 AI 能力,覆盖文本、结构化输出、embedding、rerank、图像、视频、语音与转写,不再要求用户自己填 provider key。这把「生成的 app 自带 AI 功能」从一段需要人接线的样板代码,变成了默认状态。
agent 能力边界(按官方文档逐项核对)
| 能力 | 实际行为 | 可核验点 |
|---|---|---|
| 联网检索 | 实时搜索,结果内联并给可点击来源链接 | 引用可点开逐条验,不是黑箱摘要 |
| 浏览器使用 | 打开自己生成的 app、实际操作、批评设计、调试复杂流程,过程中回传截图;也可访问外部 URL 取视觉参考 | 闭环自校验:生成→用→挑错→改 |
| 自动修错 | 缺文件/依赖、语法与格式、运行时错误、import/export 问题 | 在生成循环内自动触发 |
| Fix with v0 | 部署报错时出现按钮,把错误日志交给 v0 诊断并修 | 付费档每天 10 次免费,仅对未手工改过的代码免费 |
| 终端命令 | 沙箱内跑 shell:测交互、查仓库、跑单测、调 Vercel/GitHub CLI | 三档权限 Ask / Auto / Full 由用户控 |
| 外部工具 | Marketplace 集成 + 自带 MCP 服务器(Linear / Notion / Sentry 等) | 单 scope MCP 上限 2026-08 从 10 提到 100 |
其中浏览器使用是它与多数开源 coding agent 的真实差距:大多数开源 harness 需要用户自己接一套 playwright 才能形成「生成→打开→看见→修」的闭环,v0 把这段做成了默认路径,并且把截图回传给人看。
发布链路:2026-09-01 的那次收口
GitHub 托管的项目现在有一个统一的 branch + Publish 流程:点 Publish,v0 创建或复用一个 PR、合并进 base 分支、把合并结果部署到生产。常规路径上不再需要在 branch / PR / merge / deploy 四个动作之间来回切。每次改动落在一个隔离的工作分支上并带 preview 部署,可以先验再进 base。
更要紧的是它对既有工程约束的态度:仓库仍然是事实来源,required checks、code review、merge 限制与其他分支保护照常生效;当某条规则需要人介入时,v0 暂停流程并直接给出 PR 链接,而不是绕过。这一条是「vibe coding 工具能不能进有合规要求的团队」的实际闸门——绕过的工具再快也过不了 review 制度。
另外从 2026-08-28 起,在项目内新开的 chat 直接以该项目自己的源码为起点(GitHub 分支 / 托管仓库 / 生产部署),第一条消息就带着代码上下文;沙箱 CPU 或内存打满时付费 chat 会自动升一档 VM 并在后台重启,而不是超时失败。
边界与失败模式
- 栈是有立场的:默认产出 Next.js + Tailwind + shadcn/ui。已有 React 之外的技术栈、或必须落在自建 K8s 上的团队,收益会明显打折。
- 最短路径锁在 Vercel:零配置 AI Gateway 与一键 Publish 都指向 Vercel 基础设施。Git 同步是存在的,但「阻力最小的那条路」不经过你自己的机房。
- 成本随迭代次数走:credits 计费,而 agent 的多轮自校验本身就是多次调用。Fix with v0 的免费额度还额外要求代码未被手工改过——一旦人介入过,修错也开始烧 credits。
- 没有任何公开的正确性基准:官方文档给的是能力清单与角色场景(PM / 设计 / 工程 / 数据 / 市场 / 客服 / 创始人),没有 SWE-bench 之类的可读数字。所有「能生成生产级代码」的说法目前都只有厂商口径。
- 权限档位需要人自己拿捏:Ask / Auto / Full 三档里,Full 意味着沙箱内 shell 基本放手。沙箱隔离是官方说法,我们没有对其逃逸面做独立验证。
我们的复现计划
要把这条从 C 级(厂商宣称)提到 A 级(已确认),需要三件事:同一份 PRD 让 v0 与一个开源 harness 各跑一遍,比对生成代码的可运行率与返工量;在受保护分支上验证「规则需要人介入时确实暂停而不是绕过」;把 credits 消耗与迭代轮次的关系测出来,给出真实单位成本。这三项跑完之前,卡片上的读数请按「厂商说的」理解。