Jiang 等：仅凭语言能否生成「可玩的游戏」——Fukai 读 OpenGame

一段摘要

游戏开发是创意设计与复杂软件工程的交汇点。大型语言模型（LLM）擅长编写单一代码，但面对「从一句描述生成一个完整可玩游戏」时往往力不从心。本文介绍的 OpenGame 是一个开源智能体，旨在从自然语言规格出发，自动生成可在浏览器中游玩的完整2D网页游戏。

核心在于 Game Skill 的概念——由「项目骨架模板」（Template Skill）与「持续积累的调试手册」（Debug Skill）组合而成，使智能体能在稳定的基础上构建游戏，并系统化地修复集成错误。据作者报告，在150个游戏课题的评测中，OpenGame 达到了新的最高水准，并超越了 Cursor 等主要比较对象。

引言

本论文的第一作者是 Yilei Jiang，来自香港中文大学（CUHK）MMLab 团队。来源为 arXiv:2604.18394，于2026年4月20日发布的预印本（预印本指未经期刊或会议同行评审即公开的原稿），归类为软件工程（cs.SE）。即，目前尚非经过同行评审的正式论文，讨论仍在进行中。

我今日选择这篇论文，是因为它正面回答了一个对 Puzzlebyrinth 读者——真正在制作游戏和谜题的人——而言具有现实意义的问题：「如果用语言告诉 AI『做一个这样的游戏』，能否得到一个完整可玩的成品？」不是生成代码片段，而是生成启动即可游玩的完成品。它带着数据，展示了这有多难，以及目前已走到哪里。

背景

近年来，LLM 与基于它的「代码智能体」在解决单独的编程课题方面进步惊人，正如 SWE-bench 等基准测试所示。但游戏与普通实用软件性质不同，作者指出：可玩游戏是持续运行的实时系统，包含更新循环、物理、事件处理和素材（资产），各部分必须无缝协作。

作者列举了最先进模型在尝试生成完整游戏时反复出现的三类失败。其一是逻辑不一致，导致游戏卡死、无法结束或核心机制失效。其二是缺乏引擎专有知识，绕过引擎内置组件，从头重写物理等系统。其三是文件间不一致，各文件单独看似乎完整，但组合时无法协同工作。

为何这个问题重要？降低游戏开发门槛——将文字构想直接转化为可玩形式——是创作领域长期以来的愿望。然而同时掌握引擎结构、编程语言和脆弱的集成工作，门槛始终难以降低。OpenGame 可以理解为通过专门化智能体跨越这道墙的尝试。

方法

OpenGame 将目标锁定在 Phaser——一个可以仅用 JavaScript 编写2D网页游戏的开源框架。Unreal 或 Unity 等业界标准引擎依赖专有的界面操作和二进制格式，对以文字交互的 AI 而言难以处理。而 Phaser 可以完全用代码表达，因此成为智能体的理想实验场——这是作者的判断。

核心是可复用的能力模块 Game Skill，由两个部件构成。其一是 Template Skill：最初仅从「不预设任何类型的最小骨架」出发，每完成一个课题后，从中提取可稳定复用的代码片段，存入模板库。据作者介绍，这一过程自然形成了五大模板系列：横版重力系、俯视连续移动系、网格系、物理碰撞系、UI 管理系。

其二是 Debug Skill：不是固定的检查清单，而是根据构建和运行结果持续更新的「活的手册」。每次出现失败，就将错误特征、根本原因和经验证的修复方法逐一记录，并在下次课题中复用。此外还配备了轻量级预编译检查，用于提前发现历史上常见的不一致（素材名称不匹配、配置项缺失、场景切换错误等）。调试知识得以积累并持续沉淀——这正是与通用代码智能体的本质区别。

底层模型也经过专门训练。GameCoder-27B 以 Qwen3.5-27B 为基础，经三阶段训练：首先是继续预训练（CPT，向现有模型进一步输入 Phaser 和 JavaScript 游戏相关文本，建立领域直觉），其次是监督微调（SFT，用高质量的问答对训练将创作意图转化为代码的能力），最后是基于执行结果的强化学习（RL，以实际游戏运行结果作为反馈信号进行优化）。

发现

评测采用名为 OpenGame-Bench 的专用框架进行。覆盖5个类型（横版、俯视射击、谜题、经典街机、策略）共150个课题，通过无头浏览器实际运行游戏，从构建健康度（Build Health）、视觉可用性（Visual Usability）、意图一致性（Intent Alignment）三个维度评分。

主要结果如下。以 Claude Sonnet 4.6 为推理引擎的 OpenGame，构建72.4、视觉67.2、意图一致65.1，据论文称创下新的最高水准。最强的比较对象 Cursor（Claude Sonnet 4.6 版，66.8・61.4・58.9）分别被超出5.6・5.8・6.2分。专门训练的 GameCoder-27B 在构建健康度上也超越了未专门训练的同规模通用模型。

