247 道考题测 AI 做游戏：最强模型只拿 59.68 分，「能跑」和「能玩」之间隔着一条鸿沟
要点
上海交大等机构发布 SWE-Game 基准：41 款 Godot 游戏拆出 247 道考题实测六个 AI 模型，最强模型修 bug 拿 83 分，从零建游戏全都不及格。
让 AI 独立做一款游戏，它会先做什么？大概率是先把角色放进场景，让玩家能走能跳——然后故事就卡住了：尖刺看得见，踩上去没反应；通关画面能弹出来，玩家什么都没做就触发了。这不是段子，而是上海交大等机构的研究者在系统性测试 AI 编程能力时真实撞见的问题。他们把结果做成了一份基准测试，名字叫 SWE-Game：41 款真正能玩的 Godot 参考游戏，拆出 247 道考题，让六个当时最先进的 AI 模型同台应考。结论写在分数里——即便是全场最强的 Opus5，在三类「从零构建游戏」的任务中，最好成绩也没能突破 60 分（满分 100）。
这份基准的 arXiv 编号是 2609.33678，由 Xiaoyu Chen、Weiran Huang 等 11 位作者完成，9 月 27 日提交、10 月 7 日完成修订，随后被 Hugging Face Daily Papers 收录。它要回答的问题听起来简单，做起来极其棘手：游戏这种软件太特殊了，它活在玩家的操作里。一般的代码任务写个函数、跑个单元测试，对错一目了然；但「角色该不该碰到尖刺就死」这件事，没法靠看代码片段判断——你得真的操纵角色走过去撞一下，看它是不是真的死了。
为此，研究团队先造了一个「标准答案库」：41 款横跨 2D 和 3D、涵盖射击、平台跳跃、解谜、策略、模拟经营等 13 种玩法的可执行游戏，代码总共 16.8 万行，场景文件 1587 个，节点 2.2 万多个，还配套了 138 段真实游戏录像。每款游戏都走了正规流程——先用 Kenney 这类现成素材包定视觉风格，写详细的游戏设计文档固定目标与规则，再按「引入、变化、组合」的节奏设计关卡。247 道考题分五种类型，对应真实开发的不同处境：只给一句话需求从零建游戏（Brief-to-Game）、照着完整设计文档实现（GDD-to-Game）、往半成品骨架里填玩法逻辑、修复 83 个「能跑但行为不对」的注入故障，以及把 Godot 游戏原样移植到 Unity。
整篇论文技术含量最高的部分，是让评测能「真的玩一遍」游戏的机制。不同 AI 做出的游戏，内部命名五花八门——甲的玩家叫 Player，乙的叫 MainChar。SWE-Game 的解法是让提交方自己「翻译」：在约定文件里声明关卡和结局，用 gbplayer、gbhazard 这类标签给对象打上语义角色，把血量、进度、分数绑定到约定字段。评测程序由此能用统一驱动程序操纵任何一款提交上来的游戏。更妙的是那个「无操作对照组」：让游戏在不接收任何输入的情况下也跑一遍，如果这样它还能自己弹出胜利画面，这条「通关证据」就是假的——没有这个设计，AI 完全可以在代码里埋个 30 秒计时器，用最省力的方式骗过表面检测。
考完的分数结构，比总分本身更值得琢磨。Opus5 在全部五种任务里都拿了最高分：漏洞修复 83.46 分、引擎移植 72.40 分，但三道构建题——简报生成 50.38、设计文档实现 59.68、骨架补全 54.06——全部没过 60 分线。差距的方向很明确：让 AI 在已有框架里定位并修复一个具体问题，它已经相当熟练；让 AI 从零设计并实现一整套自洽的游戏机制，它还差得远。
更有信息量的是失败归因。研究者把实现问题归为七类，不同模型的踩坑方式截然不同：GPT 系模型超过一半的问题（56.4%）是「需求遗漏」——压根没把需求文档里要求的东西做出来；GLM 系模型则相反，52.2% 的问题是「玩法逻辑错误」——认真做了但做错了。这像两种不同类型的粗心考生：一种看漏了题整道大题空着，另一种认真答题却算错了结果。前者指向长文档需求追踪能力的短板，后者指向运行时逻辑推理的欠缺——想针对性改进哪个模型，药方可能完全不一样。
评测系统自身的可信度也做了核验：研究团队从 100 款 AI 制作的游戏里抽取 1200 条人工标注行为，可执行检测的平衡准确率达到 92.59%，而基于视频的视觉语言模型判断只有 78.41%——在「发现真实缺陷」上差距更大，94.25% 对 75.40%，差了将近 19 个百分点。视觉那一侧单独验证：658 条评分规则交 VLM 打分，与 200 段录像的人类评分相关系数 0.829。分工原则由此清晰：判断游戏逻辑对不对，交给可执行测试；判断游戏好不好看，交给视觉模型。
不过，把这份基准当成「AI 游戏开发能力排行榜」来读，几位独立评析者都提醒要小心。Pixelwolf 指出，每个模型只搭配了一个 agent 框架，分数测的是「模型+工具+工作流」的组合，没法把功劳单独记在模型头上；41 款参考游戏也不代表大型项目或数月迭代的真实制作周期。徐康的评析更直接：论文没有公布其余模型的名称与分差，修复和移植的具体分数也未给出，「不必把 Opus5 的领先解读成产品级结论」，适用边界应当写死在 Godot 参考实现与五类任务之内。ByteNote 还注意到一个细节：基准与代码尚未在论文页挂出链接，第三方复验暂时无从谈起。
在 AI 能力评测的版图上，SWE-Game 的真正贡献可能不是又一张排行榜，而是一次评测思路的升级：从检查「代码能不能跑」转向验证「软件行为对不对」。CCTest 的评析将其概括为从「代码生成」到「软件行为验证」的转变——游戏是个有代表性的压力测试场：需求用自然语言表达，正确性要通过交互体现，错误可能只在特定操作序列下才暴露，单看源代码或一段演示视频都容易漏掉。同期工作里，WebGameBench 靠浏览器交互评网页小游戏，GameLogicBench 靠引擎内状态断言测机制——后者还发现许多失败的提交照样能运行，恰恰说明「看起来完成」和「真的能玩」之间的裂缝有多普遍。
所以，AI 建的游戏现在到底能玩吗？答案是：修补型的活干得像模像样，创造型的活还差着一场硬仗。对想把 AI 编程助手用进开发流程的团队，这份基准给出的最实用建议也许不是分数，而是那个无操作对照组背后的道理——验收一个 AI 交付物，永远要问一句：这件事是不是真的发生了，还是只是看起来发生了。至于「AI 独立做出一款逻辑严密又好玩的游戏」的那一天，按这份成绩单倒推，它得先学会一件更难的事：不是把游戏做得「看起来对」，而是真正理解一个机制为什么该这样运转。
—
