investigate

name	investigate
description	遇到 Bug、测试失败或异常行为时使用，在提出修复之前强制执行根因分析。

系统性调试 (Investigate)

概览

四阶段根因分析流程，确保在定位根因之前不做任何修复。铁律：没有根因就不能打补丁。

何时使用

• 测试失败或构建失败。
• 生产环境报错、性能退化、数据不一致。
• 并发问题（死锁、竞态条件、数据竞争）。
• 任何"不知道为什么坏了"的场景。

核心流程

Phase 1: 调查 (Investigate)

• 复现问题，拿到可重复的 repro（命令、输入、环境）。
• 收集证据：错误日志、堆栈跟踪、指标变化、相关 diff。
• 确定范围：哪些模块 / 服务 / 表受影响，哪些不受影响。

Phase 2: 分析 (Analyze)

• 梳理数据流：输入 -> 处理 -> 存储 -> 输出，定位断裂点。
• 时间线分析：什么时候开始坏的，之前发生了什么变更。
• 排除法：用二分或隔离手段缩小范围。

Phase 3: 假设 (Hypothesize)

• 构造 1-3 个假设，按可能性排序。
• 为每个假设设计验证实验（最小成本的验证优先）。
• 逐一验证，新证据否定假设时立即更新。

Phase 4: 实施 (Implement)

• 仅在根因确认后才开始修复。
• 修复必须附带回归测试，覆盖根因触发条件。
• 验证修复不引入新问题（运行完整测试套件）。

后端 / 数据库特化

场景	调查手段
慢查询	EXPLAIN ANALYZE, pg_stat_statements, slow query log
锁竞争	pg_locks / SHOW ENGINE INNODB STATUS / deadlock log
数据不一致	对账查询, WAL/binlog 回溯, 事务隔离级别检查
内存泄漏	pprof / heaptrack / jmap + GC 日志
连接池耗尽	连接数监控, idle connection 审计, 泄漏连接追踪

快速参考

阶段	产出	禁止事项
调查	可重复的 repro	禁止猜测性修复
分析	断裂点定位	禁止跳过数据收集
假设	排序后的假设列表	禁止只看一个假设
实施	修复 + 回归测试	禁止无测试的修复

与 systematic-debugging 的关系

本 skill 是后端/数据库场景的特化补充，不替代 superpowers:systematic-debugging。两者配合使用：

• systematic-debugging：提供行为纪律（红旗清单、单变量测试、3 次失败升级架构讨论、修复前先写失败测试）。
• investigate：提供后端特化的调查手段和工具（慢查询、锁竞争、数据不一致等）。

常见错误

• 没有 repro 就开始修：修了也无法验证，容易反复。
• 只看症状不看根因：补丁式修复，问题换个姿势再现。
• 假设锚定：第一个假设看起来合理就不再验证其他可能。
• 修复后不跑全量测试：修 A 破 B。

质量评估标准

以下为二元（pass/fail）评估项，用于验证本 skill 输出质量。可配合 autoresearch 工具自动化运行。

EVAL 1: 可重复的 repro
问题: 调查阶段是否产出了可重复触发问题的具体步骤（命令、输入、环境）？
Pass: 给出了明确的复现步骤，第三方可以按步骤独立复现
Fail: 只有问题描述，没有具体复现步骤，或步骤不完整

EVAL 2: 根因先于修复
问题: 是否在明确根因之后才开始编写修复代码？
Pass: 存在明确的根因陈述（"问题是因为 X"），且修复代码出现在根因陈述之后
Fail: 在定位根因之前就开始修改代码，或没有明确的根因陈述

EVAL 3: 多假设验证
问题: 是否构造了至少 2 个不同的假设并逐一验证？
Pass: 列出了 2 个以上假设，每个假设都有对应的验证步骤和结果
Fail: 只有 1 个假设，或假设没有验证就直接采纳

EVAL 4: 回归测试
问题: 修复是否附带了覆盖根因触发条件的回归测试？
Pass: 新增或修改了测试，且测试直接覆盖了导致 bug 的条件
Fail: 没有新增测试，或测试与根因无关

EVAL 5: 全量测试通过
问题: 修复完成后是否运行了项目的完整测试套件并展示通过结果？
Pass: 展示了完整测试运行的实际输出，全部通过
Fail: 没有运行测试，或只运行了部分测试，或有测试失败