博客

ViBench 2.0：长周期软件构建基准测试

智能体能否一次构建一个功能，最终打造出完整产品？

ViBench 2.0: A Benchmark for Long-Horizon Software Building — cover image

发布于：

2026年10月28日Preeya Kirani

Preeya Kirani

Daniel Furman

Daniel Furman

Peter Zhong

Peter Zhong

Michele Catasta

Michele Catasta

今天我们发布 ViBench 2.0，这是一个面向长周期软件开发的基准测试。它加入了来自 Fireworks [1]的专项智能指数（SII），Fireworks 是我们在开放权重模型推理与训练方面的合作伙伴。SII 汇集了由从业者构建的基准测试，用于在跨行业的真实工作任务上比较开放、闭源和专项模型。

大多数编码基准测试，例如 DeepSWE [2]，在现有代码库中交给智能体一个定义明确的任务。而在 ViBench 2.0 中，智能体从空项目开始，然后以 Uber、GitHub 或 Google Docs 等产品为蓝本，一次构建一个功能，最终打造出完整产品。

ViBench 2.0 包含十七个产品、241 个功能请求和 544 个测试计划。表现最好的模型 GPT-6.1 Sol、GPT-6 Astra 和 Opus 5.5 仅在其 49⁠-⁠65% 的构建中通过了全部测试计划。

我们为何构建 ViBench 2.0

我们以 ViBench 1.0 为蓝本进行建模 [3] 当时Replit用户正在构建的东西，比如协作白板和简历生成器。如今人们来到Replit是为了构建完整的业务，这些业务往往包含功能齐全的软件产品。ViBench 2.0衡量的是模型能否构建出这样的产品。

智能体根据一份简短规格说明构建给定产品的第一个版本，然后在其现有代码之上最多添加十八个功能。这种设计迫使它在还不知道后续需求的情况下就选定数据库模式和路由，因此后续功能可能比早期功能更难实现。ViBench 1.0 发现，当模型向自己编写的代码添加功能时得分更低，论文将这种设定称为 Vibe-on-Vibe。ViBench 2.0 通过模拟产品的演进进一步扩展了这一设定。其中八个产品已在 GitHub 上公开 [4] 采用 Harbor 格式 [5]；其余九个为留出集。本文所有结果均可通过发布版 v2.0.6 中的一条命令，在我们基于 OpenHands 的测试框架上重新运行。 [6].

在此过程中，智能体必须处理：

  • 干净部署： 测试从空数据库启动构建，因此依赖残留数据的构建会全部失败。
  • 现有数据： 在社区聊天产品中，提及某人的消息必须在其改名后显示其新名字。
  • 不变量： 在网约车产品中，分摊车费的分摊金额相加后必须始终精确等于行程费用，精确到分。
  • 陈旧状态： 在代码托管产品中，在他人保存之前打开的编辑器绝不能抹掉他们更新的更改。
  • 并发： 在商城产品中，两种退货方式绝不能对同一件商品重复退款。

最后一个功能构建完成后，评分智能体会在真实浏览器中运行测试计划，进行点击、输入并检查结果。

我们使用 Opus 5.5 作为评分器，因为在我们测试过的模型中，它犯的错误最少。为了检验它，我们在可正常运行的构建中逐一植入了 34 个 bug，而在 bug 可见期间，它从未让任何计划通过。当 GPT-6.1 Sol 对 Opus 的 477 次通过结果重新评分时，99.2% 被确认正确。我们也没有发现任何迹象表明 Opus 偏袒 Claude 模型的构建。

测试计划检查什么

功能请求描述的是用户期望什么，而不是如何构建它。例如，设计工具撤销功能请求的一部分：

Add undo and redo for changes to objects: creating, editing, moving, deleting, grouping and ungrouping, and renaming or rearranging layers in the layers panel. … Each person has their own undo history, so undo only takes back your own changes, never a collaborator’s. Making a new change clears what you could redo.

