Vision2Web

评测对象是完整开发系统。

输入截图、需求和素材，输出可运行网站，再通过实际访问判断视觉与功能。Vision2Web 测量的是 模型 × Agent 框架 × 执行环境 的联合表现。

与其他 benchmark 的定位差异

以下重建论文 Table 1。这里的「多模态」指任务是否提供视觉输入；计数不能直接当作难度排序。

三层递进，三种失败来源。

论文 §2.1 将任务按交付范围分层，所有层级都配有图像、图标、视频、字体等素材资源。它不是将同一个网站固定地升级三次，也不是训练课程表；三个任务集合的规模和输入分布不同。[1, §2.1–2.3]

每层实际输入的规模

原论文 Table 2，保留 ± 的原始表达；表注未进一步明确其统计定义，不擅自将其标成置信区间。文本 token 单位为千；“—”表示该表未提供该项，并非代理执行时完全不接收任何指令。

规模上的变化：L3 平均 28.2 个测试用例，对比 L2 的 7.5 约为 3.76 倍；需求文本由约 1.0k 增至 4.3k。更困难的不只是看更多图片，而是让多个功能在共享状态下同时成立。以上倍数为根据 Table 2 的四舍五入均值复算。

查看原论文跨设备、多页与全栈实例（Figures 7–9）

Figure 7 展示同页三设备形态；Figure 8 的主页、服务页、联系我们页面说明跨页复刻范围；Figure 9 展示主页、对话与登录视图。原型图仅表达目标状态，不能单独替代交互需求文档。

形式化理解：生成一个可执行系统

Our Interpretation · 教学记号 \(\mathcal{P}\) 是原型集合，\(D\) 是需求，\(\mathcal{R}\) 是素材；\(\mathcal{A}_{\theta}\) 表示模型驱动的开发 Agent，\(\mathcal{E}\) 是工具/运行环境，\(B\) 为执行预算；\(C\) 是生成代码与部署产物，\(W\) 是可访问的网站。这是本页为解释流程引入的记号，不是论文提出的训练目标或概率模型。

执行环境承担编译、启动与浏览器渲染。论文不要求某一种 latent、tokenization 或代码生成解码器，也没有统一 beam search / top-p 的方法创新；这些因素若影响复现，必须作为具体模型与框架设置记录。

从网站池到可判定任务。

1. 结构筛选：排除太简单或失效的页面

   使用 HTML 标签分布、DOM 深度和 token 长度检查页面；排除结构畸形、布局过于简单、语义不足的样本。63,515 是该阶段留下的候选网站数量，论文没有在这里给出完整初始池大小。

2. 内容筛选：优先具有实际设计与功能内容的页面

   VLM 评估功能丰富度、模块清晰度与视觉一致性，保留 7,391 页；排除交互贫乏、组织混乱、功能覆盖低的候选。从 63,515 到 7,391 的保留率约 11.64%，是本页复算，而不是论文单列指标。

3. 人工复核：把网页转成规格明确的开发题

   审核跨设备一致性、实现难度、页面尺寸、交互的清晰度与丰富性，并控制类别覆盖。网站来源与最终开发任务不是无需人工处理的直接一一转换；不能把 193/7,391 当成一个严格自动筛选器的性能。

四大域、16 子类：测什么业务能力？

分类体系来自前端工程师访谈与计算机专业博士生整理。以下按 Table 7–8 合并，原论文中的知名网站名是类别示例，不能据此推断这些品牌都是最终测试样本。搜索可查看具体子类。

Table 8 复算总计：Content 40/30/10；Transaction 28/18/8；SaaS 17/11/5；Public Services 15/7/4；三个层级合计 100/66/27。覆盖广不代表均匀抽样；L3 部分 SaaS 子类仅 1 个任务。

难度不仅由任务数决定

论文 Figure 6 用静态网页 DOM 统计对比 Design2Code-Hard：平均标签数 1,385±985 对 251±232；平均 DOM 深度 22±7 对 10±4；不同标签类型数 40±14 对 22±5。结构规模明显更高，但 DOM 复杂度是难度代理变量，不是对 Agent 推理难度的直接测量。

Figure 5 表明三种设备截图的高度分布不同。长页面同时增加视觉输入负担、遗漏风险和素材匹配需求。Figure 4 则分析高度与视觉表现的关系，见实验章节。

任务材料与评测材料必须分开

datasets/
  webpage/  → 100 个任务
  frontend/ → 66 个任务
  website/  → 27 个任务
每个任务的材料（按层级适用）：
  prototypes/   原型图片及设备形态
  resources/    图像、图标、字体、视频等
  prompt.txt    L2 需求文字
  prd.md        L3 产品需求
  workflow.json 评测用工作流

