메뉴
系统化排查根因：4 阶段法（复现 → 缩小 → 假设 → 验证）。Use when something is broken, wrong, slow, weird, unexpected, intermittent, 出错, 报错, bug, 问题, 不对, 慢, 卡, 怪, 排查, 定位, debug, troubleshoot. 适用于代码 bug、产品异常、流程出错、数据不对——任何「事情没按预期发生」的场景。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
动手前精炼意图：用苏格拉底式追问把模糊需求变成清晰 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, 体重, 饮食, 运动, 睡眠, 卡路里, 跑步, 健身。
生活记录：日记、周报回顾、月度回顾、生活事件记录、成长追踪。Use when user wants to write journal, diary, weekly review, monthly reflection, life events, milestones, 日记, 周报, 月报, 复盘, 回顾, 感恩, 反思. 三段式结构。
会议处理：会议纪要生成、字幕/录音转文字、议程管理、行动项追踪。Use when user has meeting notes, transcripts, subtitles to process, 会议, 纪要, 字幕, 录音, 议程, 行动项, meeting notes, transcript. 自动提取关键决策和待办。
项目管理：项目创建、任务管理、进度追踪、风险评估、周报生成。Use when user needs to manage projects, tasks, milestones, risks, timelines, 项目, 任务, 进度, 风险, 里程碑, 排期, project, task, sprint. 数据存入当前工作目录，按目录组织。
| 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