Vibe Code Bench: Evaluating AI Models on End-to-End Web Application Development

本文提出了名为 Vibe Code Bench 的新基准，通过自主浏览器代理对 16 个前沿模型进行端到端 Web 应用开发评估，揭示了当前模型在从零构建应用方面仍存在显著局限，并强调了自测试机制及评估者一致性对结果的关键影响。

要点

这篇论文介绍了一个名为 "Vibe Code Bench"（可以想象成“氛围编程大考”）的全新测试项目。

为了让你轻松理解，我们可以把人工智能写代码想象成雇佣一个超级聪明的“数字实习生”。

1. 以前的考试 vs. 现在的考试

• 以前的考试（旧基准）：
  想象一下，你让实习生做一道数学题（比如“计算 1+1"），或者让他修补一个已经写好的乐高城堡里的一个小缺口（比如修复一个 Bug）。

  • 现状： 现在的 AI 在这些“填空题”或“修补题”上表现得很棒，几乎能拿满分。
  • 问题： 但这不代表它能从零开始盖一座完整的房子。

• 现在的考试（Vibe Code Bench）：
  这次，考官直接给实习生一张手绘的草图（自然语言描述，比如“我想做一个能记录习惯的 APP"），然后说：“给你 5 个小时，从零开始，把这座房子盖好，并且要能住人（能运行），还要能通水电（连接数据库和支付系统）。”

  • 核心挑战： 这不是做一道题，而是从 0 到 1 完成整个项目。

2. 考场是怎么设计的？

为了公平测试，作者们搭建了一个全真模拟的“数字工地”：

• 100 个任务： 就像 100 个不同的建筑图纸。有的简单（个人用的习惯追踪器），有的中等（初创公司的预约系统），有的很难（企业级的审批流程）。
• 真实环境： 实习生不能只写代码，他们必须在一个虚拟的房间里，拥有电脑终端（像黑客一样敲命令）、浏览器（像普通人一样点鼠标）和外部服务（比如真的能发电子邮件、真的能处理信用卡支付，虽然是在测试模式下）。
• 考官是谁？ 考官不是人，而是一个全自动的“机器人质检员”。它会像普通用户一样，打开浏览器，一步步点击、登录、买东西、发评论。如果机器人能顺利完成所有步骤，这个 APP 就算“及格”。

3. 考试成绩怎么样？

作者测试了目前世界上最顶尖的 16 个 AI 模型（包括 GPT-5、Claude 等）。结果有点让人清醒：

• 最高分： 最好的模型（GPT-5.3-Codex）只拿到了 61.8% 的通过率。
  • 比喻： 就像让 100 个顶尖建筑师盖房子，结果只有 60 多座房子能真正住人，剩下的要么没盖好，要么门打不开，要么水电没通。
• 结论： 虽然 AI 写代码很厉害，但独立、可靠地从头开发一个完整软件，目前仍然是 AI 的“未解之谜”。

4. 发现了什么有趣的秘密？

在分析这些“实习生”的表现时，作者发现了一个关键的成功秘诀：

• 自我测试（Self-Testing）：
  • 表现好的模型： 它们写几行代码，就会停下来，打开浏览器自己点点看，发现错了就改，再写，再测。就像是一个谨慎的工匠，边做边检查。
  • 表现差的模型： 它们埋头狂写代码，写完直接交卷，从不检查。就像是一个急躁的画手，画完直接扔给老师，结果全是错别字。
  • 数据说话： “自我测试”的次数和最终成绩有极强的正相关（相关系数 0.72）。会“自己找茬”的 AI，才能盖出好房子。

5. 为什么这个测试很重要？

以前我们总问："AI 能不能写代码？”答案是肯定的。
现在的问题是："AI 能不能像人类工程师一样，把想法变成真正能用的产品？”

• 评估更真实： 以前的测试就像考“填空题”，现在的测试是考“毕业设计”。
• 成本与效率： 研究发现，花更多的钱和时间（让 AI 多跑几遍测试），确实能提高成功率，但边际效应递减（越往后越难提升）。
• 谁来当考官？ 论文还发现，谁来做考官很重要。用不同的 AI 模型当考官，对同一个 APP 的打分可能天差地别。这就像让不同的美食评论家试吃，有的觉得好吃，有的觉得难吃。