官方数据仓库包含这些材料。workflow.json 的存在不代表应把隐藏评分规则提供给生成 Agent；复现实验应检查推理阶段输入如何构造，并记录是否发生测试规格泄漏。全量共有 21,516 个输入文件，918 是原型图数量，不是所有图片素材的数量。本文无专用训练集训练过程，193 项是评测任务，不应自行编造 train/val/test 比例。[3]

用例标注：专家负责真值，Agent 帮助展开

Our Interpretation质量控制的关键是测试规格是否唯一且必要，不是标注文本是否足够长。原文没有完整量化标注工时、不同审核员一致率或需求覆盖率，因此无法仅凭“专家参与”推出标注已无遗漏。

八类功能检查，覆盖的是哪些缺陷？

Figure 3 是全栈任务的用例类型分布。上表“典型观察”为类别解释，不宣称每个例子都逐项出现在数据集中；真实测试以 workflow.json 为准。

把测试组织成有状态的工作流。

一个“点击提交”的结果，取决于之前是否登录、字段是否填写、页面是否到达。论文把这些依赖显式组织起来，而不是独立询问模型“这个网站好不好”。

论文将整体测试视为有向依赖图：节点是可独立描述的验证子过程，边表示顺序依赖和共享状态。\(G,N,E\) 是本页的辅助记号；\(\mathcal{W}\) 是具体可执行工作流。多条工作流共同覆盖图中节点。[1, §3 & Algorithm 1]

Our Interpretation“拆分”并不自动保证每条 workflow 有可独立重置的数据库快照。复现时仍需检查各流的前置条件、账号、清理规则和重跑副作用；有依赖的实际应用状态不会因为测试命名不同就消失。

功能节点：目标、动作与断言缺一不可

• \(O_i\)：测试目的，例如检查空内容不能提交；不是操作脚本本身。
• \(A_i\)：受约束动作，例如点击 Submit；限制 Agent 随意探索或补做步骤。
• \(V_i\)：验证条件，例如不应跳转并出现必填错误；决定 Pass/Fail。
• \(\mathcal{H}_{\lt i}\)：之前节点的目标和动作历史，帮助理解当前页面为何处于该状态。
• \(\mathcal{C}_i\)：验证器看到的上下文；历史提供连续性，同时也可能传播错误理解。

论文的功能验证器以 WebVoyager 任务执行协议为基础，用 GLM-4.6V 处理当前观察、思考并选择 GUI 动作。原文简化 prompt 的动作空间包含 Click、Type、Scroll、Wait、GoBack、Refresh、Key、Answer；输入包括整页与当前 viewport 截图，输出为 Thought 与 Action。这是测试 Agent 的循环，不是网站生成 Agent 的训练过程。

视觉节点：在正确状态下截图，再比较

\(P_i\) 是目标原型，\(S_i\) 是浏览器/应用状态，\(s_i\) 是评分（本页改用小写以避免与验证条件 \(V_i\) 混淆）。视觉节点可以处在登录、导航或填表之后；因此 VS 不一定只测网站首页。若导航失败，后续截图可能反映错误页面，这同时包含到达状态失败和视觉复刻失败的影响。

原论文工作流实例：发帖表单

下列内容来自附录 A.2.1（PDF pp.17–18），原文标为 Simplified Workflow Example。视口 1920×1080，整个流程在同一浏览器会话执行。可点击步骤查看验证目的。

关键细节：准备节点的 validations 为 None；当前分析代码只把有 validations 的功能节点纳入 FS 分母。一次功能节点可能含多个断言，评分单位仍是节点，而不是给每条断言分别加一分。视觉节点“Prototype: post”则触发截图比对，并不产生功能通过分。

看懂分母，才能看懂排名。

以下公式把 §3.2 的自然语言定义显式化，并与核查的 analyzer.py 对照。VS/FS 对外通常报告在 0–100 尺度。[1][4]

Functional Score：池化节点通过率

\(N_{\ell}\) 是某层全部计分功能节点数量。当前实现为有 validations 的用例初始化 0 分，成功结果文件中的 Pass 记为 1；Fail、Blocked 或缺失结果保持 0。先汇集所有节点，再求平均：用例较多的任务对该层 FS 的权重更高，并非每个网站先算通过率后等权平均。

Visual Score：组件平均，再原型平均

\(K_p\) 为评审对第 \(p\) 张原型划分的组件数，\(q_{p,k}\) 是组件分数；\(M_{\ell}\) 为该层原型总数。组件先等权平均，各原型再等权平均。这意味着多原型任务占更大权重，但组件较多的页面不会仅因组件多就在第二次平均中更重。

