用途
本技能用于系统化调试：当出现缺陷、不稳定测试或运行时/构建失败时，在提出任何修复之前，先完成根因追踪，并在附近扫描是否存在相同签名的重复模式。其核心理念是：随机修复浪费时间并制造新缺陷，快速补丁会掩盖底层问题。核心原则是——始终先找到根因再尝试修复，只修复症状属于失败。
该技能在 v10 中属于建议性技能，用于加深调查质量，不授权仅做局部补丁、凭猜测或“修复崩溃的那一行”的思维方式。
主要能力
- 四阶段调查工作流：根因调查、模式分析、假设与测试、实施修复。
- 根因追踪技术：观察症状 → 找到直接原因 → 追问“谁调用了它” → 沿调用链向上追踪 → 找到原始触发点。
- LSP 辅助的根因追踪：使用 lspGotoDefinition、lspCallHierarchy（incoming/outgoing）、lspFindReferences 系统化追踪执行流。
- 假设置信度评分：维护 2-3 个假设并标注 0-100 置信度，80-100 可进入修复，50-79 需继续测试，0-49 应降级或丢弃。
- 认知偏差防范：确认偏差、锚定、可得性、沉没成本。
- 重启调查协议：2 小时无进展、3 次以上修复无效、无法解释当前行为、修复生效但不知原因时，应重启调查。
- 架构升级判断：3 次以上修复失败时，应质疑架构而非继续修复症状。
- 参考文件：references/root-cause-playbooks.md（构建/类型失败、不稳定测试、运行时崩溃、浏览器错误、git bisect、边界追踪）与 references/investigation-hygiene.md（上下文纪律、证据记录、假设跟踪、重启协议、架构升级）。
使用方式
按四阶段流程执行，每个阶段完成后方可进入下一阶段。
阶段一：根因调查。在尝试任何修复之前：仔细阅读错误信息与完整堆栈；稳定复现问题；检查近期变更（git diff、提交、依赖、配置、环境差异）；在多组件系统中于每个组件边界添加诊断埋点，记录进入与离开的数据、验证环境/配置传播、检查各层状态；沿调用栈向上追踪数据流直到源头；追踪配置到其消费者（第三方 SDK、环境变量、导入时行为）。在提出替换、迁移或大规模重构之前，先执行“选项零”：能否仅通过配置或环境变更修复？先陈述并测试该假设。
阶段二：模式分析。寻找可工作的相似代码；完整阅读参考实现；列出工作与损坏之间的每一处差异；理解依赖、设置、配置、环境与假设。
阶段三：假设与测试。形成单一明确假设（“我认为 X 是根因，因为 Y”）；做最小改动测试，一次只改一个变量；验证后再继续。假设需可证伪，避免“状态有问题”“时序不对”这类不可证伪的表述。
阶段四：实施修复。先创建失败测试用例（最简单复现，尽可能自动化）；实施单一修复，只针对已确认的根因，一次一个改动，不做“顺便”改进或捆绑重构；验证修复：测试通过、其他测试未被破坏、问题确实解决。若修复无效：若少于 3 次，返回阶段一用新信息重新分析；若达到或超过 3 次，停止并质疑架构，与人类伙伴讨论后再尝试更多修复。
输出格式：按“缺陷调查”结构输出，包含阶段一证据（错误、堆栈、复现、近期变更）、阶段二模式分析（工作示例、关键差异）、阶段三假设（理论、测试、结果）、阶段四修复（根因、变更、文件路径:行号、回归测试）以及验证（测试命令、全部测试、功能恢复）。
适用场景
适用于任何技术问题：测试失败、生产缺陷、意外行为、性能问题、构建失败、集成问题。尤其在以下情况使用：时间压力大、看似“只需一个快速修复”、已尝试多次修复、上次修复无效、不完全理解问题。不应因问题看似简单、时间紧迫或管理者要求立即修复而跳过流程。
当失败匹配以下形态时，阅读 references/root-cause-playbooks.md：构建或类型破坏、测试失败、运行时崩溃、浏览器或控制台错误、间歇性异步缺陷、“以前能用”的回归、多组件交接失败。
限制
本技能为建议性，不授权仅做局部补丁或凭猜测修复。若系统化调查后确认问题确属环境、时序或外部因素，应记录调查内容、实施适当处理（重试、超时、错误信息）并添加监控/日志；但 95% 的“无根因”情况属于调查不完整。关于具体命令、边界追踪模式与 git-bisect 配方，需查阅参考文件。