AI独立做游戏到底行不行？SWE-Game基准测试：差距明显

假如把一款游戏整个交给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在作弊，而是评测标准一旦有缝，模型在优化过程中自然会往阻力最小的方向走；人类考试里的押题、猜答案，本质上也差不多。

那张问题分类表也值得反复看。同样是把游戏做砸，GPT系模型的问题出在“没做”，GLM系模型的问题出在“做错了”。想针对性改进某个模型，开出的方子可能完全不同：前者要补的是长需求文档的追踪和自查能力，后者要补的是运行时逻辑推理的扎实度。这种细颗粒度的失败归因，比一个总分有用得多。

论文里还提到另一层：视频参考能拉高视觉呈现分数，却未必能提升内容完整度。“看起来像”和“做得对”，在AI的能力结构里可能是两件相对独立的事。一个模型可能很会模仿表面的视觉风格，却在理解深层设计逻辑时掉链子。放到更大的AI能力评估语境里，这个发现也许同样成立：生成式AI模仿表象的进步速度，很可能快过它理解本质的速度。

如果哪天AI真能独立做出一款逻辑严密、好玩又好看的完整游戏，在那天到来之前，它大概率得先学会一件更难的事：真正理解一个机制为什么该这样运转，而不是把游戏做得“看起来对”。

Q&A

Q1：SWE-Game是什么？

A：这是上海交大等机构提出的一个评测基准，用来检验AI编程助手能否独立构建、修复、移植游戏。它包含247个任务，基于41款可执行的Godot参考游戏。

Q2：SWE-Game测试里哪个AI模型表现最好？

Opus5 在五种任务类型中总分都排第一。可从零搭建游戏的三类任务里，它的最好成绩也没到60分（满分100分），这一点连它自己也没能例外。

Q3：SWE-Game是怎么判断AI做的游戏对不对的？

A：主要靠一套“游戏仪表化接口”。评测程序借此统一识别不同AI所做游戏里的玩家、敌人等对象，再通过回放操作、检测状态变化来验证；同时用无操作对照组排除虚假通关。