用途：在遇到任何 bug、测试失败或异常行为时，先按四阶段框架定位根因，再提出修复，避免随机修补掩盖问题。核心原则是“未完成根因调查不得提出修复”。
主要能力：
- 根因调查：仔细阅读错误信息与堆栈、稳定复现问题、检查近期变更（git diff、提交、依赖、配置）、在多组件系统中于各组件边界加诊断日志以定位失败层、沿调用栈向上追踪数据来源。
- 模式分析：寻找可用的相似代码、完整阅读参考实现、列出工作与故障版本的全部差异、梳理依赖与配置假设。
- 假设与测试：提出单一明确假设，做最小改动验证，一次只改一个变量，验证后再继续。
- 实施修复：先写失败测试用例，再针对根因做单一修复，最后验证测试通过且未破坏其他测试。
使用方式：按阶段顺序执行，每阶段完成后再进入下一阶段。若修复失败，少于 3 次则回到阶段 1 重新分析；达到 3 次以上应停止并质疑架构，与人类协作者讨论。深层调用栈错误需配合 root-cause-tracing，编写失败测试需配合 test-driven-development。
适用场景：测试失败、生产缺陷、异常行为、性能问题、构建失败、集成问题，尤其在时间紧迫、看似只需“快速修复”、已多次尝试修复或尚未完全理解问题时。
限制：资料未提供安装命令、平台支持、收费方式或具体工具集成细节；文中提及的配套技能（如 root-cause-tracing、test-driven-development）需另行具备。若调查确认为环境、时序或外部因素，应记录调查过程并加入重试、超时、错误提示与监控，但资料指出约 95% 的“无根因”情况实为调查不完整。