troubleshooting

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

问题排查 (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 命令：告诉用户如何从日志文件中提取关键信息

示例：

# 查找某个错误码相关的日志
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：瞎猜信号

排查流程

1. 收集信息

代码上下文调研（必须）：调用 codebase-researcher subagent 调研问题相关的代码上下文，包括：

• 报错涉及的函数/模块的实现逻辑和调用链
• 相关数据结构和状态流转
• 上下游模块的交互方式

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

2. 假设-验证循环

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

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

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

流水线/现网问题时，在 reference/cases/ 搜索匹配案例：

• 提取错误关键字（错误码、异常类型、模块名）
• 匹配 symptoms.keywords
• 按案例诊断步骤验证

4. 模块专项排查

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

输出格式

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

案例沉淀

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

强制规则