诊断 Bug
在形成强理论之前，先构建一个快速、明确的通过/失败信号。从命令、输出、追踪和保存的工件中脱敏处理敏感信息。
循环
- 复现。 编写一个能触及用户确切症状、且可在该 Bug 上失败的命令。如果没有紧凑的复现方式，请阅读 references/feedback-loop.md。
- 最小化。 一次移除一个输入、步骤、调用者和配置。只保留失败所需的最小集合。
- 假设。 写出 3-5 个按优先级排序的可证伪原因。对于每个原因，指出哪些观察结果可以确认或推翻它。
- 探测。 每次只改变一个变量。优先使用调试器或在边界处进行有针对性的插桩。用独特的
[DEBUG-...]前缀标记临时日志。 - 锁定修复。 将最小的真实复现案例转化为在正确的公共接口处失败的回归测试。应用最小的修复。重新运行测试和原始复现命令。
- 清理。 移除临时插桩和测试工具。报告原因、证据、修复以及任何剩余的覆盖缺口。
规则
- 在两次失败的修复尝试后，停止。在尝试另一个补丁之前，重新检查假设或设计。不要堆叠猜测。
- 对于性能回退，在更改代码之前先测量基线并进行性能分析或二分查找。仅靠日志不足以诊断性能问题。
- 如果没有正确的测试接口，请明确指出。修复后，使用
$codebase-design判断缺失的接口是否需要结构性改进。 - 只有当原始症状消失且回归检查通过时，才能声称修复成功。