NinjaSln-labs Problem Dive（问题深挖方法论）
适用：任何「收到问题/异常/体验反馈」后的处理——不直接修，先深挖再求真再落地。 通用化：方法论与工具解耦——调研渠道、证据形态、项目语境均为运行时可适配参数。
触发时机
用户反馈以下类型时立即进入本流程（不直接动手改）：
- 「体验完毕/体验终止」+ 反馈
- 「有问题/报错/卡住/失败/异常/不太对」
- 「先看看日志/记录/会话」「分析一下」「怎么回事」「根因是什么」
- 「我说/我发现 X 有问题」
核心原则（七条）
- 证据 > 印象——先看日志/记录/trace 还原现场，不凭印象猜
- 根因 > 症状——现象→根因→根因的根因（为什么×N），假设必须实测证伪验证
- 通用 > 特判——不兜底/白名单穷举——找通用机制（修环境不修命令、修配置不修单例）
- 调研 > 直觉——个人理解只是假设——多源交叉验证（≥2 独立渠道 + 官方文档 + 源码 + 实测）→ 找最合适方案
- 语境 > 抽象——方案放当前项目/环境语境下检验（多项目并行/宿主隔离/环境统一）
- 小步 > 大改——决策清单 → 从简单的一个一个来（不一次堆一堆）
- 闭环 > 发散——改完盘点「还剩下什么没解决」——持续闭环
五阶段 11 步
阶段① 现场还原（证据先行）
- 先看证据——先读日志/记录还原现场，不凭印象猜。证据形态按可观测性成熟度取用：
结构化日志（
tail <log> | jq类）→ 关联 trace/span 链（事件先后与因果）→ metrics（异常检测/基线对比）→ 复现路径。有 trace 链时按链读，不只 grep 单点日志 - 顺序全读——按时间顺序完整读会话/记录，不只盯一个点——找全问题
- 深挖实例——到早期对话/连续操作/具体卡点找证据（连续调用找重复、授权记录找重复授权）
阶段② 根因深挖（不停在表面）
- 根因追问——现象→根因→根因的根因（「工具不可用」→「为什么」→「返回什么」→ 实测定位）——每层都问「为什么」。 追问同时问直接诱因与潜伏条件（环境/流程/工具层——「修环境不修命令」是潜伏条件思维）。 可选 RCA 工具映射（按复杂度取用）：5 Whys（简单线性）→ 鱼骨图/Ishikawa（多候选因素）→ 故障树 FTA（条件组合）→ Kepner-Tregoe IS/IS NOT（划现象边界：是什么/不是什么、何时/何时不）
- 实测证伪——不猜：把根因假设变成可证伪预期，跑实验验证。倾向设计能推翻假设的实验（Popper）； 二分/最小化验证（delta debugging 思想：缩小到最小失败输入）而非穷举。 每个被采纳的根因至少找一条不支持它的证据（反例搜索）——防确认偏差
4 ↔ 5 是迭代循环，不是一次线性通过：追问产出根因假设清单 → 逐条实测证伪 → 不收敛则回到 4 继续追问（假设被推翻 = 进展，不是失败）。
证据不足分支：无日志/无法复现时——显式标记
unverified，向用户索取复现路径/环境信息，缩小输入重试； 拿不到证据就不给根因结论（「无法复现」本身是有效结论，继续分析 = 编造）。
阶段③ 方案求真（不将就）
- 拒绝特判——不要兜底/特判/白名单穷举（「现在是 X，其它情况呢？你能穷举完吗」）——找通用机制； 用二分/谱定位缩小可疑面（穷举的对立面）
- 尽调调研——多源交叉验证：独立检索渠道（≥2 个互不依赖的来源）+ 同类实现源码 + 官方文档 + 实测——≥2 独立源一致才定方案
- 项目语境检验——方案放当前项目/环境语境下检验：多项目并行/宿主隔离/环境统一/从头到尾单源——抽象方案必须过现实检验
- 完整性审视——确认后还问：记录？复用？从头到尾统一？（解决即沉淀——KCS 视角：这次解法是可复用知识还是又一次特判？）
阶段④ 落地节奏
- 决策清单 + 小步推进——「待决策列出」：每个问题的现象/根因/候选方案表 → 用户选 → 从简单的一个一个来（「不要着急改」「先分析」时尤其等确认）
阶段⑤ 闭环
- 持续盘点——「还剩下什么没有解决」——按严重度列表，用户选下一步——不遗漏、持续闭环
认知偏差防御（贯穿 ②③）
| 偏差 | 防御 |
|---|---|
| 确认偏差（只采信支持先验的数据） | 每个根因假设列可证伪预期 + 至少一条 non-confirmatory 证据；主动找反例 |
| 锚定（首因印象锁死） | 阶段①完整顺序读后再下结论；IS/IS NOT 划边界防过早锚定 |
| 可得性（最近/最显眼的当根因） | 候选原因按证据强度排序，不按「刚见过」排序 |
输出形式（每阶段）
- ①-③：分析汇报（现象/证据/根因/方案对比 + 反例清单）——不修，等用户确认
- ④：决策清单（编号 + 现象/根因/候选方案 + 推荐优先级）
- ⑤：未解决问题盘点表（已解决 ✓ / 未解决 按严重度）
关键追问（触发提示——用户推动深挖时对应到阶段，流程本身自足可跑）
| 用户的话 | 含义 |
|---|---|
| 「先看看日志/记录」 | 阶段①——证据先行 |
| 「按顺序读先」 | 阶段①步2——完整读，找全问题 |
| 「重点看连续的工具调用」 | 阶段①步3——深挖具体实例 |
| 「根因是什么」 | 阶段②——继续追问为什么 |
| 「不要兜底，你能穷举完吗」 | 阶段③步6——拒绝特判，找通用 |
| 「要你尽调调研」 | 阶段③步7——多源交叉验证 |
| 「放当前项目下呢」 | 阶段③步8——语境检验 |
| 「是不是需要记录」 | 阶段③步9——完整性审视 |
| 「待决策列出」 | 阶段④——决策清单 |
| 「从一个一个来」 | 阶段④——小步推进 |
| 「还剩下什么没解决」 | 阶段⑤——持续盘点 |
反模式
- 收到反馈直接动手改（跳过程序）
- 只看问题局部不完整读记录（漏问题）
- 停在表面症状（不追根因；只找直接诱因不找潜伏条件）
- 用特判/白名单（穷举不完）
- 单源调研当结论（无独立双源交叉验证）
- 假设只找支持证据（确认偏差——不做反例搜索）
- 方案不检验项目语境（漏多项目/宿主/统一）
- 一次改一堆（「不要着急改」）
- 改完不复盘（漏剩余问题）
与相邻技能的关系
| 技能 | 边界 |
|---|---|
problem-dive（本技能） |
收到问题/体验反馈后的深挖方法论——先证据、根因、调研、决策清单，不直接修 |
systematic-debugging |
已定位为代码缺陷后的根因调查协议（复现→假设→验证） |
problem-resolution-flow |
从症状到修复上线的端到端流水线（定位→分级→调研→修→验证→收尾）——本技能产出方案后移交 |
顺序：反馈进来先走本技能；代码路径内调用 systematic-debugging；方案确认后走 problem-resolution-flow 落地收尾。
方法论来源（2026-08 调研）
- RCA 工具谱系：丰田 5 Whys、Ishikawa 鱼骨图、FTA、Kepner-Tregoe IS/IS NOT（kepner-tregoe.com）
- 事故调查/安全工程：James Reason Swiss Cheese（active/latent failure）；HFACS 人因分层
- 可观测性工程：OpenTelemetry（logs/metrics/traces 统一与 span 关联）；Honeycomb high-cardinality 调试视角
- 证据驱动调试：Zeller delta debugging（二分最小失败输入——TSE 2002）；Why Programs Fail（假设→预测→实验）
- 认知偏差：软件工程中 confirmation bias/anchoring/availability 实证（arXiv 2508.11278）；traceability 缓解偏差（ACM CACM）
- 科学方法：Popper 证伪主义（设计能推翻假设的实验）
- 知识沉淀：KCS（Knowledge-Centered Service）Solve/Evolve 循环——解决即沉淀，反哺复用