# Troubleshooting

> 问题排查。当用户遇到编译错误、运行时异常、单测失败、流水线报错、现网告警等需要定位问题时触发。

- Skill: `davidyichengwei/troubleshooting` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add davidyichengwei/troubleshooting`
- Raw SKILL.md: https://api.skillmd.com/api/skills/davidyichengwei/troubleshooting/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: davidyichengwei (https://skillmd.com/u/davidyichengwei)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/davidyichengwei/troubleshooting

---


# 问题排查 (Troubleshooting)

## Iron Law

```
NO ASSUMPTIONS. NO FIX WITHOUT ROOT CAUSE.
```

1. **禁止假设**：所有结论必须基于代码 + 用户提供的 log，不得凭经验猜测
2. **未找到根因，禁止提修复建议**

---

## 核心约束

1. **AI 无法访问用户环境**：只能看用户发来的信息 + codebase 代码
2. **让用户执行命令**：命令必须用代码块输出，方便复制
3. **输出目标**：根因 + 修复建议（不自己修复）

---

## Log 不足时的处理

**禁止在缺少 log 的情况下猜测根因。**

当用户提供的 log 不足以定位问题时：

1. **在代码中找关键 log**：定位相关代码路径，找出能区分不同故障场景的 log 语句
2. **提供 grep 命令**：告诉用户如何从日志文件中提取关键信息

**示例**：
```bash
# 查找某个错误码相关的日志
grep -E "error_code|ErrorCode" /path/to/log | head -50

# 查找某个函数调用前后的上下文
grep -B5 -A10 "FunctionName" /path/to/log

# 按时间范围过滤
grep "2025-01-29 10:3[0-9]" /path/to/log | grep -i error
```

**要点**：
- 明确告诉用户 grep 什么关键字
- 说明这个 log 能帮助确认/排除什么

---

## 排查记录

流水线/现网问题排查时，创建排查记录文档实时跟踪进度。

**判断是否创建**：询问用户问题类型：
- **流水线报错 / 现网告警** → 创建排查记录
- **开发调试中的问题** → 不创建，直接排查

**模板位置**：[reference/troubleshooting-log-template.md](reference/troubleshooting-log-template.md)

**创建方式**：
```bash
cp skills/troubleshooting/reference/troubleshooting-log-template.md \
   troubleshooting-[问题简述]-$(date +%Y%m%d).md
```

**记录要点**：
- 每个重要发现立即记录（日志、代码位置、中间结论）
- **每次有新进展必须更新文档**：新发现的 log、代码分析结果、排除的假设
- **同步更新待确认点**：哪些假设已验证、哪些还需确认、下一步要做什么
- 定位后补充根因和证据链

---

## Red Flags：瞎猜信号

| 危险想法 | 正确做法 |
|----------|----------|
| "看起来像是 X" | 有什么证据？让用户验证 |
| "试试改 Y 看看" | 这是猜测，不是诊断 |
| "应该是 Z 导致的" | "应该"不是证据 |

---

## 排查流程

### 1. 收集信息

| 必须收集 | 深度排查额外收集 |
|----------|------------------|
| 错误日志、堆栈、错误码 | 时间线、环境差异 |
| 复现条件、触发步骤 | 是否间歇性发生 |
| 代码版本、最近变更 | 完整服务拓扑 |

**代码上下文调研（必须）**：调用 `codebase-researcher` subagent 调研问题相关的代码上下文，包括：
- 报错涉及的函数/模块的实现逻辑和调用链
- 相关数据结构和状态流转
- 上下游模块的交互方式

**信息不足时主动追问，不要猜测。**

### 2. 假设-验证循环

```
形成假设 → 让用户验证 → 确认或否定 → 迭代
```

**3+ 轮失败规则**：连续 3 轮假设被否定 → 停止猜测，扩大信息收集范围。

### 3. 历史案例（深度排查时）

流水线/现网问题时，在 `reference/cases/` 搜索匹配案例：
- 提取错误关键字（错误码、异常类型、模块名）
- 匹配 `symptoms.keywords`
- 按案例诊断步骤验证

### 4. 模块专项排查

根据项目需要，可在 `reference/` 下为特定模块添加专项排查资料。

---

## 输出格式

- **开发调试问题**：直接在对话中输出根因和修复建议
- **流水线/现网问题**：更新排查记录文档，格式参见 [troubleshooting-log-template.md](reference/troubleshooting-log-template.md)

---

## 案例沉淀

复杂/代表性问题排查后，按 [case_template.md](reference/cases/case_template.md) 沉淀到 `reference/cases/<module>/`。

---

## 强制规则

| 规则 | 说明 |
|------|------|
| **禁止假设** | 结论必须基于代码 + log，不得凭经验猜测 |
| **Iron Law** | 未找到根因，禁止提修复建议 |
| **禁止缺 log 猜根因** | log 不足时，从代码中找关键 log 并提供 grep 命令，不得猜测 |
| **代码上下文调研** | 必须调用 `codebase-researcher` subagent 调研问题相关代码 |
| **实时更新文档** | 每次新进展/新结论必须更新排查记录，同步维护待确认点 |
| **假设验证** | 让用户验证，不脑补结果 |
| **3+ 轮规则** | 连续失败则扩大范围 |