随后，测试计划会以用户实际触发该规则的方式来检验它。Alice 和 Bob 轮流编辑同一个矩形，然后 Alice 按下撤销：

1. Alice: create rectangle "R" at (100,100), 100x100, fill #CCCCCC.
2. Alice: move R to (300,100).
3. Bob: rename R to "Rocket".
4. Alice: change R's fill to #00AA00.
5. Bob: set R's opacity to 50%.
6. Alice: Undo. Read R on both screens.
...
Verify:
- After 6, R's fill is #CCCCCC while its name is still "Rocket", its opacity still 50% and its position still (300,100).

后续步骤会在 Bob 移动、取消分组或删除形状后重复该检查。GPT-6.1 Sol、GPT-6 Astra 和 Opus 5.5 在它们的十二次构建中有八次未能通过该计划。该请求和该计划均为公开 [4].

各模型对比

ViBench 2.0 的官方结果来自 Fireworks 的运行：每个模型对十七个产品进行四次构建，使用相同的测试框架和设置。所有构建器均以中等努力程度和温度 1.0 运行，并采用相同的限制条件。 README 列出了完整的设置。

ViBench 2.0：每次构建的 pass@1 与成本对比

17 个产品各进行 4 次构建的平均值。须线表示 95% 区间。

Pass@1 是指所有测试计划均通过的构建所占比例，按每个产品的四次构建取平均值。

GPT-6.1 Sol 以 65% 的 pass@1 领先，其次是 GPT-6 Astra 的 60% 和 Opus 5.5 的 49%。这三者都通过了超过 90% 的测试计划，因此它们大多数失败的构建只差几个计划。Sol 每次构建的成本约为 $12，Astra 约为 $90。DeepSeek V4.1 Flash 以每次构建约 $2.50 的成本通过了 77% 的测试计划，不过没有任何开源权重模型能通过完整构建。Opus 5.5 平均约 70 分钟完成一次构建，比 Sol 快约 2.5 倍。Opus 产生的 token 仅少约 6%，因此这一差距主要来自 API 提供商的速度。

各代 GPT 模型的得分

为了观察得分在不同代际模型间的变化，我们自行在八个公开产品上运行了较早的 GPT 模型，与官方结果分开进行。

ViBench 2.0：各 GPT 模型的 pass@1 与计划通过率

8 个公开产品各进行 4 次构建的平均值。

Pass@1 计划通过率

Pass@1 是指所有测试计划均通过的构建所占比例；计划通过率是指一次构建中通过的测试计划所占比例。*GPT-6.1 Sol 是 Fireworks 的官方运行结果；其他模型是我们自己的运行结果。

各代模型的 Pass@1 逐代上升，从 GPT-5.4 的 0% 升至 GPT-6 Sol 的 31% 和 GPT-6.1 Sol 的 53%，计划通过率则从 42% 攀升至 95%。公开产品上的得分低于全部十七个产品上的得分，因此 Sol 在此处的 53% 低于其 65% 的总体成绩。OpenAI 在撰写本文时的最新模型 GPT-6.1 Terra 通过了 47% 的构建，成本约为 GPT-6.1 Sol 的一半。

顶级模型失败之处

顶级模型遗漏的计划，往往是真实用户会遇到的小细节。以下是四个公开产品中的例子：

  • 代码托管产品： 草稿拉取请求永远不会显示其合并冲突。
  • 文档编辑： 没有人能对表格单元格内的文字发表评论。
  • 设计工具： 按下撤销可以撤回队友的更改，而不仅仅是你自己的更改。
  • 社区聊天产品： 没有角色的服务器所有者无法管理任何人。

大多数测试计划检查的是各项功能如何协同工作。有两种失败模式尤为突出。在顶级模型约每 40 次构建中就有 1 次，产品在智能体被告知应当存在的空数据库上根本无法启动，因为后面的 schema 代码在创建表的语句之前就引用了该表。更常见的情况是，构建在功能交汇处失败，正如上面的例子所示。在这些模型的失败构建中，近四分之三仅在功能交汇处失败。

