用途：在遇到任何技术问题时使用，包括测试失败、生产环境 Bug、异常行为、性能问题、构建失败与集成问题，尤其适用于时间紧迫、看似只需“快速修复”、已多次尝试修复或尚不理解问题本质的情形。
核心原则：在尝试修复前必须先找到根因，只治症状视为失败。铁律是“未完成根因调查前不得提出修复”。
四个阶段：第一阶段根因调查，仔细阅读报错与完整堆栈，稳定复现问题，检查近期改动，多组件系统需在各边界加诊断日志收集证据，并沿调用栈回溯数据流，定位坏值来源。第二阶段模式分析，寻找同类可工作代码，完整比对参考实现，列出工作与故障之间的全部差异，理解依赖与假设。第三阶段假设与验证，提出单一明确假设，做最小改动只改一个变量，验证后再继续；若不知原因应如实说明并求助。第四阶段实施，先建失败测试用例，再实施单一修复，验证修复且不破坏其他测试。若修复失败少于 3 次回到第一阶段；达到 3 次以上应质疑架构，与人类伙伴讨论，而非继续尝试第 4 个修复。
危险信号：如“先快速修一下以后再说”“试试改 X 看行不行”“一次改多处再跑测试”“跳过测试手动验证”等，均应立即停下回到第一阶段。当有 3 次以上修复失败，说明可能是架构问题。
若系统化调查确认问题确属环境、时序或外部因素，可记录调查内容、采取重试/超时/错误提示等处理并补充监控日志；但 95% 的“无根因”案例实为调查不完整。
配套技术包括根因回溯、纵深防御、基于条件等待；相关技能为测试驱动开发与完成前验证。资料称系统化方式通常 15-30 分钟修复，随机修复需 2-3 小时。使用方式、安装命令与具体平台信息暂未提供。