这项由香港科技大学广州与香港科技大学联合开展的研究以预印本形式于2026年7月7日发布在arXiv平台论文编号为arXiv:2507.06306v1归属计算机软件工程cs.SE领域。感兴趣的读者可通过该编号在arXiv上查阅完整论文。**一、从看图说话到看图造App差距究竟有多大**假设你拍了一张某款手机App的截图然后交给一位素未谋面的程序员要求他仅凭这张截图——没有任何说明文字没有交互演示没有原始代码——从零复原出一个能实际运行的App。这位程序员不仅要把界面画得像还要让按钮真的能点、让购物车真的能装东西、让搜索框真的能筛选内容。这件事有多难近年来大型语言模型LLM在写代码这件事上进步神速甚至有人拿着一段文字描述就能让AI生成一个可用的网站。但文字描述有个天然局限要精确表达这个按钮是圆角的、颜色是深蓝色、点击后弹出一个侧边栏之类的视觉细节费时费力还容易出偏差。更麻烦的是跨页面的交互逻辑——比如把商品加入购物车后在另一个页面还能看到它——用自然语言描述起来极易前后矛盾。于是以截图为输入、直接生成可运行应用的想法应运而生。这个方向已有一些研究但它们大多只关心生成出来的页面**长得像不像**却没人深究这个页面**能不能用**按钮按下去会不会真的发生正确的事情香港科大的研究团队正是为了填补这个空白推出了**UI2App**——据他们所知这是第一个专门衡量从截图推断交互行为能力的基准测试。他们把它比作一场严格的考试让六个目前最顶尖的视觉-语言大模型VLM同台竞技结果颇为令人意外。**二、这场考试的题目长什么样**UI2App包含327张截图被整理成45组配套截图集每组截图对应同一个多页面Web应用的不同路由即不同页面。研究团队从2013个开源GitHub项目出发经过四道自动化筛选——许可证合规、目录结构合理、能在180秒内完成构建、没有强制登录墙——过滤掉绝大多数候选剩下164个再由专家人工审核最终保留45个。这45个应用覆盖了相当多元的类型。按功能划分为四大类内容类博客、作品集、文档、SaaS落地页、管理类各种后台管理系统、交易类电商、加密货币交易所、NFT市场、预订系统和特色类分析仪表盘、音乐播放器、待办事项、学习应用。每组截图平均有7.3张最少4张最多14张用无头浏览器在1440×900的分辨率下统一截取并经过去重和专家审查。每道题的规则很简单把这些截图全部给你**不附带任何文字说明、不告诉你哪个按钮做什么、不演示任何交互过程**。你需要生成一个基于ReactTypeScript框架的完整可运行应用尽可能还原截图所展示的一切——包括那些截图里没有明说、但理应存在的功能。**三、考卷分四道题最难的是最后一道**研究团队设计了一套四维度评估体系像是给App做全面体检。第一个维度叫**EXEC**即能不能跑起来。模型生成的代码先尝试编译构建再渲染首页如果两步都能成功就算通过。这里有两个分数EXEC1是一次性通过率EXEC3是允许模型最多修三次bug每次把报错信息反馈给它自己后的通过率。第二个维度叫**NRS**即导航可达性。应用跑起来之后检验是否能从首页出发通过界面上可见的导航链接到达输入截图对应的每一个页面。这个评估需要人工完成因为有些导航藏在嵌套菜单或弹窗里程序难以自动探测。第三个维度叫**VFS**即视觉相似度。把生成应用的每个页面截图与原始参考截图进行比对通过分析页面中可见的内容块从大小、文字、位置、颜色四个子维度打分取平均值。这个过程完全不依赖AI打分是纯算法驱动的。第四个维度也是整套评估的核心与最大难点叫**IIS**即交互推断得分。它要回答的问题是模型是否正确推断并实现了截图中隐含的交互逻辑IIS的设计颇费心思。研究团队意识到同一个视觉界面可能对应多种合理的实现方式——搜索框可以按回车触发也可以实时更新还可以点按钮触发这三种都算正确。因此IIS不是和标准答案比对而是基于功能是否实现来打分。为了让评分有据可依研究团队把Web应用中常见的交互行为归纳为七大类。第一类是开关切换比如深色模式的切换按钮或者标签页的选中态。第二类是展开折叠比如手风琴式的菜单或者下拉抽屉。第三类是列表操作比如搜索、筛选、排序、分页。第四类是数据增删改查即常说的CRUD操作。第五类是表单校验比如必填项提示或格式检查。第六类是通知反馈比如操作成功后弹出的提示条。第七类也是最难的是跨路由状态即某些数据在页面跳转之后仍然保持——购物车里的商品换到另一个页面还在就是典型例子。这七类交互还有一个复杂度分层。最简单的S1级只涉及当前组件内部的状态变化比如一个按钮按下去自己变色S2级需要跨组件共享数据比如一个列表的筛选条件影响到另一个地方的显示S3级最难要求数据在页面路由切换后仍然存活这在技术上意味着需要用全局状态管理库或持久化存储来维持。分数计算时S1、S2、S3分别乘以权重1、2、3越复杂的交互实现了得分越高。每个被测应用的交互项目都经过三位标注员独立评估对于一步之差的分歧比如一个认为完全实现另一个认为部分实现采用插值处理对于跨越两级的分歧则由第三位标注员仲裁。标注一致性相当理想Krippendorff α值在0.72到0.84之间。**四、六位选手同台竞技结果出乎意料**研究团队测试的六个模型分别是Claude Sonnet 4.6、Kimi K2.5开启了推理模式、GPT-5.4、Gemini 3.1 Pro Preview、Qwen3.5-397B-A17B以及GLM-4.6V。从能不能跑起来看Claude Sonnet 4.6的一次性成功率最高达到95.6%和Gemini 3.1 Pro Preview一起在允许修三次bug后都达到了100%。GPT-5.4的初次成功率只有64.4%但经过三次自我修复后能爬到82.2%提升幅度接近18个百分点是六个模型中自我修复能力最强的。GLM-4.6V的表现最差即使修了三次也只有35.6%的成功率。从长得像不像VFS看**Gemini 3.1 Pro Preview以78.1分拔得头筹**Claude Sonnet 4.6以75.7分紧随其后其余依次是Kimi K2.565.3、GPT-5.465.0、Qwen3.556.0、GLM-4.6V22.6。从交互推断IIS看排名彻底乾坤大挪移。**Claude Sonnet 4.6以39.3分领跑而视觉保真度冠军Gemini 3.1 Pro Preview只得到7.5分排名第四**。两者之间的差距高达5.2倍。位列二、三的是Kimi K2.520.7和Qwen3.513.2均为开源模型双双超越了排在末尾的两个闭源模型GPT-5.46.7和GLM-4.6V4.5。这个结果揭示了一个核心发现**视觉还原能力和交互推断能力是两种相对独立的本领**。能把界面画得很像不代表能让界面真的活起来。Gemini在像素级还原方面表现出色但在交互逻辑上几乎是一个精致的纸糊模型。**五、交互难度越高模型越容易集体哑火**按照S1、S2、S3三个复杂度层级分开统计后一条规律清晰地浮现出来所有模型的得分都随复杂度提升而下降而且降幅相当明显。S1级交互最简单比如展开折叠、开关切换的最高分是Claude的48.5最低是GLM-4.6V的6.2分差42.3分。S2级需要跨组件协调的列表操作、数据增删改查的最高分是Claude的31.6模型之间的分差收窄到30.3分。到了S3级跨路由状态持久化情况极为严峻六个模型中有三个——Qwen3.5、Gemini、GLM-4.6V——得分**恰好为零**就连表现最好的Claude也只拿到21.6分。具体到每类交互展开折叠C02和开关切换C01是模型相对擅长的领域Claude在这两类上都达到了67分和51分左右。而数据增删改查C04、通知反馈C06和跨路由状态C07是普遍的软肋——Gemini在这三类上得分全部为零GPT-5.4在通知反馈和跨路由状态上同样是零分。按应用类型看管理类后台应用Admin是最难啃的骨头六个模型在这类应用上的平均IIS只有9.4大约是内容类和交易类的一半。研究团队指出这并不能简单地用后台应用的跨路由交互更多来解释因为交易类应用的跨路由交互比例同样不低但得分却更高。这可能与后台系统特有的数据联动复杂性有关目前尚无定论是未来研究值得深挖的方向。**六、代码跑不起来到底错在哪里**研究团队对52例在三次修复机会用尽后仍然构建失败的案例进行了详细的故障解剖。失败原因中占比最大的37%是**幻觉图标导入**模型引用了lucide-react图标库中并不存在的图标名称。比如GPT-5.4在一个后台管理项目中写了import { Funnel } from lucide-react但实际上在当前版本中这个图标还叫FilterFunnel是更新版本才有的名字。这属于纯粹的事实性错误提示词无法预防。排名第二的35%是**覆盖了不该动的脚手架文件**模型重新生成了项目的package.json把本不存在的包名或错误版本号写进去导致安装步骤直接报错。提示词已经明确要求不要重新生成脚手架文件但GLM-4.6V对这条规则的遵守率只有约53%。其余失败原因还包括使用了提示词里没有声明的第三方库10%、使用了项目未配置的路径别名4%、文件间导入导出名称不匹配6%、JSX语法解析错误4%等。值得注意的是同一个EXEC3失败的结论背后藏着两种截然不同的问题GPT-5.4的失败主要来自知识准确性不足而GLM-4.6V的失败主要来自指令遵循能力不够。这两个问题需要不同的解决思路但若只看最终的失败率数字这种差异完全被遮蔽了。**七、把模型放大代码能力就线性提升吗**为了探究模型参数量和能力之间的关系研究团队还单独测试了Qwen2.5-VL这一系列的四个尺寸3B、7B、32B、72BB代表十亿参数。结论不是线性的而是存在一个陡峭的**相变**。3B、7B、32B三个尺寸的构建成功率和视觉相似度几乎都贴着地板——EXEC3不超过2.2%VFS不超过0.2。但到了72B情况突然大变EXEC3跳到62.2%VFS跳到35.2。可用的React应用生成能力在32B和72B之间某处悄然涌现出来。更有趣的是失败的原因也随着模型变大而改变。3B主要败在最基础的语法层面——代码连正确的括号和标签都写不对。7B突破了语法关但倒在了不一致性上——各个文件之间相互矛盾。32B又进了一步但开始出现幻觉式的依赖引用——它能写出结构完整的代码却引用了并不存在的包。72B在这些问题上都有所改善但仍有37.8%的生成物无法构建可见单纯靠堆参数无法把构建成功率推到极限。**八、几个活生生的失败案例**纸面数字之外研究团队还通过具体应用的深度分析来展示IIS背后的真实差距。在一个模仿Genshin音乐合成器的应用中截图展示了六边形音键盘、MIDI键位标注Q到U、A到J、Z到M等和作曲时间轴。但没有任何文字告诉模型这个应用会发出声音。六个模型中四个生成了视觉上相当不错的界面但鼠标按下去毫无动静没有音频依赖。只有Kimi K2.5从截图的视觉线索出发推断出这是一个发声的合成器并实现了完整的Web Audio信号链用AudioContext创建三角波振荡器通过GainNode控制音量以500毫秒的指数衰减模拟真实乐器的余音还附带了MIDI音符到频率的数学换算公式。生成的应用是真正能弹奏的乐器而非截图的平面复制品。在一个电商应用中同一套截图交给Claude Sonnet 4.6和Gemini 3.1 Pro Preview然后研究人员执行相同的操作两次点击加入购物车然后跳转到购物车页面。Claude生成的应用通过一个CartContext把商品加入全局状态跳转后购物车页面正确显示了商品和小计Gemini生成的界面看起来几乎一样但购物车页面始终是空的因为加入购物车的动作根本没有连接到任何全局存储。这就是所谓的冻结立面——外表光鲜内部是空的。在一个仿Duolingo的学习应用中/lesson页面展示了一个选择题和一个CHECK按钮。截图没有说明答对了会怎样、答错了会怎样、经验值该如何更新。只有Claude Sonnet 4.6推断出这里需要一个完整的答题引擎实现了选择答案、判断对错、反馈显示、经验值叠加的完整逻辑。其余五个模型要么渲染了一个静态的题目界面按钮没有绑定任何事件要么只做了部分实现。这些案例都有一个共同特征从截图本身看各模型的输出往往长得差不多但一旦真正用起来差距就暴露无遗。这正是VFS无法捕捉、而IIS专门设计来量化的那部分能力。**九、这项研究对未来意味着什么**说到底UI2App这项研究揭示了一个此前被遮盖的能力鸿沟**会画图不等于会造物**。目前最顶尖的模型即使在所有条件都给足的情况下IIS最高也只有39.3分。跨路由状态保持这一项目前连最好的模型都只能做到21.6分而有一半的模型连零都没能突破。如果把这类能力的上限设为100那么当前最好的表现相当于刚刚达到及格线的四成。这对实际开发者意味着现在用AI截图生成App的工作流程在视觉层面已经相当可用但在逻辑层面还需要大量人工检查和补充。尤其是跨页面的状态管理、CRUD操作的完整实现AI几乎不能可靠地自动推断仍需开发者亲自把关。对模型研发者而言这项研究指出了一个很具体的改进方向不只是让模型看图更准更要让模型从图推理更深——从一个按钮的形状推断出它背后应有的事件绑定从一个数字的显示推断出它依赖的数据状态管理架构。也许最有意思的问题是人类程序员在只有截图的情况下能做到多少分如果人类专家的上限也远低于100那么对AI来说这本身就是一个格外刁钻的任务如果人类能轻松达到80、90那就意味着模型在理解应用意图这件事上还有很长的路要走。这个问题论文本身没有回答但或许正是后续研究值得探索的方向。有兴趣深入了解完整方法细节和所有实验结果的读者可以通过arXiv编号**arXiv:2507.06306**查阅原始论文。---**QA**Q1IIS评分和VFS评分为什么会出现冠军不同的情况AIIS交互推断得分衡量的是App的按钮、购物车、表单等交互功能是否真正能用而VFS视觉相似度衡量的只是界面长得像不像。这两种能力并不挂钩——一个模型可以把界面画得极像原图但背后的按钮没有绑定任何事件购物车加了商品也不会显示另一个模型画面可能稍逊但逻辑实现更完整。Gemini在视觉还原上排第一但在交互推断上排第四正是这种分离的典型体现。Q2UI2App基准测试的跨路由状态为何是最难的交互类别A跨路由状态指的是数据在页面切换后仍然保持的能力比如把商品加入购物车后跳到另一个页面购物车里的商品还在。这在技术上要求使用全局状态管理如React Context、Redux等或持久化存储而不能把数据放在某个页面组件内部。难点在于截图完全不会告诉模型这里需要全局状态模型必须自己从界面线索推断出来。六个被测模型中有三个在这一类别得了零分最好的Claude也只有21.6分满分100。Q3Qwen2.5-VL模型从32B扩展到72B时为什么性能会出现跳跃式提升A研究发现在3B到32B的范围内模型根本无法生成可构建的React应用构建成功率一直接近于零。但在72B时成功率突然跳到62%视觉相似度也从几乎为零跳到35分。这种现象叫做能力涌现——某些复杂能力不是随参数量线性增长的而是在超过某个临界点后才突然出现。目前推测这与多文件代码生成、组件依赖管理等需要整体协调能力的任务特性有关但具体机制还需进一步研究。