Each language version is independently generated for its own context, not a direct translation.
这篇论文介绍了一个名为 Vision2Web 的新工具，你可以把它想象成**“给 AI 程序员出的一套终极网页设计考试”**。
为了让你更容易理解，我们可以把开发一个网站比作**“盖房子”**。
1. 为什么要搞这个考试？（背景）
现在的 AI（大语言模型）很聪明，能写代码，就像请了个**“天才建筑学徒”**。
- 以前的考试（旧基准）： 就像只考学徒“能不能砌好一面墙”或者“能不能修好一扇坏掉的窗户”。这只能看出他修修补补的能力，看不出他能不能从头到尾盖好一栋完整的别墅。
- 现在的痛点： 没人知道这个学徒能不能真的盖出一栋既好看（视觉还原）、又好用（功能正常）、还能住人（全栈运行）的房子。
2. Vision2Web 是什么？（核心概念）
Vision2Web 就是一个分等级的“盖房子”大考，专门测试 AI 能不能根据设计师的图纸（图片），把房子盖出来。
它把考试分成了三个难度等级，就像游戏闯关一样：
- 第一关：静态网页（画图纸）
- 任务： 给你一张房子的外观效果图（比如电脑、平板、手机三种视角的图）。
- 要求： AI 要画出和图一模一样的“毛坯房”（静态代码）。
- 比喻： 就像让学徒照着照片画素描，要求线条、比例、颜色分毫不差。
- 第二关：交互式前端（装修并通电）
- 任务： 给你多张图，还要告诉你房间之间的逻辑（比如“点击门把手，门会开”）。
- 要求： AI 要盖出一个能动的房子，点击按钮要有反应，页面之间能跳转。
- 比喻： 不仅要画得像，还要把灯装好，门能推开，楼梯能走上去。
- 第三关：全栈网站（盖摩天大楼）
- 任务： 给你详细的施工说明书和图纸。
- 要求： AI 要盖出一栋完整的摩天大楼，包括地基、水电、保安系统（数据库）、前台接待（后端）和装修（前端）。
- 比喻： 这是最难的一关，要求从打地基到入住，所有环节都要跑通，不能塌房。
3. 怎么给 AI 打分？（独特的“双考官”制度）
以前的考试，要么靠人眼死盯着看（太慢），要么靠死板的代码测试（太死板）。Vision2Web 发明了一套**“双考官”自动评分系统**：
- 考官 A（GUI 智能体）：负责查“功能”
- 角色： 一个**“挑剔的试住员”**。
- 工作： 它会自动操作网站，像真人一样点击、输入、跳转。
- 比喻： 它会在房子里走一圈，看看门能不能开、灯能不能亮、水龙头有没有水。如果它点“登录”没反应，就扣分。
- 考官 B（VLM 视觉法官）：负责查“颜值”
- 角色： 一个**“强迫症设计师”**。
- 工作： 它拿着 AI 盖好的房子和原始图纸做对比。
- 比喻： 它会拿着放大镜看：“哎，这个窗户歪了 2 度”、“那个按钮颜色太深了”。它专门挑刺，确保房子和图纸长得一模一样。
4. 考试结果怎么样？（发现的大问题）
作者让目前最厉害的 8 个 AI 模型参加了这场考试，结果发现：
- 越难越拉胯： AI 在“画图纸”（第一关）时表现还不错，但一旦到了“盖摩天大楼”（第三关），大部分 AI 就彻底崩溃了。
- 小屏幕更难受： 让 AI 适应手机或平板的布局，比适应电脑屏幕要难很多，就像让学徒在狭小的空间里盖房子，容易出错。
- 最强选手也有短板： 即使是目前最强的 AI（如 Claude Opus），在盖复杂大楼时，也会经常把“水电”搞错，或者把“房间”连错。
- 框架很重要： 同样的 AI 大脑，放在不同的“工具箱”（开发框架）里，表现也不一样。就像给同一个厨师换不同的锅，炒出来的菜味道不同。
5. 这篇论文的意义是什么？
这就好比给 AI 行业立了一个新的“行业标准”。
- 以前我们不知道 AI 到底能不能干大活。
- 现在有了 Vision2Web，我们就能精准地知道：AI 哪里强（画图画得好），哪里弱（盖楼容易塌）。
- 这告诉未来的研究者：别光盯着让 AI 写几行代码了，得想办法让 AI 学会统筹规划，学会盖整栋楼，而不仅仅是砌砖。
总结一下：
这篇论文就是给 AI 程序员发了一张**“建筑师资格证”的考试大纲。它告诉我们，现在的 AI 虽然能当个不错的“绘图员”或“装修工”，但离成为一个能独立“盖摩天大楼”的总建筑师**，还有很长的路要走。
Each language version is independently generated for its own context, not a direct translation.
Vision2Web 技术总结
1. 研究背景与问题 (Problem)
尽管大语言模型（LLM）显著提升了自主软件代理（Coding Agents）的编码能力，但在端到端复杂视觉网站开发领域的系统性评估仍存在严重不足。现有的评估基准主要存在以下局限：
- 任务形式单一：如 SWE-Bench 等基准主要关注增量式的代码修复，缺乏对从设计到部署的全生命周期软件工程的评估。
- 多模态覆盖错位：现有的多模态基准（如 Design2Code）多局限于静态单页 UI 生成，缺乏对交互式多页面及全栈开发的评估；而端到端开发基准（如 WebGen Bench）往往缺乏视觉输入。
- 验证机制不足：由于任务定义模糊和验证过程约束不足，难以可靠、可复现地评估复杂的交互逻辑和长程系统结果。
核心问题：如何构建一个能够系统评估多模态编码代理在视觉网站开发中，从静态 UI 到全栈系统构建能力的基准，并建立可靠的自动化验证机制？
2. 方法论 (Methodology)
2.1 分层基准设计 (Hierarchical Benchmark Design)
Vision2Web 提出了一个包含三个递进层级的任务框架，旨在解耦并评估不同阶段的代理能力：
- Level 1: 静态网页 (Static Webpage)：评估模型将 UI 原型图（桌面、平板、移动端）转换为响应式静态代码的能力，侧重于视觉保真度。
- Level 2: 交互式前端 (Interactive Frontend)：评估多页面逻辑、导航流及组件组织的能力，要求生成具有连贯交互的多页面前端。
- Level 3: 全栈网站 (Full-Stack Website)：模拟真实工程场景，结合需求文档和原型图，要求代理管理复杂应用状态、进行集成调试并交付全栈系统。
2.2 数据集构建 (Dataset Construction)
- 来源：数据严格筛选自 C4 验证集，避免从流行网站泄露。
- 流程：采用三阶段过滤管道（结构评估 -> 内容筛选 -> 人工审核），最终构建包含 193 个任务（涵盖 16 个子类别）、918 张原型图和 1,255 个测试用例的高质量数据集。
- 多样性：覆盖四大类网站（内容、交易、SaaS 平台、公共服务），确保真实世界的多样性。
2.3 基于工作流的代理验证范式 (Workflow-Based Agent Verification)
为了解决端到端评估的不可复现性问题，Vision2Web 提出了一种结合 GUI 代理验证器 和 VLM 裁判 的混合验证机制：
- 工作流抽象：将测试过程建模为有向依赖图，将测试节点解耦为独立的功能验证和视觉验证子程序。
- 功能验证 (Functional Verification)：使用 GUI Agent Verifier（基于 WebVoyager 协议）。代理根据专家设计的引导动作（Guided Actions）执行测试流程，验证逻辑断言和状态检查，计算功能得分 (FS)。
- 视觉验证 (Visual Verification)：使用 VLM Judge（基于 Gemini-3-Pro-Preview）。在渲染页面到达特定节点时，VLM 将渲染结果与参考原型进行组件级对比，计算视觉得分 (VS)。
- 优势：这种设计既保留了代理交互的灵活性，又通过结构化工作流约束了执行路径，实现了客观、可复现的评估。
3. 主要贡献 (Key Contributions)
- 分层任务设计：首个系统解耦视觉网站开发各阶段（静态、交互、全栈）能力的基准，支持细粒度的能力归因。
- 真实多模态数据：基于真实世界网站构建的大规模基准，包含明确的多模态约束（原型图 + 需求文档 + 多媒体资源）。
- 可复现的验证范式：提出了一种与具体实现无关的评估范式，结合结构化工作流与代理执行，同时量化功能正确性和视觉保真度。
4. 实验结果 (Results)
研究评估了 8 种最先进的多模态模型（包括 Claude-Opus-4.5, GPT-5, Gemini-3-Pro, Qwen3-VL 等）在 OpenHands 和 Claude Code 两个框架下的表现：
- 性能随复杂度下降：所有代理在从静态网页向全栈网站过渡时，性能显著下降。即使是表现最好的模型，在全栈任务上的视觉得分（VS）和功能得分（FS）也大幅降低（例如 Gemini-3-Pro-Preview 在全栈任务上 VS 仅为 11.7）。
- 设备与视觉复杂度影响：模型在桌面端表现最佳，平板和移动端性能下降 10-20%；原型图越复杂、密度越大，性能越差。
- 模型差异：
- Claude-Opus-4.5 在所有层级和框架中均表现最佳，但在复杂全栈任务上仍有明显短板。
- GPT-5 在静态页面表现尚可，但在长程规划和多页集成上较弱。
- Qwen3-VL 和 Seed-1.8-VL 在复杂多模态编码任务上几乎无法完成（全栈任务得分为 0）。
- 框架影响：除 Claude 模型外，大多数模型在 OpenHands 框架下的表现优于 Claude Code 框架。
- 类别差异：公共服务类网站（结构简单）表现最好，SaaS 平台（多页导航、复杂交互）表现最差。
- 失败模式分析：
- 细粒度视觉对齐失败：布局错位、尺寸错误、资源处理不当。
- 跨模块理解失败：多页面间视觉一致性差，导航链接断裂。
- 系统级规划失败：缺乏自主验证机制，长程任务中功能实现偏离需求，导致系统崩溃或无法启动。
5. 意义与影响 (Significance)
- 揭示能力鸿沟：Vision2Web 证明了当前最先进的编码代理在处理结构化复杂性、跨页协调和持久状态推理方面存在系统性缺陷，孤立任务的高性能无法保证端到端系统构建的成功。
- 推动评估范式转变：该基准强调了从单一功能测试向分层、渐进式挑战任务设计的转变，以及采用原则性、可复现的自主评估范式的重要性。
- 未来研究方向：为提升代理的跨模态推理、长程任务规划及多组件协调能力提供了明确的评估标准和改进方向。
总结：Vision2Web 填补了视觉网站开发领域系统性评估的空白，通过分层任务设计和创新的混合验证机制，揭示了当前 AI 代理在构建复杂全栈应用时的真实能力边界，为未来更强大的软件智能体研发奠定了坚实基础。