Luo 等人：AI 智能体能否在真实引擎中制作出可以游玩的完整游戏？——Fukai 的解读

一段话摘要

当用自然语言说「帮我做这种游戏」时，AI（这里指能读写文件、执行命令的「编程智能体」——自动完成代码编写工作的 AI）能否将一款游戏从头到尾组装完成？这篇论文正面回答了这个问题，提出了名为 GameCraft-Bench 的评估基准。作者来自香港中文大学（深圳）等团队，是2026年6月16日投稿于 arXiv 的预印本（刚刚投稿、尚未经过同行评审的阶段）。

关键在于评价方式：不是检验生成代码是否正确，而是「实际启动后，玩家操作时是否作为游戏有所响应」。作者们在开源游戏引擎 Godot 上准备了横跨15个类型的140道制作课题。对最新各公司智能体进行测试的结果是，即使最强配置，全体得分也仅为41.46%，多数低于40%。智能体能做出「看起来像样的操作机制」，但要到达包含内容厚度、界面易读性、精加工在内的完成品，尚需时日——这是论文的要点。

前言

我每天早上都会浏览与谜题和游戏设计相关的新论文，今天选择的是一篇名为 GameCraft-Bench 的评估基准论文。作者为 Tongxu Luo、Rongsheng Wang 等，通讯作者为 Benyou Wang。所属机构涵盖香港中文大学（深圳）、深圳 Loop Area Institute、腾讯混元团队、北京科技大学（USTB）、上海交通大学、新加坡国立大学等多个机构。论文于2026年6月16日作为预印本投稿至 arXiv（arXiv:2606.17861，分类为 cs.CL=计算语言学），尚未通过同行评审。由于投稿时间较短，引用尚未积累，本文仅作为「广泛讨论前的一手信息」，介绍我能在原文中确认的内容。

为什么今天选择这篇。关于用生成式 AI 制作游戏的话题，往往伴随着华丽的演示视频，但冷静衡量「最终能否做出可以游玩的作品」的量尺却出人意料地少。这篇论文试图设计那把量尺本身。对于游戏制作者而言，这是一份判断哪些工作可以委托给 AI、哪些不能的材料。

背景

对于能写代码的 AI 的评价，以往主要通过单元测试（自动检验特定输入能否返回期望输出的机制）或任务完成与否来衡量「代码是否正确运行」。但游戏的情况不同。游戏的本质是「玩家操作→世界更新→结果返回画面」这一反应往复（作者的用语：action-response loop）。仅凭看代码，操作无效、碰撞判定偏移、敌人不动、无法到达终点、UI 显示缺失等失败是看不出来的，只有实际启动游玩才会暴露。

作者们整理出，评估游戏生成需要三个条件（desiderata，应满足的理想属性）。第一是 Engine Grounding（引擎落地：在真实游戏引擎上，连同其规范、素材、启动步骤一起开发）。第二是 Artifact Completeness（成果物完整性：提交的不是零散部件，而是可以直接启动的完整项目）。第三是 Interactive Verification（交互式验证：不是静态审阅，而是通过实际操作后的行为来判定）。

而现有评估基准并不能同时满足这三点，作者们指出。据其整理，OpenGame-Bench 要求制作完成品但对象是网页游戏且不以操作判定；GameDevBench 使用真实引擎（Godot）但局限于教程衍生的局部编辑和固定测试；WebGameBench 通过浏览器操作评估但并非在引擎上开发。GameCraft-Bench 正是为填补这一空白——「将用户意图运送到引擎原生的完整游戏，并通过操作来验证其行为」——而设计的。

方法

GameCraft-Bench 将每道课题设计为五个阶段的流水作业。第一阶段「课题打包」：将（1）用自然语言描述所需游戏的规格书、（2）Godot 开发环境全套、（3）用于评分的隐藏评分表（评分标准按项目分解的表格）三者打包在一起。规格书描述玩家体验，不给出具体实现指示。评分表不向智能体展示。

第二阶段「智能体生成」：智能体实际构建 Godot 项目。可以制作场景、编写脚本、配置输入、使用素材、启动项目、查看截图后修改，进行迭代。提交物有两项——完成的 Godot 项目本体，以及「可回放的操作记录（trace）」。Trace 是含时间戳的按键和鼠标操作记录，不是游戏的一部分，而是供评分方稍后重现相同操作的证据。

