GameXpert-Bench：从“能做出游戏”到“能完成开发”

2026年8月25日阅读约 3 分钟

导语

让编码智能体根据自然语言写出一个能运行的小游戏，已经不再只是概念演示。但“能生成一个可玩的原型”，与“像专业开发者一样完成游戏开发”之间，仍隔着需求理解、程序逻辑、界面交互、视听内容、缺陷排查和持续迭代等多个环节。腾讯混元团队提出的 GameXpert-Bench，正是为了测量这段差距。

传统评测往往关注一次性生成结果，或只测试某个孤立的修复环节。这种方式容易忽略真实开发中的连续过程：智能体先创建项目，随后面对用户反馈或自行发现问题，最后还要在多轮修改中不断增加功能，同时不能破坏已有行为。

GameXpert-Bench 将这一生命周期拆成三条互补轨道：

评测方式也并非只依赖代码静态分析，而是结合实时游戏交互、确定性行为测试和最终产品标准。数据集包含 11 种类型的 97 个生成任务、来自 50 个关卡的 100 个修复任务，以及 17 条包含六轮请求的优化链条。修复任务中的缺陷经过人工验证，旨在更贴近实际开发中的问题形态。

基准结果传递出一个清晰信号：当前智能体较擅长搭建“能玩起来”的基础版本，也能按照明确、局部的要求实现功能。但当任务要求它主动发现问题、确认运行时行为，或在连续改动后保持整体稳定时，表现明显变得不可靠。

这一区别非常关键。游戏开发不是把文本需求逐项翻译成代码，而是要持续观察一个复杂系统的实际行为。一个功能看似已经写入项目，可能仍存在交互失效、逻辑冲突或修改后旧功能被破坏等问题。GameXpert-Bench 因而把“过程能力”纳入核心评估，避免用一次成功的生成掩盖长期协作中的风险。

对编码智能体研究而言，这项工作将评测重点从代码产出推进到可执行产品和完整工作流；对工具开发者而言，它提醒人们加强运行时观测、测试生成、缺陷定位和回归保护；对用户而言，智能体更适合被视为能够快速搭建原型的协作者，而不是无需监督的独立游戏开发者。

更广泛地看，游戏是检验智能体长程能力的高密度场景：逻辑、视觉、交互和可玩性必须在同一执行产物中同时成立。未来，真正有竞争力的系统不仅要会生成代码，还要能够验证结果、理解反馈，并在不断变化的需求下保持系统完整性。