Nobukz Code 复盘 AI 辅助 RPG 开发的五类事故及应对

事故是难免的

仅靠指示 AI，我就花了 3 周时间制作了一款 RPG。如果只写顺利的故事，可能会让人觉得“交给 AI 就能搞定一切”。
但实际上，发生了不少事故。
这次我将记录已知的失败以及我是如何恢复的。

事故 1：我编写的文件在同步中丢失

这个游戏的文件存在于两个地方：AI 操作的本地 PC 和运行游戏服务器的家庭 NAS。我们将本地创建的文件发送到 NAS，并将 NAS 上修改的文件拉取到本地。这种往返操作是使用将接收端完全对齐为与发送端相同格式的工具进行的。即使接收端版本更新，也会被覆盖。

10 月 3 日，AI 在未确认差异的情况下进行了拉取。在此之前，我在本地编辑器的“待办事项”列表中添加了两项并保存。结果，该文件被 NAS 上的旧版本覆盖而丢失了。

由于“待办事项”列表更新频率很高，我很快就发现了新增的两项内容消失了。但如果这是平时不常接触的设置文件或细微的 bug 修复，我们可能会在很长一段时间内都未察觉而继续推进。

此外，能够恢复也是运气好。我本地的编辑器保留了正在编辑的内容。AI 对此进行了检查，找到了包含已消失文本全文的备份并恢复了它。

同一天，我为同步工具添加了“保护功能”。当接收方存在更新内容时，会在覆盖前进行拦截。
该保护功能在添加后立即生效。例如，我在 NAS 管理界面刚刚保存的城镇居民数据，就被本地旧版本阻止了覆盖操作。10 月 6 日，当我试图通过管理界面更改世界设置（如土地价格等）时，也曾被阻止以免除丢失。

事故 2：每小时备份将未完成的草稿推送到了生产环境

10 月 2 日，发生了另一桩类似的事故。
原本用于每小时将 NAS 数据复制到备份位置的机制，直接调用了向“生产环境发送”的工具。因此，AI 正在处理中的未完成文件被推送到了生产环境中。

“创建备份”与“推送到生产环境”看似相似，实则是截然相反的工作。备份可以反复创建而无妨，但推送到生产环境的必须是经过确认的最终版本。
我们将备份改为存储在与生产环境不同的位置，并采用追加保留的方式。现在，只有手动操作时才会推送到生产环境。

事故 3：我也曾进行过覆盖操作

也有相反的情况。10 月 4 日，AI 在列表中新增了 17 个项目后，我因旧内容未关闭而在编辑器中保存，导致这 17 个项目全部消失。我从已发送至 NAS 的副本中仅恢复了丢失的部分。
当文件存在于两个位置时，事故可能从任一位置发生。

事故 4："出于好意"却做得过头

AI 有时会宽泛地解读指令并一次性推进执行。

连原图都重绘了（10 月 3 日）
当我告知后续追加制作的 Boss 变异体图片"基底（原图）过于粗糙，令人感到违和"时，所有 77 种的原图都被重绘了。我本希望仅在中型 Boss 或 Boss 时使用其他图片，但 AI 进行了过度解读。普通魔物的图片已从备份恢复至原状。

适应屏幕宽度后反而变得难用（10 月 7 日）
管理界面在小窗口中会出现溢出，因此我指示修复。AI 仅以"消除溢出"为目标，在宽度较窄时将列表与详情改为上下堆叠显示。
我的屏幕宽度恰好低于该阈值，结果反而更难使用，变成了字面意义上的"恶化"。

在下一个版本中，我们恢复了保持左右排列、仅缩窄列宽的形式。
AI 在“没有溢出”这一点上，按照指示正确地进行了修正。但是，我真正想要的是“能够继续使用熟悉的布局”。如果只给出一个模糊的目标指示，AI 会毫不犹豫地牺牲其他方面。从那以后，我在确认项目中加入了“是否保持左右排列”。

本想改一行，结果差了 1,700 行
原本只是给曲目列表增加一首歌，但由于重写了整个文件，导致产生了 1,700 行的差异。我从备份中恢复，并重新添加了那唯一的一行。

事故 5：为了测试，在生产环境中创建了 84 个账号

10 月 5 日，我注意到管理后台的玩家列表中有很多名为“probe”的条目，便询问：“这是 bug 吗？”原来，AI 每次进行功能验证时，都会在正式服务器上创建测试用的账号。总计多达 84 个。当时正让家人试玩，这些测试账号与真实玩家混杂在一起，显得十分混乱。
AI 在删除数据前保留了副本。此后我们规定，功能验证仅在本地测试服务器上进行。

为了让看不见、听不见的 AI 使用

AI 无法像我们一样看到游戏画面，也听不到声音。
因此，我让 AI 为自己制作了用于自行确认的工具。例如：将画面拍照以便查看、通过计算音频长度和静音时间来绘制波形图、统计管理界面中的溢出部分等。在使用将声音波形化的工具时，我发现了一些没有播放效果的音效。

在制作大量图片的漫长工作中，有时会在中途被中断。在制作 1,046 个图标的过程中曾两次停止，导致未能完成的部分被留空粘贴。现在，即使发生中断，也可以从断点处重新开始。

为了防止同样的事故再次发生

第一次事故发生在二月。我当时重新制作的图片并未出现在发布用的位置上。从那以后，“修改原稿时也同步更新发布用版本”成为了要求 AI 遵守的约定中尤为重要的一项。

回顾过去，能够恢复过来，多亏了以下三点。

1. 在做出更改之前，务必保留备份
2. 有记录说明为何要更改，以及知道回退到何种程度即可
3. 每次发生事故时都增加了相应的约定

如果不加提醒，AI会反复犯同样的错误。但如果将其写成约定，下次它就会避免再犯。事故也成为了增加约定的契机。

在事故频发的时期，我也曾对AI发泄过怒火。但这无异于自缚手脚，因此我确立了“不信任AI”、“不再将任务交给AI”这一基本原则。随后，在深入探讨如何系统化地构建防止事故机制的过程中，我制定了各种约定和工具。

不仅限于游戏，许多人在工作中也因质量问题或安全问题而苦恼。但将AI视为有害之物还是多功能工具，取决于拥有权限者的方针与指示。也就是说，在绝大多数出现问题的情形中，问题并非出在AI本身，而是出在使用者一方。

我属于支持AI的一方，但我希望在不放松掌控、不盲目信任的前提下，巧妙地加以利用。

下次将讨论管理后台。如果先开发出能在浏览器中直接编辑怪物和物品的「数据编辑器」，开发流程会发生怎样的变化？文章还将介绍用于报告错误的机制，以及让机器人自动持续游玩的「自动调试玩法」。

具体步骤计划整理在「步骤篇（付费）」中。