第三阶段「构建关卡」确认提交物是否能启动。无法启动或记录无法读取，则得分为零。第四阶段「回放」在1280×720画面上重现记录的操作，将游玩视频和每秒2帧的静态图作为证据保存。第五阶段「评分与汇总」：将这些影像证据，按照隐藏评分表，由多模态（同时处理图像和文字的）判定 AI 从四个维度评分。四维度分别为 Core Mechanics（核心玩法机制）、Content Depth（内容厚度与进程）、Functional Visuals（功能性画面显示与易读性）、Art and Presentation（外观与精加工），权重分别为0.15、0.35、0.15、0.35。内容厚度与精加工权重较大。

课题本身由12名游戏经验丰富的注释者创建。每道课题除了公开规格书和隐藏评分表外，注释者还自行在 Godot 上实现了「最小可玩原型（oracle 解）」，核验规格是否可实现、评分项目是否可在视频中观察、各项目是否对应可观察（而非主观）状态。规格书、评分表、原型三者对齐后才最终确定，即质量管理流程。

发现

作者们对7种最新智能体配置进行了全140道课题的评估。按论文 Table 4，全体得分（%）为：Claude Code 上的 Opus-4.7 high 以41.46%最高，其次是 Codex 上的 GPT-5.5 high（39.49%）、Kimi Code 上的 Kimi-K2.6（30.65%）、MiMo-V2.5-Pro（24.10%）、GLM-5.1（18.29%）、MiniMax-M2.7（10.95%）、DeepSeek-V4-Pro（2.15%）（模型名均按原文引用）。最强也仅四成多，作者们由此指出：「目前的智能体有时能制作出可启动的『游戏状物体』，但要一贯实现所要求的机制、内容、画面状态和精加工，尚有差距。」

按维度来看，所有智能体的 Core Mechanics（玩法机制）相对较高，内容和精加工较低。强势前三——Opus-4.7 high、GPT-5.5 high、Kimi-K2.6 的 Core Mechanics 分别为55.34%、54.36%、39.76%，而 Content Depth 分别降至39.48%、38.61%、28.07%。作者们将此归纳为「能制作局部可辨的机制，但难以扩展到完整一贯的系统」，并作为第一个知见总结。

分析中也出现了有趣的对比。能查看渲染画面并据此修正的智能体，可以修正仅靠代码看不出的失败。Kimi-K2.6 在140道课题中共查看画面2998次（平均每道21.41次，中位数19，仅有4道课题从未查看），Opus-4.7 为1952次（13.94次），而 GPT-5.5 仅268次（1.91次）。另一方面，「多操作就好」也不成立：MiMo-V2.5-Pro 先大量写文件再主要用 shell 命令调试，shell 操作占全工具调用的56.3%，但工具调用总次数与得分几乎无关（作者报告相关性 r=+0.016）。5道得零分的课题，均是游戏已能启动但未提交操作记录（trace），导致所有评分项目未被评估。能否闭合评价的环路至关重要。

应用场景

那么，游戏和谜题制作者如何利用这些发现？第一，作为「可以委托给 AI 的范围」的现实分界线。如果想把小型2D游戏原型委托给 AI，这篇论文的数字告诉你：「核心操作机制可以期待，但内容厚度、界面易读性和精加工要由人类承接，制定计划时以此为前提。」Core Mechanics 与 Content Depth、Art 之间的差距（强势智能体也有约15～20个百分点的差距），直接可作为你的工作分配参考。

第二，作为自己团队评估流程的参考。GameCraft-Bench 的「是否能启动→回放操作记录→视频评分」三段式框架，也适用于不使用 AI 的普通玩法测试。例如，接收外包或实习生的原型时，可以直接转化为清单：（1）能否直接启动；（2）按规定操作序列是否能到达预期游戏状态；（3）录制过程并按四维度（机制・内容・易读性・精加工）评分。「隐藏评分表」的思路——向制作方描述体验，评估时分解为可观察项目——也可作为内部关卡评审标准复用。

