大家好！

我是尼古拉斯，是 Prigod Idle 的独立开发者，这是一款使用 Godot 4.6 制作的高级放置自动战斗角色扮演游戏。这是我的第一个真正的游戏项目，大约两年前我开始规划并开发它，前一年半左右的时间我都是手动编写所有代码（先是 Unity，后来改用 Godot）。过去几个月里，我的工作流程发生了很大变化：现在 Claude 负责编写代码、协助规划和构建工具，GPT 偶尔也会帮忙（等到 GPT-6 可能还会有所改变）。

我不想让这成为又一个关于开发者是否应该使用 AI 的泛泛争论。我更想解释的是，在一个已经在使用 AI 之前就相当庞大的实际项目中，实际情况是怎样的，包括一些错误和有缺陷的规划。

最大的改进并非来自找到某个神奇的提示词，能在几分钟内完美实现一切。而是来自给 Claude 足够的项目上下文、方向和愿景，让它能够真正帮助我。

在编写功能之前先进行规划

对于较大的功能，我会先写下作为玩家和开发者想要什么：粗略的 UI 草稿、预期的行为以及任何不能改变的东西。每周至少两次，我还会让 Claude 重新检查项目的当前状态，这样当某些内容发生变化时（这种情况经常发生），它的认知能保持最新。这一步的一个重要部分是让它找出我遗漏的关联。有了一个既涵盖游戏当前状态又包含我下一步想实现内容的计划，Claude 常常能给出关于交叉关联和可能出错之处的有益见解。

例如，我想要一个带有可见蓄力动作的 Boss 攻击。在大多数情况下，这听起来像是一个小的战斗功能。在很多游戏里可能确实如此，但在我的游戏里，它可能会影响到 Boss 数据、战斗状态机、眩晕和沉默处理、施法条 UI、战前计数提示、失败诊断、平衡模拟、离线进度规则、本地化以及一大堆测试。我希望在实现任何东西之前，这些关联都被列出来。否则，很容易只构建了攻击本身，后来才发现离线模拟器处理不正确，或者玩家从未被教导如何应对它。

计划保存在我的本地 PC 上，稍后会被推送到我的仓库。这样在代码改动之前，我可以纠正计划，并为后续的讨论留下系统为何如此设计的记录，这也有助于写补丁说明。而且我也喜欢把它纳入版本控制 :)

实现

一旦我批准了计划，我会将其拆分成更小的部分。我描述行为和约束，以及我想用它来改进或创建什么。Claude 会读取相关的场景和脚本，一次实现一部分，并给我留下笔记，供我稍后写入游戏设计文档。

这正是 AI 为我节省最多时间的地方。它擅长追踪项目中不熟悉部分的调用（即使有错误），添加符合现有模式的数据条目，更新多个相关的代码路径，然后编写枯燥的回归覆盖测试。它还处理许多维护工作，比如：调试、版本升级、资产组织和记录更改内容。调试仍然是我自己定期做的事情，但通常都是小问题。

当我给它的任务太大时，它的作用就不那么大了。一个大的请求常常会产生乍看合理但基于一个错误假设（即使我尝试构建提示词让 Claude 在假设之前先提问）的代码。较小的改动使得这些错误更容易被发现，需要时也更容易丢弃。但这确实意味着我必须检查每一个改动，这就引出了下一点。

我如何检查结果

目前有三个层面。

第一，针对规则和数据的大型无头测试套件。无头很重要：如果没有它，Claude 和 GPT 每次都会在一个窗口中打开游戏，然后我在它运行时几乎无法使用 PC。这个套件可以捕获无效的内容引用、存档兼容性问题、内容和成就的解锁条件、奖励和成本计算以及战斗回归问题。当完整测试运行会淹没我真正想看的数字时，我也会使用小的、功能特定的探测器。

第二，游戏玩法和平衡工具，它们运行真实的游戏逻辑，只是速度远超实时。它们可以遍历进度、模拟战斗原型、检查成本计算和货币消耗是否仍然成立，或者重复某个特定的 Boss 配置而无需等待太长时间，所有这些都可以从不同起始点以多种难度和速度进行。这很有帮助，因为一个放置游戏的经济体系在某个存档点的简化版本可能顺利通过，而真正的奖励却是有问题的，这样我也可以分别测试几个部分。我在游戏的不同阶段构建了许多原型配置用于测试。我还让 Claude 为特定场景构建了工具：存档编辑器、作弊工具、用于 PvP 平衡的竞技场模拟器等等。过去几周我经常使用的一个工具是科技树建模器，以便按我的想法移动科技树节点并编辑它们的要求。

