用 AI 开发游戏，让我明白了如何交付 AI 产品

我开发了一款回合制星舰战斗游戏，名叫 Sektorium: Captains’ Duel。两位舰长在六边形棋盘上对决，每个回合依次经历四个阶段：分配能量、规划移动、锁定传感器、开火射击。这款游戏可以直接在浏览器中免费游玩，无需下载，无需注册，拥有六个各具特色的派系，并且完全开源。它的灵感来自我童年时玩过的桌游：Star Fleet Battles、BattleTech。那些游戏的乐趣，一半在骰子，一半在思考。游戏的大部分代码是在 Claude.ai 等大语言模型的深度辅助下完成的。你可以在 sektorium.com 体验，也可以在 GitHub 上 fork 源码，亲眼看看这一切是怎么实现的。

我想说清楚这件事的性质：这是一场蓄意为之的学习实验。我故意违反了自己关于产品管理的大多数原则，只是想亲眼看看 Claude.ai 到底能做什么。没有严格执行的阶段性评审，没有范围约束，没有对自己说"这在路线图里吗"。我放手让工具跑。目的是找到边界——通过实际动手，而不是空谈理论，亲身体验 AI 协作工具在哪里让你更快、在哪里悄悄地让你更慢。游戏是实验室，发现才是真正的产出。

以下是从这场实验中存活下来的五条教训。它们与游戏开发关系不大，更多是关于如何与大语言模型协作完成一件有野心、有生命周期的事——而这越来越成为所有在真实产品中部署 AI 的人的日常。我分享这些教训的方式，和我与 SproutVest 合作的创始人和基金分享调研发现的方式一样：失误比成功更有价值，所以我会直说哪里痛。

第 01 课

真正的杠杆在文档，不在模型

我被问得最多的问题大概是"AI 到底写了多少？"诚实的回答是：很多。有用的回答是：模型从来不是瓶颈，上下文才是。

大语言模型默认不记得两次对话之间发生了什么。每次新对话都从零开始。如果你不主动重建"项目是什么、规则是什么、东西放在哪里"，模型就会用听起来合理的猜测来填补空白——而这些猜测有时会和昨天那些同样听起来合理的猜测相互矛盾。我的解决方案是准备一套精简的文档，在每次会话开始时加载：一份定义不可妥协规则和工作结构的总纲，每个主要阶段各有一份包含范围和验收标准的分纲，以及一份专门回答"这个部分真的做完了吗"的验收文档。

这个认知对产品工作的迁移价值最直接：围绕代码的文档，比代码本身更重要。文档质量高时，产出自然跟上；文档过时或前后矛盾时，再高明的提示词也救不回来。如果你是一位正在落地 AI 功能的产品经理，你的需求文档、不变量和完成标准不是走流程的材料，而是支撑一切的基础，而且是出错代价最高的那部分。

第 02 课

少数不可妥协的规则值得坚守

一开始我就确定了三条规则，并且拒绝打破它们。游戏逻辑必须完全可复现——相同的输入永远产生相同的结果。服务端始终是权威，玩家浏览器只是一扇窗，永远不是事实来源。每一次游戏状态的变化都记录为一条只增日志的条目，就像银行账本——只能追加，不能修改。

这三条规则对于"发布一款可玩的游戏"来说一条都不是必需的，我完全可以跳过。但几个月后，当我想要实现回放、AI 对手、观战模式，以及证明一场竞技对局没有被篡改时，每一个功能几乎都是免费的——因为规则早就在那里了。回放只是把日志重新播放一遍，AI 对手只是通过同一套引擎生成和人类一样的操作。

这条教训不是"采用这三条规则"。而是：少数架构层面的约束，早早确立、坚决捍卫，胜过日后补打的十个锦上添花。你为了一点小方便妥协掉其中一条的那一天，就是某个未来功能悄悄损坏、几个月后你才发现的那一天。用产品语言说，这就是平台决策与功能决策的区别——而 AI 功能特别擅长把昨天的便捷捷径变成今天的结构性债务。

第 03 课

AI 辅助的工作会产生真实的技术债务，而且累积很快

这条教训我必须诚实地说，因为它从外部看不见，却是所有用这种方式工作的人迟早会踩中的陷阱。大语言模型写出的代码，看起来像它最近见过的代码。通常这是礼物，因为它会学习你的惯例并一致地应用。但这也意味着它传播坏模式的速度和传播好模式一样快，偶尔还会发明没人要求的新模式。

