菜单
系统化排查根因：4 阶段法（复现 → 缩小 → 假设 → 验证）。Use when something is broken, wrong, slow, weird, unexpected, intermittent, 出错, 报错, bug, 问题, 不对, 慢, 卡, 怪, 排查, 定位, debug, troubleshoot. 适用于代码 bug、产品异常、流程出错、数据不对——任何「事情没按预期发生」的场景。
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
基于 SOC 职业分类
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/BrikerMan/git-github.com-BrikerMan-opencrew --skill bm-systematic-troubleshooting命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
正在显示 SKILL.md
动手前精炼意图：用苏格拉底式追问把模糊需求变成清晰 spec，分块呈现给用户确认后再开干。Use when user has a vague idea, fuzzy goal, or complex request that needs sharpening, 想做, 想要, 计划, 设计, 帮我做, 帮我想, brainstorm, idea, plan, spec, design. 写文章/做决策/做计划/写代码前都适用。
沟通达人：对话准备、角色扮演、文案润色、关系分析、冲突化解。基于非暴力沟通(NVC)框架。Use when user needs help with conversation prep, roleplay, message drafting, relationship advice, conflict resolution, 沟通, 对话, 怎么说, 怎么聊, 角色扮演, 关系, 冲突, 拒绝, 道歉, 表白, 加薪, 请假, 话术. 含语气调节器和场景模板库。
个人健康管理：身体指标追踪、饮食记录、运动记录、睡眠记录、趋势分析。Use when user wants to log or check weight, diet, exercise, sleep, body metrics, 体重, 饮食, 运动, 睡眠, 卡路里, 跑步, 健身。
| name | bm.systematic-troubleshooting |
| description | 系统化排查根因：4 阶段法（复现 → 缩小 → 假设 → 验证）。Use when something is broken, wrong, slow, weird, unexpected, intermittent, 出错, 报错, bug, 问题, 不对, 慢, 卡, 怪, 排查, 定位, debug, troubleshoot. 适用于代码 bug、产品异常、流程出错、数据不对——任何「事情没按预期发生」的场景。 |
| source | opencrew |
| version | 20260521.01 |
先复现，再缩小，再假设，最后验证。绝不靠猜。 适用于所有「事情没按预期发生」的场景。
不只是代码 bug——产品流程异常、数据对不上、设备不工作、操作没反应、流程卡住，都适用。
目标：让问题可控地、稳定地、最小步数地出现。
关键动作：
问题分类（决定下一步策略）：
| 类型 | 特征 | 难度 |
|---|---|---|
| 必现 | 每次都出 | 低 |
| 条件触发 | 特定输入/状态/时间才出 | 中 |
| 偶发 | 时有时无，无规律 | 高（先想办法变成条件触发） |
| 一次性 | 出过一次再没出 | 最高（先收集证据，等再次出现） |
反模式：
目标：把"问题出在哪"的边界从大到小压缩。
方法：
| 方法 | 操作 | 适用 |
|---|---|---|
| 二分 | 砍一半看问题在不在 | 不知道在哪一段 |
| 切换 | 换数据/环境/设备/账号 | 怀疑环境 |
| 回退 | 退到一个已知好的版本 | 之前是好的 |
| 最小化 | 剥离到最小可复现 | 复杂系统 |
| 时间法 | git bisect / 翻历史 | 回归问题 |
追问 5 次"为什么"：
修最深一层能修的，别修最表面那层。
目标：基于证据列出 2-3 个最可能的根因，每个都能验证。
好假设的标准：
config.json 里 port 字段是字符串 '8080' 而不是数字 8080"列假设按概率排序：
假设 1（最可能）：A 改坏了 B
- 验证：跑 X 看 Y
- 证据来源：错误信息提到 A
假设 2：环境差异
- 验证：在 staging 复现
- 证据来源：本地好用，线上不好用
假设 3（兜底）：第三方依赖
- 验证：检查依赖版本
- 证据来源：最近升级过
目标：确认假设对不对，然后再确认修复有效。
两步验证：
验证根因：用阶段 3 的检验动作，确认假设成立
验证修复：
排查过程要落档，方便用户跟进 / 后续复盘：
# 排查记录：{问题}
## 现象
- {一句话描述}
- 复现步骤：
1. ...
2. ...
## 环境
- {OS / 版本 / 配置}
## 排查时间线
### 阶段 1：复现 ✅
- 复现成功，必现
- 最小步骤：...
### 阶段 2：缩小
- 二分了 X，问题在 Y 模块
- 5why：... → 根因猜测：...
### 阶段 3：假设
1. ❌ A：验证后排除（证据：...）
2. ✅ B：成立（证据：...）
### 阶段 4：验证
- 修了 ...
- 复现步骤现在不再触发 ✅
- 周边测试通过 ✅
## 根因
{一句话}
## 修复
{改了什么，为什么这样改}
## 防再发
- {流程/检查项)
| 反模式 | 为什么错 | 正确做法 |
|---|---|---|
| 瞎改试运气 | 改对了不知道为啥，改错了浪费时间 | 先复现 + 假设 |
| 跳过复现直接猜 | 假设没证据，方向可能完全错 | 先稳定复现 |
| 一次改 5 个地方 | 不知道哪个起了作用 | 一次一个变量 |
| 改了能跑就不管 | 只是掩盖，可能再发 | 修根因，不修症状 |
| 看错误最外层 | 最外层是入口不是根因 | stack trace 从内往外读 |
| 不看现有 issue | 可能是已知问题 | 先搜 GitHub Issues / 历史排查记录 |
| 修完不验证 | 可能没修好或引入新问题 | 跑复现步骤 + 周边测试 |
场景：用户说"我的某个文件不见了"
场景：会议没人来
./working/troubleshoot-{topic}.md./postmortems/{date}-{topic}.md