首个持续更新Visual Spec-to-App Benchmark发布

近年来，AI编程代理（Coding Agent）的发展速度令人惊叹。从Claude Code、OpenAI Codex到Cursor、Gemini CLI，大型语言模型已能自主完成编码、调试、运行乃至部署完整的Web应用，“AI软件工程师”正从理论概念加速走向现实落地。然而，一个更具挑战性的问题也随之浮现：如果不再提供GitHub Issue，而是直接给出一张Figma设计稿，AI能否真正开发出一款可交付的产品？

过去几年，SWE-bench、OpenHands等基准测试确实推动了Coding Agent的进步，但它们主要聚焦于代码仓库维护与GitHub Issue修复。相比之下，真实软件开发往往从一份产品需求文档和Figma设计稿起步，开发者需要从零构建完整的Web应用。这意味着，Coding Agent面临的挑战正从代码生成（Code Generation）逐步演进为产品生成（Product Generation）。然而，目前仍缺乏一个能系统评估这种能力的公开基准。

正是为了填补这一空白，来自亚利桑那大学、Zoom和石溪大学的研究团队推出了VISTA——首个面向视觉规范到Web应用（Visual Spec-to-Web-App）的Coding Agent端到端基准测试。与传统软件工程评测不同，VISTA不再要求Agent修复现有代码，而是要求它根据产品需求、网页设计稿和Figma信息，从零开始构建一个完整、可运行、具备真实交互能力的Web应用。

图1：VISTA在线排行榜持续评测Claude、GPT、GLM、Gemini、Cursor等主流Coding Agent，并随模型与Harness的更新实时刷新排名，从产品质量、开发效率和成本等多个维度对比真实的软件开发能力。

如果说过去大家关注的是“谁更会写代码”，那么现在，一个新问题已经出现：谁更会开发产品？VISTA排行榜想要回答的，正是这个问题。从目前的榜单表现来看，有三个值得关注的趋势。

趋势之一：Coding Agent的竞争，已不再是单纯的模型比拼，而是“模型+Harness”的系统级较量。榜单上的评测对象早已不是GPT、Claude或GLM的裸模型，而是它们与开发Harness共同组成的完整Agent。同一模型在不同的Harness下表现可能天差地别，这说明工作流设计、工具调用和执行策略，已成为影响软件开发能力的关键变量。

趋势之二：领先模型之间的差距正在缩小，但离“满分”还差得远。目前排名靠前的fable-5、Claude Opus 4.8、GPT-5.5和GLM-5.2，已能根据产品需求和Figma设计完成完整的Web应用开发，但最高综合得分仍不足0.3。这表明，尽管Coding Agent已具备一定的软件开发能力，但要稳定地完成真实产品开发，仍有很长的路要走。

趋势之三：“最好”并不等同于“最快”或“最省”。从排行榜数据来看，不同Coding Agent已形成截然不同的工程风格。例如，目前排名第一的fable-5虽然综合得分最高，但平均每个任务要消耗约75万Tokens；相比之下，GLM-5.2仅消耗约30万Tokens，几乎只有前者的一半，而GPT-5.5的Token消耗进一步降至约28万。不同模型在开发时间上也差异显著——有些倾向于反复迭代，用更高的计算开销换取更好的产品质量；有些则更注重开发效率，在有限成本内完成任务。

这也意味着，Coding Agent的竞争正从“模型能力”转向“工程能力”。未来的软件工程基准测试，不应只有一张质量排行榜，更需要同时衡量质量、效率和成本，才能真正回答AI是否具备独立开发产品的能力。

正因如此，VISTA从一开始就被设计成一个持续更新的Living Benchmark。随着Claude Code、Codex、Cursor、GLM、GPT、Gemini等模型及Harness的持续迭代，排行榜也将不断刷新，持续记录Coding Agent的能力演进，而不只是停留在论文中的一次性实验结果。

论文已经发布，相关项目、基准数据、评测代码以及在线排行榜也已全部开源上线，并将持续测试最新模型，为社区提供一个开放、持续更新的软件工程评测平台。

VISTA：一个面向真实产品开发的基准测试

图2：VISTA整体框架。给定产品需求、视觉设计以及Figma信息，Coding Agent从零开始完成整个Web Application的开发，并通过统一评测框架验证最终产品质量。

