用途：从一个已观测到的失效现象出发（界面异常、多余日志、性能回退、截图或线上症状），先把问题变成可反复验证的信号，再定位并修复根因。
六个阶段：1）建立紧凑反馈回路——单元/集成/e2e 失败测试、curl 脚本、CLI 夹具对比、无头浏览器脚本、重放抓包、临时 harness、属性/模糊测试、二分法或差分回路，人机交互脚本为最后手段；2）复现，确认症状与用户描述一致且可重复（非确定性缺陷追求更高复现率）；3）先列出 3-5 个可证伪的排序假设，并结合仓库近期提交、议题与架构记录；4）插桩，每个探针对应一条预测，优先调试器/REPL，其次定点日志，日志需带唯一前缀如 [DEBUG-a4f2] 便于统一清理；性能类问题先建基线再二分；5）先写回归测试（仅当存在正确测试缝）再做最小修复，随后重跑第一阶段回路验证；6）清理插桩、删除临时原型、记录正确假设，并在提交信息或 PR 中说明，检查是否需架构改进。
限制：第一阶段为硬性门槛，无法构建回路时不应进入假设阶段，而应说明已尝试内容并索取环境访问、抓包或日志、生产插桩许可；不做盲目重试；不修症状而非根因；不在修复中重构；若无正确测试缝，应将其作为架构发现记录而非强行添加错误位置的测试。经过 3 轮假设-验证仍未命中时，应回到第三阶段重新勘察、收紧回路或转向重新规划。缺少相邻工具（TDD 助手、无头浏览器、议题跟踪器等）时优雅降级，按内置指引继续。