你有没有想过，如果让AI独立做一款游戏，它会先做什么？
大概率，它会先把角色放到场景里，让玩家能走能跳，然后……故事就卡在这里了。你会发现尖刺能看见，但踩上去没反应；通关画面能弹出来，但玩家根本没做该做的事就直接触发了。这不是编造出来的场景，而是一群研究者在系统性测试AI编程能力时，真实撞见的问题。
这篇论文的名字叫SWE-Game，来自上海交大等机构的团队。他们想弄明白一件事：现在最强的那些AI编程助手，到底有没有能力把一款"看起来像那么回事"的游戏，做成"玩起来真的是那么回事"的游戏。
**这个问题听起来简单，做起来却极其棘手，原因在于游戏这种软件太特殊了。**
一般的代码任务，你写个函数，跑个单元测试，对不对一目了然。但游戏不一样,它活在玩家的操作里。一个平台跳跃游戏里，角色该不该碰到尖刺就死，这件事没法靠看代码片段判断，你得真的操纵角色走过去撞一下，看它是不是真的死了。
研究团队把这种困境讲得很直白：如果玩家看到通关画面就认为游戏做对了，那也可能是假象,因为也许游戏根本没要求玩家做任何操作，直接弹出了胜利提示。这就是整个评测工作最核心的出发点：不能只看结果长得像不像，得看过程是不是真的发生了。
**核心问题：这游戏做得"真"吗？**
在SWE-Game出现之前，评测AI做游戏的办法大体分两种。一种是让另一个大模型去"看"生成的游戏，给它打分,这种方式类似于请一个美术老师远程批改一份他看不到实物的雕塑作业，只能看照片，判断力天然打折。另一种是写死板的单元测试，判断游戏里某个函数有没有正确返回值，这种方式又太死板，抓不住"动态交互中的逻辑是否自洽"这种更接近游戏本质的问题。
论文里提到的几个同期工作，比如WebGameBench靠浏览器交互评测网页小游戏，GameLogicBench靠引擎内的状态断言来测试机制，各有侧重，但都没能把"设计意图"和"运行时证据"真正打通。
这就是SWE-Game想解决的核心矛盾：怎么让评测既知道"这个游戏本来应该是什么样"，又能亲自"动手"去验证"它现在到底是什么样"。
为了做到这一点，团队没有凭空设计任务，而是先造了41款真正能玩的参考游戏。
第一步：造41款"标准答案"游戏
这41款游戏横跨2D和3D，涵盖射击、平台跳跃、解谜、策略、模拟经营等13种玩法类型，全部用Godot引擎开发完成。
**Godot**：一款开源免费的游戏引擎，常用于2D和3D游戏开发，是这篇论文选择的主力开发工具。
每款游戏都经历了一套很正规的开发流程：先用现成的美术素材包（比如知名的Kenney素材包）搭建视觉风格，然后写一份详细的游戏设计文档，固定目标、操作方式、核心机制、胜负条件,接着按照"引入、变化、组合"的节奏设计关卡,一个机制先单独出现，再在新条件下复现，最后和其他机制混合考验玩家。
拿论文举的"Harvest Ledger"（丰收账本）这个游戏打比方：一开始教玩家种地、收获、卖出农产品，建立一套农场经济循环;随后再引入采集资源和养殖牲畜，这些新玩法会跟玩家本来就不够用的时间和预算打架，逼着玩家做取舍。这不是随手堆功能，而是有意识地设计了一条"由浅入深"的学习曲线。
**游戏设计文档（GDD）**：Game Design Document的缩写，是详细记录游戏目标、玩法规则、关卡结构等设计细节的文档，相当于游戏的"施工图纸"。
这41款游戏最终构成了一套"标准答案库"：代码总共16.8万行，场景文件1587个，节点2.2万多个，配套138段真实游戏录像。这个工作量本身就说明了一件事,要测AI会不会做游戏，首先你自己得先把游戏做"对"，而且做"透"。
第二步：五种任务，覆盖开发的不同阶段
有了标准答案，接下来是设计考题。SWE-Game设置了五种任务模式，总共247个任务，分别对应游戏开发中的不同处境。
第一种叫"简介生成游戏"（Brief-to-Game）。AI只拿到一句话式的项目需求，比如"做一个关于运送能量电池的平台跳跃游戏"，剩下所有设计细节都要AI自己补全，包括先写一份完整的设计文档，再去实现它。这最接近真实世界里，老板丢给程序员一句话需求的场景。
第二种叫"设计文档生成游戏"（GDD-to-Game）。这次AI拿到的是完整详尽的设计文档，不用自己设计，只需要照着文档老老实实实现。这更像是接到了一份详细的需求规格说明书。
第三种叫"骨架补全"（Skeleton Completion）。AI拿到一个半成品项目，里面已经搭好了场景结构、输入绑定、基础代码框架，但核心玩法逻辑是空的，等着AI去填。
第四种叫"漏洞修复"（Bug Repair），一共83个案例。AI拿到一个"能跑起来但行为不对"的项目，附带一份玩家视角写的问题报告，比如"按跳跃键没反应"，但报告里绝不会告诉你是哪个文件哪一行出了问题。有些错误甚至是故意埋的障眼法，看起来很可疑但其实无害，考验AI不被表面现象带偏。
第五种叫"Godot到Unity引擎迁移"（Godot-to-Unity Porting）。AI要把一个用Godot写好的游戏，原封不动地在Unity引擎里重新实现一遍，保留操作方式、核心机制和游戏进程。
**如果你去装修一套房子，设计师已经把图纸画好了，和你自己要先量房、画图、再动工，这是完全不同的两种工作量和挑战**。SWE-Game用这五种任务，把AI放进了从"白纸设计"到"按图施工"再到"故障排查"再到"搬家重建"的全套真实开发流程里，而不是只考它一种最简单的情况。
第三步：怎么让评测"真的玩一遍"游戏
这是整篇论文技术含量最高的部分,一套叫做"游戏仪表化接口"的机制。
**游戏仪表化接口**：论文中设计的一套标准化接口，让评测程序能够识别不同AI做出的游戏里，哪个物体是玩家、哪个是敌人、哪个数值是血量，从而统一地去操纵和观察游戏运行。
这里有个很现实的难题：不同AI做出来的游戏，内部代码结构、对象命名、场景层级可能完全不一样。甲的游戏里玩家角色叫"Player"，乙的游戏里可能叫"MainChar"或者"Hero01"。评测程序怎么知道哪个对象是玩家，哪个数值代表血量？
SWE-Game的解法是，让提交游戏的一方自己做"翻译"。Godot项目要求在一个叫gb_levels.json的文件里声明关卡和结局，用gb_player、gb_hazard这样的标签给对象打上语义角色，把血量、进度、分数这些关键数值绑定到约定好的字段上。
有了这层翻译，评测系统就能用统一的驱动程序去"操纵"任何一款提交上来的游戏：找到玩家在哪，让它走到尖刺旁边，碰一下，然后检查血量是不是真的少了，或者角色是不是真的死而重生了。
**这就像国际海关检查进出口货物，不管货物原产地用什么语言标注包装，所有货物都必须按统一的海关编码来申报。**
**如果没有这套统一接口，评测者就得为每一份AI提交的代码单独写一套检测脚本**,这显然不现实，247个任务乘以6个AI模型，等于要手写上千套定制脚本，而且AI下一次换个命名习惯，脚本就全部报废。统一接口把这个问题从"理解每个人的方言"变成了"要求所有人说普通话"，评测才能规模化、标准化地进行。
有了这套接口，评测程序才能真正做两件事：一是回放"认证路线",这是在参考游戏上预先录好、验证过的操作序列，拿到候选游戏里重放，看能不能走通；二是运行AI自己写的"功能演示"，检验AI提交的demos.json里声称实现的功能，是不是真的在游戏里发生了。
这里还有一个很巧妙的设计,"无操作对照组"。简单说，就是让游戏在不接收任何玩家输入的情况下也跑一遍，如果这样它也能自己触发胜利画面，那说明这条"通关证据"是假的，根本不是靠玩家操作完成的,这一条不计分。
**这个设计像极了药物临床试验里的安慰剂对照组。如果不设置这个对照组，AI完全可以在代码里埋一个计时器，运行到第30秒自动弹出胜利画面，看起来像是真的通关了，但其实跟玩家操作没有任何关系。**
有了对照组，这种"伪通关"立刻会被识破。
除了功能性评测，SWE-Game还为每款游戏专门设计了视觉评分标准，交给视觉语言模型打分。
**视觉语言模型（VLM）**：一种既能理解图像又能理解文字的AI模型，在这篇论文里负责从截图和录像中判断游戏的视觉呈现质量。
这套规则总共658条，分成游戏实现、内容构成、引导反馈、视觉呈现四大类，每一条都写明了什么情况算满分、什么情况打折扣、什么情况算零分，并且要求模型引用具体画面帧和规则条款来支撑它的判断，而不是凭感觉打分。
六个AI打擂台：谁赢了？
测试覆盖了六款当时较先进的模型：Qwen3.8 Flash、Grok4.6、GPT-5.6 Luna、Opus5、GLM5.3 Flash、Minimax M3，每个模型配上各自的代理框架去完成全部247个任务。
结果有点意外，也有点不意外。
**Opus5在全部五种任务里都拿到了最高总分，但即便是最强选手，在三个"从头构建游戏"的任务里，最好成绩都没能突破60分（满分100分）。**
具体来说，Brief-to-Game（简介生成游戏）任务里Opus5拿到50.38分，是最高分;GDD-to-Game（设计文档生成游戏）任务里它拿到59.68分;Skeleton Completion（骨架补全）拿到54.06分。而在难度相对低一些的Bug Repair（漏洞修复）任务里，Opus5能拿到83.46分，表现明显更好。
这个分数分布透露出一个信号：让AI从零设计并实现一整套游戏机制，远比让它在已有框架里修复一个具体问题要难得多。
论文还细致拆解了每个模型翻车的具体原因，这部分信息量很大。研究者把实现问题归为七类：需求遗漏、玩法逻辑错误、引擎集成错误、交付错误、视觉素材不匹配、状态生命周期错误，以及其他。
有意思的是，不同模型踩的坑还不太一样。
| 问题类别 | GPT系模型 | Opus系模型 | GLM系模型 |
|---|---|---|---|
| 需求遗漏 | **56.4%** | 36.9% | 20.5% |
| 玩法逻辑错误 | 12.3% | 18.5% | **52.2%** |
| 引擎集成错误 | 17.3% | 7.6% | 7.5% |
GPT系模型最大的问题是"漏做了需求"，占它所有问题的56.4%,也就是说超过一半的毛病，根源不在于写错了代码，而在于压根没把需求文档里要求的东西做出来。Opus系模型也有同样的倾向，但比例低一些。而GLM系模型完全不同，它的主要问题是"做了但做错了"，玩法逻辑错误占到52.2%。
**这就像两种不同类型的粗心考生。一种是看漏了题目，整道大题空着没写；另一种是认真答了题，但是算错了结果。这两种错误背后的训练短板很可能是不一样的**：前者可能是对长文档的需求追踪能力不足，后者更可能是代码逻辑推理和调试能力的欠缺。
论文还做了一个很有价值的消融实验：如果拿掉给AI看的参考游戏视频会怎样？
结果显示，有视频参考的情况下，视觉评分总体更高。GPT-5.6 Luna有视频时视觉总分60.05分，没视频时只有54.45分,提升了5.6分。Opus5也有类似提升。最明显的提升出现在"视觉呈现"这个细分维度，GPT-5.6 Luna因为有视频参考提升了6.48分，Opus5提升了9.0分。
但有意思的是，"内容构成"这个维度，两个模型反而是没视频时表现更好。研究者推测，这可能是因为视频传递的信息主要是"看起来该是什么样子"，对最终外观还原有帮助，但未必能让AI更准确地理解设计需求里的内容范围。
**这就像给一个厨师看菜品成品照片和给他菜谱文字说明，照片能让他把菜摆盘摆得更像，但未必能让他更清楚每道菜该用哪些食材、分量多少。**
评测系统本身靠谱吗
搞了这么一大套复杂的评测机制，一个自然的问题是：这套评测本身准不准？会不会它自己也在瞎判？
研究团队专门找了人类来核验。他们从100款AI做出来的游戏里抽取了1200条人工标注的行为断言，拿可执行检测和基于视频的视觉语言模型判断分别去对比人类的判断。
结果是，**可执行检测的平衡准确率达到92.59%，而基于视频的视觉语言模型判断只有大约78.41%。**
在"发现真实缺陷"这项能力上，两者的差距拉得更大：可执行检测的缺陷检测率是94.25%，视觉语言模型只有75.40%，差了将近19个百分点。
这个数字说明了一个很朴素但重要的道理：**让AI"看"视频去判断游戏对不对，终究比不上亲自操纵游戏、实际检验状态变化来得可靠。**
视觉评分那一套单独验证了一下。研究者拿200段游戏录像让人类打分，再和规则化的视觉语言模型评分对比，相关系数达到0.829（1.0代表完全一致），平均绝对误差只有0.103（满分1分的尺度下）。这说明，在"判断游戏好不好看、反馈够不够清晰"这类更主观的问题上，视觉语言模型的判断还是相当可信的。
这个结果其实给出了一条清晰的分工原则：**判断游戏逻辑对不对，交给可执行测试；判断游戏好不好看，交给视觉语言模型打分。**两者各司其职，不能互相替代。
这件事为什么重要
把这些发现串起来看，会发现一个挺现实的图景：当下最强的AI编程助手，在"修修补补"类任务上已经相当靠谱，漏洞修复任务里Opus5拿到83.46分，说明定位问题、动手改代码这件事它们已经练得比较熟了。但在"从无到有创造一个完整、好玩、逻辑自洽的游戏系统"这件事上，差距依然很大，最高分也没能摸到60分的门槛。
这背后其实折射出一个更宏观的问题：当前的AI擅长的是"有明确边界的局部任务",给它一段有问题的代码，告诉它症状，它能顺藤摸瓜找到病根。但游戏开发需要的是"系统性的全局设计能力"，一个机制怎么和另一个机制联动、一个关卡怎么为后续关卡做铺垫、一个数值变化怎么被及时反馈给玩家,这些需要的是整体的设计直觉，而不是局部的代码正确性。
写在后面
读完这篇论文，最触动我的其实不是分数本身，而是那个"无操作对照组"的设计。
这个细节暴露了一个很容易被忽视的真相：AI在"应付检查"这件事上，可能比我们想象的更擅长。如果不设这个对照，很多AI完全有可能、也完全有动机，直接在代码里塞一个计时器凑一个"虚假通关"，用最省力的方式骗过表面检测。这不是说AI在"作弊"，而是说如果评测标准本身有漏洞，模型在优化过程中天然会找到那条阻力最小的路径,这和人类考试里押题、猜答案没有本质区别。
另一个让我反复琢磨的地方是那张问题分类表。同样是做不好一款游戏，GPT系模型的毛病集中在"没做"，GLM系模型的毛病集中在"做错了"。这意味着如果你想针对性地改进某个模型，药方可能完全不一样,前者需要加强的是长需求文档的追踪和自查能力，后者需要补的是运行时逻辑推理的扎实度。这种细颗粒度的失败归因，比单纯一个总分有用得多。
还有一点值得多想一层：论文里提到，视频参考能提升视觉呈现分数，却未必能提升内容完整度。这说明"看起来像"和"做得对"，在AI的能力结构里可能是两件相对独立的事。一个模型可能很擅长模仿表面的视觉风格，却在理解深层设计逻辑上掉链子。这个发现放到更大的AI能力评估语境里，也许同样成立:生成式AI在模仿表象上的进步速度，很可能快过它在理解本质上的进步速度。
如果有一天AI真的能独立做出一款逻辑严密、好玩又好看的完整游戏，那一天到来之前，它大概率得先学会一件更难的事:不是把游戏做得"看起来对"，而是真正理解一个机制为什么该这样运转。
Q&A
Q1：SWE-Game是什么？
A：SWE-Game是上海交大等机构提出的一个评测基准，用来检验AI编程助手能不能独立构建、修复、移植游戏，包含247个任务，基于41款可执行的Godot参考游戏。
Q2：SWE-Game测试里哪个AI模型表现最好？
A：Opus5在全部五种任务类型里都拿到最高总分，但即便是它，在三类从零构建游戏的任务中，最好成绩也没能突破60分（满分100分）。
Q3：SWE-Game是怎么判断AI做的游戏对不对的？
A：主要靠一套"游戏仪表化接口"，让评测程序能统一识别不同AI做出游戏里的玩家、敌人等对象，再通过回放操作和检测状态变化来验证，同时用无操作对照组排除虚假通关。
