实机反馈诊断链

何时触发

• 用户发来一批实机反馈（「死亡后还能掷骰」「看不到墓碑」这类现象描述）
• 修一个 bug 前要先证明根因，而不是先改代码再看

步骤

1. 先写结论摘要表：项号 / 结论 / 级别（代码级确认 / 待实测 / 无法确认）。先给结论，再给证据。
2. 逐环证据链：从用户操作 → 入口函数 → 关键分支 → 副作用，每一环写清 文件:行号 与判断条件。允许出现「这一环没跑」的结论。
3. 疑似排序：把「证据不足但可能」的假设按可能性排序，并给每条一个可验证现象（实机日志出现什么就说明是哪条）。
4. 修复计划：
   • 优先「单一入口」——把散落在多处的分支收敛成一个函数，避免修一处漏三处；
   • 列出所有调用点（行号），确认改完不漏；
   • 同步写断言：修复后哪条断言能兜住这个 bug 不复现。
5. 请对方复验时给清单：需要哪几行日志、看哪几个画面、什么算通过。别只说「你再试一下」。
6. 不改行为先定位：诊断阶段只定位不修，避免边查边改把证据搅乱。

验收

• 结论表每项都有级别标注
• 证据链精确到文件与行号，不是「可能在 X 里」
• 修复计划有调用点清单
• 修复后新增/复用了断言
• 复验清单可直接照着执行

坑

• 拿「用户说法」当根因：现象是症状，根因在链路某一环。
• 只贴代码片段不贴行号，下一轮自己都找不到。
• 边诊断边改，导致复现条件被破坏，最后说不清到底修好了没有。