用途：把调试从“读代码猜原因”变成基于运行证据的流程，防止在未定位根因前就提交结论或提出修复。
核心门槛：只有运行时证据（从运行中程序读到的值）表明某状态位于失败路径上，才允许得出“bug 在 file:line”的结论；否则任何“一定是 X”都只是待验证假设。
四阶段循环：
- 复现：构造可随时触发的命令、输入或测试，并保留失败输出。无法复现时，差异本身（如 CI 失败本地通过）指向环境、版本、数据或时序差别，应追查该差异。
- 隔离：二分缩小至最小失败面，可对输入减半、禁用半数步骤、git bisect 定位引入提交；再切一刀失败消失处即边界。
- 定位：在边界放置临时探针（日志、断点、断言）并重跑，读取真实变量值、实际执行分支与调用顺序；结论以探针输出为准，定位后移除探针。
- 验证：应用修复后重跑第一阶段复现，必须通过；并用一句话说明修复到观测值变化的因果链。项目有测试套件时，补一个修复前失败、修复后通过的测试。
常见陷阱：先改代码验假设；只修症状不追溯坏值产生处；未弄清原因就删复现；把调试探针留在提交中；修复后一次通过就当证明。
限制：该技能靠自我约束，编辑时无强制机制；仅适用于确定性缺陷。间歇性失败属非确定性问题，需改用 fix-flaky-test。其他未提供。