用途：用于修复缺陷、排查失败或用户报告错误与异常行为时，按严格流程定位并修复问题。核心原则是：未完成根因调查前不得提出修复方案，症状式修补会浪费时间并引入新缺陷。
主要能力：分为四个阶段。阶段一为根因调查：阅读错误信息与堆栈、稳定复现、检查近期变更（git diff、提交、依赖、配置）、在多组件系统中于各边界加诊断日志、沿数据流回溯到错误值来源。阶段二为模式分析：寻找可用的相似代码、完整阅读参考实现、列出可用与故障路径的差异、确认依赖。阶段三为假设与最小验证：写出单一具体假设，做最小改动、一次只变一个变量，验证成立则进入阶段四，否则重新提出假设。阶段四为实施：先建立失败测试或复现，再实施单一修复，验证测试通过且未破坏其他测试。
使用方式：当用户报告缺陷、错误或“不工作”，出现测试、构建或集成失败，出现异常行为或性能问题，或用户要求调试、找缺陷、追问原因时启用。若已尝试三次以上修复且每次暴露新问题，应停下质疑架构并与用户讨论，而非继续第四次猜测。
限制与注意：资料未提供具体安装命令、平台或收费信息。若调查后确认无根因（环境、时序或外部因素），应记录调查内容、加入重试、超时或清晰错误提示，并补充日志与监控；多数“无根因”实为调查不完整。输出应包含根因与修复的清晰说明、建议的回归测试或现有测试覆盖确认，以及作为单独说明的后续事项，不把无关改动混入修复。