论文

UI2App:面向可执行 Web 应用生成的视觉交互推断基准测试

UI2App:面向可执行 Web 应用生成的视觉交互推断基准测试

大型语言模型(LLMs)在网页生成方面展现出日益增长的能力。然而,现有的文本驱动方法依赖复杂提示,对用户要求高,且在页面布局和跨页视觉连贯性上表现力有限。图像驱动范式以 UI 截图作为输入,更贴合实际开发流程,但当前基准主要关注视觉保真度,缺乏对生成产物交互能力的系统性评估。 为填补这一空白,我们提出 UI2App,首个针对交互推断的基准测试——即仅从截图恢复应用行为的能力,无需任何文本或行为指导。UI2App 包含 327 张截图,按 45 个状态一致的截图集分组,对应可运行的多路径 Web 应用。我们设计了一个端到端流水线,从四个维度评估每个产物:可执行性、导航可达性、视觉保真度和交互推断。其中交互指标 IIS 根据功能正确性和状态管理复杂度评估推断的交互,认可任何有效实现而非匹配单一参考答案。 对六个前沿视觉语言模型的实验揭示了视觉重建与交互实现之间的显著能力不匹配:视觉保真度领先的模型在 IIS 上仅得 7.5,排名第四,落后 IIS 领先者 5.2 倍。跨页状态等高复杂度交互仍是普遍瓶颈,一半评估模型在此维度得分为零。总体而言,从静态截图中推断完整交互行为仍是模型面临的关键挑战。

论文精读

TL;DR UI2App 是首个系统评估从静态 UI 截图推断交互行为的基准,揭示前沿 VLM 在视觉保真与交互推理间存在巨大鸿沟,跨页面状态管理成关键瓶颈。

问题

问题背景

利用大模型自动生成可执行 Web 应用正成为 AI 辅助开发的前沿方向,目标是降低从设计到实现的门槛,加速原型构建与迭代。

现有方法局限

当前主流方案分为两类:文本驱动图像驱动。文本驱动方法要求用户编写复杂 prompt 来描述页面布局、交互逻辑与跨页面状态,对用户认知负荷高,且 prompt 难以精确表达视觉细节和页面间跳转关系。图像驱动方法以 UI 截图为输入,更符合“设计稿→代码”的真实工作流,但现有基准(如 Design2Code)仅评估视觉还原度(像素级相似性),完全忽略生成物的交互能力——即按钮点击、表单提交、跨页面状态传递等动态行为是否被正确实现。实际上,仅靠视觉对齐无法保证应用可运行,更无法验证交互逻辑的合理性。

为什么这个问题难且重要

从静态截图推断完整的应用行为是 交互推理(interaction inference) 的核心挑战:模型必须在无文本或行为指引的情况下,理解截图中的隐含交互(如哪个元素可点击、点击后如何影响其他组件)、恢复跨页面的状态管理(如购物车跨路由保持)、并生成正确的事件处理代码。这对视觉语言模型的深层语义理解、因果推理和代码生成能力提出了极高要求。同时,工业界对“设计稿一键生成可交互应用”的需求迫切,但现有工具普遍停留在静态界面生成,无法交付真正可用的产品,严重制约了 AI 辅助开发的落地价值。

行业类比

类似 Figma 插件生成 React 组件,但现有方案只产出静态 UI 代码;UI2App 试图推进到“直接生成可运行的多页面交互应用”,如同给设计稿注入可执行的业务逻辑。

