分析、计划、代码、检查：我们用 AI 开发的节奏 🤖

我们从来没有隐瞒过，我们在 Blocks Beyond The Stars 上大量使用了 AI，没有它，这么大的游戏根本不可能作为下班后的业余项目做出来。但对我们来说，“用 AI 开发”并不意味着：敲下一个愿望，拿走结果，然后碰运气。几个月下来，一套固定的模式逐渐形成，听起来出乎意料地老派，却正因为如此才管用。今天我们把它完整地讲给你们听。

一切总是从一个人和一个想法开始。在任何 AI 动手之前，总有人想要或注意到了什么：可能是一位玩家用反馈键报告动物出现在他的墙里，也可能是我们自己，听到 Justus 在游戏中说他缺少什么。在这里，AI 不会自己发明任务，任务是交给它的。

然后 AI 分阶段工作。一共四个阶段，顺序总是一样：分析、计划、实现、验证。（第五步，手动测试，在这之后进行，但那又是人的工作，稍后再细说。）最重要的诀窍，是 AI 不被允许做的事：立刻写代码。一个马上开始敲代码的 AI，会以惊人的速度解决错误的问题。所以每个较大的任务都从一次分析开始：现在已经有什么，原因到底在哪里，还有什么和它有关？结果是文字，不是代码。

然后是计划，而且会有人读它。分析之后是计划：会动到哪些文件，按什么顺序，已知哪些陷阱，还有哪些决定没做？恰恰在这里，会冒出那些最好在编程之前就回答的问题（“这个在浏览器里也要能用吗？”“旧存档怎么办？”）。只有计划定下来，才会进入实现，而这往往是整件事里最无聊的部分。这正是它应该有的样子。

相关的事放在一批里做。第二条能为我们省下大量时间的规则是：当几个问题相似或相互关联时，比如五个手柄菜单都有同样的焦点问题，或者同一轮测试里的十五个发现，AI 拿到的是打包好的一个任务，而不是十五个单独的任务。这样它只需要把相关代码过一遍，各个解决方案能够彼此配合而不是互相矛盾，也不会有东西掉在两个任务之间的缝里。

每次发布之前：两轮各自独立的检查。每个较大的工作步骤之后，以及新版本发给你们之前，我们总会让 AI 再检查一遍结果。但这是两次刻意分开的调查。第一：目标功能和错误修复是不是真的完整做完了，还是某处还留着半成品、被忘掉的边界情况或缺失的翻译？第二，单独再过一遍：这些改动有没有在别的地方引出新问题？把两者混成一个问题是行不通的，同时找漏洞和找连带损害的人，每样只能找到一半。分开问这两个问题，能让我们省下大量返工；发布说明里那些写着“顺手修复”的东西，有相当一部分正是来自这些检查轮次。

最后，由人再测一遍。第五步不是 AI 的阶段，而是我们的：手动测试意味着真正去玩。刚构建好的版本，一个真正的手柄，一个真正在玩的孩子。很多能挺过所有分析的东西，在沙发上的头五分钟里就会死掉。因为一样东西手感对不对，是世界上任何分析都回答不了的问题。

仔细看，你会发现这套模式里没有什么 AI 魔法，只有古老的工程手艺：先理解，再计划，然后建造，最后检查。而围绕这一切的框架，对我们来说始终是一样的：想法由人提出，最终测试由人完成，AI 在两者之间工作。唯一的新鲜事，是这个循环变得有多快。🔍