6个Agent组团Vibe Gaming：自己生成、试玩、修Bug

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

敌方坦克出现在屏幕上，炮管锁定玩家，战斗看似已经开始。但靠近敌人后，坦克没有发射炮弹，反而挥起炮管开始近身攻击。

第一眼看上去，这像是一次典型的AI抽风。继续玩下去却会发现，移动、碰撞、攻击和伤害判定都能正常工作。

它偏离了常见设计，却意外形成了一套可以成立的新玩法。

△坦克挥动炮管近身攻击

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

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

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

页面能打开、角色能移动，并不等于玩家能够完成一局游戏。

平台可能高于跳跃极限，敌人有动画却没有攻击判定，障碍物的刷新频率也可能叠成一条无法通过的“必死路”。

修改同样可能带来连锁反应。

用户只想把角色跳跃调高一点，系统却同时改变重力和其他物体的运动轨迹；代码勉强完成后，素材又可能缺失或风格不一致。

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

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

只有把这些因素放回同一个运行过程里检查，系统才知道问题究竟出在哪里。

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

△Spellcaster六Agent创作与验证闭环

Spellcaster生成的不是一段孤立代码

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

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

这套流程并不追求一次生成就结束，而是形成“生成—运行—检查—修复”的循环。

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

系统根据修改意图处理对应部分，不必每次都从头生成。

从一句话到可玩原型

整个创作过程可以概括成四步：先把想法变成能够运行的游戏，再通过对话迭代玩法和数值，接着结合运行结果修复问题，最后完成素材匹配和视觉装配。

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

目前，平台跳跃、塔防、跑酷、地牢肉鸽和弹幕射击等常见类型，都可以通过这套流程生成并继续修改。

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

这套流程也改变了原型的使用方式。

独立开发者可以先验证一个玩法值不值得继续投入，内容创作者可以把互动故事或网络热梗变成可操作的版本，普通用户则不必先掌握编程和游戏引擎。

第一版不符合预期时，还可以继续要求系统调整规则、难度和画面，而不是从一份陌生代码重新开始。

回到文章开头那个例子，在只关注代码的流程里，它很容易被当成错误删除；在可玩性验证之后，它也可能被识别为一条逻辑自洽的玩法路径。

对游戏原型来说，价值有时不仅来自准确复现，也来自那些没有被提前设计、但确实可以玩的意外。

下一阶段：世界模型直接生成游戏画面

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

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

团队已经把下一阶段的方向指向世界模型：

玩家的移动、攻击和选择会与当前画面、角色状态、交互历史一起成为模型输入，由模型实时预测世界接下来会发生什么，并直接生成下一刻的画面与反馈，不再以传统代码和引擎渲染管线作为核心中间环节。

这意味着，AI游戏将从“自动生成一个可以运行的项目”，进一步走向“实时推演一个能够响应玩家的世界”。

支撑这次技术跨越的，是团队在智能体和世界模型方向的长期积累。

Spellcaster背后的DarwinMind（杭州达迩文智能），长期布局多智能体系统与世界模型方向，核心成员来自浙江大学、南京大学和澳大利亚国立大学。其联合创始人中多位是来自浙江大学的博士生导师，他们长期从事世界模型、多模态大模型和智能体系统研究。

内测申请：https://www.spellcaster.world/releaseplan
Don't Code. Just Cast.

文章来自于"量子位"，作者 "允中"。