---
name: problem-dive
description: >-
  收到问题/异常/体验反馈时的问题深挖方法论：先看证据（日志）→ 顺序全读会话找全问题 →
  根因追问（为什么×N + 实测验证不猜）→ 拒绝特判/穷举（找通用机制）→ 尽调调研（多源交叉验证：
  tavily+serper 双引擎+竞品源码+官方文档+实测）→ 项目语境检验（多项目/隔离/统一）→ 完整性审视
  （记录/复用/单源）→ 决策清单+小步推进 → 持续盘点闭环。当用户反馈「体验完毕」「有问题」「报错」
  「卡住」「失败」「异常」「先看看」「分析一下」「怎么回事」等触发。产出：根因+最合适方案+小步落地。
---

# Problem Dive（问题深挖方法论）

> 来源：NeonForge 多轮体验反馈迭代实践（2026-08-06 提炼）——用户引导的问题处理路径。
> 适用：任何「收到问题/异常/体验反馈」后的处理——**不直接修**，先深挖再求真再落地。

## 触发时机

用户反馈以下类型时**立即进入本流程**（不直接动手改）：
- 「体验完毕/体验终止」+ 反馈
- 「有问题/报错/卡住/失败/异常/不太对」
- 「先看看日志/记录/会话」「分析一下」「怎么回事」「根因是什么」
- 「我说/我发现 X 有问题」

## 核心原则（七条）

1. **证据 > 印象**——先看日志/记录还原现场，不凭印象猜
2. **根因 > 症状**——现象→根因→根因的根因（为什么×N），假设必须实测验证
3. **通用 > 特判**——不要兜底/白名单穷举——「你能把所有工具都穷举吗」——找通用机制（修环境不修命令）
4. **调研 > 直觉**——个人理解只是假设——多源交叉验证（tavily+serper 双引擎 + 竞品源码 + 官方文档 + 实测 ≥3 源）→ 找最合适方案
5. **语境 > 抽象**——方案放当前项目下检验（多项目并行/宿主隔离/从头到尾统一）
6. **小步 > 大改**——决策清单 → 从简单的一个一个来（不一次堆一堆）
7. **闭环 > 发散**——改完盘点「还剩下什么没解决」——持续闭环

## 五阶段 11 步

### 阶段① 现场还原（证据先行）
1. **先看证据**——体验后先读日志/记录还原现场，不凭印象猜（如 `tail 日志 | jq` 结构化读）
2. **顺序全读**——按时间顺序完整读会话，不只盯一个点——找全问题（用户说「按顺序读先」时尤其）
3. **深挖实例**——到早期对话/连续工具调用/具体卡点找证据（如：连续工具调用找重复、授权记录找重复授权）

### 阶段② 根因深挖（不停在表面）
4. **根因追问**——现象→根因→根因的根因（「工具不可用」→「为什么」→「返回什么」→ 实测定位）——每层都问「为什么」
5. **实测验证**——不猜：跑实验证伪/证实假设（如 `vite --port 0` 实测落 5173、受限 PATH 实测 command not found）——**实测结果优先于文档/直觉**

### 阶段③ 方案求真（不将就）
6. **拒绝特判**——不要兜底/特判/白名单穷举（「现在是 vite，其它语言工具呢？你能穷举完吗」）——找**通用机制**（如修环境 PATH 注入，不修具体命令）
7. **尽调调研**——个人理解只是假设——多源交叉验证：tavily + serper（独立引擎双源）+ 竞品源码（同类 agent 仓库）+ 官方文档 + 实测——≥3 源一致才定方案
8. **项目语境检验**——方案放当前项目下检验：多项目并行/宿主隔离/环境统一/从头到尾单源——抽象方案必须过现实检验（用户「你放到当前项目下呢」）
9. **完整性审视**——确认后还问：记录？复用？从头到尾统一？（如环境：检测→记录→使用单源——检测时确认的环境=使用时用的环境）

### 阶段④ 落地节奏
10. **决策清单 + 小步推进**——「待决策列出」：每个问题的现象/根因/候选方案表 → 用户选 → **从简单的一个一个来**（不一次做一堆——用户「不要着急改」「先分析」时尤其要等确认）

### 阶段⑤ 闭环
11. **持续盘点**——「还剩下什么没有解决」——按严重度列表，用户选下一步——不遗漏、持续闭环

## 输出形式（每阶段）

- ①-③：**分析汇报**（现象/证据/根因/方案对比）——不修，等用户确认
- ④：决策清单（编号 + 现象/根因/候选方案 + 推荐优先级）
- ⑤：未解决问题盘点表（已解决 ✓ / 未解决 按严重度）

## 关键追问（用户常用来推动深挖）

| 用户的话 | 含义 |
|---------|------|
| 「先看看日志/记录」 | 阶段①——证据先行 |
| 「按顺序读先」 | 阶段①步2——完整读，找全问题 |
| 「重点看连续的工具调用」 | 阶段①步3——深挖具体实例 |
| 「根因是什么」 | 阶段②——继续追问为什么 |
| 「不要兜底，你能穷举完吗」 | 阶段③步6——拒绝特判，找通用 |
| 「要你尽调调研」 | 阶段③步7——多源交叉验证 |
| 「放当前项目下呢」 | 阶段③步8——语境检验 |
| 「是不是需要记录」 | 阶段③步9——完整性审视 |
| 「待决策列出」 | 阶段④——决策清单 |
| 「从一个一个来」 | 阶段④——小步推进 |
| 「还剩下什么没解决」 | 阶段⑤——持续盘点 |

## 反模式

- 收到反馈直接动手改（跳过程序）
- 只看问题局部不完整读会话（漏问题）
- 停在表面症状（不追根因）
- 用特判/白名单（穷举不完）
- 单源调研当结论（用户「没有双源交叉验证」批评）
- 方案不检验项目语境（漏多项目/宿主/统一）
- 一次改一堆（用户「不要着急改」）
- 改完不复盘（漏剩余问题）

## 与相邻技能的关系

| 技能 | 边界 |
|------|------|
| `problem-dive`（本技能） | 收到问题/体验反馈后的**深挖方法论**——先证据、根因、调研、决策清单，**不直接修** |
| `systematic-debugging` | 已定位为**代码缺陷**后的根因调查协议（复现→假设→验证） |
| `problem-resolution-flow` | 从症状到**修复上线**的端到端流水线（定位→分级→调研→修→验证→收尾） |

顺序：反馈进来先走本技能；代码路径内调用 `systematic-debugging`；方案确认后走 `problem-resolution-flow` 落地收尾。