如果说传统基准测试更关注“修改代码”，那么VISTA更关注另一件事：AI是否真的能开发一个完整的软件产品。因此，VISTA没有把任务定义为代码补全，也没有让Agent去修复已有仓库，而是直接从产品设计开始。对于每一个任务，Agent都需要根据产品需求、网页截图以及Figma设计，自主理解页面布局、分析组件层次、选择开发框架，并最终实现一个能运行的多页面Web Application。与传统Design-to-Code工作不同，VISTA不只是要求生成一个静态页面，而是要求Agent完成一次完整的软件开发流程：理解需求、检查上下文、实现页面与交互逻辑、启动应用，并在运行失败时完成调试与修复。整个基准测试更贴近现实中的软件开发，而不是理想化的网页生成任务。

VISTA主要围绕三个目标展开。首先，它关注真实的软件开发流程。Agent不只是生成HTML，而是需要完成页面导航、状态管理、交互逻辑以及应用部署等完整开发任务。其次，它强调视觉规范（Visual Spec）驱动的软件开发。除了自然语言需求外，基准测试同时提供网页截图以及经过裁剪的Figma结构信息，使Agent能够真正理解产品设计，而不仅仅依赖文本描述。更重要的是，VISTA被设计成一个可持续更新的基准测试。Coding Agent正以极快的速度迭代，传统论文中的实验结果往往只能代表某一个时间点。为了持续追踪模型能力的发展，VISTA将长期维护在线排行榜，随着Claude Code、OpenAI Codex、Cursor、Gemini等模型及其Harness的更新持续刷新评测结果。

构建真实世界的软件开发基准测试

图3：VISTA Benchmark覆盖10类真实Web应用，共包含128个页面、3253个交互组件以及458个视觉锚点。

一个基准测试是否可信，很大程度上取决于它的数据。对于Coding Agent而言，直接利用互联网网页构建基准测试并非理想选择。HTML、CSS和JavaScript早已广泛存在于大语言模型的训练数据中，如果直接采用真实网页，很容易受到数据污染的影响，使模型表现被高估。因此，VISTA并没有从网页出发，而是选择以Figma设计稿作为整个基准测试的起点，将Figma渲染截图和结构化JSON共同作为Ground Truth。

整个基准测试覆盖10类典型Web应用，包括新闻、房产、招聘、论坛、旅行预订、聊天、云存储、电商、项目管理和音乐流媒体，共包含128个页面。为了保证评测质量，研究团队进一步裁剪原始Figma JSON，仅保留页面布局、组件层级、文本标签以及交互目标等与开发密切相关的信息。同时，对所有页面进行了细粒度人工标注，共标注3253个可交互组件和458个视觉锚点，为后续评测提供统一、稳定的参考。相比传统网页数据集，VISTA更关注一个核心问题：Agent是否真正理解了产品设计，而不仅仅是生成了一段网页代码。

五种输入条件，模拟真实开发流程

图4：VISTA设计了五种Prompt Conditions，从纯文本需求逐步增加页面截图和Figma结构信息，并分别评测固定技术栈与自由技术栈两种开发模式。

现实中的软件开发，并不存在统一的输入形式。有时开发者只有一份PRD，有时只有设计稿，也有时会直接拿到完整的Figma文件。为了尽可能贴近这些真实场景，VISTA从设计信息和开发自由度两个维度设计了五种Prompt Conditions。一方面，输入从纯文本需求逐步增加页面截图和Figma结构信息，让Agent获得越来越丰富的产品上下文；另一方面，基准测试同时评测固定技术栈和自由技术栈两种开发模式，以分析开发约束对Agent表现的影响。

这种设计不仅能比较不同Coding Agent的整体能力，还能够回答几个更细粒度的问题：页面截图究竟能带来多少帮助？Figma的结构信息是否真正有价值？技术栈约束是否会影响Agent的开发能力？相比传统基准测试的单一设置，VISTA更希望系统地刻画不同开发条件下Agent的能力边界。

不只是“长得像”，更要“真正能用”

现有不少网页生成基准测试主要依赖浏览器Agent或大语言模型判断生成结果，虽然扩展性较好，但在复杂UI场景中容易受到模型本身影响，难以稳定评估真实的软件质量。VISTA采用了一种更加直接的思路：DOM-Grounded Evaluation。评估器（Evaluator）可以同时衡量两件事：生成的界面是否保留了参考结构，以及匹配上的元素是否实现了预期行为。评测分成以下四步：

第一步，坐标对齐。每个参考稿都标注了关键交互目标，包含一个包围框和一个预期交互类型（导航、文本输入、开关、外链、弹窗等）。由于生成的应用会平移、缩放或重排布局，评估器先用高置信度的语义锚点估计一个逐轴仿射变换，把参考稿坐标映射到渲染页面坐标系上。