我遇到了三种表现。模型重新发明了已经存在的工具函数，悄悄地在十几个文件里重新实现同一个小工具，而不是导入那个唯一的权威版本。它把本该是共享 helper 的逻辑变成了散落在代码库各处的复制粘贴块。它还积累了各种垃圾——文件名后缀加了"2"的重复文件、从未运行过的测试、替代方案到位之后还在原地的旧 schema。每一项单独来看微不足道，加在一起就是真实的清理工作。

对产品负责人来说，更深层的意义是：模型会放大你本来就在走的方向。发布快不等于真正在推进。真正重要的纪律不是写出更聪明的提示词，而是早早发现重复并在第三次出现之前收拢，而不是等到第三十次。如果你衡量一个 AI 辅助团队只看发布速度，你看不见正在积累的债务——而它会在你想扩张的时候突然以减速的形式出现。

第 04 课

编了号的路线图照样挡不住需求蔓延

我的计划有一个整整齐齐的编号阶段列表，看起来很有纪律。然后一个"第 7.5 阶段"在中途出现了，因为某个早期阶段交付了一个功能，却遗漏了它明显需要的配套部分。后续阶段不断膨胀，吸纳了账号系统、社交登录、排位赛、装饰道具，以及一堆集成——大多数以"小改动"的名义进入。单独来看，每一项都没有错，每一项在我加入那天都站得住脚。累积的结果是：整个项目里真正可以玩的游戏部分，大概只占工作量的五分之一，其余是身份系统、社交功能、经济系统和脚手架。

那个编号列表制造了一种范围有界的幻觉，而现实从未兑现这个幻觉。路线图真正的价值最终体现在暂停点——那些我可以停下来决定下一件事是否值得做的时刻。我擅长暂停，却不擅长决定不做。

可迁移的习惯：最多只规划两个阶段，且每个阶段要有一个明确的"不在范围内"章节，和范围章节并排放置。推迟的事项和纳入的事项同等重要。投机性工作——那些你因为有趣而构建的集成，而不是因为真实用户需要它——应该留在路线图之外，直到它能解决一个具体的问题。先建基础设施再找受众，是反的——即便工具让基础设施变得便宜，尤其是在这种情况下。

第 05 课

做了一半的迁移，比没开始更糟糕

整个 Sektorium 代码库里最令人困惑的东西，是我为一次从未执行的重组创建的一对暂存目录。暂存完成了，拆分没有。那些目录就这样在那里躺了几个月，里面是存放于别处的代码的过时副本，以及描述一个也许永远不会到来的未来的注释。每次我搜索代码库（包括每次模型搜索代码库），"这个东西到底在哪里？"这个问题突然有了三个看似合理的答案。

同样的形态以更小的规模遍布各处：比替代品存活得更久的旧文件、被复制到三个地方的模板、本该是一个文件却散落在五个文件里的笔记。每一次都是：一个变更开始了，新的制品创建了，旧的从未删除，结果是两个事实来源渐渐分叉。

我希望我坚持住的规则是：要么在规定的时间窗口内完成迁移，要么回滚，永远不留长期存在的"以后再完成"状态。这在有 AI 协作者的情况下比没有时更加重要，因为模型会读取你留下的一切，并把它们都当作信号。你脑子里会自动过滤掉的歧义，它会忠实地放大。干净的工作空间不是为了整洁而整洁，那是你的协作者赖以发挥作用的上下文。

下一次构建，我会带上什么

如果明天我重新开始一个类似的项目，调整的部分主要是纪律，而不是设计。在任何真实工作开始之前写好不变量和完成标准，并在每次会话时加载。选定少数几条架构规则，坚决捍卫。专门针对重复进行审查，在第二次出现时就收拢，而不是等到第三十次。最多规划两个阶段，推迟的事项和承诺的事项同等认真地写下来。一个变更值得开始，就做完它或撤销它——永远不要留在暂存状态。

最大的意外是：这件事与 AI 本身关系不大。模型快、能干、不知疲倦。决定这种速度最终变成产品还是变成一团混乱的，始终是同一件事：清晰的规则、诚实的范围，以及保持工作空间足够干净的纪律——干净到所有人，无论人类还是 AI，都能分辨什么是真的。工具变了，工作没变。

在 SproutVest，我们每天帮助创始人和基金将深层技术转化为具有商业价值和可信赖的产品。越来越多地，这意味着帮助团队充分发挥 AI 协作工具的潜力，同时不被它们悄悄积累的债务所淹没。如果这正是你面前的问题，我很乐意交流。