这是欧米的第535篇游戏开发原创分享。

点击关注↑ 解锁价值百万的「灵感生产线」

以前一个人做游戏的时候，文档很容易被放到后面。很多东西都在自己脑子里：这个脚本为什么这么写，某个字段是什么意思，敌人死亡后为什么先发事件再回收，自己当时都知道。项目小的时候，这种方式也能维持一阵，哪里记不清了，打开几个脚本看看，大概还能重新接上。

但 AI 开始参与开发以后，情况会慢慢变得不一样。

你让 AI 写代码，它不知道三天前你和另一个对话里定过什么；让它重构，它也不知道某个看起来多余的接口其实正在被编辑器工具调用；换一个 AI 做审查，又得重新解释项目结构和规则。如果还有多个 AI 角色接力开发，这个问题会更明显。

所以用了 AI 以后，我反而越来越觉得，项目里的文档比以前更重要了。

这里说的文档，不是几十页的正式设计报告。它更像项目的一份“当前说明”：现在有哪些规则已经确定，各个模块负责什么，哪些接口不能随便改，这次任务允许做到哪里。

AI 后面能不能继续参与开发，很大程度上取决于这些东西有没有说清楚。

AI最缺的是项目历史和边界

AI 能看代码，也能看你给它的需求，但它不知道这些东西为什么会变成现在这样。

比如项目里有这样一个方法：

publicvoidAddGold(int amount){    gold += amount;    OnGoldChanged?.Invoke(gold);}

单独看很简单。AI 可能会建议把金币统一放到 CurrencySystem，甚至进一步改成：

Dictionary<CurrencyType, int>

这样以后就能同时支持金币、钻石、活动货币，看起来扩展性也更好。

但也许你之前已经决定了：战斗内只有一种临时金币，而且不会带出关卡；钻石和局外货币属于另一套系统，两边就是故意分开的。

这个决策如果只存在开发者脑子里，AI 看不到。它只能根据当前代码重新判断，于是很容易把“项目已经做过的取舍”当成“还没有完善的地方”。

所以文档不应该只写这个项目“有什么”，还要写清楚边界。

例如：

BattleState负责：- 当前战斗金币- 基地 HP- 胜负状态不负责：- 生成敌人- 播放 UI 动画- 保存局外货币- 加载关卡EnemyBase负责：- 移动- 受伤- 死亡状态不负责：- 发放金币- 刷新 UI- 判断关卡胜利

这类说明对 AI 很有帮助。

因为 AI 写代码时很容易“顺手做完”。敌人死亡了，它顺手加金币；金币变化了，它顺手刷新 UI；场上敌人没了，它又顺手判断胜利。单独看每一步都合理，最后却把系统边界慢慢写乱了。

文档里写清楚“谁负责什么”和“谁明确不负责什么”，往往比单纯列一张类名表更有用。

别让项目规则一直散在聊天记录里

AI 辅助开发还有一个很现实的问题：同一个规则经常是在不同时间慢慢补齐的。

比如“减速 Buff 怎么处理”，第一次可能只确定：

同类减速不叠加，只刷新持续时间。

后来做 Boss 时又补了一条：

Boss 免疫减速。

再做第二种减速技能时才发现，还要确定：

不同来源的减速取最高值。

如果这些规则一直散在不同对话里，过一段时间以后，很容易连自己都记不清最终版本是哪一个。下一次再让 AI 修改 Buff 系统，又要重新解释一遍。

更稳的方式，是把已经确认的规则放到固定位置：

GAME_RULES.md## Slow Buff- 减速使用百分比。- 同一 Buff 重复命中不叠层，只刷新持续时间。- 不同来源的减速取最高值。- Boss 免疫减速。- 减速免疫不影响伤害结算。

以后再开发冰冻塔、减速陷阱或者 Boss，都以这里的规则为准。

项目稍微大一点以后，可以保留几份很轻量的文档：

PROJECT.md项目结构、Unity 版本、主要技术约束。GAME_RULES.md已经确认的玩法规则。ARCHITECTURE.md主要模块职责和公共接口。TASK.md当前任务目标、修改范围和验收标准。

不一定非要叫这些名字，也不需要每份都写很长。重点只是让下一个接手任务的 AI 有一个固定地方确认：现在项目是什么状态，哪些事情已经决定。

这样也比每次写一大段 Prompt 更容易复用。

文档最怕的不是少，而是旧

文档多不一定是好事。

假设 ARCHITECTURE.md 里还写着：

BattleUI 直接读取 GameManager 中的金币。

但代码早就重构成：

BattleState    ↓ OnGoldChangedBattleUI

下一次 AI 如果先读旧文档，很可能又开始写：

GameManager.Instance.Gold

从它的角度看，它并没有乱写，反而是在认真遵守项目说明。

所以多 AI 协作里，文档最怕的不是少，而是旧。

项目规则已经变化，最好先更新共享文档，再继续下一轮任务。否则文档写得越详细，误导也可能越严重。

个人项目没有必要维护几十页架构说明。只保留真正会影响后续开发的内容，而且保证这些内容可信，价值反而更高。