构建成果一览

ViBench 并不评判设计，但设计会影响人们如何评判一个产品。由于这具有主观性，我们在下方附上了截图以及我们的解读。这些截图展示的是我们自己运行所产生的构建结果。

同一家族的模型无论产品是什么，都会产出相似的设计。规格说明描述的是产品做什么，而不是它长什么样，因此模型会退回到自己的品味。GPT 模型倾向于添加插图和醒目的大标题。Claude 模型倾向于构建更朴素的界面，更贴近它们所模仿的产品。在朴素的测试框架下、提示词中没有任何设计指导时，连深色主题这样的选择都取决于模型。在图中代码托管标签页里，Sonnet 5.5 在四次构建中有一次选择了深色主题，而在其他标签页中一次都没有。在我们看来，最好看的构建并不比更朴素的构建更容易通过。

构建 1构建 2构建 3构建 4GPT-6.1 SolGPT-6 AstraOpus 5.5Sonnet 5.5

设计工具每个构建版本的文件浏览器界面，均加载相同数据。点击截图可放大查看。

接下来

如今的顶尖模型在 ViBench 2.0 上能正确构建产品的大部分内容，但逐个功能地构建则暴露了它们的局限。新功能必须与智能体此前编写的代码相契合，而构建往往正是在这里出问题。

我们预计，像这样的分数将出现在更具成本效益的模型上，包括开放权重的模型。GPT-6.1 Sol 以每次构建约 12 美元的成本领先，是这一趋势的早期迹象。

关于方法论的详细说明即将发布。最新结果请见 SII 排行榜 以及 vibench.ai.

致谢

感谢 Fireworks 团队：Vivek Chauhan 和 Charlie Gu 牵头促成了将 ViBench 引入 SII 的合作，Arleen Liu 和 Sandeep Singh 负责运行该基准测试。还要感谢 Georgian——自 ViBench 启动以来一直与我们合作的伙伴，尤其要感谢 Kartik Gupta 构建了 Harbor 适配器，Aditya Shukla 和 Scott Cui 提供的支持，以及 Pashootan Vaezipoor 对项目方向的塑造。最后，感谢 Replit AI 团队的其他成员对 ViBench 的贡献。

参考文献

  1. 专项智能指数
  2. DeepSWE：在原创的长周期工程任务上衡量前沿编程智能体
  3. ViBench：Vibe 编程基准测试
  4. ViBench 公共仓库
  5. Harbor 框架
  6. OpenHands 软件智能体 SDK

附录

产品名称

ViBench 的产品均以公开产品为原型，仅用于评测。产品名称是其各自所有者的商标，这些所有者与 ViBench 无关联，也不为 ViBench 背书。

指标

ViBench 报告四项指标：

  1. Pass@1：所有测试计划均通过的构建所占比例。
  2. 计划通过率：所有步骤均通过的测试计划所占比例，按产品取平均值。
  3. 平均成本：模型完成一次构建的成本，按标价以美元计。
  4. 平均构建时间：一次构建的实际耗时（分钟），从第一个版本到最后一个功能。

区间为 95% 置信区间，由 vibench 分数计算得出 [4]，该方法在接近 0% 时使用精确二项区间。所有模型都在一个基于 OpenHands 构建的智能体运行框架中运行 [6] [6]因此，针对不同配置调优的模型在这里可能会得到较低的分数。

脚注

  1. 1

    这里的所有结果都可以通过一条命令从 v2.0.6 版本重新运行，运行在我们基于 OpenHands 的测试框架上。 [6].

  2. 2

    所有构建器均以中等工作量和温度 1.0 运行，并采用相同的限制条件。 README 列出了完整的设置。

  3. 3

    截图展示的是我们自己运行得到的构建结果。

更多