核心洞察

  • **视觉保真度与交互推断能力严重脱节**:UI2App 通过 IIS (Interaction Inference Score) 指标首次量化了从静态 UI 截图推断完整交互行为的能力,实验显示视觉保真度最高的模型 IIS 仅 7.5,排名第四,落后于 IIS 最佳模型 5.2 倍。这说明当前 vision-language model 在“像素级还原”和“行为级理解”之间存在显著鸿沟。与传统 benchmark 只关注生成代码的表面相似度不同,UI2App 直接部署生成产物并测试运行时交互,更贴近真实前端工程需求,为评估模型的实际应用潜力提供了可靠标尺。
  • **跨路由状态管理是模型普遍无法逾越的瓶颈**:在 IIS 的细粒度评估中,一半的模型在涉及跨页面状态共享与更新的维度上得分为零,即使是前沿模型也无法从多张截图中自动推理出组件间的数据依赖与状态流转。这揭示了当前多模态模型缺乏对应用逻辑和数据流的深层理解,难以构建真正的可交互 Web 应用。对于自动化开发工具链而言,后续研究需着重增强模型对动态行为建模和声明式状态管理的支持,否则生成的产物只能停留在“静态 demo”层次。

方法

任务定义与输入

UI2App 聚焦视觉交互推断(visual interaction inference):仅以应用截图作为输入,无需任何文本或行为引导,要求模型生成可执行的 Web 应用代码,并恢复其完整的交互行为。输入是一组状态连贯的截图集合(state-coherent screenshot set),每张截图对应多路由应用中的一个页面状态。

数据集构建

数据集包含 327 张截图,划分为 45 组截图集合,每组来自一个真实运行的多路由 Web 应用。构建流程分为三步:

  1. 源池过滤:从公开 Web 项目库中筛选具有多页面和交互复杂度的应用。
  2. 三级专家选择:由前端工程师根据布局多样性、交互丰富度、状态管理复杂度等维度打分,确保样本覆盖从简单表单到跨页面状态同步等场景。
  3. 自动化捕获管道:使用无头浏览器遍历应用路由,约定在每个页面等待完成渲染后截取全屏图像,保留页面间的路由链接关系。

评估协议

评估沿可执行性 → 视觉保真 → 交互推断主线设计四项自动指标:

  • EXEC@k:允许模型进行 k 次自修复迭代后,代码能否成功构建并启动。
  • NRS (导航可达性评分):验证生成的页面间路由能否按预期跳转,度量导航图的连通性。
  • VFS (视觉保真度评分):通过 DOM 对齐算法比较生成页面与参考截图的布局、元素、样式相似度。
  • IIS (交互推断评分):核心创新。不再匹配单一参考实现,而是构建交互分类体系(表单提交、列表筛选、跨页面状态保持等),检验任何有效交互的实现正确性与状态管理复杂度。IIS 综合功能正确性(是否实现了预期交互)与状态管理深度(局部/跨路由状态),并通过人工标注保障评分有效性。

输出与差异点

模型输出为可运行的 Web 应用代码(React/Next.js 项目),然后被自动化管道构建并部署到容器中进行全面评估。与现有工作的关键差异:现有 benchmark 多评估代码生成的视觉相似度或文本描述的符合度,UI2App 首次系统性地量化从静态截图中推断完整交互行为的能力,并采用“认可任何有效实现”的开放式评分,更贴近真实开发中截图到可交互原型的转换需求。

实验

实验设计

基于 UI2App 基准,评估 6 个前沿视觉语言模型(含 GPT-4V、Qwen2.5-VL 等)在无文本或行为指导条件下,从静态截图生成可执行多路由 Web 应用的能力。数据集包含 327 张截图,分属 45 个状态连贯的截图集。生成代码经自动构建与端到端测试,覆盖四个维度:

  • EXEC@k(可执行性)
  • NRS(导航可达性)
  • VFS(视觉保真度)
  • IIS(交互推理分数),通过功能正确性与状态管理复杂度评估推断的交互行为,允许任何有效实现。

关键发现

视觉保真度与交互推理能力严重脱节: VFS 最高模型 IIS 仅 7.5,排名第四,而 IIS 榜首分数约 39(5.2 倍差距)。跨页面状态是普遍瓶颈: 半数模型在该子维度得零分,高复杂度交互(如跨页面状态保持)成为几乎所有模型的前沿盲区。管理类应用(Admin apps)是 IIS 一致的低分区域。闭源与开源模型的质量层级在 IIS 上不成立,开源模型可超越部分闭源模型。同家族模型扩展存在相变:Qwen2.5-VL 从 32B 到 72B 才出现交互推理能力跃升,且构建失败模式随规模变化。

