用途：在遇到任何缺陷、测试失败或意外行为时，先调查根因再提出修复。核心理念是不先猜测就动手，并把已验证的修复与临时缓解区分开；事件处理中可先执行经授权的回滚或遏制以恢复服务，同时保留证据供后续根因调查。
主要能力：提供四阶段流程。阶段一为根因调查：仔细阅读错误信息与完整堆栈，确认能否稳定复现，检查最近变更（git diff、提交、依赖、配置），多组件系统中在各边界加入诊断插桩，只记录字段名、大小、状态和关联 ID，记录前先脱敏，并沿调用栈逆向追踪数据流，在源头而非症状处修复。阶段二为模式分析：找同代码库中可工作的相似实现，完整阅读参考实现，列出工作与损坏之间的每处差异，理解依赖与假设。阶段三为假设与测试：一次只写一个明确假设，做最小改动、单变量测试，验证后再继续；不成立则形成新假设，不在旧假设上叠加修复。阶段四为实现：先建立最小可复现的失败测试（有框架则自动化），只做一处根因修复，不夹带重构，再验证测试通过与未破坏其他测试。
使用方式与限制：若修复连续三次以上仍失败，应停止并质疑架构与假设，与人类协作者讨论后再继续，而不是尝试第四次修复。文中给出的多组件排查示例包括仅检查环境变量是否存在而非输出取值，以及用 codesign --verify --verbose=2 "$APP" 验证已构建产物，但产物验证本身不能证明正确的签名身份已传递。日志可能泄露密钥或个人路径，应使用白名单摘要并检查产物后再分享。辅助技术包括 root-cause-tracing.md 逆向追踪、defense-in-depth.md 根因后多层校验、condition-based-waiting.md 用条件轮询替代任意超时；相关技能为 test-driven-development。若调查确认为环境、时序或外部因素，应记录调查过程、剩余不确定性及可区分环境故障与实现缺陷的证据，并加入适当处理与监控。资料未提供安装命令、收费和平台信息。