Claude、GLM、GPT谁是最强AI工程师？首个持续更新基准测试发布

近年来，Coding Agent 的发展速度有目共睹。从 Claude Code、OpenAI Codex 到 Cursor、Gemini CLI，这些大语言模型已经能够自主完成编码、调试、运行乃至部署完整的 Web 应用——“AI 软件工程师”这一概念，正逐步从理想走向现实。

然而，一个更为尖锐的问题也随之而来：

如果提供给 AI 的不是一个 GitHub Issue，而是一张 Figma 设计稿，它能否真正开发出一个可交付的产品？

过去几年，SWE-bench、OpenHands 等基准测试在推动 Coding Agent 进化方面发挥了关键作用，但它们主要聚焦于代码仓库维护和 GitHub Issue 修复。真正的软件开发通常始于一份产品需求文档和一张 Figma 设计稿——开发者需要从零开始构建完整的 Web 应用。这意味着，Coding Agent 面临的挑战已不仅仅是代码生成，而是产品生成。遗憾的是，业界一直缺乏一个能够系统评估这一能力的公开基准。

来自 University of Arizona、Zoom 与 Stony Brook University 的研究团队，近期推出了 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 试图回答的正是这个问题。从当前的排行榜来看，有三个趋势值得关注。

第一，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 的竞争正从“模型能力”逐渐转向“工程能力”的较量。未来的软件工程基准，不应只有一张质量排行榜，更应该同时衡量质量（Quality）、效率（Speed）和成本（Cost），真正回答 AI 是否具备独立开发产品的能力。

正因如此，VISTA 从设计之初就被定位为持续更新的基准（Living Benchmark）。随着 Claude Code、Codex、Cursor、GLM、GPT、Gemini 等模型及 Harness 的持续迭代，排行榜也将不断刷新，持续记录 Coding Agent 的能力演进——而非停留在论文中一次性实验的结果。

论文目前已发布在 arXiv，项目网站、Benchmark、评测代码以及在线 Leaderboard 已全部开源并上线，并将持续测试最新模型，为社区提供一个开放、持续更新的软件工程评测平台。

• 论文地址：https://arxiv.org/abs/2605.26144

• GitHub 仓库：https://github.com/kaboider/VISTA_Bench

• 项目网站与排行榜：https://kaboider.github.io/VIS_APP/

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

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

如果说传统基准更注重“修改代码”，那么 VISTA 更关心另一件事：AI 是否真的能开发出一个完整的软件产品。

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

VISTA 主要围绕三个目标展开。

首先，它关注真实的软件开发流程。 Agent 不只是生成 HTML，而是需要完成页面导航、状态管理、交互逻辑以及应用部署等完整开发任务。

其次，它强调视觉规格驱动的软件开发。 除了自然语言需求之外，Benchmark 同时提供网页截图以及经过裁剪的 Figma 结构信息，使 Agent 能够真正理解产品设计，而不仅仅依赖文本描述。

更重要的是，VISTA 被设计成一个可持续更新的基准。 Coding Agent 的迭代速度极快，传统论文中的实验结果往往只能代表某个时间点。为了持续追踪模型能力的发展，VISTA 将长期维护在线 Leaderboard，随着 Claude Code、OpenAI Codex、Cursor、Gemini 等模型及其 Harness 的更新持续刷新评测结果，而非停留在一组静态实验数据上。

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

图 3：VISTA 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 是否真正理解了产品设计，而不仅仅是生成了一段网页代码。

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

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

现实中的软件开发，并不存在统一的输入形式。有时开发者只有一份 PRD，有时只有设计稿，也有时会直接拿到完整的 Figma 文件。为了尽可能贴近这些真实场景，VISTA 从设计信息和开发自由度两个维度设计了五种 Prompt Conditions。

一方面，输入从纯文本需求逐步增加页面截图和 Figma 结构信息，让 Agent 获得越来越丰富的产品上下文；另一方面，Benchmark 同时评测固定技术栈和自由技术栈两种开发模式，以分析开发约束对 Agent 表现的影响。

这种设计不仅能够比较不同 Coding Agent 的整体能力，还能回答几个更细粒度的问题：

• 页面截图究竟能带来多少性能提升？

• Figma 的结构信息是否确实具有价值？

• 技术栈约束是否会影响 Agent 的开发能力？

相比传统 Benchmark 的单一测试设置，VISTA 更希望系统地刻画不同开发条件下 Agent 的能力边界。

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

现有不少网页生成基准主要依赖浏览器 Agent 或大语言模型判断生成结果，虽然扩展性较好，但在复杂 UI 场景中容易受到模型本身影响，难以稳定评估真实的软件质量。

VISTA 采用了一种更直接的思路：DOM-Grounded Evaluation。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，VISTA 更希望成为一个长期演进的基准（Living Benchmark）。

未来，团队将持续引入最新模型、最新 Harness 和新的应用场景，不断更新在线 Leaderboard，与社区共同记录 Coding Agent 的能力演进。

从产品需求理解到视觉设计解析，从网页生成到交互验证，再到开发流程分析——VISTA 将“看图写网页”拆解为视觉理解、页面定位、交互行为和Agent Workflow 等多个维度，希望为 AI 驱动的软件工程研究提供一个更加真实、开放且可复现的评测平台。

随着 Coding Agent 从“写代码”逐渐迈向“开发产品”，软件工程基准也需要从代码评测（Code-Centric Evaluation）走向产品评测（Product-Centric Evaluation）。

一个值得追问的问题是：未来评测一个 Coding Agent，不应只问“它会不会写代码”，更应该问它能不能真正交付一个产品。VISTA 希望成为回答这一问题的一个起点。

关于团队

本项工作由 University of Arizona、Zoom 与 Stony Brook University 合作完成。团队长期从事 AI Agent、大语言模型、多智能体系统等方向研究，近期重点关注 AI for Software Engineering、Coding Agent 的评测、优化与应用，致力于推动更加开放、可复现的软件工程基准建设。

作者介绍

第一作者：

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 系统研发。

Jiawei Zhou，Stony Brook University 助理教授，研究方向包括自然语言处理、机器学习、大语言模型、AI Agent、推理规划、多模态及 AI 评测。

Jingdi Chen，University of Arizona Electrical and Computer Engineering 助理教授，ANNIE Research Group 负责人，研究方向包括 AI Agent、多智能体强化学习、软件工程、网络优化、网络安全、可解释 AI、大语言模型/视觉语言模型（LLM/VLM）及量子计算与人工智能交叉研究。

平台建设

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 的持续更新。

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