VLM 自动按有意义的功能区分块，输出 name、score、reason 的 JSON 列表。论文使用 Gemini-3-Pro-Preview。没有固定的人工区域掩码，也不是像素面积加权。分块粒度会改变分数：同一大片内容被切成 5 块与 1 块，和其余区域的相对权重可能不同。

层级分数与 Overall

前三个层级 Avg 与论文 Table 3 对齐；最后 Overall 来自当前官方分析实现，原文主表并未列出单一 Overall 列。它对三层等权，因此 L3 的 27 项与 L1 的 100 项对总分各占三分之一。

Deployment Success Rate 不是完成度

DSR 表示能否成功部署，Table 3 将其作为参考而非官方核心指标。以 OpenHands + GPT-5 为例，L3 DSR 为 100%，但 VS 18.3、FS 49.7、Avg 34.1：全部启动成功不等于所有功能正确。当前代码把失败部署对应的原型/功能结果保留为零，不能只筛出成功部署的样本后报告更好看的均值。

最难的是多模块同时正确。

论文主实验：8 个多模态模型，分别放入 Claude Code 与 OpenHands。比较的是端到端系统，不应把框架、模型、部署与环境影响全部归因于视觉理解。

完整主结果 · Table 3

以下保留全部 16 组结果与 DSR。表格可横向滚动；同一框架内各指标最佳值加粗、次佳值加下划线（DSR 不做名次标记）。“Avg”是相应层级综合分，不是网站完成百分比。

设备与长页面：哪里更容易失真？

OpenHands + Gemini-3-Pro-Preview 桌面 63.3、平板 55.8、手机 48.3；桌面到手机下降 15.0 分，约为桌面分数的 23.7%。这也说明论文“10–20%”概括需要分清相对百分比与百分点，并非所有条目都落入该范围。Opus-4.5 对应 58.9 → 47.7，下降 11.2 分。

Figure 4 是原型高度与 VS 的分布关系。它支持长/密集页面更困难的关联观察，但未隔离文本长度、模块数量、图像压缩、素材难度等混杂因素；“视觉输入太长导致失败”仍不是严格的因果消融。

不同业务域的差异 · Table 4

Opus-4.5 在公共服务 VS/FS 为 56.9/60.0，SaaS 为 22.9/39.9。作者将差异解释为后者有更多跨页与复杂交互。注意：SaaS 下 Sonnet-4.5 的 FS 42.8、GPT-5 的 FS 40.5 都略高于 Opus 的 39.9；“总体最好”不代表每个子项都最好。L3 子类样本小，类别差异不宜过度外推。

按功能类别定位短板 · Table 5

Opus 的导航路由 66.3，但状态管理 43.2、CRUD 43.6、文件媒体 33.3；GPT-5 的表单交互 56.8 高于 Opus 的 49.2。这些数据适合定位错误类别，不能把某类低分直接归结为单一内部能力缺陷。比如文件操作还会受浏览器工具和执行环境影响。

失败模式：从细节到整合

查看原论文失败案例（Figures 10–12）

这些是定性展示，不能从截图单独判断数据库持久化或 API 是否正确；相应系统性结论来自作者的综合错误分析。

评测器也需要被评测。

论文 v3 新增/展开了人类一致性与 backbone 敏感性验证。它们回答的是“评测结果有多可信”，不是“网页开发任务有多容易”。[1, §4.4]

这些数字能支持什么？

验证器 backbone 敏感性 · Table 6

三项模型的差异分别为 −2.0、+0.7、+2.1 分（GPT-5-Mini 相对 GLM-4.6V，本页复算）。总体均值接近可能掩盖子项差异。Table 6 使用 Sonnet-4.6、GPT-5.4、Gemini-3.1-Pro-Preview，不是 Table 3 的同一模型版本集合。

视觉敏感性分析复评 153 个项目的 567 张原型，用 Gemini-3.1-Pro-Preview、Doubao-Seed-2.0-Pro、GLM-4.6V 与 GPT-5.4 四个 Judge，得到一致排序：Sonnet-4.6 → GPT-5.4 → Kimi-K2.5 → Gemini-3.1-Pro-Preview。原文同时明确绝对分数标尺因 Judge 而变。

这不是完整组件消融

论文比较了模型、框架与验证器 backbone，但未提供充分的“无 workflow vs 有 workflow”“去掉 guided actions”“无历史”“去掉专家质检”“不同工作流拆分长度”的受控对照。因此评测器达到一定一致性的证据较明确，而结构化工作流究竟贡献了多少稳定性尚无法单独量化。

