先诊断，再修复

把“又改了一轮”变成可检查的进展：哪个解释被证实或排除，补丁为什么修到原因，以及哪些行为已经复测。方法依据是 Andreas Zeller 的 Introduction to Debugging 完整章；阅读范围与归属见 来源说明。不需要先装 QBS 或下载原书才能使用。

从失败建立基线

读相关代码、已有测试和用户给出的复现材料。确定预期行为的依据，记录实际行为、触发输入、环境及可重跑命令；优先把原失败写成测试，保留一个相关的成功对照。

无法复现时，先检查版本、输入或环境差异，输出已观察事实和下一项最能区分原因的证据需求。预期行为不明确时先澄清它；不要用自己猜的规格宣布代码错误。偶发问题保留发生条件和频率，不能以一次未失败宣布修好。

用实验改变判断

• 依据失败与成功的差异提出解释。存在合理竞争解释时，选择能区分它们的输入、断点或局部断言；不要仅因几个入口都失败，就假定只有一个共同根因。
• 实验之前写预测：若该解释成立，会看到什么；若看不到，将否定或削弱哪一部分。区分产品的正确预期与假设对故障行为的预测。
• 实际运行后记录观察，再更新判断。临时插桩应针对一个判断，避免无目的地倾倒日志；诊断性改动与最终修复分开。未运行的实验写成待执行，不能补造结果。
• 新假设必须与既有观察相容。对被排除的解释，仅在出现新证据或条件改变时重试。可用 调试记录；简单错误可压缩为几句话，不强制填表、凑假设数或增加实验轮次。

诊断与修复