逐一移除各组件的消融研究同样引人关注。去掉仅替换固定接口的钩子驱动实现方式（Hook-Driven Implementation）、改为从头编写后，构建分下降10.1分、意图一致下降11.6分，致命缺陷频发。作者认为这是最重要的机制。此外，自动修复循环在允许迭代次数为零时构建分为58.7，随着允许次数增加而稳步提升。

本文特别想强调的是各类型意图一致的细分数据。横版76.8、俯视射击71.4表现较高，而策略58.2、谜题/UI 52.6则明显偏低。作者解释，谜题类游戏的玩法依赖于「逻辑状态」（如库存管理或消除规则），与视觉表现的关联较弱，即便出现偏差也不会在画面上产生异常，形成「静默失败」，导致自动调试难以发现。实际上

实际用途

那么，对于制作游戏和谜题的人来说，这项研究有何实际意义？举几个例子。其一：如果你想大量原型化小型网页谜题，OpenGame 式的「模板+接口」思路直接有效。不是每次让 AI 从零开始，而是先固定好网格逻辑（谜题系列的稳定骨架），只替换盘面大小和胜利条件，就能快速迭代出不易崩溃的原型。即便不使用 AI，这一思路本身也值得借鉴。

其二：如果你想为超休闲游戏大量生成关卡或小品，可以借鉴 Debug Skill 的「逐条记录失败特征・原因・修复方法」思路，在自己的项目中建立缺陷台账。仅需在编译前加入针对反复出现的集成错误（素材名称不匹配、配置项缺失等）的轻量检查，生成流水线的良率就会提升。

其三：如果你想评估 AI 辅助游戏制作工具，OpenGame-Bench 的评测维度——分别衡量构建健康度・视觉效果・意图一致性——可作参考。不是「能运行还是不能运行」的二择，而是能区分「编译通过却无法游玩」「视觉华丽却不符合指示」等不同质量的失败。这可以成为评价自家工具优劣的共同语言。

此外，谜题/UI 表现最差这一结果本身就是对制作者的警示。如果要将工作交给 AI，就需要自己准备能检测出视觉上不可见的逻辑偏差的机制——状态记录，或将规则违反可视化的调试显示。

局限性

我们也应坦率地审视局限性。首先是作者自身承认的部分：研究对象限于使用 Phaser 的网页2D游戏，Unreal 或 Unity 等商用引擎，或3D及大规模作品不在射程之内。此外，即便是表现最好的配置，约34.9%的需求仍未达成，尤其是谜题和策略中的「静默逻辑失败」，自动修复尚无法解决，被明确列为今后课题。

Fukai 在此想指出的是评测独立性的问题。视觉和意图一致性的评分使用了 VLM（Vision-Language Model，能同时处理图像和文本的 AI）来判定。也就是说，这是「AI 制作的成果由另一个 AI 来评分」的结构，人类玩家实际感受到多少乐趣、界面是否易懂，并未被直接衡量。作者也加入了部分人工验证，但最终得分的核心仍依赖自动判定。

还有一点。GameCoder-27B 单独的性能提升较为温和（三阶段训练后构建分从62.8升至63.9），作者自己也表示，改善的大部分来自框架层面而非基础模型。专门训练模型的性价比，目前仍需审慎评估。

Fukai 的解读

以下是 Fukai 的个人解读。我倾向于将这项研究定位于「制作流程本身的自动化」这一脉络，而非程序性内容生成（PCG）的延伸。如果说传统自动生成产出的是关卡或素材等部件，OpenGame 试图自动化的则是选择骨架、填入接口、出错后修复这一整套——人类设计师在脑中默默进行的制作工序本身。

结语

想要深入了解的读者请注意：OpenGame 属于「让 AI 制作游戏」的研究，与「让 AI 玩游戏」的研究方向相反。如果想要「让 AI 玩游戏」的地图，可以将本站此前介绍的 GVGAI-LLM 论文并排阅读，这样生成与攻略这两个车轮的全貌便会显现。若想了解自动生成的历史脉络，可以参考用语言模型生成关卡的研究（Todd 等, 2023）、以及概览 PCG 与 LLM 接合的综述，此处不再详列。

参考文献

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

・OpenGame: Open Agentic Coding for Games（Yilei Jiang 等，2026，arXiv preprint arXiv:2604.18394）

・OpenGame 项目主页

・OpenGame GitHub 仓库

・相关研究：Level Generation Through Large Language Models（Todd 等，2023）

・相关研究：Procedural Content Generation in Games: A Survey with Insights on Emerging LLM Integration（2024）