第三，每一个视觉变化都需要一个真实的窗口截图。仓库中有专门的 Godot 场景，可以在受控状态下打开屏幕，必要时与之交互，截取截图并检查基本的布局不变性。还会针对不同语言和字号进行布局扫描。

最后一个层面之所以存在，是因为一个测试报告说场景打开没有错误，几乎不能告诉我 UI 改动是否有效。AI 在良好的用户体验方面似乎仍然是在黑暗中摸索。一个按钮可能存在但位于折叠线以下。一个面板可能使用有效的锚点，但在窄窗口下仍会覆盖导航。德语文本可能把干净的英文布局搞得一团糟，尤其是在不同字号结合的情况下。这些都是常见的 AI 错误，普通的无头测试永远发现不了。即使是截图验证的测试，大多数时候也有问题。

我仍然自己检查截图和界面。测试套件证明请求的状态已经达到，并给我一致的证据。但它不知道结果是否看起来廉价、令人困惑或不协调。而且它也不知道这到底是不是一个有用的功能。这就引出了：

我仍然自己做的事情

就像我说的，UI 好坏参半。我要么自己构建，要么给 Claude 一个相当精确的草稿然后手动检查。它可以很好地复现已有的组件，但如果我要求它“做一个好看的屏幕”，结果通常会有技术上有效的节点和非常少的视觉层次。它也可能忽略现有的场景生命周期，同时生成的代码看起来完全自洽。

平衡性以及整体感觉和节奏是我自己做的事情。打击时机、声音和音乐的位置以及音量调整、一次游戏进程应该持续多久、何时以及哪些奖励应该掉落、一个效果或动画是否令人满意——这些是我需要通过大量玩游戏来做的决策。我也曾在另一个项目上尝试把太多平衡工作交给 AI，结果严重出错。模拟可能在整体数据获取上确实有帮助，但它们并不能直接帮助决定什么应该感觉公平或有趣。由于我的游戏允许大量不同的构建，涉及多个相互关联的系统、协同作用和能力，这些是数学无法单独解决的问题。

我不是艺术家，而且我非常不擅长制作 UI 以外的任何东西。两年前在非常早期的阶段，我尝试过 AI 生成的图像，但我不喜欢它们的外观，而且动画化它们非常困难。所以我决定：Prigod Idle 中不会出现任何生成的图像。视觉效果来自授权资产包（感谢 Humble Bundle 提供了很多），我追踪每个文件的来源，以便注明出处并在 Steam 上准确披露。这只是我为这个游戏设定的边界，而不是声称其他人应该做什么。声音和音乐也是如此。

我还自己写 Steam 补丁说明。Claude 会保留一份非常长的技术变更列表，这作为素材很有用。它自己的补丁说明版本往往是这样的：“制作屏幕上的按钮向下移动了 8 像素，以提高可访问性并防止玩家沮丧。”玩家通常只需要知道影响他们的更改。我挑出那些，在确实有趣的时候解释原因，其余的省略。它挑选的重点也往往很奇怪：不，这次最重要的不是怪物动画略有改进。

最后，游戏设计方向仍然是我的：哪些系统属于游戏，一个构建应该是什么感觉，以及某个功能（已完成或仍在规划中）是否值得保留。Claude 可以快速提出 20 种解决方案，但我仍然必须自己做出决定，玩各种版本，有时还要意识到自己错了并放弃。

所以我当前的循环是：我定义目标和想要达到的结果，AI 映射受影响的系统，我以小块实现改动，运行逻辑测试和模拟，验证 UI，然后自己玩游戏。之后我自己修复问题，或者记下小问题反馈给 Claude 进入下一个循环。

这比试图改进提示词、找到合适的技能或合适的 AI 模型（不过 Fable 仍然效果最好）要可靠得多。层级基本上是：测试捕获规则，截图和我捕获呈现效果，我来决定游戏是否真的好玩。

对于任何在原型阶段之后在游戏项目中使用 AI 辅助的人：在修复游戏错误并让它真正有趣方面，哪种工作流程最有效？我认为我的方法适合我，但我想听听其他人是怎么做的。

对于任何想尝试 demo 并提供反馈的人，这是 Steam 链接。