当AI被截图"考试"：香港科大团队揭示大模型看图造App的真实水平

来源：市场资讯

（来源：科技行者）

这项由香港科技大学（广州）与香港科技大学联合开展的研究，以预印本形式于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的分辨率下统一截取，并经过去重和专家审查。

每道题的规则很简单：把这些截图全部给你，**不附带任何文字说明、不告诉你哪个按钮做什么、不演示任何交互过程**。你需要生成一个基于React+TypeScript框架的完整可运行应用，尽可能还原截图所展示的一切——包括那些截图里没有明说、但理应存在的功能。

**三、考卷分四道题，最难的是最后一道**

研究团队设计了一套四维度评估体系，像是给App做全面体检。

第一个维度叫**EXEC**，即"能不能跑起来"。模型生成的代码先尝试编译构建，再渲染首页，如果两步都能成功，就算通过。这里有两个分数：EXEC@1是一次性通过率，EXEC@3是允许模型最多修三次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.5（65.3）、GPT-5.4（65.0）、Qwen3.5（56.0）、GLM-4.6V（22.6）。

从"交互推断"（IIS）看，排名彻底乾坤大挪移。**Claude Sonnet 4.6以39.3分领跑，而视觉保真度冠军Gemini 3.1 Pro Preview只得到7.5分，排名第四**。两者之间的差距高达5.2倍。位列二、三的是Kimi K2.5（20.7）和Qwen3.5（13.2），均为开源模型，双双超越了排在末尾的两个闭源模型GPT-5.4（6.7）和GLM-4.6V（4.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"`，但实际上在当前版本中这个图标还叫`Filter`，`Funnel`是更新版本才有的名字。这属于纯粹的事实性错误，提示词无法预防。

排名第二的（35%）是**覆盖了不该动的脚手架文件**：模型重新生成了项目的`package.json`，把本不存在的包名或错误版本号写进去，导致安装步骤直接报错。提示词已经明确要求"不要重新生成脚手架文件"，但GLM-4.6V对这条规则的遵守率只有约53%。

其余失败原因还包括：使用了提示词里没有声明的第三方库（10%）、使用了项目未配置的路径别名（4%）、文件间导入导出名称不匹配（6%）、JSX语法解析错误（4%）等。

值得注意的是，同一个"EXEC@3=失败"的结论背后，藏着两种截然不同的问题：GPT-5.4的失败主要来自知识准确性不足，而GLM-4.6V的失败主要来自指令遵循能力不够。这两个问题需要不同的解决思路，但若只看最终的失败率数字，这种差异完全被遮蔽了。

**七、把模型放大，代码能力就线性提升吗？**

为了探究模型参数量和能力之间的关系，研究团队还单独测试了Qwen2.5-VL这一系列的四个尺寸：3B、7B、32B、72B（B代表"十亿参数"）。

结论不是线性的，而是存在一个陡峭的**相变**。3B、7B、32B三个尺寸的构建成功率和视觉相似度几乎都贴着地板——EXEC@3不超过2.2%，VFS不超过0.2。但到了72B，情况突然大变：EXEC@3跳到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**查阅原始论文。

**Q&A**

Q1：IIS评分和VFS评分为什么会出现冠军不同的情况？

A：IIS（交互推断得分）衡量的是App的按钮、购物车、表单等交互功能是否真正"能用"，而VFS（视觉相似度）衡量的只是界面"长得像不像"。这两种能力并不挂钩——一个模型可以把界面画得极像原图，但背后的按钮没有绑定任何事件，购物车加了商品也不会显示；另一个模型画面可能稍逊，但逻辑实现更完整。Gemini在视觉还原上排第一，但在交互推断上排第四，正是这种分离的典型体现。

Q2：UI2App基准测试的"跨路由状态"为何是最难的交互类别？

A：跨路由状态指的是数据在页面切换后仍然保持的能力，比如把商品加入购物车后跳到另一个页面，购物车里的商品还在。这在技术上要求使用全局状态管理（如React Context、Redux等）或持久化存储，而不能把数据放在某个页面组件内部。难点在于，截图完全不会告诉模型"这里需要全局状态"，模型必须自己从界面线索推断出来。六个被测模型中有三个在这一类别得了零分，最好的Claude也只有21.6分（满分100）。

Q3：Qwen2.5-VL模型从32B扩展到72B时为什么性能会出现跳跃式提升？

A：研究发现，在3B到32B的范围内，模型根本无法生成可构建的React应用，构建成功率一直接近于零。但在72B时，成功率突然跳到62%，视觉相似度也从几乎为零跳到35分。这种现象叫做"能力涌现"——某些复杂能力不是随参数量线性增长的，而是在超过某个临界点后才突然出现。目前推测这与多文件代码生成、组件依赖管理等需要整体协调能力的任务特性有关，但具体机制还需进一步研究。