多智能体做游戏：规划、构建、试玩、审查四种角色怎么分工

适用场景

满足下面任意一条，就值得拆：

• 游戏能分成三块以上。 角色控制、关卡、UI、敌人 AI、音频、资产。"能分开"的标准是边界一句话说得清，比如"HUD 只读 state.speed，从不写它"。
• 单个会话开始漂移。 修好的 bug 又回来了，单位被悄悄改了，名字被改回旧的。这是上下文过载，开新会话、给一份短简报，比再提醒一遍可靠得多。
• 你需要一个说真话的检查。 写功能的智能体倾向于报告"已完成"。只看验收清单和运行中游戏的另一个智能体，没有理由手下留情。
• 资产和代码可以并行。 一个智能体在 Blender 里做道具，另一个对着同尺寸的占位方块写玩法。

不适合：一天能做完的原型、单文件小游戏、还没有稳定规格的项目。五个智能体对着一个模糊的想法，会做出五个互不兼容的想法。先写规格（先写规格再做 AI 游戏），用一个智能体跑通一个能玩的核心循环；等你能说出"第二个智能体要交出哪个文件"，再加人。

代价：每个智能体都要重读规格和它碰到的代码，所以 token 的增长比智能体数量更快。换回来的是并行，以及一轮不用你亲自做的检查。建议从两个起步：构建者加试玩者。

最低配置：一个 git 仓库；一个能跑命令行的智能体工具（Claude Code、Codex、Cursor 之类）；一种给运行中游戏截图的方法（网页游戏用 Playwright，Blender 用渲染命令）；再留一小时写第一版计划。