来自 University of Arizona、Zoom 与 Stony Brook University 的研究团队推出了 VISTA, 首个面向 Visual Spec-to-Web-App Coding Agents 的端到端 Benchmark。近年来Coding Agent 正以前所未有的速度发展。从 Claude Code、OpenAI Codex 到 Cursor、Gemini CLI大语言模型已经能够自主完成编码、调试、运行甚至部署整个 Web 应用「AI 软件工程师」正逐渐成为现实。然而一个新的问题也随之出现如果不给 AI 一个 GitHub Issue而是给它一张 Figma 设计稿它还能开发出一个真正可以交付的产品吗过去几年SWE-bench、OpenHands 等 Benchmark 极大推动了 Coding Agent 的发展但它们主要关注代码仓库维护和 GitHub Issue 修复。相比之下真实的软件开发通常始于一份产品需求PRD和一张 Figma 设计稿需要开发者从零构建完整的 Web 应用。这意味着Coding Agent 面临的挑战已经从 Code Generation 逐渐演进为 Product Generation。然而目前仍然缺少一个能够系统评测这一能力的公开 Benchmark。为了解决这一问题来自 University of Arizona、Zoom 与 Stony Brook University 的研究团队推出了 VISTAVIsual Spec-To-App Benchmark, 首个面向 Visual Spec-to-Web-App Coding Agents 的端到端 Benchmark。不同于传统软件工程 BenchmarkVISTA 不再要求 Agent 修复已有代码而是要求 Agent 根据产品需求、网页设计稿以及 Figma 信息从零开始构建一个完整、可运行、具有真实交互能力的 Web 应用。图 1VISTA Online Leaderboard 持续评测 Claude、GPT、GLM、Gemini、Cursor 等主流 Coding Agent并随着模型与 Harness 的更新实时刷新排行榜。从产品质量、开发效率和成本等多个维度比较真实的软件开发能力。如果说过去大家关注的是「谁更会写代码」那么今天一个新的问题已经出现谁更会开发产品VISTA Leaderboard 希望回答的正是这个问题。从目前的排行榜来看有三个值得关注的趋势:第一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 的竞争正从「模型能力」逐渐演变为「工程能力」的竞争。未来的软件工程 Benchmark不应只有一张质量排行榜更应该同时衡量质量Quality、效率Speed和成本Cost真正回答 AI 是否具备独立开发产品的能力。也正因为如此VISTA 从一开始便被设计成持续更新Living Benchmark。随着 Claude Code、Codex、Cursor、GLM、GPT、Gemini 等模型及 Harness 持续迭代排行榜也将不断刷新持续记录 Coding Agent 的能力演进而不仅仅停留在论文中的一次性实验结果。论文目前已发布于 arXiv项目网站、Benchmark、评测代码以及在线 Leaderboard 已全部开源并且上线并将持续测试最新模型为社区提供一个开放、持续更新的软件工程评测平台。Paperhttps://arxiv.org/abs/2605.26144GitHubhttps://github.com/kaboider/VISTA_BenchProject Website Leaderboardhttps://kaboider.github.io/VIS_APP/VISTA一个面向真实产品开发的 Benchmark图 2VISTA 整体框架。给定产品需求、视觉设计以及 Figma 信息Coding Agent 从零开始完成整个 Web Application 的开发并通过统一评测框架验证最终产品质量。如果说传统 Benchmark 更关注「修改代码」那么 VISTA 更关注另一件事情AI 是否真的能够开发一个完整的软件产品。因此VISTA 并没有把任务定义为代码补全也没有让 Agent 修复已有仓库而是直接从产品设计开始。对于每一个任务Agent 都需要根据产品需求、网页截图以及 Figma 设计自主理解页面布局、分析组件层次、选择开发框架并最终实现一个能够运行的多页面 Web Application。与传统 Design-to-Code 工作相比VISTA 不只是要求生成一个静态页面而是要求 Agent 完成一次完整的软件开发流程理解需求、检查上下文、实现页面与交互逻辑、启动应用并在运行失败时完成调试与修复。整个 Benchmark 更加贴近现实中的软件开发而不是理想化的网页生成任务。VISTA 主要围绕三个目标展开。首先它关注真实的软件开发流程。Agent 不只是生成 HTML而是需要完成页面导航、状态管理、交互逻辑以及应用部署等完整开发任务。其次它强调 Visual Spec 驱动的软件开发。除了自然语言需求之外Benchmark 同时提供网页截图以及经过裁剪的 Figma 结构信息使 Agent 能够真正理解产品设计而不仅仅依赖文本描述。更重要的是VISTA 被设计成一个可持续更新的 Benchmark。Coding Agent 正以极快的速度迭代传统论文中的实验结果往往只能代表某一个时间点。为了持续追踪模型能力的发展VISTA 将长期维护在线 Leaderboard随着 Claude Code、OpenAI Codex、Cursor、Gemini 等模型及其 Harness 的更新持续刷新评测结果而不是停留在一组静态实验数据。构建真实世界的软件开发 Benchmark图 3VISTA Benchmark 覆盖 10 类真实 Web 应用共包含 128 个页面、3253 个交互组件以及 458 个视觉锚点。一个 Benchmark 是否可信很大程度取决于它的数据。对于 Coding Agent 而言直接利用互联网网页构建 Benchmark 并不是一个理想选择。HTML、CSS 和 JavaScript 早已广泛存在于大语言模型的训练数据中如果直接采用真实网页很容易受到数据污染Data Contamination的影响使模型表现被高估。因此VISTA 并没有从网页出发而是选择以 Figma 设计稿作为整个 Benchmark 的起点将 Figma 渲染截图和结构化 JSON 共同作为 Ground Truth。整个 Benchmark 覆盖 10 类典型 Web 应用包括新闻、房产、招聘、论坛、旅行预订、聊天、云存储、电商、项目管理和音乐流媒体共包含 128 个页面。为了保证评测质量研究团队进一步裁剪原始 Figma JSON仅保留页面布局、组件层级、文本标签以及交互目标等与开发密切相关的信息。同时对所有页面进行了细粒度人工标注共标注 3253 个可交互组件 和 458 个视觉锚点Visual Anchors为后续评测提供统一、稳定的参考。相比传统网页数据集VISTA 更关注一个问题Agent 是否真正理解了产品设计而不仅仅是生成了一段网页代码。五种输入条件模拟真实开发流程图 4VISTA 设计了五种 Prompt Conditions从纯文本需求逐步增加页面截图和 Figma 结构信息并分别评测固定技术栈与自由技术栈两种开发模式。现实中的软件开发并不存在统一的输入形式。有时开发者只有一份 PRD (Product Requirements Document) 有时只有设计稿也有时会直接拿到完整的 Figma 文件。为了尽可能贴近这些真实场景VISTA 从设计信息和开发自由度两个维度设计了五种 Prompt Conditions。一方面输入从纯文本需求逐步增加页面截图和 Figma 结构信息让 Agent 获得越来越丰富的产品上下文另一方面Benchmark 同时评测固定技术栈和自由技术栈两种开发模式以分析开发约束对 Agent 表现的影响。这种设计不仅能够比较不同 Coding Agent 的整体能力还能够回答几个更加细粒度的问题页面截图究竟能带来多少帮助Figma 的结构信息是否真正有价值技术栈约束是否会影响 Agent 的开发能力相比传统 Benchmark 的单一测试设置VISTA 更希望系统地刻画不同开发条件下 Agent 的能力边界。不只是「长得像」更要「真正能用」现有不少网页生成 Benchmark 主要依赖浏览器 Agent 或大语言模型判断生成结果虽然扩展性较好但在复杂 UI 场景中容易受到模型本身影响难以稳定评估真实的软件质量。VISTA 采用了一种更加直接的思路DOM-Grounded Evaluation。Evaluator 可以同时衡量两件事生成的界面是否保留了参考结构以及匹配上的元素是否实现了预期行为。Evaluation 分成以下四步第一步坐标对齐。 每个参考稿都标注了关键交互目标包含一个包围框和一个预期交互类型 (导航、文本输入、开关、外链、弹窗等)。由于生成的应用会平移、缩放或重排布局评估器先用高置信度的语义锚点估计一个逐轴仿射变换把参考稿坐标映射到渲染页面坐标系上。第二步DOM 元素匹配 (定位)。 Evaluator 在真实浏览器里渲染应用把每个参考页面映射到对应的实现 URL, 再把标注目标匹配到页面上可见的可交互 DOM 候选元素。这一步本身就是一个结构一致性度量只有当预期组件确实以真实 DOM 元素存在、且对齐后出现在参考位置附近时才能拿到高定位分。它因此能惩罚那些纯图像指标容易漏掉的失败视觉上看着合理却不可交互的 画出来的按钮、缺失的控件、错位的组件、塌陷的页面结构。第三步行为专项检查。 定位之后Evaluator 对匹配上的 DOM 元素跑针对具体交互类型的检查覆盖前端状态变化、导航 / 路由行为以及任务需要时的后端或类数据库状态更新。第四步聚合。 对每个关键交互评估器给出定位分和行为分最终的结构 — 功能分数是两者逐项相乘后取平均:相乘的设计意味着一个交互必须「位置对并且行为对」才能得分。VISTA 的 DOM-Grounded Evaluator 结构保证每个交互都会得到定位Localization和行为Behavior两个分数并共同决定最终得分。这意味着一个组件只有位置正确且功能正确才能获得高分如果只是「画出了一个按钮」却无法点击或者页面布局正确却交互失效都无法通过评测。因此相比只关注视觉相似度VISTA 的评测思路回答了一个更接近真实开发的问题Agent 开发出来的网站究竟能不能真正交付给用户使用不只是「做得好」还要「做得快、做得省」图 5VISTA 除了评估最终产品质量还持续统计不同 Coding Agent 的开发成本Tokens与开发时间Wall-clock Time帮助全面评估真实的软件工程能力。对于真实的软件开发而言最终效果只是评价标准之一。一个优秀的软件工程师不仅需要做得好Quality还需要做得快Speed、做得省Cost。Coding Agent 同样如此。因此除了最终产品质量VISTA 还持续统计每个 Agent 完成任务所消耗的 Token 和 实际开发时间Wall-clock Time帮助开发者从工程角度全面评估不同模型。从目前的评测结果来看不同模型之间展现出明显不同的开发策略。例如Claude Code harnessFable-5 整体保持了较高的产品质量但通常会消耗更多 Token并花费更长时间完成开发Claude Code harnessGLM-5.2 在开发速度和 Token 消耗之间取得了较好的平衡Codex GPT-5.5 则以相对较低的 Token 消耗获得了接近领先模型的性能体现出较高的开发效率。这些结果说明未来评价 Coding Agent不应只有一张排行榜。不同模型正在形成各自不同的工程风格有的追求最高质量有的强调开发效率也有的更加注重成本控制。因此VISTA 希望提供的不只是一个「谁最好」的排行榜而是一份更加完整的 AI Software Engineer Report帮助研究者从质量Quality、速度Speed、成本Cost以及后续的开发流程Workflow等多个维度理解不同 Coding Agent 的真实能力。不仅评测结果也分析 Agent 如何开发图 6VISTA 对不同 Coding Agent 的开发流程进行分析比较上下文检查、代码编写、验证以及错误恢复等行为模式。除了最终得分VISTA 还进一步分析了 Coding Agent 的开发过程。研究团队将每一次开发过程拆解为上下文检查Inspect、代码编写Write、结果验证Verify、错误恢复Failure Recovery等多个阶段从而观察不同模型在软件开发过程中的行为差异。分析发现不同模型虽然都遵循「先理解、再开发、最后验证」这一整体流程但在开发策略上存在明显区别。例如Claude 系列模型更倾向于反复检查上下文并在失败后重新诊断问题再继续开发GPT 系列模型则采用更加多样化的修复路径在验证和错误恢复之间切换更加频繁。这些分析不仅揭示了不同 Coding Agent 的工作风格也为未来 Agent Workflow 的优化提供了新的研究视角。相比只关注最终分数VISTA 希望进一步回答优秀的 Coding Agent究竟是如何完成软件开发的一个持续演进的 Benchmark不同于许多论文发布后便停止维护的 BenchmarkVISTA 更希望成为一个长期演进Living Benchmark。未来团队将持续引入最新模型、最新 Harness 和新的应用场景不断更新在线 Leaderboard与社区共同记录 Coding Agent 的能力演进。从产品需求理解到视觉设计解析从网页生成到交互验证再到开发流程分析VISTA 将「看图写网页」拆解为视觉理解、页面定位、交互行为和 Agent Workflow 等多个维度希望为 AI 驱动的软件工程研究提供一个更加真实、开放且可复现的评测平台。随着 Coding Agent 从「写代码」逐渐迈向「开发产品」软件工程 Benchmark 也需要从代码评测Code-Centric Evaluation走向产品评测Product-Centric Evaluation。我们相信未来评测一个 Coding Agent不应只问「它会不会写代码」更应该问它能不能真正交付一个产品。VISTA 希望成为回答这一问题的一个起点。