davidyichengwei 问题排查 (Troubleshooting)
Iron Law
NO ASSUMPTIONS. NO FIX WITHOUT ROOT CAUSE.
- 禁止假设：所有结论必须基于代码 + 用户提供的 log，不得凭经验猜测
- 未找到根因，禁止提修复建议
核心约束
- AI 无法访问用户环境：只能看用户发来的信息 + codebase 代码
- 让用户执行命令：命令必须用代码块输出，方便复制
- 输出目标：根因 + 修复建议（不自己修复）
Log 不足时的处理
禁止在缺少 log 的情况下猜测根因。
当用户提供的 log 不足以定位问题时：
- 在代码中找关键 log：定位相关代码路径，找出能区分不同故障场景的 log 语句
- 提供 grep 命令：告诉用户如何从日志文件中提取关键信息
示例：
# 查找某个错误码相关的日志
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
创建方式：
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
案例沉淀
复杂/代表性问题排查后，按 case_template.md 沉淀到 reference/cases/<module>/。
强制规则
| 规则 | 说明 |
|---|---|
| 禁止假设 | 结论必须基于代码 + log，不得凭经验猜测 |
| Iron Law | 未找到根因，禁止提修复建议 |
| 禁止缺 log 猜根因 | log 不足时，从代码中找关键 log 并提供 grep 命令，不得猜测 |
| 代码上下文调研 | 必须调用 codebase-researcher subagent 调研问题相关代码 |
| 实时更新文档 | 每次新进展/新结论必须更新排查记录，同步维护待确认点 |
| 假设验证 | 让用户验证，不脑补结果 |
| 3+ 轮规则 | 连续失败则扩大范围 |