上海大学与MiAO Worlds联合给出了一个游戏界面开发自动化答案

这项由上海大学与新加坡MiAO Worlds公司联合开展的研究，以预印本形式发布于2026年3月，论文编号为arXiv:2604.18591，研究方向横跨人机交互与人工智能生成内容两大领域。

每一款游戏背后，都藏着一场鲜为人知的"翻译战争"。

美术设计师耗费数周，精心绘制出充满异域风情的界面——歪斜的木纹边框、飘动的魔法纹路、层叠错落的药瓶图标。然后，这份凝聚了无数心血的视觉稿被交到了程序员手中。程序员面对这张截图，需要一笔一划地测量每个元素的位置、手动裁剪每一个图片素材、在引擎里一层一层地搭建嵌套结构，最终把这幅"画"还原成引擎能够真正运行的代码。这个过程枯燥、耗时、且极易出错，行业里称之为"设计到引擎的苦差事"。

更麻烦的是，游戏界面偏偏是所有数字界面里最难对付的一种。手机App的界面规规矩矩，按钮是方的，文字是横排的，布局遵循统一的网格逻辑；但游戏界面完全不同，它的血条可能是一截弯曲的龙骨，技能图标可能嵌在一面盾牌的浮雕里，整个界面可能像古卷轴一样层层展开。现有的那些"截图转代码"工具，基本上都是为规整的网页和App设计的，一碰到游戏界面就彻底懵圈——它们根本不理解这种不规则的形状，更不知道该如何在引擎里还原那些深度嵌套的层级关系。

正是为了解决这个痛点，来自上海大学和MiAO Worlds的研究团队开发了一套名为SPRITE的系统。SPRITE这个名字既是首字母缩写（Screenshot Parsing and Reconstruction of Interfaces via Training-free Engineering，即"无需训练的截图解析与界面重建工程"），也暗合了Unity引擎中最基础的2D图形元素——精灵图（Sprite）。这套系统的目标只有一个：给程序员一张游戏界面截图，它自动吐出引擎可以直接使用的完整工程文件。

一、这个问题到底有多棘手？从"画"到"代码"的鸿沟

要理解SPRITE为什么值得关注，得先搞清楚游戏界面开发的痛点究竟在哪里。

假设你是一名游戏程序员，设计师给了你一张RPG游戏的商店界面截图：左上角有一个带金属铆钉的面板作为背景，面板里摆着一排商品格子，每个格子里有道具图标、数量标签和价格，右下角有一个火焰纹样的购买按钮，整个界面还叠加在游戏场景的模糊背景上。你的任务是在Unity引擎里把这个界面"搭"出来。

首先，你要把每个元素从截图里裁出来——背景面板、每个格子、图标、按钮，每个都需要是透明背景的PNG格式。裁的时候，金属面板的边缘是不规则的锯齿形，火焰按钮的轮廓更是没有任何直线，这些都只能手工处理。裁完之后，你要在引擎里一个一个地摆放这些元素，调整它们的位置、大小、层级关系——哪个在上面，哪个藏在哪个容器里。最后还要写代码，让按钮能点击，让数量能更新。

这整个流程，有经验的开发者做一个复杂界面往往需要数天。而且一旦设计师改了稿，这个流程就要重来。

现有的AI辅助工具为什么帮不上忙？关键原因在于，那些工具的"世界观"里，界面就是一堆矩形盒子堆在一起，跟HTML网页没什么两样。而游戏引擎的逻辑完全不同：它用绝对坐标定位元素，用深度层级管理遮挡关系，元素的形状可以是任意不规则的多边形，根本没有CSS那套"流式布局"的概念。哪怕是GPT-4V或者Gemini这样的顶级多模态大模型，面对游戏界面时也只能框出一堆矩形框，无法真正理解它的结构。

于是，这个领域长期存在一道鸿沟：一边是艺术家的创意视觉稿，一边是工程师的引擎实现，中间靠人工苦苦衔接。

二、SPRITE的核心思路：先读懂结构，再精确提取，最后生成代码

SPRITE解决这个问题的方式，可以用"先看懂，再量准，再写出来"这九个字来概括，对应三个依次进行的阶段。