第三，作为选择类型的参考。论文的课题横跨15个类型，细分为：平台19、策略17、经营16、开放世界15、Roguelike 14、视觉小说11、谜题8、射击7、模拟6、卡牌5、恐怖5、音乐5、放置4、赛车4、体育4道。以「制作上什么最难」为维度将类型归类——连续操作与碰撞判定、规则与状态管理、进程与经济、探索与空间配置、以演出为主的对话等。如果想用 AI 辅助量产，这可以作为「从状态管理和演出比重较轻的类型入手」的判断依据。

第四，作为辅助工具设计方针。「查看画面并修正」的循环对得分有效这一事实，可以解读为：如果给 AI 提供的不只是代码，还包括截图和录像，效果更容易显现。如果在自己的 PCG（程序化内容生成）流水线中引入 AI，建议从一开始就在设计中加入每次生成后将渲染结果展示给 AI 进行自检的循环。

局限

首先是作者自己承认的局限。判定 AI 总体上与人类一致，但略显宽松。论文 Table 5 的初步人工核对显示，3个类型的平均判定 AI 全体得分为26.02%，人类为22.69%，判定 AI 高约3.32个百分点。人类对内容厚度和精加工更严格，判定 AI 对画面显示（Functional Visuals）更严格。作者们明确表示这一核对是「小规模、非设计为测量评分者间一致性的校准检验」，并非确定性的人类一致性研究。另外，评分稳定性方面，对同一证据重复判定10次的标准差约为0.0037～0.0050，较小，排名不会动摇。此外，引擎仅限于 Godot，多引擎化是未来课题，音声不在评估范围内（仅凭视频评分）。

以下是我（Fukai）阅读后的观察。第一，评估设计依赖于「操作记录（trace）」由智能体本身提交。不提交记录则所有项目未被评估，因此得分低的一部分原因可能反映的不是「制作优秀游戏的能力」，而是「执行提交指定证据这项工作的能力」。实际上零分的5道课题正是这种情况。第二，最终评分由 AI 判定，衡量的是可观察需求的满足度，而非「趣味性」的核心。作为完成度的代理指标是合理的，但将其解读为「趣味性的测量」则过度解读，我认为。第三，出现的模型名称（Opus-4.7、GPT-5.5 等）均按原文引用，这些数值是特定时间点、特定设置下的观察，应作为「此时此刻的观察」来读取。

Fukai 的解读

以下是我（Fukai）的解释。我希望将这项研究置于「谈论游戏生成 AI 的语言，从『好看的演示』向『可游玩的一贯系统』转移」这一趋势之中。以设计批评的词汇来说，这接近于将「作为完成品的游戏」这一单位，用启动・操作・观察这一运用链重新连接，并可视化这条链断裂之处的尝试。最具启示性的是，能力并非铁板一块，可以部分分解（论文报告机制与内容的相关性 r=0.61，机制与画面显示 r=0.53，精加工联系较弱）。这在我看来，意味着将委托给 AI 的工序分解为「机制」「内容」「易读性」「精加工」，分别给予不同支援的分工设计是现实可行的。这只是一种读法，但我认为在思考游戏制作流程时是有用的地图。

结语

本文力求仅凭阅读就能把握要点，但为想深入了解的人留下地图。GameCraft-Bench 与作者们自己列为比较对象的 OpenGame-Bench、GameDevBench，以及同期的 WebGameBench 并排阅读，可以立体地看清「各自试图测量什么」的差异。如果熟悉评估框架 MDA（Mechanics・Dynamics・Aesthetics，将游戏以机制・动态・美学体验三层来把握的经典分析框架），也能注意到四个评分维度与其系谱相关。演示和课题数据可从作者们的公开页面追溯。如果追踪让 AI 制作游戏的话题，建议除了华丽的完成演示视频之外，也持有「如何测量」的这类论文一篇，脚下会更稳。

参考文献

本文参考的论文与相关资料：

・GameCraft-Bench: Can Agents Build Playable Games End-to-End in a Real Game Engine? (Luo, Wang, et al., 2026, arXiv preprint arXiv:2606.17861)

・论文 PDF 版

・GameCraft-Bench 项目页面（演示・代码・数据）

・DOI: 10.48550/arXiv.2606.17861（arXiv 发行 DOI。预印本阶段，尚未正式发表于同行评审期刊）