最近，我的第二款游戏 Cubersum 进入了试玩阶段。

这款游戏是在 AI 的帮助下制作的，所以我想有些人可能会对我是如何创作的感兴趣。

对于我的第一款游戏，我亲自逐一检查了每一个功能。但今年 AI 已经发展到足够先进的程度，我不再这样做，而是专注于架构。

(1) 我第一时间就决定不采用生成式精灵图。是的，图像生成模型在过去一年里取得了巨大进步。例如，我的第一款游戏的成就图标必须手动在 GIMP 中制作，而第二款游戏我就能通过指定图像可修改的约束条件来正确生成它们，模型也处理得很好。但我仍然认为，精灵图，更具体地说是精灵图之间风格的一致性，是当前模型的弱点。我宁愿把时间花在算法上，也不愿因为图像之间不匹配而反复重新生成。所以游戏内的所有图形都是通过程序化生成的，这让图像完全可重现。

(2) 模型在音乐生成方面也取得了显著进展。游戏中所有的音乐都是生成的，而且在我看来，它们作为背景音乐效果很好。然而，音效仍然是现代模型的弱点，因为生成的片段往往太短，所以我仍然从 Freesound 获取音效。

(3) 而最重要的部分则是编程。首先，这里有一些简单的技术规则。

  • 最终结果必须始终由当前可用的最佳模型以其最高推理水平进行复核。没错，这个模型可能会将大部分工作委托给子模型，但你绝不能相信子模型来验证最终结果。
  • 一旦某个更改被实施并验证，立即提交。很容易一时兴起连续进行多次更改，结果模型在之后出错，让你不得不把新旧代码混在一起梳理。最好是每完成一个独立的计划，就提交一个独立的更改。
  • 拥有 2-3 个在不同星期几开始订阅的服务非常有用。当你用到一个模型的限制时，可以立即用另一个模型继续工作，而第三个模型则作为备份或用于审查备用。

我在工作流程中主要使用了三种模式。

  1. 文档。

    游戏应该有完整的文档。这一切始于一份设计文档和一个最小的项目，但随后，在模型的帮助下，该文档中的每一项都逐渐演变成描述项目某个独立部分的专属文档。

    你的主要工作是阅读这些文档，并验证其中的所有内容是否正确。这占据了大部分时间。游戏中的每一条规则都需要清晰地记录在案，并且你要能理解。

    一个非常有用的方法是，让模型列出某个特定事件的每一种可能结果，并指定每种结果的预期效果。你不能把这些架构决策留给模型。你需要确切地知道游戏中会发生什么以及为什么会发生。

  2. 规划。

    每一个重大的改动都应该被规划。

    一旦最小可行产品存在，所有实质性的改动都应该被组织成更改包并一起规划。这有两个原因。

    首先，这样成本更低。模型可以一次性重写一个模块或函数，而不是分别做十个小改动。

    其次，这使得可以将实现工作委托给子模型或其他模型，而不必强迫它们再次通读整个项目代码库。规划已经指明了需要更改的内容和位置。

    最重要的是，有了规划之后，模型就不太可能偏离轨道，开始做一些它自己认为正确或有用的东西了。

  3. 审查。

    所有内容都需要审查。审查确实能发现错误。

    理想情况下，审查应该由来自不同系列的模型完成。例如，如果 Codex 制定了计划，就把它发给 Claude 审查。

    然后，在计划实施之后，将未提交的代码更改发去再次审查，询问是否所有内容都按计划执行了，以及是否引入了任何回归问题。

    这是一个有用的安全网。它多次帮助我找到了主要智能体遗漏的真实问题。

(4) 在开发接近尾声时，我着手进行本地化工作，这是压力最大的部分，因为我只能依靠模型，再加上来自不同国家朋友的简短审阅。显然，我不能让别人免费翻译 10 万字的文本。

尽管如此，我认为模型处理得还算不错，因为我使用了所谓的“会议”方法。

首先，我为游戏创建了一个术语表，定义了哪些术语对应哪些概念。然后，我手动过了一遍每个术语，并与模型讨论在每个目标语言中，哪些对应的词汇是合适的。

在讨论过程中，我们还确定了一些在翻译中应该避免的“伪术语”。

一旦这个列表被批准，主要模型就生成翻译。然后另外两个模型审查源文本和翻译，并为每一个本地化键提供评论。

对于存在问题的键，三个模型随后会进行讨论，讨论这个术语到底应该如何翻译以及为什么这样翻译。

这个“为什么”非常重要。即使你自己不懂这门语言，你也能得到一个相当容易理解的解释，比如：“NNNNN 是一个语法正确但听起来不自然的生造词，而 MMMMM 是人们在日常口语中实际使用的词。”

也许这只是它们集体产生的幻觉，但我依据的假设是，来自不同系列的三个模型达成的一致意见应该能产生更准确的结果。

母语者的快速审阅表明，大部分情况下模型的翻译是正确的。我希望能在试玩中获得更精确的反馈。

(5) 所以对我来说，AI 辅助开发的流程是这样的：

  1. 首先，根据目标和期望的更改描述来规划下一步。
  2. 阅读计划，重写，再阅读，再重写。如果计划变得太大，就将其拆分成更小的计划并按顺序实施。每一个最终计划都应该经过审查，直到它真的是最终的。
  3. 然后实施计划。这可以由外部的、更简单的模型来完成，尽管最好还是把任务交给最聪明的模型，并在项目规则中指定它应该将任务委托给子模型。
  4. 实施完成后进行审查。显然，测试不应该被遗忘，但对于创建测试来说，通常只需在实施后不阻止模型编写测试就够了。如果你对某些细节特别担心，也可以要求它们为这些情况创建专门的测试。
  5. 在所有更改和测试都完成后，更新文档。否则，重要的更改会逐渐丢失。

这听起来可能有些过头了，尤其是与那些“Astra 一次复制克隆了 CS”的故事相比。

但是，如果你对自己想做的游戏有自己的概念，并且正在努力实现那个确切的概念，那么这个流程就非常重要。

也许对于“CS 克隆版”或“典型塔防”来说，具体是如何实现的并不重要。这就是为什么在这些类型的复制品中，准星可能无法正确变化，或者血条可能不会减少。

但我要重申这一点：你需要清楚地知道你的游戏中发生了什么以及为什么发生，这意味着你需要控制开发的每一个阶段。

这也是制作这款游戏花费超过半年的原因。我大约 90% 的时间都花在阅读和纠正智能体产生的文档上。

最大的优势在于，所有这些都可以用自然语言完成。

以前，创作一款游戏包括两个阶段：先用自然语言描述一切，然后用编程语言重写。现在第二阶段基本上被消除了，但第一阶段的重要性提高了。

我使用了哪些模型？

我的主要模型是 Codex，先是 GPT-5.5 后来是 GPT-5.6。我的备用模型是搭载 Opus 4.8（后来升级到 5）的 Claude。第三个模型部分是 Cursor（特别是在 Grok 成为其默认模型之后），部分是 Gemini（需要说明的是，我发现 Gemini 3.8 远没有网络上人们调侃的那么差）。