Coding Agent 的下一站，是动态交互系统的构建。
作者丨 GameCraft-Bench Team
过去一年，代码智能体（Coding Agent）发展迅速。从编写简单的单一脚本、修复局部 BUG，到跨文件完成长序开发任务，模型能力正在不断提升。
以 " 一句话生成游戏 " 为代表，AI 正在大幅降低游戏构建门槛。过去需要开发者熟练掌握引擎架构、手写逻辑代码的开发工作，现在可以通过自然语言快速生成原型，甚至生成可运行的游戏项目。这也让规模化由 AI 创造交互式体验变得前所未有地现实。
但问题是：这些从零自动生成的游戏，真的 " 能玩 " 吗？
如果生成的代码只是 " 看起来逻辑合理 "，但在真实的引擎环境中根本跑不起来，或者视觉表现与玩家交互一塌糊涂，那么在这些只看静态代码的基准里刷出高分的 Agent，就很难真正胜任现实中的游戏开发场景。
香港中文大学（深圳）、深圳河套学院等高校联合腾讯的最新研究 GameCraft-Bench 正是要解决这个问题：
如何构建一个基于真实游戏引擎、产物完整可运行、且能通过真实玩家多模态交互来验证的 AI 游戏生成评测基准。
项目主页：https://tongxuluo.github.io/gamecraft-bench-website
评估代码：https://github.com/tongxuluo/gamecraft-bench
01
为什么不直接用现有的评测基准？
过去已经提出了一些与游戏生成相关的评估基准，那我们为什么还要重新确立一个新的评估基准 GameCraft-Bench 呢？核心原因是：现有的基准很难全面、真实地衡量端到端的可玩性。
1. 真实引擎的整合难度被低估。 像 OpenGame-Bench 主要针对 Web 网页游戏，缺乏对真实游戏引擎（如 Unity、Godot）生态的考察；
2. 缺乏端到端的产物完整性。 GameDevBench 确实引入了真实引擎（Godot），但它主要关注基于游戏的局部代码修改和确定性测试，而非要求大模型从零交付一个完整的交互式游戏产物；
3. 动态交互的结果很难自动验证。 评估一个游戏，不能只看代码有没有语法错误。摄像机偏移对不对？UI 有没有重叠？按下跳跃键后角色是否真的起跳了？这些游玩过程中的 " 行动 - 响应 " 循环，传统的静态代码测试根本无法捕捉。
所以，传统的评测环境可能适合考察基础编程能力，却不适合考察复杂的交互式系统生成。
GameCraft-Bench 要解决的，就是如何将游戏生成的评测拉回到 " 引擎基础 "、" 产物完整性 " 和 " 交互验证 " 这三个游戏开发最核心的维度上。
02
GameCraft-Bench 如何把代码测试变成真实游戏评测？
GameCraft-Bench 的构建思路可以概括为一句话：先在真实引擎中约束开发规范，再把生成的项目转化为可运行、可观察、可验证的交互环境。
具体来说，GameCraft-Bench 选用了轻量级、节点树结构清晰、且支持原生 2D 和无头（headless）模式执行的 Godot 4 引擎作为底层环境。
系统会首先向代码智能体提供一份自然语言游戏设计文档（Game Design Document, GDD）。这份文档相当于游戏开发的 " 施工图 "：它会描述核心机制、操控方式、胜利条件以及视觉表现要求。随后，智能体不能只提交零散的代码片段，它必须根据说明，自动编写 GDScript 脚本、配置场景树（Scene Tree）、挂载美术资产，并最终交付一个包含入口场景和输入映射的、可直接启动的完整游戏项目。
GameCraft-Bench 不再 " 考算法题 "，而是在回答一个更重要的问题：AI 到底能不能像人类开发者一样，驾驭真实的引擎工具？
03
有了产物还不够，关键是过程能交互、结果能验证
构建出完整的引擎项目只是第一步。对游戏来说，产物真正有价值，是因为它能承载玩家的操作、记录系统状态，并给出实时的视觉反馈。
因此，每个由 AI 生成的 Godot 项目都会被自动编译启动。GameCraft-Bench 配备了一套基于演示回放（Replay）与多模态模型的自动评测流程：
Agent 需要随游戏项目一起提交演示轨迹（Demo Trace），记录一系列键盘与鼠标操作（例如：按下 " 向右 " 和 " 跳跃 "），用于展示关键游戏功能和场景。
评测系统会在全新的游戏实例中重放这些操作轨迹，自动录制游戏运行过程，并从录制视频中采样关键画面作为评测证据。
多模态大模型（VLM）作为裁判，根据游戏设计要求，对回放过程中呈现出的游戏行为、视觉反馈与状态变化进行评分，判断任务是否真正完成。
这种设计避免了让评测器自行探索游戏玩法，从而将评测重点放在 "Agent 是否成功构建并展示了目标游戏能力 " 上，而不是 " 评测器是否能够发现这些能力 "。
对于机制验证任务，系统会检查角色是否能够按要求移动、跳跃、攻击或触发指定机制；对于表现验证任务，系统通过回放录像中的可见证据，判断血条变化、状态切换、胜负界面等要求是否得到满足。
基于这套机制，GameCraft-Bench 形成了一套极其硬核的基准：覆盖 15 个主流游戏家族（从平台跳跃、塔防策略到模拟经营等），共计 140 个深度的开发任务。
04
评估的不仅是机制骨架，还有完整的产物表现
很多自动生成的游戏原型，看起来有代码、有循环，但对玩家来说根本没法玩。
因为一个真实的游戏往往不是 " 按键能动 " 就结束了，而是要提供完整的心流体验：要有明确的关卡内容、要处理复杂的碰撞判定、要有计分板和 UI 界面，还要有胜利与失败的状态流转。
因此，GameCraft-Bench 在构建评测体系时，不会盲目只看核心逻辑，而是将评估维度精细化：
核心机制（Core Mechanics）： 角色移动、物理碰撞、核心动作是否符合预期？
内容深度（Content Depth）： 游戏是否有足够的关卡元素？敌人生成是否合理？难度曲线是否存在？
反馈与可读性（Functional Visuals）： 游戏在游玩过程中的可读性与即时视觉反馈是否完备（如可读的游戏状态、警告提示、任务目标以及在 1280 × 720 分辨率下的 UI 稳定性）？
美术与呈现（Art and Presentation）： 动画是否流畅播放？视觉特效（如受击特效）是否完整？UI 画面是否风格一致且美观？
这些维度并不是通用打分项，而是会结合具体游戏任务映射到对应的由人类专家标注的细粒度 Rubric 上进行评估。评测关注的不是 " 某个游戏像不像另一类游戏 "，而是 " 它是否实现了自己设计文档中承诺的玩法与体验 "。
为了进一步验证这套自动评测体系本身的可靠性，在基准构建完成后，团队又专门对 Judge 的稳定性与一致性进行了分析。在固定游戏项目、轨迹、视频与 Rubric 的条件下，多次评测结果波动极小；而在引入人工评测进行校准后，Judge 与人工评测对比整体一致，仅在内容丰富度与表现质量上略偏宽松。这说明该 Judge 并非随机主观判断，而是能够稳定反映游戏实际完成度。
05
真实评测揭示的残酷真相：前沿模型在游戏生成上依旧薄弱
把评测标准拉到如此真实的维度后，前沿模型的真实表现到底怎么样？
测试结果揭开了冰冷的现实：端到端复杂交互系统的生成，远未被解决。 即使是当前最顶尖的代码智能体，在这个基准上的总分也往往难以突破及格线。
核心机制与后续系统扩展表现出严重的 " 数据疲软 "。对比各项细分指标可以发现，模型在 " 核心机制（Mechanics）" 上的得分率是全场最高的 ，例如 Opus-4.7 high 和 GPT-5.5 high 分别能够达到 55.34% 和 54.36%。然而，一旦涉及到系统的深度扩展与综合表现，数据便出现明显下跌 — 在 " 内容深度（Depth）" 维度上，两者的得分分别降至 39.48% 和 38.61%；在 " 艺术表现（Art）" 上，更是进一步走低至 36.86% 和 32.94%。这意味着模型仅能勉强写出基础的代码逻辑框架，却极度缺乏将系统做深、做完整的交付能力 。
06
典型模型行为诊断：Kimi-K2.6 与 MiMo-V2.5-Pro
对开发链路中工具调用序列的量化统计表明，代码智能体的工具使用偏好直接决定了系统级任务的收敛效率 。Kimi-K2.6 的视觉反馈闭环与 MiMo-V2.5-Pro 的重度执行形成了鲜明对照 ：
高效的视觉反馈闭环（Kimi-K2.6）
数据特征：在 140 项任务中，Kimi-K2.6 表现出极强的动态视觉自检倾向，平均每项任务调用 " 渲染屏幕检查工具 "（Rendered-screen inspections）达 21.41 次（中位数 19 次） ，仅有 4 项任务完全未调用该工具 。
行为模式：在 Strategy-Skirmish 实验中，它通过高频的渲染画面回读，成功将画面转化为有效的调试信号 。这使其精准定位了代码编译正常但实际运行错位的逻辑缺陷（如单位放置偏离、状态指示丢失），并逆向校正了网格系统与回合指示器布局 。这种模式实现了视觉感知引导的精准迭代，有效摆脱了一次性代码合成的随机性 。
低效的终端调试泥潭（MiMo-V2.5-Pro）
数据特征：MiMo-V2.5-Pro 表现为典型的 " 前置代码堆砌、后置重度执行 " 模式 。在其全部工具调用中，Shell 命令行执行（Bash）占比高达 56.3%，而代码阅读与编辑（Read + Edit）仅占 16.5%。统计表明，其工具调用总量与最终交付得分几近无关联（相关系数 r = +0.016） 。
行为模式：MiMo 倾向于在缺少运行验证前快速生成全量文件 ，导致后续阶段陷入冗长的命令行修补路径中 。在 5 个零分任务中，MiMo 虽然顺利通过了工程编译（Valid Build） ，却由于将海量算力耗费在局部的 Bash 调试中，最终漏掉了闭环评测所必需的交互轨迹文件（Demo Traces）交付 。这用失败实验证明了单纯堆砌命令行执行量无法确保全局任务的有效收敛 。
07
写在最后：Coding Agent 的下一站，是动态交互系统的构建
作为通向完全自主 AI 游戏生成的第一步，GameCraft-Bench 依然有它的边界（例如目前聚焦 2D 引擎，且裁判机制尚未接入音频多模态评估）。但它指明了一个不可逆转的趋势：
Coding Agent 的竞争，正在从 " 模型能不能把代码写对 "，走向 " 模型能不能交付一个真正可运行、可交互、体验连贯的软件系统 "。
传统的代码评测（如 LeetCode 题目补全）最容易规模化，但与真实软件工程存在巨大鸿沟；而直接评测真实游戏产物足够硬核，却需要极高的多模态验证和引擎打通成本。
GameCraft-Bench 试图走在这条难而正确的路上：
从自然语言的 GDD 出发，约束在真实的 Godot 引擎中开发，再把最终产物转化为可运行、可输入、可多模态验证的动态环境。
所以，GameCraft-Bench 真正回答的不是 " 哪个模型写脚本更快 "，而是：
当大模型试图接管复杂软件开发的全流程时，我们如何系统性地检验它们是否真的理解了 " 人机交互 " 的本质？
AI 编程时代，模型会越来越强。
但能让模型真正走向工业级落地、甚至有一天独立创造出 3A 大作的，可能正是这些不再妥协于静态代码、敢于直面引擎真实运行和多模态交互的残酷世界。
上车，带你看遍全球 AI 顶会精华
可独家畅览：
专家演讲 PPT
大会报告全文
热门论文解读
学术新星访谈
扫描上方二维码
关注雷峰网学术专区。