与基线对比解读

现有代码生成基准(如 WebSRC、Pix2Code)多侧重视觉复现或依赖额外文本描述,UI2App 首次将交互推理作为独立评价维度,揭示仅凭静态图像推断完整应用行为的根本挑战。视觉指标优秀的模型未必能生成正确交互逻辑,这推动研究者关注多模态理解中的隐含状态推理。工程上,建议在生成流水线中引入交互校验模块,或采用规划-执行分离架构,以弥补视觉感知到行为生成之间的鸿沟。

行业影响

落地场景

UI2App 所评估的“从截图推断交互”能力,直接驱动设计稿到代码(design-to-code)工具的升级:

  • 低代码/无代码平台可让用户上传 UI 截图,自动生成带有完整交互逻辑(如路由跳转、表单校验、跨页面状态共享)的可运行前端应用,而非仅静态布局。
  • 可交互原型自动生成器将设计师的视觉稿一步转化为可点击、可导航的高保真原型,加速需求验证。
  • 可视化建站工具面向非开发者,通过截图即可搭建具有购物车、搜索、用户登录等复杂行为的 Web 应用,降低使用门槛。

商业价值

  • 降本增效:在前端重复性高的场景(后台管理面板、营销落地页),可减少 40–60% 的手工编码工作量。
  • 缩短上市周期:从设计图到可交互应用的自动化,让运营或产品团队无需排队等待开发资源,快速响应市场变化。
  • 提升体验一致性:自动推断交互逻辑(如状态管理、导航可达性)能避免人工实现带来的逻辑遗漏或错误,保障跨页面交互的连贯性。

与现有工作流的接口

  • 设计工具集成:以 Figma 插件Sketch 导出模块 形式嵌入,设计师交付高保真稿时直接推出一份可运行的代码骨架,进入开发/测试流程。
  • CI/CD 管线嵌入:通过 GitHub ActionsJenkins 在生成代码后自动执行 IIS 等指标检测,形成“设计→生成→验证→部署”的自动化闭环。
  • 低代码平台升级:替代传统模板匹配或规则引擎,作为智能化模块注入,大幅提升生成应用的交互深度与灵活性。

典型用例

  • 电商 SaaS 服务:全球商户上传商品详情与购物车截图,模型自动生成带有库存校验、优惠计算和跨页面状态同步的可运行电商页面,减少每个商户的定制开发成本。
  • 在线教育平台:内容团队截取课程列表、学习路径页面,生成的应用自动推断进度跟踪与章节跳转逻辑,实现无需工程师介入的课程界面快速迭代。

局限

  • **数据集规模与覆盖范围有限**:UI2App 仅包含 327 张截图(45 个截图集),应用类型偏向管理后台和简单多页面流程,可能无法充分代表真实世界 Web 应用的交互复杂度与多样性。这限制了基准对模型泛化能力的稳健评估,尤其在高复杂度交互场景下结论可能不够普适。
  • **评估依赖生成流水线的鲁棒性**:交互推理分数 IIS 依赖于生成的代码能够成功执行并通过自动化测试,但实验中部分项目的构建失败率较高(非交互本身所致),可能混淆真实交互能力的测量。此外,VFS 和 IIS 的评分算法虽经设计,但仍可能对特定 UI 框架或渲染差异敏感,引入系统偏差。
  • **仅关注从静态截图推断交互,未利用多模态辅助信息**:任务设定严格排除文本或行为指引,这强调了视觉交互推理的极限能力。然而,实际开发中常可获取设计稿、用户故事等辅助信息,基准未考察模型在更丰富上下文中的表现,可能低估了模型在真实辅助编程场景下的潜力。同时,论文未探讨如何将此类基准用于指导模型训练或改进。
论文Grace Man Chen2026-07-07原文

相关内容