这项由南开大学、上海创新研究院、Alaya Studio和上海人工智能实验室联合开展的研究，于2026年6月以预印本形式发布，论文编号为arXiv:2606.19830，有兴趣深入了解的读者可通过该编号查询完整论文。
如果你曾经玩过电子游戏，或者听说过"AI写代码"这件事，你可能会好奇：AI能不能帮人做出一款完整的游戏？不是那种简单的小网页游戏，而是像真正的独立游戏开发者那样，用专业的游戏引擎，从零开始搭建一整个游戏项目？这个问题听起来很美好，但在这项研究之前，没有人能真正回答它——因为既没有足够的数据，也没有靠谱的方法来评估AI到底做得怎么样。
这支研究团队决定啃下这块硬骨头。他们的核心想法颇为巧妙：游戏圈里每年都有一种叫做"游戏马拉松"（Game Jam）的活动，参赛者要在48到72小时内从零造出一款完整游戏，而且大多数人都会把自己的作品开源。这些项目就像是大自然馈赠的"野生数据集"——数量庞大、真实可靠、覆盖各种类型的游戏设计。研究团队以此为起点，构建了迄今为止第一个专为专业游戏引擎设计的项目级代码数据集和测试基准，分别命名为JamSet和JamBench。
一、游戏开发的AI盲区：为什么这件事特别难
要理解这项研究的意义，不妨先看看AI在游戏开发领域的现状。在游戏美术方面，AI已经能生成漂亮的像素图和贴图；在游戏规则设计方面，也有模型在探索关卡生成和对话设计。但如果你把目光放到游戏的"骨架"——也就是支撑整个游戏运行的代码框架——情况就截然不同了。
这里有两个相互纠缠的难题，就像是鸡和蛋的关系。第一个难题是评估。普通的软件开发里，你可以写一段测试代码，喂给程序一些输入，看它输出的结果对不对。但游戏不是这样工作的。游戏是动态的、交互式的，同样的操作在不同游戏里会有完全不同的结果，根本没有统一的"标准答案"可以对照。你总不能让AI每次都扮演玩家去真正玩一遍吧？于是现有的方案都有缺陷：让人手写测试脚本，太费时费力，根本无法大规模推广；让另一个AI来打分，又主观又不稳定，今天和明天的标准都可能不一样；用传统的单元测试，又捕捉不到游戏里那些真正重要的运行时行为。
第二个难题是数据。没有可靠的评估方法，就没有办法从海量的开源仓库里筛选出真正高质量的游戏项目。而没有高质量数据，AI的训练就无从谈起。两个问题互相卡住对方，形成了一个死结。
这项研究的突破口，来自一个名叫Godot的游戏引擎。Godot是目前成长最快的开源游戏引擎，它有一个在其他主流游戏引擎（比如Unity或Unreal）里看不到的特性：它的所有项目文件都是纯文本格式。游戏场景文件（.tscn）、脚本文件（.gd）、项目配置文件（.godot），统统是人类可以直接阅读的纯文字，没有任何二进制黑盒。这对AI来说简直是天赐良机，因为现在的大语言模型天生就擅长处理文本。更重要的是，Godot有一个"无头模式"（headless mode），可以在没有显示器、没有图形界面的服务器上直接运行游戏并收集数据，这就为大规模自动化测试提供了可能。
二、从24万个仓库里淘金：数据集是怎么造出来的
研究团队的数据收集工作，规模相当惊人。他们从Ludum Dare、itch.io、Global Game Jam等游戏马拉松平台，以及GMTK Game Jam、Godot Wild Jam、GitHub Game Off、Brackeys Jam等更多平台，加上GitHub的大规模搜索，总共拿到了约24万个候选仓库。
当然，24万个不等于24万个高质量项目。研究团队首先做了一番相关性分析，拿出1872个同时有Ludum Dare评分和GitHub仓库的项目，看看游戏代码量和玩家评分之间有没有关系。结果发现，两者之间有相当可观的正相关性，相关系数达到0.445，并且在代码量低于1200行时，游戏评分会出现一个明显的断崖式下跌。基于这个发现，他们设定了两个基本门槛：游戏本身的代码量至少要有1200行，而第三方插件的代码量要低于1000行，防止项目靠外挂库充门面。
通过这两个预筛选条件，24万个候选仓库缩减到了37638个，然后再进行三个级别的自动化验证。第一关检查文件完整性，看看项目的基本结构是不是完整的。第二关进行编译验证，用Godot引擎实际编译这个项目，看有没有语法错误、类型错误或者缺失资源。第三关把游戏实际运行30秒，确认它不会崩溃、不会卡死、不会和引擎版本不兼容。最终通过这三关的有8549个项目，淘汰率高达96%——这说明开源游戏仓库里的噪音有多大，随便拿来的项目十有八九都是烂摊子。
研究团队没有就此停步。他们又对这8549个项目做了一轮"行为数据收集"的第四关验证：用自动化程序在无头模式下运行游戏60秒，收集游戏的运行时行为数据。其中有416个项目在60秒内没有产生任何有意义的行为变化，被归类为"沉默项目"排除掉。剩下的8133个项目，就构成了整个数据集的基础。
这8133个项目按代码量分为三档：4000行以下的是小型项目，共4356个；4000到15000行之间的是中型项目，共3145个；15000行以上的是大型项目，共632个。游戏类型跨越了40多个品类，其中平台跳跃类最多，超过2300个，其次是模拟经营类、动作类、射击类、解谜类等等。
从中随机抽取的300个项目，经过人工实际上手游玩3到5分钟验证，全部通过，形成JamBench基准测试集。剩余7833个项目则被加工成训练数据，构成JamSet训练集。
三、给每个游戏贴上"说明书"：结构化标注怎么做的
数据收集完还不够，研究团队还要给每个项目做详细的结构化标注，这些标注信息后来成为评估和训练的关键。
每个项目都会自动生成一份"项目清单"（manifest.json），通过静态代码分析提取出脚本列表、场景树结构、输入映射、全局脚本配置和场景跳转图，这些信息完全不需要人工介入。
在此基础上，研究团队借助大语言模型生成了"游戏描述"（game_description.json），包含游戏玩法说明和类型分类。他们还从Ludum Dare、Global Game Jam、GMTK等平台收集了108个真实的游戏马拉松主题，通过语义相似度匹配，最终保留了89个能与数据集项目对应起来的主题。
另一份关键文件是"评估配置"（eval_config.json），同样由大语言模型生成。它负责识别每个游戏里的玩家节点是谁、分数和生命值在哪里跟踪、有哪些关键的游戏信号、哪些场景是菜单界面哪些是真正的游戏关卡。这份配置直接驱动后续的自动化行为收集——告诉程序要往哪里发送按键输入，期待看到什么样的游戏反应。
还有一份"资产标注"（asset_annotations.json），用视觉语言模型和规则方法结合，对游戏里引用的图片、音频、字体等571941个资产文件逐一打上语义标签，方便训练数据里的AI理解这些资产是什么用途。
四、用什么标准衡量AI做出的游戏好不好
有了数据，还需要一把靠谱的尺子来量。研究团队设计了一套两维度的评估体系，从静态结构和动态行为两个角度衡量AI生成的游戏质量。
第一个维度叫做"结构完整度分数"（Structural Completeness Score，简称SCS）。打个比方，SCS就像是验收一栋房子时，检查员拿着清单逐项核对：有没有足够的房间（脚本数量）、有没有合理的楼层结构（场景数量）、插座开关设计得够不够（输入动作数量）、每个房间的功能有没有实际实现（函数数量、非空函数比例）等等，总共7个维度。每个维度把AI生成的数值和参考值做比较，最终算出一个0到1之间的综合分数。在代码补全任务里，参考值就是原项目的真实数值；在从零创作任务里，参考值是同类游戏的数据集均值。
第二个维度叫做"行为对齐分数"（Behavioral Alignment Score，简称BAS）。如果说SCS是看房子图纸画得对不对，BAS就是把人关进房子里住几天，看看电灯能不能开、水龙头有没有水、暖气管不管用。BAS通过实际运行游戏60秒，收集7个数值型维度（节点增加数、节点减少数、位置变化数、事件计数、速度活跃帧数、响应动作数）和1个集合型维度（信号触发类型重叠度），与原项目的真实行为数据做对比，计算相似程度。
这两个分数是互补关系：如果一个项目SCS低但能编译通过，说明代码只是个空架子；如果SCS高但BAS低，说明代码结构看起来完整，但实际运行时游戏根本没有正确的互动表现。只有两个分数都高，才说明AI做出来的游戏是真正可用的。
五、自动运行游戏60秒：神奇的行为收集机制是怎么工作的
如何在完全没有人操控的情况下，让一个程序自动"玩"各种不同的游戏60秒，并且保证每次运行结果完全一致，是这项研究在工程层面最有意思的挑战之一。
研究团队设计了一个三层架构来解决这个问题。第一层是离线预处理：在正式运行游戏之前，先用大语言模型分析项目清单，生成那份评估配置文件。这一步只需要做一次，结果固定不变。
第二层是纯规则驱动的输入策略生成：根据评估配置里的游戏类型、期望行为和输入映射，用完全确定性的规则生成一份"操作剧本"（input_strategy.json），里面写明了该按哪些键、点哪些位置、以什么节奏循环。平台跳跃游戏的操作剧本里，60%的时间在左右移动，25%在跳跃，15%在攻击；射击游戏则混合使用键盘移动和鼠标点击；解谜游戏主要用鼠标点击交互节点，以此类推。这一步完全没有任何AI参与，纯粹是规则映射，所以结果是百分之百可复现的。
第三层是实际的运行时执行。程序按照操作剧本，先用前10秒处理游戏主菜单——程序会扫描场景里的按钮节点，按照"Play→Start→Begin→..."的优先级排序，然后依次尝试三种方式来点过菜单：直接触发按钮的pressed信号、模拟鼠标点击按钮位置、注入Enter或Space键。一旦检测到场景切换到了游戏关卡，就进入后50秒的正式游戏阶段，按照操作剧本循环发送输入，同时持续收集7个维度的行为数据。
为了防止游戏在收集过程中暂停导致数据丢失，程序的收集脚本被设置为永远不受游戏暂停影响，并且每帧都会检测并强制解除暂停状态，同样危险的操作比如按Escape退出也被从操作剧本里排除。
菜单处理是这里面最棘手的部分。游戏马拉松作品的菜单千奇百怪：有31.2%的游戏根本没有主菜单，启动就直接进游戏；有52.4%有一个简单的单屏菜单，里面有"开始游戏"按钮；还有16.4%是复杂的多层菜单，夹杂着动画过渡、设置界面、角色选择等等，需要三种方案轮流尝试才能顺利通过。
六、基准测试任务长什么样：考试题目怎么设计的
JamBench定义了两大类考题，用来测试AI在游戏代码生成方面的能力。
第一类叫做"主题驱动创作"（Task 1）：给AI一个游戏马拉松主题，让它从零开始造出一款完整的Godot游戏项目。测试集包含50个来自真实游戏马拉松的主题，每次实验重复三次取平均值。其中任务1a只给一个主题关键词（比如"困在循环里"），任务1b在主题之外还提供一段游戏玩法描述，用来区分"想出创意"和"实现工程"这两种能力。
第二类叫做"多粒度代码补全"（Task 2）：拿一个真实的游戏项目，把其中一部分代码删掉，让AI补全缺失的部分。这一类按照删除粒度分成三个级别。2a级是函数级：随机清空30%到50%的函数体，只留下函数签名，让AI补全函数内部逻辑。2b级是脚本级：随机移除30%到50%的脚本文件，让AI从头写出这些脚本的完整内容。2c级是全脚本级：把所有脚本文件全部删除，只保留场景文件，让AI重建整个代码层。测试集就是那300个经过人工验证的基准项目，每个项目都跑三个粒度的测试。
七、九个顶尖AI模型的实际表现：差距有多大
研究团队用JamBench对9个顶尖的大语言模型进行了全面测评，包括Claude Opus 4.6、GPT-5.4、Gemini 3.1 Pro、Kimi K2.5、DeepSeek V4 Pro、Qwen3.5-397B、GLM-5，以及更小的Qwen3.5-27B。此外还测试了5种"代码智能体"配置，也就是用Claude Code作为框架，让模型在迭代调试的循环里反复修改自己的输出。
从零开始创作游戏的表现，大致令人满意但不令人兴奋。在任务1a（只给主题）里，能顺利通过三关验证（文件完整、能编译、能稳定运行30秒）的比例，顶尖模型平均在70%左右，其中Gemini 3.1 Pro达到了78.7%。但SCS和BAS的分数就没那么好看了——绝大多数模型的SCS在0.28到0.46之间，BAS在0.09到0.17之间。换句话说，大多数模型能做出一个能跑的空壳，但游戏的实质内容远远不够。
当研究团队给模型额外提供玩法描述（任务1b）时，出现了一个有趣的权衡：大多数模型的SCS和BAS分数提升了，说明玩法说明确实帮助模型做出了更完整的游戏设计，但编译通过率却下降了，说明描述越详细，模型要实现的东西越多，出错的机会也越大。
代码补全任务的结果，暴露出一个更严峻的规律。在小型项目上，顶尖模型的运行通过率（L3a）还能保持在80%左右，SCS在0.90以上，BAS在0.60到0.71之间，表现相当不错。但一旦项目规模扩大到大型，所有指标都断崖式下跌：运行通过率跌到5.7%附近，SCS跌到0.50左右，BAS跌到0.50以下，Qwen3.5-27B这种规模更小的模型在大型项目上的函数级补全里甚至全军覆没，通过率直接归零。这种随项目规模增长而急剧恶化的现象，研究团队称之为"能力断崖"。
在不同粒度之间，有一个反直觉的发现：脚本级补全（2b，删掉更多内容）的编译通过率，反而比函数级补全（2a，删掉较少内容）更高。原因在于，函数级补全要求AI严格遵守原有的函数签名、变量命名和调用接口，稍有偏差就会导致编译失败；而脚本级补全允许AI从头重写整个文件，内部逻辑只要自洽就行，限制更少，反而更容易通过编译。但从SCS和BAS来看，2a的分数高于2b，因为2a保留了更多原始代码，结构完整度自然更高。这说明补全粒度和难度之间的关系并不简单，更精细的补全要求更强的上下文感知能力。
八、代码智能体能否突破瓶颈：令人意外的答案
代码智能体的测试结果，是整项研究中最发人深省的发现之一。
在任务1a里，给Claude Opus 4.6加上智能体框架之后，它的运行通过率从77.3%提升到了82.7%；DeepSeek V4 Pro从72.7%提升到84.0%。这个提升看起来挺可观的。但SCS几乎没变（Claude：0.41对0.42），BAS也几乎没变（Claude：0.11对0.13）。智能体花了大量时间和算力在迭代调试上，但最终做出来的游戏在质量层面和直接输出相比毫无区别。
在代码补全任务里，这个模式更加突出。在中型项目的脚本级补全里，加上智能体后Claude的运行通过率从62%跳升到76%，DeepSeek从58%升到73%，看起来进步巨大。但SCS和BAS几乎原地踏步：Claude的BAS从0.36变成了0.37，SCS从0.61变成了0.62。
这个现象说明了什么？智能体的迭代调试机制，擅长修复的是语法层面的问题——漏了一个括号、引用了不存在的变量、类型不匹配等编译器会报错的问题。但游戏工程的真正难点不在这里，而在于架构设计——多个文件之间的接口契约是否协调、场景的节点树设计是否合理、全局状态是否被正确管理、游戏逻辑的流程是否符合玩家的交互预期。这些问题不会触发编译错误，智能体的迭代循环看不到它们，当然也就无法修复。编译能通过，不等于游戏能好玩，更不等于代码架构是正确的。
九、AI和人类开发者的思维方式有什么不同
研究团队在分析实验结果时，发现了模型生成代码和人类游戏开发者写的代码之间有一些系统性的差异，这些差异揭示了AI在游戏工程层面的理解盲区。
第一个显著差异是输入抽象。在真实的Godot游戏项目里，开发者平均会定义6.9个自定义输入动作（比如给"jump"、"move_left"、"attack"分别定义一个抽象动作名称，再把具体按键绑定到这个名称上）。这种做法的好处是，如果以后想改按键配置，只需要改一处定义，所有用到"jump"的地方自动更新。但AI生成的代码里，自定义输入动作的数量接近于零，模型倾向于直接硬写按键代码（比如直接检测空格键是否被按下），而不是用这种间接抽象的方式。
第二个差异是全局状态管理。真实项目里有76.3%使用了自动加载脚本（autoload）来管理跨场景共享的全局状态，比如玩家的分数、已解锁的关卡、游戏设置等。AI生成的代码则倾向于把所有逻辑堆在单个脚本里，不用autoload，导致不同场景之间很难共享信息。
第三个差异是场景切换设计。真实项目里多数都有完整的场景切换机制，但AI生成的项目里场景切换功能的使用率很低，生成的游戏往往只有一个单一场景，缺乏从菜单到游戏、从游戏到结算界面的完整流程。
这些差异说明，模型学会了"让代码能跑"，但没有学会"按照专业游戏开发的惯例来写代码"。这是两件完全不同的事。
十、用真实项目训练之后，AI会变聪明吗
研究团队用JamSet对Qwen3.5-27B进行了微调实验（得到了Qwen3.5-27B-SFT模型），来验证这份训练数据到底有没有实际价值。
结果是积极的。微调后的模型在任务1a里，编译通过率从66.0%提升到70.7%，SCS从0.27提升到0.34。更重要的是，那些工程习惯层面的差异也开始改善：自定义输入动作数量从平均0.08个上升到3.44个，autoload使用率从55.1%上升到77.1%，场景切换的使用率从18%上升到49.4%。这说明用真实游戏项目训练，确实能让模型学到人类游戏开发者的工程习惯，而不只是学到能跑但不合规范的代码写法。
在代码补全任务里，微调后的模型在小型项目上的表现和基础版本差距不大，但在中型和大型项目上，SCS和BAS都有一定幅度的提升，说明领域专属训练数据在处理复杂项目时的价值更为突出。
不过这个微调实验规模有限，研究团队使用的是LoRA（一种参数高效的微调技术），训练数据只包含小型和中型项目（因为大型项目的训练数据单条就超过了32768个词元的截断限制），所以这个结果更多是一个概念验证，而非完整的模型训练方案。
十一、三个典型失败案例：AI到底败在哪里
研究团队挑了三个案例来具体说明AI目前的失败模式。
第一种叫"空架子游戏"。DeepSeek V4 Pro和Qwen3.5-397B都做出了能通过三关验证的项目，但SCS分数极低。具体看Qwen的项目，里面有个看起来很厉害的"地形管理器"脚本（129行），还有个"界面管理器"（119行），但核心的"玩家控制器"脚本只有2行代码，什么游戏逻辑都没有实现。这证明了仅靠编译通过率是骗不了人的，SCS和BAS是必要的补充。
第二种叫"引擎语法盲区"。Claude Opus 4.6在一次脚本级补全任务里，设计了一个把驼峰命名法转换为下划线命名法的算法，逻辑完全正确，用通用编程思路来看无懈可击。但代码在Godot里根本编译不过，因为在GDScript（Godot的脚本语言）里，字符串的下标访问有特殊的类型限制，和通用编程语言的习惯不一样。这种引擎特有的语言细节，在现有训练数据里极为罕见，模型没有机会学到。
第三种叫"跨文件接口漂移"。Kimi K2.5在补全一个摄像机抖动效果脚本时，写出了功能等效的实现，能编译，也能运行。但它用了和原始版本不同的变量命名——原始代码里有shake_pwr和shake_stbl这两个变量，被其他脚本引用来控制摄像机缩放和瞄准辅助功能；而Kimi的版本把这两个变量改名成了shake_intensity和shake_decay。这个改动不会触发任何编译错误，但其他脚本读取这两个变量时就会失败，游戏的缩放和瞄准功能就会悄无声息地失效。这解释了为什么Kimi在这个项目上的SCS是0.56（代码结构看起来完整），但BAS只有0.27（实际运行行为有大量缺失）。模型能把单个模块写对，但无法感知并保护跨文件的隐式接口契约。
说到底，这项研究做了一件有点像考古挖掘的事情：从24万个满是噪音的开源仓库里，一层一层地筛，一关一关地验，最终提炼出8133个真正可用的游戏项目，建起了这个领域第一座像样的基础设施。它告诉我们，今天的顶尖AI在处理小规模游戏代码时已经有了不错的基础能力，但一旦项目变大，能力就会断崖式下跌。代码智能体能修补语法问题，但改变不了架构设计的短板。用真实项目训练确实能让AI学到工程习惯，但还远未达到替代人类开发者的水平。
对于普通游戏爱好者来说，这意味着AI辅助游戏开发目前还处在"帮你写小功能脚本"的阶段，距离"帮你做完一整款游戏"还有相当长的路要走。对于研究者来说，JamSet和JamBench提供了一个可复现、可扩展的测试平台，未来改进训练方法、探索更好的代码架构提示方式都有了具体的着力点。有兴趣深入了解这项研究的读者，可以通过arXiv编号2606.19830查阅完整论文。
Q&A
Q1：JamBench是什么，和普通代码测试基准有什么区别？
A：JamBench是专门针对Godot游戏引擎的项目级代码生成基准测试集，包含300个经过人工验证的真实游戏马拉松项目。与普通代码测试基准（通常用单元测试验证函数输入输出）不同，JamBench通过实际运行游戏60秒来收集运行时行为数据，并用结构完整度分数（SCS）和行为对齐分数（BAS）两个维度来评估AI生成的游戏质量，能捕捉到普通单元测试无法发现的游戏互动行为问题。
Q2：为什么AI代码智能体提升了编译通过率，却没有提升游戏实际质量？
A：代码智能体的迭代调试机制主要针对编译器能检测到的问题，比如语法错误、变量引用错误、类型不匹配等。但游戏质量的核心问题在于架构设计层面，比如多个文件之间的接口是否协调、场景节点树设计是否合理、全局状态管理是否规范。这些问题不会触发编译报错，智能体的反馈循环感知不到它们，自然也就无法修复，所以行为对齐分数（BAS）和结构完整度分数（SCS）几乎没有改善。
Q3：用JamSet训练之后，AI的游戏工程习惯具体改善了哪些方面？
A：微调后的Qwen3.5-27B-SFT在三个工程习惯指标上有明显改善：自定义输入动作数量从平均0.08个上升到3.44个，说明模型学会了用抽象输入动作而非硬编码按键；autoload全局脚本的使用率从55.1%上升到77.1%，说明模型开始用正确的方式管理跨场景共享状态；场景切换功能的使用率从18%上升到49.4%，说明生成的游戏项目有了更完整的场景流程设计。
热门跟贴