第一阶段叫做"语义脚手架构建"。这里的"语义"，指的是对界面内容的理解，而不仅仅是对像素颜色的识别。SPRITE首先请一个视觉语言大模型（简单说，就是能同时理解图片和文字的AI）来看这张截图，但并不是让它随便说说自己看到了什么，而是要求它按照一个预设好的格式填写答案。这个格式是用YAML语言写的——YAML是一种人读起来很顺眼、机器也容易处理的结构化文本格式，长得有点像带缩进的购物清单。

研究团队为这个AI设计了一个特殊的"角色提示"，称为"UI大师"人格，要求它以资深游戏UI开发者和系统架构师的身份来分析界面。这个提示背后有三个核心设计意图：第一，让AI专注于功能逻辑，过滤掉视觉上的装饰性噪声；第二，强制AI为每个元素填写"父级"字段，从而把一个平面的元素列表变成一棵真正的层级树；第三，让AI为每个元素写一段视觉描述，这段描述将在下一阶段指导精确的图像分割模型。

为什么选YAML而不是更常见的JSON格式？这里有一个精心考量：YAML省去了大量的括号和引号，同样的内容用YAML写比用JSON写要少20%到30%的字符，意味着AI可以用同样的"思考额度"处理更密集的界面内容。更妙的是，YAML靠缩进来表示层级关系，这和Unity引擎的UXML格式（Unity用来描述界面结构的标记语言）在结构上天然吻合，为后面的代码生成铺好了路。

经过这一阶段，系统得到的是一份"知道各个元素是什么、它们怎么嵌套、大概在哪里"的结构草图，但坐标还是模糊的估计值，资产文件也还没有提取出来。

第二阶段叫做"精准定位与资产提取"。大模型的优势在于理解语义，但它的短板恰恰是精确的空间定位——让它说"按钮大概在右下角"没问题，让它给出精确到像素的坐标就力不从心了。所以第二阶段引入了专门做图像识别的"2D视觉基础模型"来弥补这一短板。

具体来说，系统用第一阶段生成的视觉描述作为查询条件，驱动GroundingDINO模型在截图上做开放词汇目标检测——简单说，就是"找到那个带金属铆钉的深色半透明面板在哪里"这样的任务。定位到大致区域之后，再用SAM2（Segment Anything Model 2，一个专门做精确图像分割的模型）来描绘出元素的精确轮廓，哪怕是火焰纹样的不规则边缘也能准确勾勒出来，并导出带透明通道的PNG文件。

但提取素材之后，还有一个容易被忽视的问题：被提取出来的元素原本是叠压在背景上的，把它拿走之后，背景就会留下一个空洞。如果不处理这个空洞，背景图就无法单独使用。于是系统还调用了LaMa（一个专门做图像修复的模型）来做"背景补全"，把那个空洞用合理的背景内容填满，确保每一层资产都是干净、可用的独立图片。

完成这一阶段后，YAML文档里的坐标从模糊估计变成了精确的像素值，每个元素也都有了对应的资产文件路径。这份文档完成了从"知道结构"到"知道确切位置和对应文件"的升级。

第三阶段叫做"引擎原生合成"。有了这份精确的YAML文档，最后一步就是让另一个大语言模型把它翻译成Unity引擎能直接读取的代码。研究团队使用了GPT-5和Claude 4.5 Sonnet两个模型来完成这项工作，采用了"少样本提示"（给模型几个示范例子）加上"思维链推理"（让模型一步步思考）的方式，确保生成的UXML和USS代码严格遵循第二阶段确定的层级结构。

系统不仅生成界面的静态结构代码，还会根据元素的语义标签推断出基本的交互行为——比如，被标记为"Button"的元素会自动获得鼠标悬停状态的样式，被标记为"Toggle"的元素会获得开关逻辑。这样生成出来的不只是一个静态的界面骨架，而是一个可以立即在引擎里运行、响应用户操作的功能性原型。

此外，团队还集成了FLUX图像生成模型，让用户可以用文字描述来改变某个素材的视觉风格，比如"把这个按钮改成赛博朋克风格"，从而把整套系统从纯粹的重建工具扩展成了创意辅助工具。

三、评测：用真实的工业级素材检验，结果如何？

