AI 游戏开发走出 Demo 之后：战斗、关卡和测试才是硬仗

2026 年 9 月 14 日，Games Alchemy 作者 Antti Kananen 发布了一篇新的 AI 游戏制作复盘，记录自己把智能体工作流从资产和演示推进到战斗、关卡、UI、音频与测试时遇到的问题。项目开始要求这些内容在同一套可玩系统中彼此配合后，真正的制作难点才集中暴露出来。

文中的数据和效果来自作者自己的项目，没有独立复现，更适合作为一份制作流程样本。它说明 AI 已经能承担大量实现工作，也清楚展示了“能运行”和“值得玩”之间仍有哪些环节。

战斗把“功能完成”拆成许多验收点

角色和武器出现在画面里相对容易，攻击是否成立则牵涉输入、碰撞、动画、镜头、特效、声音和受击规则。作者遇到过剑的动作看似正常但碰不到敌人、弓箭进入准备姿势却不响应真实鼠标输入、敌人朝向玩家但武器指向错误等问题。

他的处理方式是停止把“战斗”当作一个整体任务，改为分别检查动作接触、方向、时间窗口、输入路径、伤害、反馈和拒绝条件。测试不仅调用内部开火函数，也模拟真实鼠标操作；近战方向和弓手朝向则用多组固定案例反复检查。

按作者记录，一份被接受的构建最终通过了 16 组打包回归测试。这能证明刀刃是否命中、墙是否挡住攻击、敌人是否进入正确状态，却不能判断动作有没有重量、弓箭释放是否舒服，或同一种敌人打到第二十次会不会无聊。机械路径可以自动验收，游戏手感仍要靠人实际玩过之后决定。

关卡需要用玩家路径检查

同样的差距也出现在关卡制作中。作者让智能体把道路、城墙、地形、城区、桥梁、室内和地下空间连接成可行走场景；其中一个版本的可玩区域超过一公里，并对数千个路径采样点做了检查。随后，实际控制器测试继续走过入口、楼梯和长距离路线。

这些检查没有消除视觉问题。反向墙面、错误轴心、穿进地面的草、压低空间的天花板和朝向相反的家具仍然需要人工发现。部分路线最初通过了结构测试，玩家视角下却依然不合格；后续行走又暴露了楼梯转角和缺失绕行路线。

这套过程更接近“规划、生成、行走、取证、人工否决、再修正”的循环。坐标连通只能回答路是否存在，无法回答空间是否易读、构图是否合理，或局部环境有没有叙事感。

UI 和声音的瓶颈在使用情境

智能体可以较快完成设置页的信息结构、控件和基本响应，但作者发现早期界面容易停留在“功能齐全的开发工具”状态。玩家先看到什么、哪些选项应当收起、不同分辨率下如何调整，以及画面哪里需要强调，仍需要明确的设计方向。

音频也有相似规律。生成音乐较快提供了可用的情绪方向，单个音效听起来合适，却可能在连续攻击中太长、循环后令人疲劳，或在游戏内出现响度、空间位置和同时发声数量的问题。作者的一轮音频制作产出了 63 个短单声道变体，并用自动检查处理文件结构、峰值、循环和路由；最终是否能用，仍要戴上耳机在游戏中听。

多模型协作也需要制作管理

作者把边界清楚的编码、修复、数据和测试任务交给成本较低的模型，把视觉判断、较大空间和最终复核留给能力更强的模型。每次交接都要带上目标、具体文件、已接受参考、约束、测试、已知缺陷和完成条件，否则多个模型只会重复熟悉同一份项目。

这种分工也带来新的预算问题。一次困难任务可能连续得到质量不稳定的结果，继续重试很容易消耗更多上下文和额度。作者采用的办法包括在任务开始前设预算、限制低质量重试次数、按任务类型记录消耗，并为昂贵模型准备更便宜或确定性的替代路径。

对正在试用 AI 游戏开发流程的团队，这份复盘提供了四个可直接执行的起点：把大功能拆成可观察的验收点；让自动测试走真实输入和玩家路径；保存固定测试场景与已接受参考；为重试和模型升级设置停止条件。AI 可以把项目更快推到可玩构建，但从这里开始，质量更多取决于测试、取舍和持续积累的制作规则。