总结

这篇论文就像给 AI 行业发了一张**“驾照路考”成绩单**。

它告诉我们：现在的 AI 已经能熟练地做数学题和修修补补了，但要想让它独立盖起摩天大楼（从零开发完整应用），它还只是个需要不断自我检查、偶尔会犯错的“新手司机”。

Vibe Code Bench 就是那个让所有 AI 模型必须面对的真实路考，它不再看谁背题背得好，只看谁能真正把车（软件）安全、完整地开到目的地。

技术摘要

Vibe Code Bench：端到端 Web 应用开发 AI 模型评估基准技术总结

1. 研究背景与问题定义 (Problem)

尽管生成式 AI 在代码生成领域取得了显著进展，但现有的评估基准（如 HumanEval、SWE-Bench）主要关注孤立的任务（如函数合成、修复现有代码库中的 Bug），无法衡量模型从自然语言需求出发，从零开始（Zero-to-One）构建完整、可部署 Web 应用的能力。

当前存在的关键缺口在于：

• 缺乏端到端评估：现有基准缺乏对多文件代码、配置管理、部署流程及用户交互工作流的完整评估。
• “氛围编程”（Vibe Coding）的验证缺失：非技术用户希望通过自然语言直接构建应用，但缺乏可靠基准来验证 AI 是否能独立完成从需求到可运行原型的整个过程。
• 评估粒度不足：传统单元测试或 DOM 耦合检查无法真实反映最终用户视角的应用可用性。

2. 方法论 (Methodology)

Vibe Code Bench (VCB) 提出了一套全新的评估框架，包含数据集构建、生成环境、自动化评估管道及指标体系。

2.1 数据集构建 (Benchmark Design)

• 规模与结构：包含 100 个 真实的 Web 应用规范，分为 50 个公开验证集和 50 个隐藏测试集。
• 任务分类：涵盖三个领域，模拟不同复杂度的开发场景：
  • 个人应用 (24 个)：个人用途，通常无认证。
  • 独立开发者应用 (45 个)：初创业务场景，含简单邮件认证。
  • 企业工具 (31 个)：内部系统，含复杂角色权限体系。
• 集成挑战：28% 的任务要求集成外部服务（Stripe 支付、MailHog 邮件），增加了异步处理和状态同步的难度。
• 测试工作流：每个任务配备 6-23 个 自动化浏览器工作流（共 964 个工作流，10,131 个子步骤），覆盖核心功能、边缘案例和关键用户路径。

2.2 生成环境 (Generation Harness)

• 基础架构：基于修改版的 OpenHands，提供容器化的开发环境。
• 工具链：模型拥有终端（Terminal）、浏览器（Browser）访问权限，以及 Supabase（数据库/认证）、Stripe、MailHog 等服务的集成接口。
• 技术栈约束：强制统一技术栈（React + Vite 前端，Tailwind CSS，Supabase 后端，Docker Compose 部署），以确保评估的一致性。
• 时间约束：每个应用生成限时 5 小时，模拟真实开发约束。
• 系统提示词：强制模型在提交前进行自我测试（Self-testing），包括构建、启动 Docker 容器及浏览器验证。

2.3 自动化评估管道 (Automated Evaluation Pipeline)

• 评估代理：使用 Browser Use 自主代理（基于浏览器操作）进行“点击式”测试，而非依赖 DOM 选择器或内部单元测试。
• 评估逻辑：
  1. 部署验证：检查应用是否成功启动。
  2. 工作流执行：代理模拟用户操作，验证每个子步骤（Substep）的预期结果。
  3. 评分标准：单个工作流通过需 ≥90% 的子步骤成功；应用准确率 = 通过的工作流比例。
• 隔离性：每个工作流在独立的浏览器会话和账户数据中运行，防止状态泄露。

2.4 评估指标

• 准确率 (Accuracy)：通过的工作流百分比。
• 成本 (Cost) & 延迟 (Latency)：API 调用成本及生成总耗时。
• 误差分析：对失败案例进行六类归因（认证问题、缺失功能、验证策略阻止、UI 渲染、数据一致性等）。

