用途：当缺陷原因未知时，用一系列实验逐步缩小可能解释的范围，而不是靠猜或通读代码。适用于已报告缺陷、间歇性测试失败、环境间行为差异、性能或内存回退、以前可用现在失效，以及用户追问运行中代码“为什么会这样”的情况。若原因已知，则跳过本流程直接修复。
主要能力与核心概念：先复现再读代码，可靠复现是调试中价值最高的产物；每步提出假设、预测可观察后果，并运行最便宜且能证伪它的实验；用二分法缩小搜索空间，可对提交（git bisect）、输入、调用栈或配置进行二分；追根因而非症状，持续追问是什么产生了当前状态。
使用方式：1）精确记录报告，包括期望、实际、版本、环境、输入、时间戳、用户及 trace 或 correlation id；2）复现并简化到确定且快速，例如 git checkout v4.11.2，LOG_LEVEL=debug pytest -q tests/test_invoices.py::test_eu_vat -x --tb=long 2>&1 | tee /tmp/repro.log；3）把复现写成失败测试；4）先读已有证据，如堆栈、日志、git log；5）二分，如 git bisect start、git bisect bad HEAD、git bisect good v4.9.0、git bisect run pytest -q tests/test_invoices.py::test_eu_vat、git bisect reset；6）在怀疑边界加高信号临时日志；7）通过控制变量确认能随意开关失败；8）修复后验证测试由失败转为通过；9）扩大检查同类原因；10）记录为何现有测试、类型或评审未捕获。
间歇性测试：先量化失败率，如 pytest tests/test_sync.py::test_ordering --count=200 -x -q 或 go test -run TestOrdering -count=200 -race ./...；再归类为顺序依赖、时间、并发或外部状态，并修复根因。隔离需有负责人和截止时间。
最佳实践与限制：一次只改一处；记录每个假设与结果；超时后切换策略；性能问题以测量为准；保留复现作为回归测试；优先用调试器和结构化日志。反模式包括未复现就改代码、只修症状、散弹式调试、先怪平台、信任重跑变绿、修好后删除复现。资料未提供具体收费、平台支持范围或安装命令等信息。