复现的单位是一整套协议。

本文不是需要重新训练的模型。要复现主表，需要固定数据、生成 Agent、模型版本、容器、推理预算、启动协议、验证器与聚合脚本。只使用同名模型不足以重现实验。

全栈任务的 prompt 实际要求

1. 规划与设计：确定数据库 schema、种子数据、前后端架构和目录。
2. 构造 seed data：根据原型生成内容，并覆盖加载、空、错误等 UI 状态。
3. 实现：后端 API、鉴权、校验、初始化；前端复刻视觉并消费真实 API。
4. 部署验证：端口 3000；生成 start.sh 并在干净环境验证。
5. 交付：完整代码、设计文档、种子数据、启动脚本、README；不得跳过需求或擅加功能。

原文 prompt 把截图称为“provided above, not from files”；任务定义又同时讨论工作目录中的输入材料。复现时应保留具体 adapter 的图像注入方式，而非仅把路径字符串交给一个不支持图像的模型。附录展示的是结构化简化模板，并非承诺所有原始请求参数已完整公开。

Structure of GUI Agent Verifier Prompt
You are aGUI Testing Agent.
Your primary task is toexecute software test cases on a Web applicationby interacting with the graphical user
interface and determining whether the test casepasses or failsbased on defined validation criteria.
The current time is{time}.
Context:
{context}
Test Case
Objective
{objective}
Actions
{actions}
Validations
{validations}
Test Platform
Web
Action Space
The agent operates in a predefined GUI action space (Click, Type, Scroll, Wait, GoBack, Refresh, Key, Answer),
following standard web interaction semantics.
History
You havealready performed the following actions(format: Thought, Action):
{history}
Output Format
Your reply should strictly follow the format:
• Thought: Your brief thoughts
• Action: One Action format you choose
Current Observation
Full-page screenshot:{fullpage screenshot}
Current viewport screenshot:{viewport screenshot}

Structure of VLM Judge Prompt
You are asenior QA automation engineer. Your task is tocompare a prototype image with an actual page
screenshotand score the appearance of the page.
Important:Carefully observeall differencesbetween the prototype and the actual page. Do not overlook any
discrepancies, however small. Score strictly according to the rules below.
Input
1.Prototype Image:{prototype page}
2.Actual Page Image:{actual page}
Note:You need to automatically segment the page into meaningful UI components based on visual and functional
layout.
Component Segmentation Rules
• Divide the page intological functional blocks, not too granular or too coarse.
• For each block, treat it as asingle componentfor scoring purposes.
Scoring Rules
Each component or block receives an independent score:
Score Description
1.0 Perfect Match:Component position exactly matches the prototype. Layout, spacing, alignment,
and sizing are identical. Text, fonts, colors, icons, and images are fully accurate. No visually
discernible differences.
0.75 Minor Imperfections:Mostly accurate positioning with very slight misalignment (<2 px). Layout
and spacing largely consistent. Only minor typos or formatting differences. Multimedia shows
slight scaling or color variation.
0.5 Partial Match:Roughly correct position but noticeable misalignment or spacing issues. Layout
partially consistent. Multiple text discrepancies. Multimedia partially incorrect or inconsistent.
0.25 Poor Match:Component recognizable but significantly misaligned. Layout mostly inconsistent.
Text differs significantly. Multimedia missing or incorrect.
0.0 No Match:Component missing or completely misplaced. Layout unrelated to prototype. Text and
multimedia absent or entirely incorrect.
Output Requirements
Outputonlya JSON object in the following structure:
[
{
"name": "<component name>",
"score": <0 | 0.25 | 0.5 | 0.75 | 1>,
"reason": "<brief explanation of why this score was given>"
}
]

