代码能跑 ≠ 游戏能玩

给 AI 输入一句“生成一款坦克大战游戏”，代码很快就运行了起来。

敌方坦克出现在屏幕上，炮管锁定玩家，战斗看似一触即发。但靠近敌人后，坦克并没有发射炮弹，反而挥起炮管开始了近身肉搏。

乍一看，这似乎是一次典型的 AI “抽风”。但继续玩下去会发现，移动、碰撞、攻击和伤害判定都能正常工作。

它虽然偏离了经典设计，却意外形成了一套逻辑自洽的新玩法。

△ 坦克挥动炮管进行近身攻击

这也是 AI 生成游戏时最容易被忽略的问题：代码能运行只是第一步，真正困难的是让游戏成为一个能够持续交互的系统。

代码能跑，游戏为什么还是不能玩？

过去一年里，大模型已经生成了大量的贪吃蛇、平台跳跃和射击游戏。

然而，网页能打开、角色能移动，并不等同于玩家能够顺利完成一局游戏。

在实际生成中，平台高度可能超出跳跃极限，敌人有动画却没有攻击判定，障碍物的刷新频率甚至可能堆叠出一条无法通过的“必死路”。

此外，局部的修改往往会带来连锁反应。

例如，用户只想把角色的跳跃高度调高一点，系统却同时改变了重力和其他物体的运动轨迹；或者代码勉强写完后，美术素材却缺失或风格严重不一致。

每个局部看起来都正确，组合起来却无法游玩，这就是 AI 游戏生成中的“可玩性黑洞”。

它比编译报错更难处理。代码报错通常能精确定位到具体的文件和行数，但游戏“不好玩”可能同时涉及数值、地图、反馈和玩家操作等多个维度。

只有将这些因素放回同一个运行环境中进行动态检查，系统才能找出问题究竟出在哪里。

△ 从基础代码生成结果到主题化可玩版本

△ Spellcaster 六 Agent 创作与验证闭环

Spellcaster 的解决方案是：先将用户的描述整理成游戏规则、角色能力、关卡目标、胜负条件、敌人行为和关键数值，然后再交给多个专用 Agent 协同处理。

Rule Agent 负责规则制定，Level Agent 负责关卡设计，Asset Agent 负责素材生成；
Playability Agent 和 Simulation Agent 负责检查关键路径是否可达、核心交互是否有效，以及游戏是否存在“必死局”；
一旦发现问题，Repair Agent 会定位问题属于规则、数值、关卡、素材还是代码，并进行局部修复。

这套流程并不追求一次性生成，而是构建了一个“生成—运行—检查—修复”的闭环。

用户拿到结果后，依然可以通过对话继续迭代：调整角色速度、增加敌人、修改关卡，或者更换视觉风格。

系统会根据修改意图精准处理对应模块，无需每次都从头重新生成。

整个创作过程可以概括为四个步骤：首先将创意转化为可运行的游戏，接着通过对话迭代玩法和数值，然后结合运行结果修复问题，最后完成素材匹配与视觉装配。

输入“生成一个星空背景的弹幕射击游戏”，大约 15 分钟后，用户就能拿到一个可供试玩的原型。

目前，平台跳跃、塔防、跑酷、地牢肉鸽（Rogue-lite）和弹幕射击等常见游戏类型，均可通过这套流程生成并持续修改。

△ 十二款游戏原型同屏展示

这套流程也彻底改变了游戏原型的开发方式。

独立开发者可以快速验证某个玩法是否值得继续投入，内容创作者可以将互动故事或网络热梗转化为可操作的游戏版本，而普通用户则无需提前掌握编程和游戏引擎。

如果第一版不符合预期，用户可以继续要求系统调整规则、难度和画面，而不是面对一份陌生的代码无从下手。

回到文章开头那个“坦克近战”的例子：在只关注代码的传统流程中，这很容易被当作 Bug 删除；但在可玩性验证机制下，它完全可能被识别为一条逻辑自洽的全新玩法路径。

对于游戏原型而言，价值不仅在于准确复现既有设计，有时也来自那些未经提前规划、却切实可玩的意外创意。

目前的 Spellcaster 采用的仍是“AI 生成代码和美术素材，再由游戏引擎运行”的实现路径。

AI 改变了游戏的生产方式，但代码依然是连接创意与最终画面的中间介质。

团队已将下一阶段的研究方向指向了世界模型：

玩家的移动、攻击和选择，将与当前画面、角色状态及交互历史一同作为模型输入。模型将实时预测游戏世界的下一步走向，并直接