AI 协作工作流：从想法到可验证的结果
你不需要先成为 Unity 专家，才能让 AI 帮你开发。但需要能判断：它是否理解了需求，方案依赖什么，交付物怎样接进工程，结果怎样验证。
高效沟通的目标是减少隐藏假设，而不是把提示词写得很长。
一次协作的完整链
每一步都要有产出。例如“先检查方案”的产出是数据流、修改文件、所需组件和平台假设；不是一大段听起来合理但无法执行的解释。
先准备工程上下文包
目标：微信小游戏，竖屏 2D 网格合成。
当前版本：编辑器、渲染管线、输入包、微信SDK、关键插件。
工程结构：相关目录、场景层级、Prefab与配置的位置。
当前事实：已经完成什么，哪里是模拟实现。
本次需求：玩家动作、合法规则、失败规则、可见反馈。
约束：复用现有实现，不添加无必要依赖，不改无关功能。
交付：代码、编辑器配置、验证步骤、平台假设。
优先让 AI 读取当前代码与配置，而不是凭它对某个教程的记忆重建一套。涉及画面时提供参考图和行为说明；涉及错误时提供日志与复现。
按能验证的阶段拆分
以“合成后播放反馈并保存”为例：先规则正确，再视图正确，再交互正确，最后反馈与存档。每一步能在几条明确操作里验证，才适合独立交付。
避免一次要求 AI 完成玩法、商城、广告、云存档和所有适配。范围太大时，中间错误互相掩盖，你也很难知道哪些是真的完成。
审查时特别看 Unity 特有部分
后端习惯让你关注代码质量，但 Unity 工程还有场景、Prefab、序列化引用、导入设置和包版本。
| 审查点 | 向 AI 追问 |
|---|---|
| 生命周期 | 初始化、重复启用、退出时分别做什么？ |
| 引用配置 | 谁把哪个对象拖进哪个字段？缺失如何报告？ |
| 平台依赖 | 哪个 API 在当前微信组合中已核实？ |
| 状态所有权 | 谁能修改分数、棋盘和奖励？ |
| 异步与中断 | 请求晚到、取消、销毁如何处理？ |
| 性能 | 哪些工作每帧执行？是否有测量依据？ |
不接受无法验证的“已完成”
“代码已写好”“编辑器能编译”“在微信 Android 上测试成功”是不同证据。让 AI 分别报告实际执行了什么、观察到什么，以及哪些步骤还需要你操作。
如果 AI 无法控制 Unity 编辑器，它仍可以写代码、列操作和检查文件，但不能因此声称场景已运行或真机已通过。你负责执行需要真实环境的部分，再把证据回传。
错误反馈的最短有效格式
环境是……；按这三步操作……；期望……；实际……；第一条异常和堆栈是……；相关对象配置与状态是……。请先解释根因和影响范围，再给最小修复，并回归原步骤。
修复时尽量一次只改变一个原因。AI 如果建议“等待一秒再初始化”，要追问真正的依赖顺序；如果建议“忽略异常”，要追问状态是否仍然正确。