AI 写代码已经不新鲜了，但"AI 写完代码自己跑、跑挂了自己修、修完继续跑"还是新鲜事。8 月中旬，杭州团队 DarwinMind 的 Spellcaster 让 6 个 Agent 组团做游戏，输入一句"生成一个星空背景的弹幕射击游戏"，大约 15 分钟就能拿到一个可以试玩的原型；几乎同一时间，港中文的开源框架 OpenGame 把"自调试"做成了架构级能力，跑通了一条从文本提示到可玩游戏的无人流水线。
这两件事放在一起，标志着一个分水岭：AI 做游戏的能力竞争，正从"谁会写代码"转向"谁能让代码自己跑通"。今天我们聊聊这个闭环到底怎么落地，以及中小团队能从中抄到什么。
从"生成"到"跑通"，差着一个自调试闭环
大多数 AI 编程工具的现状是：能生成代码，但生成不等于能跑，能跑不等于能玩。你让 AI 生成一个塔防游戏，它可能真的给你几百行代码，但一运行全是跨文件报错，然后你得自己一行行排查。这个"最后一公里"，才是之前 AI 做游戏的最大拦路虎。
Spellcaster 的思路是把开发从"一次性交付"变成"陪伴式迭代"。它的整套流程并不追求一次生成就完事，而是形成一个"生成—运行—检查—修复"的循环：先把想法变成能运行的游戏，再通过对话迭代玩法和数值，接着结合运行结果修复问题，最后完成素材匹配和视觉装配。第一版不符合预期也没关系，继续对话调整规则、难度和画面就行，不需要从一份陌生代码重新开始。
这背后是 6 个 Agent 的分工协作：有的负责理解需求、有的负责写代码、有的负责运行试玩、有的负责检查报错、有的负责修复、有的负责装配素材。对我们做研发的人来说，这套东西最有价值的不是"自动生成"，而是把"调试"这件最耗人力的脏活累活，第一次真正交给了 AI。
自调试是怎么实现的？看 OpenGame 的两个"技能库"
要说清楚"自己修 Bug"怎么实现，得看港中文开源的 OpenGame 框架。它做了两件架构级的事：
- Template Skill（模板技能库）：内置平台跳跃、俯视、网格、塔防、UI 驱动五类游戏模板，Agent 拿到新需求先套模板再改，而不是每次从零生成——模板意味着大量已知正确的地基。
- Debug Skill（调试技能库）：维护一个验证过的跨文件错误修复协议库，遇到同类报错直接调用已验证的解法，实现自我纠错，不需要人工介入调试。
支撑这两个技能库的，是团队自研的 27B 参数模型 GameCoder-27B（基于 Qwen3.5-27B 训练，经过持续预训练、指令微调、带执行反馈的强化学习三阶段）。在 OpenGame-Bench 评测上，框架配合 Claude Sonnet 4.6 在"构建健康度"拿到 72.4 分，超过 Cursor 5-6 分。有意思的是，消融实验显示框架架构本身对性能的贡献大于模型升级——这印证了一个观点：在 AI 做游戏这件事上，"会修"比"会写"更值钱。
把调试经验沉淀成可复用的"修复协议库"，这个思路其实跟传统游戏开发的 Bug 库、踩坑文档一脉相承，只是 AI 把它变成了自己能调用的能力。
数值怎么交给 AI？SOON Fx 的另一条路
代码和美术之外，还有一块硬骨头是数值。SOON 平台的做法值得单独拎出来说：它内置了一个 AI 数值引擎 SOON Fx，能用自然语言描述自动生成战斗、闯关、卡牌、模拟经营等玩法的逻辑——血量、掉落、成长曲线成套数值体系，而且产出内容自带碰撞判定、通关条件这些基础运行规则。
这意味着你不需要先懂数值公式，直接说"我要一个难度递增的关卡，每关敌人血量上浮 20%"就能把骨架搭出来。SOON 在 45 天测试周期里诞生了超 3000 款可运行游戏作品，并建立了 AP1 到 AP6 的品质分级体系，多款作品达到 AP4、AP5 的精品等级，游玩时长能撑到几十小时。
但我们得说句公道话：数值是玩法的骨架，AI 能把骨架搭出来，"手感"仍然是人的活。生成出来的数值体系大概率是"合理但平庸"的，真正的好手感，需要人对目标用户的体感反复微调。AI 在这里的角色是帮你把 80% 的重复劳动干掉，剩下 20% 的审美判断，还得人来拍板。
中小团队怎么用这套能力，别只会看热闹
这套能力对中小团队最实际的价值，不是"用 AI 做出完整产品"，而是把玩法验证的成本打到地板。三个场景特别值得抄：
- 玩法验证：一个玩法想法，一句提示词 15 分钟出可玩原型。以前验证一个玩法要开发几周，现在半天能测三个方向，先验证值不值得继续投入，再做决策。这直接解决了"做出来了没人玩"里最贵的那个试错环节。
- 迭代试验：调整角色速度、增加敌人、修改关卡、更换视觉风格，全用对话完成，不需要懂代码。对策划来说，这意味着可以在动手画原型图之前，先亲手"玩到"自己的设计。
- 批量内容生产：平台跳跃、塔防、跑酷、地牢肉鸽、弹幕射击这些常见类型都能生成并继续修改。做休闲品类投放素材的团队，甚至可以直接拿它来生成玩法切片做买量素材的"试玩版"。
落地节奏建议三步走：先选一个类型把闭环跑通，摸清工具的能力边界；再把跑通过程中的经验沉淀成自己的模板和修复库（这点跟 OpenGame 的思路一样）；最后把 AI 原型接入真实开发管线，让 AI 干它擅长的骨架活。要记住，AI 原型是"验证工具"不是"交付物"，真正上线、提审、过包，仍然需要人工收尾。
三个边界，AI 暂时帮不上忙
把话说透，AI 多智能体开发游戏还有三件事帮不上忙，别抱幻想：
- 手感：物理反馈、打击感、镜头调度这些"好不好玩"的层面，Agent 只能修 Bug，修不了"没感觉"。这类问题甚至连报错都不会报，AI 无从下手。
- 长线内容：几十小时游玩的优质内容供给，AI 目前只能搭骨架。生成式玩法可以当起点，撑不起完整的游戏长线。
- 真机与合规：机型适配、性能优化、隐私合规、提审过包，这些环节要人工拿数据说话，AI 生成的代码在真机上的表现，仍然需要测试和人来把关。
再往远看一步，Spellcaster 团队已经把下一阶段的方向指向了世界模型——让模型直接根据玩家的操作实时生成下一刻的画面与反馈，不再以传统代码和引擎渲染管线作为核心中间环节。到那一天，"开发游戏"和"运行游戏"的边界会被彻底改写。但对今天的我们来说，先把"生成—运行—检查—修复"这个闭环用起来，就已经比 90% 的同行快一步了。