智猩猩AI整理
项目团队投稿
让 AI 写游戏，已经有人把《英雄联盟》《跑跑卡丁车》的玩法搬上了它的考卷。
但把需求交出去，AI 就能一路写代码、做测试、修 Bug，最后交出一款真正能玩的 3D 游戏吗？
当 Agent 已经能调用工具、使用浏览器，接下来要检验的，是这些能力能否在一次完整开发中配合起来：前面设计的规则，后面能否实现；试玩发现的问题，能否真正修回代码。
围绕这个问题，上海创智学院联合腾讯、上海交通大学、复旦大学，香港大学等单位推出3D GameDev Arena，将长程 3D 游戏开发变成 Coding Agent 的新考场。
先看一段 AI 交出的卡丁车游戏。
视频：Codex + GPT-6 生成的卡丁车游戏。
角色会移动，镜头能旋转，场景也加载出来了。但当玩家开始加速、碰撞、失败、重试，一款游戏才真正接受考验：规则是否生效，状态是否一致，出了问题还能不能修好？
3D GameDev Arena 关注的，正是 AI 从读懂规格到交付可玩游戏的完整过程。
项目收录了 169 条游戏规格，围绕规划、实现、浏览器自测和修复展开评测，并从两个角度检验结果：功能有没有做对，玩家更愿意玩哪一个。
项目主页已提供成对盲测试玩。同一条规格下，两款游戏匿名呈现；投票后，再揭晓各自使用的模型和 Harness，也就是负责组织模型、工具与执行流程的开发框架。
01
先看结果：谁的游戏更受欢迎，
代价又是多少？
在研究团队收录的 125 票有效偏好投票快照中，GPT-6 Astra + Codex 以 71.49 的 Bradley–Terry 偏好分数暂居首位。GPT-6.1 Sol + Codex 以 63.46 位列第二，GPT-5.6 Sol + Codex 以 43.44 位列第三。
完整配置与费用、耗时信息如下：
模型 + Harness
偏好分数
平均费用
平均耗时
GPT-6 Astra + Codex
¥3,209
7.9 小时
GPT-6.1 Sol + Codex
¥589
14 小时
GPT-5.6 Sol + Codex
¥2,182
15 小时
Kimi K3 + Kimi CLI
¥961
21 小时
GLM 5.3 + ZCode
¥163
3.1 小时
Grok 4.7 + Grok Build
¥86
2.7 小时
表：团队收录的偏好评测快照。“—”表示数据未提供。偏好分数由成对投票估计，不代表功能通过率；最新结果以项目主页为准。
体验之外，开发成本同样值得关注。GPT-6 Astra + Codex 在这份快照中的平均费用为 3,209 元；GPT-6.1 Sol + Codex 为 589 元；GLM 5.3 + ZCode 则为 163 元。
把费用与功能评测结果放在一起，可以看到另一组差异：
图：客观代码评分与平均费用对比。横轴为平均费用，采用对数刻度；纵轴为客观代码评分，与上表的玩家偏好分数属于不同指标。
图中，GPT-6 Astra 的客观代码评分最高，费用也最高；Kimi K3 与 GPT-6.1 Sol 的评分接近，但费用不同。这样的对照让读者能够同时看到交付效果和资源投入。
这些结果比较的是“模型 + Harness”的具体配置。要理解分数，还需要先看它们做了什么题、又如何接受评测。
02
169条游戏规格，
把复杂玩法交给Agent
3D GameDev Arena 从游戏规格出发，不提供针对题目预先搭好的游戏工程。Agent 需要阅读详细文本和可选的图片参考，自行组织玩法、控制、场景、资源与状态逻辑。
任务目录包含169 条规格，难度分布如下：
表：任务目录的难度分布。规格数量不等于每套配置已经完成的评测数量。
玩法灵感覆盖了许多熟悉的作品：从《跑跑卡丁车》的竞速，到《英雄联盟》的对战，再到《无主之地》的战斗与装备；目录还涉及《怪物猎人》《我的世界》《传送门 2》《只狼》《深海迷航》等游戏。
这些游戏名称帮助读者理解玩法方向。每道题都以明确的规格限定实现范围，Agent 需要交付对应玩法的浏览器游戏。
Agent 必须把规格落实到运行逻辑中。角色在什么条件下受伤，资源如何消耗，任务怎样完成，失败后恢复哪些状态，都需要前后一致。
例如，宝箱没有正确发放装备，后面的战斗就可能无法完成；检查点没有记录进度，重试就可能把玩家送回错误的位置；碰撞与角色控制不一致，玩家甚至走不到任务目标。
长程开发的难点，就藏在这些互相依赖的状态里。
03
从规划到再测试，
考察一次完整交付
从零开发一款 3D 浏览器游戏，要求 Agent 持续推进同一个项目。
它要先读懂规格、规划玩法，再编写场景与逻辑；随后启动浏览器，操作自己的作品，结合画面、控制台和运行状态定位问题，回到代码中修复，再次测试。
研究团队将这条开发链路概括为：
规划 → 实现 → 浏览器自测 → 观察 → 修复 → 再测试
按照研究团队介绍的协议，规划阶段最多允许三次尝试；如果在干净环境中构建或启动失败，平台还会提供一次额外修复轮次。平台提供的修复，与 Agent 开发过程中的自主编辑、测试和回归分别记录。
这也意味着，“一次任务交付”可以包含多轮内部开发与自测，不能直接理解为模型只生成一次代码就完成了游戏。
研究团队用“宝箱 → 装备 → 战斗 → 检查点 → 失败／重试 → 撤离”举例说明状态依赖。这是流程示意，不能当成某个正式任务已经通过验收的成绩。
随着开发推进，Agent 既要补全功能，也要检查修改是否影响了已有机制。修好了移动，却破坏了碰撞；加上了暂停，却让计时器继续运行——这些回归问题，都会影响最终交付。
04
实现可以不同，
验收目标必须一致
不同 Agent 生成的游戏，代码结构可能相差很大。
有的把状态集中在游戏引擎对象中，有的通过命令分发器控制行为，有的用模拟时钟推进过程，还有的需要通过浏览器操作。评测如果只接受一种代码结构，就可能漏掉采用其他实现方式的正确行为。
Arena 的做法是：先固定验收目标，再适配访问候选实现的方式。
人类先写下验收标准，将其拆成固定的功能子项，并在候选实现出现前冻结。候选提交后，评测器检查生产代码，寻找真实入口、状态访问方法、控制命令与时间推进接口，生成对应的 probe.ts 和 test-plan.json。
适配改变的是测试如何进入游戏，验收要求保持不变。
例如，要检查角色恢复了多少生命值，不同游戏可以有不同的状态读取接口，但恢复条件、预期数值和允许误差应遵循同一条标准。不能因为某个实现难以测试，就临时降低要求。
每个验收项都需要留下实际值、预期值、容差与完成状态；测试覆盖率、失败和阻断情况也要保留。读者才能知道，一个分数背后究竟执行了哪些检查。
05
功能做对之后，
把体验交给玩家
满足规格与获得玩家喜爱，是两个需要分别回答的问题。
Arena 为此设置了两条评测轨道：功能评测检查规则与机制，人类偏好评测比较实际游玩体验。
在成对盲测中，系统抽取同一条规格下的两个候选，随机安排 A／B 位置。玩家分别试玩后，可以选择 A 更好、B 更好、平局、都不好，或跳过。
有效投票提交后，系统再揭晓双方的模型与 Harness。
同一题目、匿名呈现，让玩家可以先关注操控、反馈和整体体验，再了解作品出自哪套配置。收集到的成对偏好通过 Bradley–Terry 模型估计为分数，形成开头展示的排行榜。
随着候选与投票增加，这份榜单也会变化。功能证据、玩家偏好、费用和耗时放在一起，才能更具体地描述每套配置的表现。
06
轮到你试玩了
3D GameDev Arena 把一个具体问题带到了 Coding Agent 面前：面对一份复杂规格，能否持续开发、发现错误并完成修复，最终交付一款可以运行和检验的游戏？
它也把体验判断留给了玩家。
关注+星标，获取AI前沿进展与开源一线动态
热门跟贴