为了测试SPRITE的实际效果，研究团队没有用现成的通用数据集，而是专门构建了一个面向游戏场景的基准数据集，命名为GAMEUI Benchmark。

这个数据集收录了来自多种游戏类型的界面——包括角色扮演游戏（RPG）的装备背包、第一人称射击游戏（FPS）的战斗抬头显示器、策略游戏的城建面板，以及休闲游戏的关卡选择界面，覆盖了从简洁主菜单到密密麻麻的物品栏等各种复杂程度。这些都是从真实工业生产环境中筛选出来的高保真界面，每一个条目都配有完整的配套资料：Figma设计软件导出的JSON结构文件（记录了专业设计师定义的层级关系和交互元数据）、手工分割好的精灵图素材、以及由有经验的开发者手写的Unity UXML和USS代码（作为评判生成代码质量的标准答案）。研究团队表示，这个数据集目前还在持续扩充中，会逐步覆盖更多游戏UI功能模块。

在这个数据集上，团队做了两类评估。

第一类是素材提取质量的对比测试。研究团队把SPRITE的提取结果和两类现有方案做了直观比较：一类是直接用Claude-4.5或Qwen3-VL这样的视觉大模型来做目标检测，另一类是不经过语义脚手架阶段、直接用GroundingSAM做分割的基线方案。

结果相当清晰。直接用视觉大模型的方案，输出的只是一堆矩形框，对于火焰按钮、异形图标这类不规则元素完全无能为力——矩形框切出来的要么缺了一块要么多了一堆背景，根本不能直接用。不经语义引导直接分割的方案能勾出大致轮廓，但会出现严重的"碎片化"问题：本来一个完整的面板，因为没有语义约束，模型不知道哪些像素应该归为一组，于是把它切成了七零八落的几十个碎片，完全不可用。SPRITE因为在分割之前先建立了语义层级，知道"这是一个整体的背景面板，不是很多个独立的零件"，所以能够输出轮廓精确、语义完整、透明通道干净的素材文件。

第二类是专家评审。三位资深游戏UI/UX设计师参与了这次评估，他们在GAMEUI Benchmark上实际操作了SPRITE生成的功能原型，并对自动分割出来的素材、界面的层级结构以及UXML源代码进行了逐项审查。评分采用10分制，1分代表完全无法使用，10分代表可以直接投入生产。

在"视觉保真度"方面，SPRITE获得了8.5分——专家们确认，重建出来的界面在视觉上与原始截图高度吻合，素材质量符合行业标准。在"层级逻辑"方面，SPRITE获得了8.0分，专家们认为自动生成的嵌套结构合理，符合专业开发者的预期。在"交互准确性"方面，SPRITE获得了7.0分，这是三项中最低的，专家们指出系统目前只能推断基础交互行为，对于更复杂的时序逻辑无能为力。

这个7.0分背后对应的，是SPRITE目前已知的几类局限性：当界面里有大量半透明元素相互叠压时，分割模型难以确定遮挡关系；对于高度抽象的"叙事型界面"（比如那种把界面元素伪装成游戏世界里真实物品的设计），视觉边界本身就很模糊，系统也会犯错；最关键的是，拖拽、复杂动画曲线、状态机跳转这类需要时序推理的交互逻辑，完全超出了当前系统对单张静态截图的理解能力。不过，专家们仍然认可了这套系统作为快速原型工具的实用价值，并对团队提出的改进方向表示期待。

四、这套系统是为谁设计的，以及它改变了什么

SPRITE在设计之初，就明确了两类目标用户，而且这两类用户的需求几乎截然相反。

对于没有编程背景的设计师或独立创作者来说，SPRITE提供的是一条"零代码"通道：把自己的设计截图或者手绘草图丢进去，直接得到一个可以在引擎里跑起来的原型，不需要懂UXML是什么，不需要知道怎么配置锚点，不需要手动处理任何素材文件。这极大地降低了创意实现的门槛，让那些"有想法但不会写代码"的人也能直接参与游戏原型的迭代。

