我单独开发了一个使用 AI 的浏览器策略游戏。它既是一个 AI 实验，也是一个晚上休闲项目。三月的时间，真实玩家。它写出了一份自信的、结构良好的变更，但又静悄悄地破坏了它，我已经多次信任了它而成了一个傻瓜。

当前的热门话题是“AI 循环”和你的绑定和测试。它们是实现这一点所必需的关键前提。

所以，我花费了很多时间来建造每个变更所经过的门控层，而不是让它写代码。这个门控层逐一增长。生产中出现了一个问题，我要求 AI 修复它，然后回顾一下发生了什么（根因分析 + 5 个为什么）并要求 AI 添加测试和门控，以便这个问题的整个类别再也不会到达线上。所以我获得了两个级别的回归测试。

一个例子。早期的代码使用了一个数据库日期函数，在开发环境中的 SQLite 中工作正常，但在线上 Postgres 数据库中静悄悄地做了错误的事情。它让我多次受到了影响。现在一个检查扫描了每个变更，寻找这个特定模式，并在找到它时失败构建。如果没有出现这个错误的 bug，已经有一个多月了——有时，当我停止观察 AI 自己对话时，它捕捉到问题并在我甚至进入手动 QA 之前就修复了它。

将这个 bug 乘以我在三个月内犯下的所有错误，那么就有了一个庞大的数字。那么，测试和回归测试的绑定就变得更加强大，难以将有缺陷和破坏的代码部署。

一些门控层赚到了它们的收入：

  • 一个规划门控，在任何代码之前运行。它读取相关代码，向我提出最多五个尖锐的问题，并打印一个短暂的工作协议。直到计划明确，任何东西都不会被建造。我从“烧焦”技能中汲取了灵感并进行了适应。
  • 一个影响门控，在任何游戏规则或平衡数字的变更之前。它表面了所有变更触及的东西，代码，文档承诺给玩家一个数字，旧值的测试，要求我确认公开。有一个全面的 /doc/ 目录，游戏机制，维基，内部经济数字都被一个资源固定。
  • 一个调和门控，对线上游戏与手册/维基，真理源进行了审计，并向我展示了代码和文档在哪个方向上偏离了。

然后是一个发布管道：只提交本会话的文件，并在质量门控通过绿色后进行同日审查，CI 类型检查了所有内容，并在六个平行分片上运行了测试套件，才能部署。

一个曾经能在秒内到达线上的变更现在需要十分钟。直到我注意到真正的伤害不是速度到达线上，而是我需要频繁地放弃一切并修复线上的游戏。这个数字现在接近于零。

如果你感兴趣，可以在这里留言或查看我的开发日志。我很享受分享这段旅程。