3. 主要贡献 (Key Contributions)

1. 首个端到端 Web 应用开发基准：提供了 100 个自然语言规范及配套的 964 个浏览器工作流，填补了“零到一”开发评估的空白。
2. 大规模模型评估：对 16 个 前沿模型（包括 GPT-5 系列、Claude Opus/Sonnet、Gemini、Qwen 等）进行了全面评估，涵盖成本、延迟及错误分析。
3. 评估者对齐协议：通过跨模型评估和人工标注研究，证明了评估器选择对结果有重大影响，并建立了模型与人类判断的对齐标准。
4. 开源复现工具：公开了修改后的 OpenHands 脚手架、轨迹数据及评估管道代码。

4. 实验结果 (Results)

4.1 整体性能

• 最高准确率：表现最好的模型 GPT-5.3-Codex 在测试集上的准确率为 61.8%。
• 模型梯队：
  • 第一梯队：GPT-5.3-Codex (61.8%), Claude Opus 4.6 (57.6%)。
  • 第二梯队：GPT-5.2, Claude Opus 4.6 Thinking, Claude Sonnet 4.6 (51%-53%)。
  • 开源/轻量模型：表现显著落后，准确率普遍在 15%-24% 之间（如 GLM-5, Qwen3.5）。
• 对比差异：VCB 的区分度远高于 SWE-Bench。例如，MiniMax M2.5 与 Claude Opus 4.6 在 SWE-Bench 上差距仅 2.8%，但在 VCB 上差距高达 42.7%。

4.2 关键发现

• 自我测试 (Self-Testing) 是关键预测因子：模型在生成过程中使用浏览器进行自我测试的行为与最终准确率呈强正相关 (Pearson r = 0.72)。这表明“边写边测”的迭代策略比单纯增加代码编辑量更重要。
• 难度与集成影响：
  • 随着任务难度从 Easy 到 Hard，准确率急剧下降（Hard 任务平均准确率仅 6%）。
  • 外部集成（特别是 Stripe 支付）显著增加难度，无集成应用平均准确率 34%，而需同时集成邮件和 Stripe 的应用降至 13.5%。
• 失败模式：
  • 主要失败原因：缺失功能 (46.7%) 和认证/授权问题 (20.4%)。
  • 分布特征：模型改进主要体现为减少“完全失败”（得分为 0）的应用数量，而非在所有应用上获得微小提升。
• 评估者对齐：
  • 不同评估器之间的结果差异巨大（例如 GPT-5.2 作为评估器与其他评估器的一致性仅为 33%-38%，而 Claude Sonnet 系列与人类的一致性高达 86%+）。
  • Claude Sonnet 4.5 被证明是与人类判断最一致的评估器。

5. 意义与局限性 (Significance & Limitations)

意义

• 重新定义 AI 编程能力：VCB 将评估焦点从“写代码”转移到“构建软件”，揭示了当前 AI 在端到端开发中仍面临巨大挑战（最高仅 61.8% 成功率）。
• 指导模型优化：研究证明“自我测试”和“迭代修复”是提升端到端性能的关键，为未来 Agent 设计提供了明确方向。
• 标准化评估：为行业提供了一个可复现、实施无关（Implementation-agnostic）的基准，解决了以往评估标准不一的问题。

局限性

• 代码质量未评估：仅关注功能通过性，未评估代码的可维护性、安全性或设计美感。
• 技术栈单一：仅针对 React/Vite + Supabase 栈，结果可能无法泛化到其他框架。
• 仅限 Web 应用：未涵盖命令行工具、桌面应用或移动应用。

总结

Vibe Code Bench 揭示了当前 AI 模型在构建完整 Web 应用方面的能力仍处于“前沿挑战”阶段。虽然顶尖模型已能解决约 60% 的复杂任务，但可靠性（Reliability）仍是主要瓶颈。该基准不仅量化了差距，还通过强调“自我测试”行为和“评估者对齐”的重要性，为下一代 Agentic Coding 系统的发展指明了方向。