凯明格资讯网首个持续更新Visual Spec-to-App Benchmark发布
随着 Coding Agent（编码智能体）技术的持续爆发式增长，从 Claude Code、更新OpenAI Codex 到 Cursor、发布Gemini CLI，持续大语言模型已具备自主完成 Web 应用编码、更新调试、发布运行乃至部署的持续全栈能力。「AI 软件工程师」的更新概念正加速走向现实。然而，发布行业面临着一个核心拷问：
如果摒弃传统的持续 GitHub Issue，转而提供一张 Figma 设计稿，更新AI 能否构建出真正可交付的发布商业级产品？
过去几年，SWE-bench 和 OpenHands 等基准测试极大地推动了 Coding Agent 的持续发展，但其焦点主要集中在代码仓库维护及 Issue 修复上。更新然而，发布真实的软件开发往往始于产品需求文档（PRD）与 Figma 设计稿，要求开发者从零构建完整的 Web 应用。这标志着 Coding Agent 的挑战已从单纯的 Code Generation（代码生成）演进为 Product Generation（产品生成）。针对这一空白，来自亚利桑那大学、Zoom 和石溪大学的研究团队推出了 VISTA（VIsual Spec-To-App Benchmark）——这是首个面向 Visual Spec-to-Web-App Coding Agents 的端到端基准测试。
与传统软件工程基准不同，VISTA 不再要求 Agent 修复既有代码，而是要求其根据产品需求、网页设计稿及 Figma 结构信息，从零构建一个完整、可运行且具备真实交互能力的 Web 应用。
图 1：VISTA Online Leaderboard 持续追踪 Claude、GPT、GLM、Gemini、Cursor 等主流 Coding Agent 的表现，并随模型与 Harness 的迭代实时刷新。该榜单从产品质量、开发效率及成本等多维度，深度评估真实的软件开发能力。
如果说过去的焦点是「谁更擅长写代码」，那么今天的核心问题已转变为：谁更擅长开发产品？
VISTA Leaderboard 旨在回答这一问题。从当前数据中，我们观察到三个关键趋势：
竞争范式转移：从「模型竞争」到「模型 + Harness」的系统竞争
排行榜上的评测对象已不再是单一的 GPT、Claude 或 GLM，而是由「模型 + 开发 Harness」组成的完整 Agent 系统。同一模型在不同 Harness 下的表现差异显著，这表明工作流设计、工具调用策略及执行逻辑已成为影响软件开发能力的关键变量。头部差距缩小，但距离「完美」仍有巨大鸿沟
尽管 fable-5、Claude Opus 4.8、GPT-5.5 和 GLM-5.2 等领先模型已能根据需求和设计稿完成完整 Web 应用开发，但其最高综合得分仍不足 0.3。这揭示出，虽然 Coding Agent 已具备初步的软件开发能力，但在稳定性与真实产品开发要求之间仍存在显著差距。「最优解」不等于「最快」或「最省」
不同 Coding Agent 展现出截然不同的工程风格。例如，排名第一的 fable-5 虽获最高综合得分，但平均任务消耗约 75 万 Tokens；相比之下，GLM-5.2 仅消耗约 30 万 Tokens（约为前者的一半），GPT-5.5 进一步降至约 28 万。在开发时间上，部分模型倾向于通过高计算开销换取高质量（反复迭代），而另一些则注重在有限成本下提升效率。
这意味着，Coding Agent 的竞争正从「模型能力」转向「工程能力」。未来的软件工程 Benchmark 不应仅关注质量排行榜，而应同时衡量 质量（Quality）、效率（Speed）和成本（Cost），以真正验证 AI 独立开发产品的能力。
正因如此，VISTA 自诞生起便被设计为 持续更新（Living Benchmark）。随着 Claude Code、Codex、Cursor、GLM、GPT、Gemini 等模型及 Harness 的快速迭代，排行榜将不断刷新，持续记录 Coding Agent 的能力演进，而非仅停留在论文的一次性实验结果中。
论文已发布于 arXiv，项目网站、Benchmark 数据集、评测代码及在线 Leaderboard 均已开源上线，并为社区提供开放、持续更新的软件工程评测平台。
Paper：https://arxiv.org/abs/2605.26144
GitHub：https://github.com/kaboider/VISTA_Bench
Project Website & Leaderboard：https://kaboider.github.io/VIS_APP/
VISTA：面向真实产品开发的 Benchmark
图 2：VISTA 整体框架。给定产品需求、视觉设计及 Figma 信息，Coding Agent 从零开始完成整个 Web Application 的开发，并通过统一评测框架验证最终产品质量。
若传统 Benchmark 关注「修改代码」，VISTA 则聚焦于另一核心命题：AI 是否具备开发完整软件产品的能力？
因此，VISTA 未将任务定义为代码补全或仓库修复，而是从产品设计源头介入。对于每个任务，Agent 需根据产品需求、网页截图及 Figma 设计，自主理解页面布局、分析组件层次、选择开发框架，并最终实现可运行的多页面 Web Application。与传统 Design-to-Code 工作流相比，VISTA 不仅要求生成静态页面，更要求 Agent 完成完整的软件开发闭环：理解需求、检查上下文、实现页面与交互逻辑、启动应用，并在运行失败时进行调试与修复。这一过程高度贴近现实软件开发，而非理想化的网页生成任务。
VISTA 主要围绕三大目标展开：
- 关注真实的软件开发流程：Agent 需完成页面导航、状态管理、交互逻辑及应用部署等完整任务，而非仅生成 HTML。
- 强调 Visual Spec 驱动的软件开发：除自然语言需求外，Benchmark 提供网页截图及裁剪后的 Figma 结构信息，使 Agent 能真正理解产品设计，而非仅依赖文本描述。
- 可持续更新的 Benchmark 架构：鉴于 Coding Agent 的快速迭代特性，VISTA 长期维护在线 Leaderboard，随模型及 Harness 更新持续刷新评测结果，避免静态实验数据的局限性。
构建真实世界的软件开发 Benchmark
图 3：VISTA Benchmark 覆盖 10 类真实 Web 应用，共包含 128 个页面、3253 个交互组件以及 458 个视觉锚点。
Benchmark 的可信度很大程度上取决于数据质量。对于 Coding Agent 而言，直接利用互联网网页构建数据集并非理想选择。由于 HTML、CSS 和 JavaScript 已广泛存在于大语言模型的训练数据中，直接使用真实网页极易导致数据污染（Data Contamination），从而高估模型表现。
因此，VISTA 选择以 Figma 设计稿为起点，将 Figma 渲染截图和结构化 JSON 共同作为 Ground Truth。
- 数据覆盖：涵盖新闻、房产、招聘、论坛、旅行预订、聊天、云存储、电商、项目管理和音乐流媒体等 10 类典型 Web 应用，共计 128 个页面。
- 数据清洗：研究团队裁剪原始 Figma JSON，仅保留与开发密切相关的页面布局、组件层级、文本标签及交互目标信息。
- 人工标注：对所有页面进行细粒度人工标注，共标注 3253 个可交互组件和 458 个视觉锚点（Visual Anchors），为后续评测提供统一、稳定的参考标准。
相比传统网页数据集，VISTA 更关注一个问题：Agent 是否真正理解了产品设计，而不仅仅是生成了一段网页代码。
五种输入条件，模拟真实开发流程
图 4：VISTA 设计了五种 Prompt Conditions，从纯文本需求逐步增加页面截图和 Figma 结构信息，并分别评测固定技术栈与自由技术栈两种开发模式。
现实中的软件开发输入形式各异：有时仅有 PRD（产品需求文档），有时仅有设计稿，有时则直接提供完整的 Figma 文件。为贴近真实场景，VISTA 从 设计信息丰富度和 开发自由度两个维度设计了五种 Prompt Conditions：
- 输入维度：从纯文本需求逐步增加页面截图和 Figma 结构信息，赋予 Agent 越来越丰富的产品上下文。
- 技术栈维度：同时评测 固定技术栈和 自由技术栈两种开发模式，以分析开发约束对 Agent 表现的影响。
这种设计不仅支持比较不同 Coding Agent 的整体能力，还能深入回答以下细粒度问题：
* 页面截图究竟能带来多少性能提升？
* Figma 的结构信息是否具备实际价值？
* 技术栈约束是否限制了 Agent 的开发能力？
相比传统 Benchmark 的单一测试设置，VISTA 旨在系统性地刻画不同开发条件下 Agent 的能力边界。
不只是「长得像」，更要「真正能用」
现有网页生成 Benchmark 多依赖浏览器 Agent 或大语言模型判断生成结果，虽扩展性好，但在复杂 UI 场景中易受模型本身影响，难以稳定评估真实软件质量。
VISTA 采用 DOM-Grounded Evaluation（DOM 接地评估）思路，Evaluator 同时衡量两件事：生成的界面是否保留参考结构，以及 匹配元素是否实现预期行为。评估流程分为四步：
坐标对齐：
每个参考稿标注关键交互目标（包含包围框及预期交互类型，如导航、文本输入、开关、外链、弹窗等）。由于生成应用可能存在平移、缩放或重排，评估器首先利用高置信度的语义锚点估计逐轴仿射变换，将参考稿坐标映射至渲染页面坐标系。DOM 元素匹配（定位）：
Evaluator 在真实浏览器中渲染应用，将参考页面映射至对应实现 URL，并将标注目标匹配到页面上可见的可交互 DOM 候选元素。此步骤本身即为结构一致性度量：只有当预期组件以真实 DOM 元素存在且对齐后位于参考位置附近时，才能获得高定位分。此举能有效惩罚那些视觉合理但不可交互的「画出来的按钮」、缺失控件、错位组件或塌陷的页面结构。行为专项检查：
定位完成后，Evaluator 对匹配上的 DOM 元素执行针对具体交互类型的检查，覆盖前端状态变化、导航/路由行为，以及在任务需要时的后端或类数据库状态更新。
相乘的设计意味着一个交互必须「位置对并且行为对」才能得分。
VISTA 的 DOM-Grounded Evaluator 确保每个交互都获得 定位（Localization）和 行为（Behavior）两个分数，二者共同决定最终得分。这意味着，组件必须位置正确且功能正确才能获高分；若仅「画出按钮」却无法点击，或布局正确但交互失效，均无法通过评测。
相比仅关注视觉相似度，VISTA 的评测思路回答了一个更贴近真实开发的问题：Agent 开发出来的网站，究竟能不能真正交付给用户使用？
不只是「做得好」，还要「做得快、做得省」
图 5：VISTA 除了评估最终产品质量，还持续统计不同 Coding Agent 的开发成本（Tokens）与开发时间（Wall-clock Time），帮助全面评估真实的软件工程能力。
在真实软件开发中，最终效果仅是评价标准之一。优秀的软件工程师不仅需要 做得好（Quality），还需 做得快（Speed）和 做得省（Cost）。
Coding Agent 亦然。因此，VISTA 在评估产品质量的同时，持续统计每个 Agent 完成任务所消耗的 Token 数量与 实际开发时间（Wall-clock Time），助力开发者从工程角度全面评估不同模型。
从当前评测结果来看，不同模型展现出明显的开发策略差异：
* 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，帮助研究者从质量（Quality）、速度（Speed）、成本（Cost）及后续开发流程（Workflow）等多维度，深入理解不同 Coding Agent 的真实能力。
不仅评测结果，也分析 Agent 如何开发
图 6：VISTA 对不同 Coding Agent 的开发流程进行分析，比较上下文检查、代码编写、验证以及错误恢复等行为模式。
除最终得分外，VISTA 进一步深入分析 Coding Agent 的开发过程。
研究团队将每次开发过程拆解为 上下文检查（Inspect）、代码编写（Write）、结果验证（Verify）、错误恢复（Failure Recovery）等多个阶段，以观察不同模型在软件开发过程中的行为差异。
分析发现，尽管不同模型均遵循「先理解、再开发、最后验证」的整体流程，但在具体策略上存在显著区别：
* Claude 系列模型：倾向于反复检查上下文，并在失败后重新诊断问题，再继续开发。
* GPT 系列模型：采用更多样化的修复路径，在验证和错误恢复之间切换更为频繁。
这些分析不仅揭示了不同 Coding Agent 的工作风格，也为未来 Agent Workflow 的优化提供了新的研究视角。
相比只关注最终分数，VISTA 希望进一步回答：优秀的 Coding Agent，究竟是如何完成软件开发的？
一个持续演进的 Benchmark
不同于许多论文发布后便停止维护的 Benchmark，VISTA 致力于成为一个 长期演进（Living Benchmark）。
未来，团队将持续引入最新模型、最新 Harness 及新的应用场景，不断更新在线 Leaderboard，与社区共同记录 Coding Agent 的能力演进。
从产品需求理解，到视觉设计解析；从网页生成，到交互验证；再到开发流程分析，VISTA 将「看图写网页」拆解为 视觉理解、页面定位、交互行为、Agent Workflow等多个维度，希望为 AI 驱动的软件工程研究提供一个更加真实、开放且可复现的评测平台。
随着 Coding Agent 从「写代码」逐渐迈向「开发产品」，软件工程 Benchmark 也需要从 代码评测（Code-Centric Evaluation）走向 产品评测（Product-Centric Evaluation）。
我们相信，未来评测一个 Coding Agent，不应只问「它会不会写代码」，更应该问：它能不能真正交付一个产品。VISTA 希望成为回答这一问题的一个起点。
关于团队
本工作由 University of Arizona、Zoom与 Stony Brook University合作完成。团队长期从事 AI Agent、大语言模型、多智能体系统等方向研究，近期重点关注 AI for Software Engineering、Coding Agent 的评测、优化与应用，致力于推动更加开放、可复现的软件工程 Benchmark 建设。
作者介绍
第一作者：
* Junjia Guo：University of Arizona Electrical and Computer Engineering 博士生（导师：Jingdi Chen）。研究方向包括 Agentic AI、大语言模型（LLM）和视觉语言模型（VLM）。主要负责 VISTA Benchmark 构建、评测框架设计及 Online Leaderboard 系统开发。
其他作者：
* Yuhang Yao：Zoom 高级研究工程师。研究方向包括可信多智能体网络和大语言模型后训练（Post-training）。卡内基梅隆大学博士，长期从事生产级 LLM Agent 系统研发。
* 个人主页：https://yuhangyao.com/
* Jiawei Zhou：Stony Brook University 助理教授。研究方向包括自然语言处理、机器学习、大语言模型、AI Agent、推理规划、多模态及 AI 评测。
* 个人主页：https://joezhouai.com/
* Jingdi Chen：University of Arizona Electrical and Computer Engineering 助理教授，ANNIE Research Group 负责人。研究方向包括 AI Agent、多智能体强化学习、软件工程、网络优化、网络安全、可解释 AI、大语言模型/视觉语言模型（LLM/VLM）及量子计算与人工智能交叉研究。
* 个人主页：https://jingdichen.com/info
平台建设
- Zimeng Pan：Google 软件工程师，卡内基梅隆大学硕士。参与 VISTA Benchmark 模型测试、Online Leaderboard 持续更新。
- Chang Li：University of Arizona ANNIE Research Group Research Intern（导师：Jingdi Chen）。参与 Coding Agent 模型测试、Benchmark 实验运行、评测数据整理及 Online Leaderboard 平台维护，支持 VISTA Benchmark 的持续更新。
