这项由香港中文大学计算机科学与工程系主导的研究，于2026年7月13日以预印本形式发布在arXiv平台，编号为arXiv:2607.11594。研究尚未正式发表于特定期刊，已提交IEEE待审。有兴趣深入了解技术细节的读者，可通过上述编号查阅完整论文。
**当游戏世界的搭建变成一件苦差事**
做过游戏的人都知道，哪怕是最简单的"闯关类"游戏，也要面对一个令人头疼的工程问题：你得精心设计每一个场景，还要保证从一个场景跳转到下一个场景的"门"两边完全对得上——目的地对、位置对、视觉特效对——哪一环出错，玩家就会卡住，或者穿越到一个莫名其妙的地方。更麻烦的是，这种"过场衔接"需要手动维护大量的脚本文件和连接表格，稍有疏漏，整个游戏世界就会四分五裂。
近年来，借助大型语言模型（LLM，可以理解为像ChatGPT这样能读懂人类语言、并生成各种内容的AI），研究者已经能够让AI自动生成单个室内场景——你告诉它"帮我造一间中世纪图书馆"，它就能给你生成一整套带家具的三维空间。问题是，这些AI每次只能生成一个场景，把它反复运行几次，你得到的是一堆互相不认识的"孤岛"，根本拼不成一个玩家可以穿行其中的完整世界。
香港中文大学的研究团队为此设计了一套名为MAGIC的系统——全称是"Multi-scene Automated Game worlds generator with Intelligent Connectivity"，直译过来就是"带智能连接能力的多场景自动游戏世界生成器"。它的目标很直接：你只需要用普通的语言描述你想要的游戏世界，MAGIC就会自动帮你生成多个场景，并把它们用可以正常使用的"传送门"连接起来，最终打包成一个可以直接在Unity游戏引擎里运行的项目。
一、三块绊脚石：为什么简单地重复用AI生成场景行不通
要理解MAGIC解决了什么问题，先得搞清楚"重复生成"到底会出哪些岔子。
第一个麻烦是"两边对不上"。一扇门，在A场景叫"通往地牢的铁门"，在B场景可能根本就没有这扇门，或者被叫成了完全不同的名字。这就好比你跟朋友约好"从北京南站坐高铁过来"，结果朋友去的是北京西站，两人根本碰不上面。AI在处理多个场景时，随着信息越来越多，很容易"忘记"之前说过的约定，导致跨场景的门口信息对不上。
第二个麻烦是"门被家具堵住了"。即便两个场景里的门名字一样、位置一样，但等到AI把家具、桌椅、书架都摆进去之后，门口可能正好被一张大沙发挡住了。玩家根本走不到门跟前，场景之间的跳转就彻底失效。这个问题用现有的评估工具完全检测不出来，因为那些工具只看场景好不好看、对不对题，从不管"门能不能走进去"。
第三个麻烦是"没有人真的去测"。目前所有评估AI生成3D场景好坏的工具，都只是拿生成结果和参考图片比一比，或者看看场景是否符合文字描述。没有任何工具会真正"进入"这个游戏世界，操控角色走到门口，踢一脚，看看到底能不能跳转到下一个场景。所以哪怕门被堵死了、跳转脚本写错了，评估系统依然可能给出"优秀"的成绩。
MAGIC的设计目标，就是把这三块绊脚石一块一块地搬开。
二、MAGIC的四步流水线：一句话变成一个完整游戏项目
MAGIC的工作方式可以用"建筑施工"来理解。建一栋大楼，你需要先画总平面图，再细化每个房间的图纸，再按图施工，最后把各楼层合并成一栋完整的建筑。MAGIC的四个阶段，做的是完全类似的事情。
**第一步：规划阶段——画出整个世界的蓝图**
用户输入一段自然语言描述，比如"我想要一个由图书馆、密室和地牢三个区域组成的逃脱游戏，图书馆和密室之间有一扇滑动书架门，密室和地牢之间有一扇铁栅栏门"。MAGIC的规划模块会把这段描述"拆开"，分别提炼出每个场景应该是什么样的，同时建立一张"过场地图"——用数学的方式表达哪两个场景之间有门、这扇门叫什么名字、穿越时会有什么视觉特效（目前支持"渐入渐出"和"光圈收缩"两种效果）。
这张过场地图被称为"过渡感知自动机"，它就像建筑师手里的总平面图，所有后续步骤都要参照它。为了确保这张图的准确性，系统会用第二个AI模型反复校验：每个场景里应有的门的数量和类型，都会被统计一遍，有缺漏的话就重新生成，直到完全吻合。这一步直接解决了"两边对不上"的问题——因为所有场景都必须以这张共同的蓝图为准。
**第二步：场景规格化——把每个房间细化到每一件家具**
有了总蓝图之后，MAGIC开始针对每个场景分别展开设计。这一步相当于设计师把总平面图细化成每个房间的详细装修方案。
系统首先把场景描述扩展成包含8到12件物品的详细清单，然后把场景划分成若干区域（比如图书馆可以分成阅览区、书架区、入口区），给每个区域分配合适的家具。所有家具的摆放位置，会按照一套领域专用语言（可以理解为一种专门描述"谁在哪里、朝哪个方向"的格式化语言）生成初稿，再由校验模块逐条检查是否违反规则，有问题就重新生成，直到所有约束都满足为止。
门和窗户的处理有额外讲究。系统会精确计算AI给出的门的位置和墙壁之间的距离，然后把门"推"到离墙最近的位置，再向内侧偏移半个门厚度，让门看起来更自然地嵌在墙里。所有被标记为"传送门"的门，都会被打上特殊的"isPortal"标签，后续各阶段可以通过这个标签精准找到它们。
这一步最关键的设计，是用来检测"门有没有被堵住"的洪水填充算法。这个算法的工作原理类似于在房间地图上"倒水"：从传送门的位置开始，让"水"向四面八方流动，经过所有没被家具占据的空格。如果水能流遍整个房间，说明传送门从任何位置都能走到；如果有些地方水流不进去，说明那里被家具堵死了，需要重新调整摆放方案。
具体来说，算法会把整个场景转换成一张细密的网格地图，每个网格格子的边长只有0.05个单位（大约是一根手指的宽度），标记出哪些格子被家具占用、哪些是可以行走的空地。然后从传送门出发，用"广度优先搜索"（一种计算机找路的方式，类似于水往低处流）扩展可达区域。最终，可到达格子数占全部可走格子数的比例，就是这个场景的"连通率"。连通率达到100%，才算通过；否则，系统会重新调整家具摆放，直到达标或者尝试次数耗尽——耗尽时，会保留连通率最高的那个方案。
这一步直接解决了"门被家具堵住"的问题。
**第三步：场景生成——把图纸变成真实的3D项目**
有了详细的场景规格之后，MAGIC调用Scenethesis（一个专门根据规格生成3D模型的系统）来生成所有家具、墙壁、地板的三维网格。与此同时，系统会根据场景规格里的传送门信息，自动生成对应的"关卡加载脚本"（LevelLoader script）——这是Unity游戏引擎里负责"当玩家走到这扇门时，跳转到哪个场景"的程序代码。
这里有一个工程细节值得一提：系统是把关卡加载脚本挂在门这个物体上，而不是挂在玩家角色上。原因是如果挂在玩家角色上，触发机制会变得不稳定，容易出现"明明走到门口了却没反应"的情况。挂在门上之后，只要检测到玩家的摄像机碰撞了这扇门，就自动触发跳转，稳定性大大提高。
这个阶段用的是模板填充方式，而不是让AI"自由发挥"写代码。这样做的好处是：生成出来的脚本保证能运行，不会因为AI写了个语法错误的代码而导致整个项目崩溃。
**第四步：整合——把散件拼成完整的游戏**
前三步对每个场景分别执行一遍，最终得到若干个独立的Unity项目文件。第四步做的事情，就是把这些散件合并成一个完整的Unity多场景项目，让场景之间的跳转脚本能够正确引用彼此。这一步本质上是文件管理和路径整合，技术上相对简单，但对于用户来说是最直观的——你打开最终项目，就是一个可以运行、可以在场景之间穿梭的完整游戏世界。
三、那个"真正进入游戏测试"的评估探员
MAGIC不只是生成工具，研究团队还为它配套设计了一个全新的评估机制——一个真正会"进入游戏、走到门口、踢一脚看看能不能过去"的自动化评估探员。
这个探员的工作流程分四个阶段。第一步，它扫描游戏项目里所有可能是传送门的物体，列出候选名单。第二步，它挨个测试这些候选传送门——让游戏角色去碰一下，看看有没有触发场景跳转，如果有，就记下跳到了哪里。第三步，对于那些真实有效的传送门，探员让角色从出生点出发，尝试走到传送门跟前，检验它在实际游戏中是否能被玩家接近；同时对传送门拍一圈环绕照片，把照片送给多模态大语言模型（能同时理解文字和图片的AI）判断，这扇门的外观是不是和描述的"滑动书架门"或"铁栅栏门"相符。第四步，把所有场景的测试结果汇总，对照预先设定的"标准答案"（即规划阶段生成的过场地图），计算精确率、召回率、F1分数、接近率和传送门外观匹配率五项指标。
这五个指标可以这样理解：精确率是"AI生成的传送门中，有多少是真实需要的"；召回率是"所有应该有的传送门中，有多少被正确生成了"；F1分数是这两者的综合评分；接近率是"生成的传送门中，有多少是玩家实际上能走到的"；传送门外观匹配率是"传送门的长相和描述是否相符"。
为了验证这个探员靠不靠谱，研究团队让两名人工评审员对20个测试案例逐一手动检查，然后把人工结果和探员结果做对比。结果显示，探员和人工判断的差距极小，各项指标的平均绝对差仅为0.0299——换句话说，这个探员的判断和人类几乎一致。
研究团队还额外做了两组对比实验。第一组（消融实验1）去掉了"候选传送门提取"这一步，直接让探员检查所有物体——结果是探员被大量无关物体淹没，耗时暴增到每个场景超过1000秒，而且判断准确性严重下降。第二组（消融实验2）保留了候选提取，但把"拍照送给AI看外观"换成"只看传送门的名字来判断外观"——结果在外观匹配率上明显差于完整版探员。完整版探员每个场景只需约40秒，各项指标也最接近人类判断。
四、测试场地：100个多场景案例的擂台
研究团队构建了一个包含100个测试案例的专用基准数据集。这些案例来自两个公开数据集的组合：一个是MIT 67室内场景数据集，包含厨房、卧室、图书馆、健身房等67类功能各异的室内场景；另一个是MMIS多模态室内场景数据集，提供了不同设计风格的室内图像和文字描述。
每个测试案例是一张"场景图"，节点是具体的室内场景，边是场景之间应有的跳转关系。案例规模从单个场景到五个场景互联不等，跳转模式涵盖线性、环形和树状分支等多种拓扑结构，传送门类型也有统一类型和混合类型两种。最终，每个结构化案例都被转化为一段自然语言描述，作为MAGIC和对比方法的输入。
五、和竞争对手比，MAGIC赢在哪里
MAGIC在每个阶段都和两类对比方法做了比较：一类是直接用GPT-4.1提问（LLM基线），另一类是Holodeck（一个已有的单场景生成系统）。
在规划阶段，MAGIC生成的场景描述准确率达到0.97，过场地图的图结构准确率达到0.97，均优于LLM基线的0.92和0.91。两者都依赖语言模型的理解能力，但MAGIC额外加入了验证循环，使得过场地图更加可靠。
在场景规格化阶段，三种方法在传送门生成的精确率上相差不大，但在召回率（即"应该有的传送门有没有全生成出来"）上差距明显：MAGIC的召回率达到0.95，LLM基线为0.92，Holodeck只有0.60。连通率（即"传送门有没有被家具堵死"）上的差距更大：MAGIC达到0.9952，几近完美；LLM基线为0.87；Holodeck最低，只有0.85，而且它的场景密度最高（占用率接近40%），说明它放了很多家具但通道却最差。MAGIC的场景密度接近28%，属于"不太稀疏、也不太拥挤"的平衡状态。
在场景生成阶段，MAGIC对所有100个测试案例均成功生成了可运行的Unity项目，成功率100%。LLM基线则一个都没成功——原因在于它对Unity的文件结构和脚本规范了解不足，哪怕只是文件命名出了一点点差错，整个项目就无法打开。此外，LLM基线在将近一半的案例中生成了"多余的跳转脚本"，导致玩家走到某个地方会意外弹到一个不该去的场景。
在端到端评估中，MAGIC的最终表现是：精确率0.99、召回率0.95、F1分数0.96、接近率0.95、传送门外观匹配率0.79。前三项都超过了0.9，说明绝大多数该有的跳转都被正确生成，且几乎没有多余的错误跳转。接近率同样接近0.95，意味着生成的传送门中大约95%是玩家实际上能走到的。外观匹配率稍低，是因为AI的外观判断标准比较严格，比如"指示牌"这个传送门，AI生成了一块普通的板子，但判断模型认为板子上没有明显的"指示"功能证据，所以判定不匹配——这属于物体模型库覆盖范围的局限，而不是流水线本身的问题。
值得一提的是，研究团队发现，测试案例的场景数量从一个增加到五个，MAGIC的各项表现并未出现明显下滑。这说明在测试范围内，流水线的质量不会随着项目规模增大而急剧恶化。不过研究团队也坦诚地指出，由于测试范围仅到五个场景，更大规模的外推还需要更多验证。
六、MAGIC目前还做不到什么
研究团队对系统的局限性做了诚实的陈述，这些边界同样值得了解。
目前MAGIC只支持室内场景，户外或大型开放世界不在它的能力范围之内。它只能在Unity引擎上运行，其他引擎（如Unreal Engine）尚不支持。过场特效只有两种（渐入渐出和光圈收缩），如果游戏设计需要更丰富的过场动画，还得另外开发。输入语言只支持英文。传送门的外观受限于物体模型库的覆盖范围，库里没有的东西生成出来可能"形似而神不似"。家具摆放是尽力而为，当重试预算耗尽时，系统会返回当前连通率最高的方案，所以少数情况下仍可能有极小区域的遮挡。
在研究方法层面，测试案例的"标准答案"是用程序脚本自动生成的，而不是由人工设计师手动创建，这意味着标准答案本身可能存在一定的人工设计偏差。每个案例只跑了一遍，没有重复多次取平均，也没有做统计显著性检验，所以给出的数字是单次运行的点估计，存在一定的随机波动。人工评审只参与了20个案例的对比验证，两名评审员的样本量也偏小。
归根结底，MAGIC做的这件事，是把一个通常需要游戏开发团队花费大量时间手工维护的工作——设计多个室内场景并保证它们之间的门全部可以正常穿行——变成了一个任何人输入一句话就能启动的自动流程。
从实际效果看，100个测试案例中每一个都能生成可运行的项目，超过95%的该有的传送门被正确生成，且绝大多数传送门都没有被家具堵死，玩家能够顺利走到。这对于一个完全自动化的系统来说，已经是相当可靠的表现。
当然，目前的版本还有不少约束：只在室内、只在Unity、只有英文、只有两种特效。如果你是一位独立游戏开发者，这些限制可能会让你觉得"离我能直接用还有点距离"。但如果你只是想快速做个游戏原型，或者想看看AI能不能帮你搭出一个可以"走进去转一圈"的三维草稿，MAGIC已经能给出一个完整的、可以打开运行的答案。
未来的可能方向，研究团队提到了几个：支持玩家主动触发传送的动作（比如按键而不只是走到门口），允许人工在某个中间阶段介入修改（比如调整场景规格再让后面的步骤继续执行），以及把整套流程推广到室外场景和其他游戏引擎。这些方向每一个都足以支撑一篇独立的论文，足见这个领域还有相当大的探索空间。
对AI辅助游戏开发感兴趣的读者，可以通过arXiv编号2607.11594查阅完整论文，也可以访问论文中提供的代码仓库，直接跑起来试一试。
Q&A
Q1：MAGIC生成的游戏场景可以直接在Unity里打开玩吗？
A：可以。MAGIC的最终输出就是一个完整的Unity项目文件，用Unity打开后可以直接运行，玩家操控摄像机在场景里走动，走到传送门就会跳转到下一个场景，不需要额外的手动配置。在100个测试案例中，每一个都成功生成了可以运行的项目。
Q2：MAGIC用的洪水填充算法是怎么判断门有没有被堵住的？
A：算法把整个场景转成一张细密的网格地图，把家具占用的格子标成"障碍"，其余的标成"可走"。然后从传送门的位置出发，像倒水一样让标记向四周扩散，只能流过可走的格子。扩散结束后，如果扩散覆盖了所有可走格子，说明门没有被堵死；如果有死角扩散不到，说明有障碍挡路，系统就会重新调整家具摆放。
Q3：MAGIC的评估探员和人工检查相比准确性怎么样？
A：研究团队用20个测试案例做了对比，让人工评审员逐场景手动检查每扇门能否正常触发跳转，然后和探员的结果做对比。各项指标的平均绝对差只有0.0299，说明探员的判断和人类几乎一致，同时每个场景只需约40秒，远比人工高效。