1. 写下要分析的问题
把问题写成一句具体的话，放在「鱼头」。比如「最近三个月每周都熬夜赶工」，而不是模糊的「状态不好」。
检查问题
- 这个问题反复出现多久了？
- 它具体表现成什么样？
输出：一个具体的问题句。
方法库 / 问题解决
鱼骨图
把一个反复出现的问题，按人、方法、环境等几类原因拆开，找到真正的根因，而不是治标。
这个方法解决什么
鱼骨图（石川图）解决的是「同一个问题反复出现」。它把「为什么」按几个固定类别拆开：人、方法、流程、环境、工具、外部。每个分支继续问为什么，一路追到根因。
它逼你停止在表面原因上打转。「项目又延期了」的直接原因是「时间不够」，但时间不够可能是因为需求总变，也可能是因为沟通方式低效。鱼骨图把这些分门别类摊开，让你看到到底是哪一类在反复制造问题。
你会得到什么
完成后，你会得到一份「鱼骨图根因清单」。它不是结论，而是一份可以保存、复盘、继续验证的行动材料。
什么时候用
- 一个问题反复出现，每次都治标没治本
- 一团乱麻，不知道从哪头理
什么时候先别用
- 一次性的事故，找直接原因就行
- 纯粹是情绪问题，更适合情绪记录
操作指南
2. 选几个原因类别当鱼骨
常用的几类：人（能力/状态/分工）、方法（做事方式）、流程（步骤/审批）、环境（时间/物理环境/团队氛围）、工具（用的软件/资源）、外部（客户/上游）。挑和你的问题最相关的 4-6 类。
检查问题
- 这个问题最可能和哪几类有关？
- 哪一类我最想逃避、却最可疑？
输出：4-6 个原因类别。
3. 每一类下追问「为什么」
对每个类别问：这一类里，什么可能导致这个问题？每个想到的原因再问一次为什么，往下挖 2-3 层。
检查问题
- 为什么这一类会导致这个问题？
- 再往下呢？
输出：每个类别下一条原因链。
4. 找出反复出现的根因
通看所有分支，哪些原因被多个类别指向，或最靠近底层？这些通常就是根因。圈出来。
检查问题
- 哪个原因被反复提到？
- 如果修掉这个，问题还会出现吗？
输出：1-3 个根因。
5. 把根因变成动作
对每个根因写一个具体、可执行的对策。鱼骨图做完如果没动作，就只是一张好看的图。
检查问题
- 针对这个根因，我能在 30 天内做什么？
输出：每个根因配一个动作。
问题清单
- 这个问题反复出现多久了？
- 修掉哪个原因，问题就不会再出现？
- 哪一类原因我最想逃避、却最可疑？
示例：为什么每周都熬夜赶工
把「每周熬夜」按几类原因拆开追根因。
| 类别 | 可能原因 | 往下挖 |
|---|---|---|
| 方法 | 总在 deadline 前一天才开始 | 白天被打断太多，没有集中时段 |
| 流程 | 需求频繁临时加 | 没有需求冻结，谁都能插 |
| 人 | 一个人扛，不好意思拒绝 | 默认拒绝就等于不配合 |
| 工具 | 沟通散在好几个群 | 没有统一排期看板 |
四个分支最后都指向「没有边界和排期」。根因不是「我不够自律」，而是没有需求冻结和统一看板。于是对策从「再努力点」变成「下周和团队约定需求冻结日」。
质量检查
- 问题写得具体，不是「状态不好」这种模糊话。
- 每类下面真的往下挖了 2-3 层，没停在表面原因。
- 找到了被多个分支指向的根因。
- 每个根因都有对策动作。
常见误区
- 只列直接原因，不往下挖。
- 原因写得空泛（「沟通不好」），没法对应动作。
- 把责任全归到「人/自己」一类，忽视流程和环境。
- 图画完没动作，根因变成免责声明。
可复制模板
模板
问题（鱼头）： 原因类别（鱼骨）： 人：→ 为什么 → 方法：→ 为什么 → 流程：→ 为什么 → 环境：→ 为什么 → 工具/外部：→ 为什么 → 反复被指向的根因（1-3 个）： 每个根因的对策动作：
来源与边界
来源与证据
由日本质量管理先驱石川馨于 1940–60 年代提出，用于根因分析。本卡按中文场景重写。
风险边界
如果困扰已经影响睡眠、饮食、安全感或日常功能，优先寻求专业支持。
相关方法
同场景或同领域的其它方法第一性原理
把一个复杂问题拆到不能再拆的基本事实，再从那里重新搭方案，而不是照搬现成做法。
议题树
把一个大问题拆成几个互不重叠的小问题，逐个击破，而不是对着整团乱麻发呆。