如何把 AI 驯成靠谱的「开发同事」？｜AI 游戏开发（三）：原子任务 + RED/GREEN + 协作记录
📚系列第 3 篇 / 共 6 篇｜ 项目：《全职炒股》｜ 技术栈：C# · Unity 6000.0.23f1 · NUnit · JSON Runtime Config · Replay · UnityPoco
「请继续完善家庭系统」——这种模糊指令会让 AI 一口气改掉模型、日结、UI、存档、文案和测试，最后你根本不知道它到底解决了什么、又破坏了什么。
项目后期所有工作都被改造成「原子任务」：每个任务同时描述「要做什么」和「不要做什么」。本文给出可直接复用的任务结构、标准 Prompt 和 RED/GREEN 流程。
协作记录也不是流水账，而是项目的长期记忆——它决定了下一个 AI 会不会推翻上一个 AI 的设计。
🖼配图建议：一张「AI 任务卡」示例截图 + RED/GREEN 测试对比图，最有说服力。
📌 本文你将收获
- 一个合格任务卡必须包含的结构（目标 + 禁止修改 + 完成条件 + 剩余风险）
- 可直接复制粘贴的标准任务 Prompt 模板
- 用 RED/GREEN 先写失败测试，降低 AI 幻觉
- 为什么新测试通过还不够，必须跑相关回归
- 协作记录怎么写才有价值，以及文件冲突该怎么处理
一、AI 协作最常见的失败方式
如果我对 AI 说：
请继续完善家庭系统。AI 可能会同时修改家庭模型、日结流程、UI、存档、文案和测试。即使结果看起来能运行，我也很难知道：
- 它到底解决了哪个问题。
- 它是否修改了正式数值。
- 它有没有破坏离线逻辑。
- 哪个测试证明它完成了。
- 失败的测试是不是本次引入的。
因此，项目后期所有工作都被改造成“原子任务”。
二、一个合格任务应该包含什么
我为每个任务使用下面的结构：
任务编号：A21i301 任务标题：把市场周期参数迁移到运行时 JSON 任务来源：技术设计文档中的配置驱动要求 本次目标：只迁移市场周期字段 禁止修改：图表、交易 UI、音频、职业数值 预计文件：配置 JSON、配置加载器、预检、测试 完成条件：JSON 可加载，版本正确，预检通过，回归测试通过 剩余风险：强交易窗口消息范围仍有旧分支这个结构的核心思想是：任务必须同时描述“要做什么”和“不要做什么”。
三、我给 AI 的标准任务提示词
下面这份模板可以直接复用：
你现在处理任务：<任务编号>-<任务标题>。 开始前请先读取： 1. 协作入口文档； 2. 与本任务相关的设计文档； 3. 最近两份相关验收记录； 4. 当前 git status 和目标文件 diff。 本次目标： - <目标 1> - <目标 2> 明确禁止： - 不修改无关系统； - 不修改正式数值； - 不删除其他协作者的改动； - 不把开发测试入口带入正式包。 请按以下顺序执行： 1. 先说明当前实现和缺口； 2. 先增加能暴露问题的测试； 3. 完成最小代码修改； 4. 运行目标测试和相关回归； 5. 检查 diff； 6. 输出修改文件、测试结果、失败原因、剩余风险； 7. 新增一份协作记录。四、使用 RED/GREEN 方式降低 AI 幻觉
对行为型需求，我倾向于先让 AI 写一个会失败的测试。
例如要增加 Replay 的TimingVersion字段，可以先写：
[Test]publicvoidReplayReportIncludesFormalTimingVersion(){ReplayReportreport=RunScenario();Assert.That(report.TimingVersion,Is.EqualTo("26.6.11.3-400tick"));}此时测试应该因为字段不存在而失败，这就是 RED 阶段。
然后 AI 实现字段、生成逻辑和导出逻辑，再运行测试。如果测试通过，就是 GREEN 阶段。
这样做有两个好处：
- AI 必须面对一个具体缺口，而不是凭感觉判断自己是否完成。
- 测试本身成为未来回归的保护网。
五、不要只跑新增测试
新测试通过后，还需要运行相关回归。
例如修改市场配置，至少要检查：
- RuntimeConfigLoader。
- ProjectSetupValidation。
- MarketRegimeEngine。
- MessageEngine。
- Replay。
- 构建启动预检。
项目中曾出现过这种情况：新增加的配置测试全部通过，但旧的消息数量断言仍然假设旧数值。这个问题不是新代码无法工作，而是测试契约已经过时。
测试失败时，不能盲目把实现改回旧规则；应该先判断哪一份设计口径是最新的，再更新测试或实现。
六、协作记录不是流水账，而是项目记忆
一份有效的协作记录应该包含事实，而不是只写“已完成”。
推荐结构如下：
# A21iXXX 任务标题 ## 任务来源 ## 当前观察 ## 修改范围 ## 未修改范围 ## 测试记录 | 测试 | 结果 | 证据 | |---|---|---| ## 失败与边界 ## 后续任务在这个项目中，AI 进入新的任务前，会先阅读协作入口文档、功能说明、验收记录和待办边界。这样可以减少重复调查，也避免一个 AI 推翻另一个 AI 的设计。
七、如何处理文件冲突
如果目标文件已经有其他未提交修改，AI 不应该直接覆盖。
推荐流程：
- 暂停写入。
- 查看当前
git status。 - 查看目标文件的定向 diff。
- 阅读最近的相关协作记录。
- 判断是同一功能的延续，还是两个设计发生冲突。
- 提出保守合并、局部重整或暂缓修改三种方案。
- 人确认后再改代码。
尤其需要小心以下区域：
- Unity 场景 YAML。
- 场景生成器。
- 主菜单控制器。
- 交易会话控制器。
- Runtime JSON 配置入口。
- PlayMode 总流程测试。
这些文件经常被多个功能共享，不能用“大范围格式化”来解决冲突。
八、任务优先级不能只按“看起来有趣”排序
我把任务分成四个优先级：
| 优先级 | 含义 | 示例 |
|---|---|---|
| P0 | 阻塞构建、验收或正式配置 | Runtime 预检、tick 审计、包体回归 |
| P1 | 直接影响主玩法 | 交易、家庭闭环、离线回归、继续游戏 |
| P2 | 支撑系统 | 存档事务、音频设置、辅助展示 |
| P3 | 长期扩展 | 档案馆、相册、小游戏、长线内容 |
档案馆和相册可能很有吸引力，但如果交易主循环还有问题，它们不应该抢占 P0/P1 的时间。
九、Git 提交方面的经验
早期提交可以快速推进，但后期需要增加提交粒度。
更理想的提交方式是：
一个任务编号 = 一组相关代码 + 对应测试 + 一份协作记录 + 一个清晰的 Git 提交这样出现回归时，可以更容易定位问题，也能让其他 AI 快速理解一次改动的范围。
十、第三篇小结
AI 协作的关键不是让 AI 获得更多自由，而是给它更清晰的边界、更小的任务、更明确的测试和更完整的交接记录。
下一篇会讨论一个随机游戏最难验证的问题：如何用固定种子和 Replay，让相同输入始终得到可以比较的结果。
📎 系列导航 & 互动引导
💡如果这篇对你有帮助，点个 赞 👍、收个 藏 ⭐、关个 注，更新不迷路～
有疑问或不同观点，欢迎在评论区一起聊。
- 上一篇：为什么我的 Unity 游戏先做纯 C# 内核？｜AI 游戏开发（二）：三层架构让 AI 改代码不再牵一发动全身
- 下一篇：随机游戏也能 100% 复现？｜AI 游戏开发（四）：固定种子 + Replay + 哈希，让偶发 Bug 无处可藏
- 专栏导读：和 AI 一起做游戏：18 天开发一款 Unity 模拟游戏（CSDN 6 篇连载导读）
标签：#AI编程 #任务拆解 #TDD #Prompt模板 #协作记录 #Unity测试
