验收：怎样知道 AI 真的实现了需求
验收不是读完代码说“看起来合理”，而是用具体条件运行一次，并检查结果。你越早写验收，AI 越少替你猜规则。
一条验收应包含四件事
给定状态 → 执行动作 → 预期结果 → 观察证据。
例如：“给定 0、1 号格都是一级物品，拖动 0 到 1，期望源格清空、目标升到二级、分数增加 10；观察棋盘数据、画面与存档。”
不要只写“合成正常”。它没有定义对象、规则和结果，也无法解释失败在哪里。
合成案例的验收矩阵
| 条件 | 动作 | 预期 |
|---|---|---|
| 同级非空且未达上限 | 拖到目标格 | 一次合成，一次加分 |
| 不同等级 | 放下 | 状态不变，返回原位 |
| 同格或棋盘外 | 放下 | 不计分，不丢物品 |
| 正在拖动 | 进入后台 | 取消并能恢复输入 |
| 正在反馈 | 切换界面 | 清理动画，规则结果仍正确 |
| 已保存局面 | 重启 | 恢复同一业务状态 |
| 存档损坏 | 启动 | 有可解释的回退，不无限报错 |
| 奖励回调重复 | 再次通知 | 同一权益不重复结算 |
分层验证，避免错误承诺
每一层回答的问题不同。纯规则测试不验证输入命中；编辑器不验证微信音频策略；开发者工具也不替代所有真机性能。报告应写清真正通过的层级。
本手册中的 GIF 与 SVG 是教学示意；C# 示例按章节标明独立类、完整组件或片段，未作为完整 Unity 工程进行真机验证。
工程交付也要验收
检查是否有新增依赖、是否修改了无关文件、场景与 Prefab 是否保存、必要 .meta 是否一起提交。确认 Inspector 没有 Missing 引用，Console 没有被忽略的错误。
构建产物要能追溯到源代码提交和版本组合。需要恢复时，知道哪个提交、哪个资源版本和哪个配置曾通过验证。
性能与体验用可观察语言
“流畅”“好看”“加载快”需要补充目标设备和场景。比如：“在目标低端机连续合成 5 分钟，记录帧时间峰值与内存；触摸不丢输入，棋盘不闪烁。”
不要编造通用的毫秒和内存标准。根据玩法、设备、商业需求和现有测量设定预算，再比较改动。
最终交付记录
本次需求与提交：
实际修改：代码、场景、Prefab、配置、依赖。
通过的验证：环境、步骤、观测结果。
失败或未验证：原因、影响、下一步。
平台与版本假设：
恢复方式：