systematic-debugging

name	systematic-debugging
description	遇到 bug、测试失败、异常行为、Unity 报错或用户反馈问题时使用；先锁定原始症状和根因，再修复。

Systematic Debugging（系统化排查）

铁律

没有根因调查，不得修复。没有命中用户原始症状，不得声称修复原 bug。

阶段 1：保真症状

• 原样保留用户描述里的关键限定词和数量范围，例如“全部消失”“最多 5 个”“锁定后”“对方骰子”“只在手机端”。
• 写清当前证据命中的症状。
• 对比两者是否一致；不一致时只能继续取证或说明差异。

阶段 2：锁定真相源

• 读取完整错误、日志、测试输出或 Unity Console。
• 复现步骤必须可靠；不能复现就补证据，不猜。
• 多组件链路必须查边界输入输出，先定位在哪一段断。
• 数据问题要追到源头，不在显示层或兜底层掩盖。

阶段 3：对照工作样例

• 找同仓库内正常工作的相似代码或资源。
• 完整读取参考实现，不只抄局部片段。
• 列出工作样例和异常样例的差异。

阶段 4：单一假设验证

• 一次只提出一个具体假设。
• 用最小证据验证假设。
• 假设失败后换假设，不叠加补丁。
• 连续三次修复失败，停止继续堆补丁，质疑架构或请求用户决策。

阶段 5：实施与验收

• 高风险或可测试逻辑先写失败测试或最小复现。
• 只修根因，不顺手重构。
• 验收回到用户原始症状。
• 如果只是止血或缓解，必须明确标注，不得称为根因修复。