AI 也可以帮忙维护文档，但最好做增量更新。

比如完成一个功能以后，可以让它检查：

请根据这次最终代码修改检查 ARCHITECTURE.md。只更新确实发生变化的部分。不要重新改写整份文档。如果代码和文档存在冲突，先列出冲突，不要自行判断哪一个正确。

最后这一条很重要。

如果代码和文档不一致，AI 不应该自己猜哪一个才是“真相”。先把冲突列出来，再由人确认，通常更安全。

有些决策要记录“为什么”

代码可以告诉 AI 当前是怎么实现的，却很难告诉它为什么故意这么实现。

比如：

为什么现在没有使用 Addressables？ 为什么 Buff 没做成通用 EffectSystem？ 为什么战斗金币和局外货币要分开？ 为什么第一版没有对象池？

这些决定可能都讨论过，只是最后没有体现在代码里。

以 Addressables 为例，也许当前不用它不是因为开发者不知道，而是因为项目还在原型阶段，资源量不大，也暂时没有远程内容更新需求。这个时候引入完整的资源管理流程，收益可能还不够高。

如果没有记录，过一段时间以后，AI 很可能再次建议：

建议引入 Addressables 统一管理资源。

然后这个问题又从头讨论一遍。

这种内容可以留一个很轻量的决策记录：

DECISIONS.md暂不引入 Addressables。原因：- 当前资源规模较小。- 现阶段主要目标是完成战斗原型。- 暂时没有远程内容更新需求。重新评估条件：- 资源量明显增加。- 开始做热更新或分包。

这种文档最大的作用，不是证明当初的决定永远正确，而是告诉未来的自己和 AI：

这个问题以前讨论过，当时为什么这么决定。

以后条件变了，再重新评估。

任务文档可以直接约束AI

文档除了说明项目，还有一个很实用的作用：告诉 AI 这一次到底能改什么。

比如开发一个冰冻塔，与其只写：

帮我增加一个冰冻塔，不要乱改其他代码。

不如直接写：

任务：增加冰冻塔。允许新增：- FreezeTower.cs- FreezeBullet.cs允许修改：- BuffConfig.cs不能修改：- TowerBase 公共接口- EnemyBase 移动逻辑- BattleState- 存档结构规则：- 造成 10 点伤害。- 附加 30% 减速，持续 2 秒。- 重复命中刷新时间，不叠层。- Boss 只受伤害，不受减速。验收：- 普通敌人减速正常。- Boss 移动速度不变。- 普通塔逻辑不受影响。

这种任务说明的价值在于边界很明确。

“不要乱改”对 AI 来说没有统一标准。你觉得顺手抽一个接口属于乱改，它可能觉得这是正常优化。把允许范围、禁止范围和验收标准直接写出来，会清楚很多。

任务完成以后，也可以让 AI 根据最终代码检查哪些项目文档需要同步更新。这样文档维护就和开发流程连在一起，不需要每隔很久再专门补一遍。

文档不用写成报告

说到这里，很容易把项目文档想得太重。

其实个人游戏项目完全没必要为了 AI 写几十页正式说明。

一个模块可能几行就够：

WaveSystem负责：- 读取当前关卡波次。- 按时间生成敌人。- 发出波次开始和完成事件。不负责：- 判断最终胜利。- 管理敌人血量。- 发奖励。依赖：- StageData- EnemySpawner- BattleFlow

一个功能任务也可能十几行就够。

文档是否有用，不看篇幅，而看下一次开发时能不能减少重新解释。

代码主要反映当前的实现，文档则更适合记录已经确认的规则、模块边界和设计取舍。两边如果能一直对应起来，再加上 Git 里的修改记录，AI 接手后续任务会轻松很多。

写在最后

AI 进入开发流程以后，写代码变快了，但项目上下文并没有因此消失。任务拆得越细，参与的 AI 越多，越需要有一个稳定的位置记录当前项目到底是怎么工作的。

哪些规则已经确定，模块分别负责什么，哪些接口不能随便改，当前任务做到什么程度，某个架构为什么暂时没有采用，这些信息如果一直只存在聊天记录和开发者脑子里，后面的任务就很容易反复重新解释。

文档不需要很多，更不需要写成报告。

它只要能让下一个接手任务的 AI 知道项目现在是什么样，并且知道哪些事情已经决定，就已经很有价值。

AI 可以帮你把很多代码写得更快。

但如果希望这些代码以后还能顺利接着开发，项目还是需要一份简单、可信，而且及时更新的说明。

结尾

好了，这就是今天分享的全部内容。

给欧米留言，分享你的心得！

点击"在看"让更多开发者看到

我是欧米，每天分享一点游戏开发小知识，希望能帮助到每一个走在实现梦想路上的游戏人。

本文由【欧米De游戏开发小屋】原创，抄袭必究

主笔：欧米

数据，排版：枫叶君

最近在做一个小的游戏创作者站点，

想先拉一个真的在做项目的小群内测。

你或者你的团队，现在如果有在做游戏，或者准备开始做，

任何游戏类型都可以。