Structure of Full-Stack Task Prompt
You are asenior full-stack engineer with expertise in web development.
Your task is toimplement and deploy a production-ready web applicationstrictly following the provided
materials in/workspace.
I. Input Materials
1. Product Requirement Document( /workspace/prd.md): Contains overview, business logic, and detailed
requirements.
2.Prototype Images(provided above, not from files): Define UI layout, style, interactions, and visual fidelity.
3.Resource Files(/workspace/resources/ **/*): Assets including images, videos, audio, icons, etc.
II. Mandatory Full-Stack Workflow
1.Planning & Design
• Define database schema and seed data.
• Specify front-end/back-end architecture and tech stack.
• Design project directory structure.
2.Seed Data Generation
• Generate complete realistic seed data reflecting prototypes.
• Populate all UI elements and states (loading, empty, error).
3.Full-Stack Implementation
•Back-End:APIs, validation, authentication, database initialization.
•Front-End:Replicate visuals, implement all interactions, consume live APIs.
•Integration:Ensure front-end and back-end work seamlessly.
4.Deployment & Verification
• Build application and verify accessibility athttp://localhost:3000.
• Generate/workspace/start.shfor fully reproducible deployment.
• Verify startup script in a clean environment.
5.Documentation
• Design document: architecture, data model, technology stack.
• README: overview, stack, directory, deployment instructions.
III. Required Deliverables
• Complete source code
• Design document
• Seed data
• Deployment script (start.sh)
• README
IV . Hard Constraints
• Implement all PRD features without skipping or inventing functionality.
• All visuals and interactions must match prototypes.
• System must be fully reproducible viabash /workspace/start.sh.
• Do not terminate the work process until all steps and startup verification are complete.

实际复现步骤：每一步保存什么证据

1. 锁定输入

   固定 dataset revision、全部任务清单、资源哈希与 workflow；记录被过滤/缺失任务，不悄悄从分母剔除。

2. 生成项目

   给定规定的图像与文本输入，保存模型/框架版本、提示、预算、完整工具日志与最终源代码；禁止把评测用例作为额外 oracle。

3. 独立启动

   清洁环境执行 start.sh，记录是否成功、时间、端口与错误；保留每次修复历史，明确三轮如何使用。

4. 执行 workflow

   固定分辨率与会话策略；逐节点保存动作、观察、Pass/Fail/Blocked 与截图；记录哪些失败源于前置条件。

5. 视觉评分与聚合

   保存每张实际截图、原型、Judge prompt、组件 JSON；按原型和功能节点池化，并报告 DSR、VS、FS、层级 Avg。

6. 质量校准

   抽样人工重评并保留节点混淆矩阵；重复运行测方差；改变 Judge 时重评同一输出，避免生成能力与评分变化混在一起。

上面是根据论文与实现整理的复现实务建议，不表示本页已经执行 193 个任务或独立复现了论文分数。

最新代码与论文设置已经分叉。

核查时间 2026-09-18；官方 commit SHA：577f9397b3db8fc6d828adde254a830caa65d515。本页只做代码阅读，没有运行完整 benchmark。以下区别均绑定此快照。

功能执行器 ↗ · 当前评测提示 ↗ · 默认配置 ↗ · 聚合逻辑 ↗

许可也存在表述差异：官方项目主页写 CC BY-SA 4.0，HF 数据卡写 CC-BY-NC-SA-4.0，arXiv 论文为 CC BY 4.0。论文插图在本页附来源；若复用完整数据集，应按对应 artifact 的实际许可核实，不能只看主页一句话。

贡献成立，边界也要明确。

真正可检验的改进方向

对 Procedural Material Generation 的启发

Research Extension · 未由本文验证可以借鉴其“外观 + 执行 + 状态”的分层思路：L1 测参考纹理的渲染复刻；L2 测可编辑节点图及参数变化的一致性；L3 测真实 SBS 编译、多通道输出、资源可携带性与独立重建。将“图能打开”“可编译”“渲染像参考”“参数编辑仍成立”分开评分，避免漂亮预览掩盖执行失败。

工作流可设计为：导入图 → 检查节点/依赖 → 实际 cook → 多通道渲染 → 修改参数 → 再渲染 → 验证预期变化。GUI/VLM 可帮助观察，但结构合法性、依赖完整性、像素指标与编译日志应尽可能使用确定性检查。此处是本页的研究设想，不是 Vision2Web 已开展的材质实验。

来源与阅读记录。

1. He et al. Vision2Web，arXiv v3 · 23 页 PDF · HTML。主来源：§2 benchmark，§3 workflow，§4 实验与校准；Appendix A.1–A.4。CC BY 4.0，原图与表格均标注；本页增加中文解释、排版、交互与批判分析。
2. 官方 GitHub 快照：核查 README、config、inference prompts、functional_tester、visual_scorer、evaluation prompts/engine、analyzer。commit SHA 577f9397b3db8fc6d828adde254a830caa65d515。
3. 官方数据集卡：文件组织、193 个任务与许可说明。本次未下载/执行整个数据集。
4. 官方 analyzer.py：零分初始化、功能节点分母、两级视觉平均与层级 Overall。
5. 官方主页与季度榜单：用于核对发布流程；本页不将实时榜单结果混作论文 Table 3。

阅读基准：2026-09-18。论文身份、主结果、附录实例与官方实现分别核查；本页没有运行论文 benchmark，也没有独立复现作者的人工一致性实验。原图、样式、脚本与 MathJax 3 均嵌入单文件，正文与公式可离线阅读；外部来源链接需要联网。