对于有经验的专业开发者来说，SPRITE做的不是替代他们，而是消除那些重复性的、让人精疲力竭的"体力活"。那些切图、摆位置、搭基础层级结构的工作，原本要占用大量时间，用SPRITE可以在几分钟内自动完成，让开发者把精力集中在真正有技术含量的地方：复杂的状态机逻辑、性能优化、精细的动画曲线调整。

这种"既降低门槛又提升效率"的双重设计，体现了团队对游戏开发生态的一个判断：游戏UI开发的痛点不只是技术门槛，更是流程中大量低效的手工劳动，而这两个问题可以用同一套工具的不同使用方式来解决。

五、接下来打算做什么：三个值得期待的方向

研究团队在论文里明确提出了三个后续研究方向，每一个都指向了当前系统的一个真实局限。

当前系统最显眼的短板是只能处理静态截图，无法理解动态交互。团队计划引入视频大模型，让系统能够分析游戏玩法录像或者UI操作的录屏，从中自动提取动画时序、状态机跳转规则、条件性视觉反馈（比如鼠标悬停时按钮从灰色变成金色的效果）。这样一来，系统输出的就不仅仅是界面的静态骨架，而是包含完整动画控制器和交互事件脚本的运行时逻辑。

另一个方向是把界面的结构（UXML，决定有什么元素、怎么排列）和样式（USS，决定每个元素长什么样）彻底分离，分别映射到一个可以用文字描述来操控的"潜在语义空间"里。这意味着开发者可以说"把整个界面改成暗黑风格"，系统就自动重新生成符合这个描述的样式，而不改动任何功能逻辑。这对于需要为同一个游戏维护多个视觉主题的开发团队来说极为实用，也为生成式A/B测试打开了大门。

第三个方向相对"软性"，但同样重要：研究团队计划通过长期跟踪研究，考察SPRITE这类工具如何改变设计师和程序员之间的协作模式——谁负责什么、信任如何建立、当自动生成结果出错时人们如何应对、整个工作流程里的认知负担发生了怎样的变化。这个方向的答案，将决定类似工具在真实工业环境里能走多远。

说到底，SPRITE想解决的问题，是一个存在于"脑子里的画面"和"引擎里能跑的代码"之间的古老鸿沟。游戏开发这件事，本质上是把人对世界的想象转化为计算机的语言，而现有流程里有太多的时间和精力消耗在纯粹的机械转换上，而不是真正的创造性工作。SPRITE用三步流水线——先读懂结构、再量准位置、再写出代码——在一定程度上自动化了这个转换过程，让创作者可以更快地看到自己的想法在引擎里运转起来。

当然，这套系统现在还远不是"交稿即用"的完成品，7.0分的交互准确性说明它在复杂动态逻辑上仍然需要人工介入。但对于那些日复一日在截图和代码之间苦苦搭桥的开发者来说，有一个工具能把最枯燥的那部分工作自动化，已经足够有价值了。对原论文感兴趣的读者，可以通过arXiv检索编号2604.18591找到完整的技术细节和实验数据。

Q&A

Q1：SPRITE系统能处理哪些游戏类型的界面？

A：SPRITE的GAMEUI Benchmark数据集涵盖了RPG、FPS、策略游戏和休闲游戏等多种类型，从简单主菜单到密集物品栏都有覆盖。由于系统采用无需重新训练的设计，理论上对各种风格和类型的游戏界面都有一定适应能力，不限于特定游戏类型。

Q2：SPRITE生成的代码能直接放进Unity项目用吗？

A：基本结构和静态布局部分可以直接使用，专家评分中视觉保真度达到8.5分、层级逻辑8.0分，达到了接近可用的水平。但交互逻辑部分只有7.0分，对于拖拽、复杂动画这类需要时序逻辑的功能，目前仍需开发者手动补充完善，不能完全免除人工介入。

Q3：SPRITE为什么不直接用现成的大模型做截图转代码，而要多做一个YAML中间层？

A：直接用大模型生成代码有两个致命问题：一是大模型对像素坐标的估计非常不准确；二是无法处理游戏界面的不规则形状素材提取。YAML中间层的作用是先用AI理解结构和语义，再用专门的图像分割模型做精确定位，两步分工协作，才能同时解决"理解层级关系"和"精确提取素材"这两个缺一不可的问题。