第二步，DOM元素匹配（定位）。Evaluator在真实浏览器里渲染应用，把每个参考页面映射到对应的实现URL，再把标注目标匹配到页面上可见的可交互DOM候选元素。这一步本身就是一个结构一致性度量：只有当预期组件确实以真实DOM元素存在、且对齐后出现在参考位置附近时，才能拿到高定位分。它因此能惩罚那些纯图像指标容易漏掉的失败：视觉上看着合理却不可交互的“画出来的按钮”、缺失的控件、错位的组件、塌陷的页面结构。

第三步，行为专项检查。定位之后，Evaluator对匹配上的DOM元素跑针对具体交互类型的检查，覆盖前端状态变化、导航或路由行为，以及任务需要时的后端或类数据库状态更新。

相乘的设计意味着一个交互必须“位置对并且行为对”才能得分。VISTA的DOM-Grounded Evaluator结构保证每个交互都会得到定位和行为两个分数，并共同决定最终得分。这意味着，一个组件只有位置正确且功能正确，才能获得高分；如果只是“画出了一个按钮”，却无法点击，或者页面布局正确却交互失效，都无法通过评测。相比只关注视觉相似度，VISTA的评测思路回答了一个更接近真实开发的问题：Agent开发出来的东西，究竟能不能真正交付给用户？

不只是“做得好”，还要“做得快、做得省”

图5：VISTA除了评估最终产品质量，还持续统计不同Coding Agent的开发成本（Tokens）与开发时间（Wall-clock Time），帮助全面评估真实的软件工程能力。

对于真实的软件开发而言，最终效果只是评价标准之一。一个优秀的软件工程师，不仅需要做得好，还需要做得快、做得省。Coding Agent同样如此。因此，除了最终产品质量，VISTA还持续统计每个Agent完成任务所消耗的Token和实际开发时间，帮助开发者从工程角度全面评估不同模型。

从目前的评测结果来看，不同模型之间展现出明显不同的开发策略。例如，Claude Code harness加上Fable-5整体保持了较高的产品质量，但通常会消耗更多Token，并花费更长时间完成开发；Claude Code harness加上GLM-5.2在开发速度和Token消耗之间取得了较好的平衡；Codex加上GPT-5.5则以相对较低的Token消耗获得了接近领先模型的性能，体现出较高的开发效率。这些结果说明，未来评价Coding Agent，不应只有一张排行榜。不同模型正在形成各自不同的工程风格：有的追求最高质量，有的强调开发效率，也有的更加注重成本控制。

因此，VISTA希望提供的不只是一个“谁最好”的排行榜，而是一份更加完整的AI Software Engineer Report，帮助研究者从质量、速度、成本以及后续的开发流程等多个维度，理解不同Coding Agent的真实能力。

不仅评测结果，也分析Agent如何开发

图6：VISTA对不同Coding Agent的开发流程进行分析，比较上下文检查、代码编写、验证以及错误恢复等行为模式。

除了最终得分，VISTA还进一步分析了Coding Agent的开发过程。研究团队将每一次开发过程拆解为上下文检查、代码编写、结果验证、错误恢复等多个阶段，从而观察不同模型在软件开发过程中的行为差异。分析发现，不同模型虽然都遵循“先理解、再开发、最后验证”这一整体流程，但在开发策略上存在明显区分。例如，Claude系列模型更倾向于反复检查上下文，并在失败后重新诊断问题，再继续开发；GPT系列模型则采用更加多样化的修复路径，在验证和错误恢复之间切换更加频繁。这些分析不仅揭示了不同Coding Agent的工作风格，也为未来Agent Workflow的优化提供了新的研究视角。

一个持续演进的基准测试

不同于许多论文发布后便停止维护的基准测试，VISTA更希望成为一个长期演进的Living Benchmark。未来，团队将持续引入最新模型、最新Harness和新的应用场景，不断更新在线排行榜，与社区共同记录Coding Agent的能力演进。从产品需求理解，到视觉设计解析；从网页生成，到交互验证；再到开发流程分析，VISTA将“看图写网页”拆解为视觉理解、页面定位、交互行为、Agent Workflow等多个维度，希望为AI驱动的软件工程研究提供一个更加真实、开放且可复现的评测平台。

随着Coding Agent从“写代码”逐渐迈向“开发产品”，软件工程基准测试也需要从代码评测走向产品评测。可以预见，未来评价一个Coding Agent，不应只问“它会不会写代码”，更应该问：它能不能真正交付一个产品。VISTA希望成为回答这一问题的一个起点。

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：首个持续更新Visual Spec-to-App Benchmark发布要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题