如何把 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(){ReplayReportreportRunScenario();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测试