mcpField
5
5why-root-cause

5why-root-cause

github.com/rbraga01测试与质量4242 次安装1 周前更新
代码仓库

关于 5why-root-cause

用于质量问题调查的结构化 5-Why 分析技能,面向需要追溯系统性根因并制定纠正措施的团队。它要求每一步由客观证据支持,并通过逻辑回溯及复现、消除测试验证根因。

主要功能

  1. 01构建单一路径的 Why 链
  2. 02以客观证据支持每一步
  3. 03检查逻辑一致性
  4. 04通过复现和消除测试验证
  5. 05区分发生与逃逸原因链
  6. 06输出纠正措施方向

适用场景

  1. 01调查流程或设备故障
  2. 02分析程序未遵循问题
  3. 03在 8D D4 中分析发生与逃逸原因
  4. 04为 CAPA 制定纠正措施方向

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/rbraga01/quality-engineering-skills --skill 5why-root-cause

安装后在 Claude Code 中输入/5why-root-cause确认已加载。

附带文件references/chain-validation.md

详细介绍

5-Why 根因分析

目标

通过结构化、基于证据的 Why 链识别并验证系统性根因,并确保该根因可以直接关联到纠正措施。

必需的执行检查清单

  • 使用可测量的数据定义问题(数值与规格对比)
  • 构建线性 Why 链——每次分析一条原因路径,不分支
  • 每个 Why 都有客观证据支持(而非意见或“可能”)
  • 验证逻辑一致性——通过反向检查
  • 确定系统性根因(而非“人为错误”或症状)
  • 验证根因:可复现性测试 + 消除测试
  • 输出能够用于制定纠正措施(PCA 或 CAPA)

适用场景

对于具有单一线性原因链的任何质量问题,都可使用 5-Why。它最适合用于流程故障、设备故障和程序不合规问题。对于存在多个促成原因的复杂问题,请先使用 鱼骨图 确定候选根因,再用 5-Why 深入分析每个候选根因。

如果存在多条可能的原因路径,不要将它们合并为一条链。针对每条路径分别运行 5-Why 链,并根据证据确定哪条路径得到证实。

前提条件

  • 已清晰定义问题(如有需要,使用 Is/Is-Not 界定范围)
  • 调查团队可以接触发生缺陷的流程、机器或系统
  • 有可用的实物证据或生产记录

在 8D 中的应用——发生原因与漏检原因

用于 8D D4 时,需要分别构建两条 Why 链:

链起始问题要查明的内容
发生原因链“缺陷为什么会发生?”发生根因(RCO)——产生缺陷的流程或设计失效
漏检原因链“缺陷为什么未能在到达客户前被发现?”漏检根因(RCE)——检测系统失效

**分别独立运行每条链。**不要在同一条链中混合发生原因和漏检原因——它们对应不同的纠正措施。发生原因链针对预防;漏检原因链针对检测。


工作流程

步骤 1 — 精确描述症状

从客观、可测量的问题陈述开始。不要说“零件有问题”,而应说“零件编号 Y 的批次 2026-05-12 中,尺寸 X 测得 23.5mm;规格为 25.0 ± 0.5mm”。

第一个 Why 要回答:“[具体症状] 为什么会发生?”


步骤 2 — 构建 Why 链

每个 Why 都应遵循以下规则:

规则 1:每个答案都必须有证据支持

  • 可接受的证据:测量数据、生产记录、机器日志、直接观察、实物样品
  • 不可接受: “可能”“也许”“有人说”

规则 2:每个答案都必须在逻辑上引出下一个 Why

  • 检验可逆性:“因为 [Why N],所以 [Why N+1]”
  • 如果句子在逻辑上说不通,说明链条断裂

规则 3:聚焦于当前链条

  • 一条 Why 链 = 一条原因路径
  • 如果遇到分叉(两种可能原因),应分别调查

规则 4:在系统性根因处停止

  • 满足以下条件时,即已找到根因:修复该问题可以防止缺陷再次发生
  • 典型的系统性根因:缺少程序、培训体系不足、流程设计缺陷、缺少防错措施、测量系统失效

步骤 3 — 验证链条

沿着已完成的链条反向检查:

“因为 [Why 5],所以 [Why 4]。因为 [Why 4],所以 [Why 3]……”

如果任何一步在逻辑上无法成立,就修改该步骤。


第 4 步 — 验证根本原因

满足以下条件时,根本原因才算正确:

  • 可复现性测试: 能否通过触发根本原因,刻意制造出该缺陷?能 → 已验证
  • 消除测试: 如果修复根本原因,缺陷是否会消失?(通过试运行或逻辑测试)

如果无法进行这两项测试,根本原因就尚未确认,只是一个假设。 不要基于假设结束调查。应获取证据予以确认,或调查其他可能的原因路径。


示例

问题: 来料检验时发现连接器引脚弯曲,12/200 个零件(6%)。

#为什么证据已验证?
1引脚为什么会弯曲?将引脚插入外壳时发生变形显微镜检查确认了变形模式
2为什么会在插入时变形?插入力超过了引脚的屈服强度力测量结果:48N,引脚额定承受力为 35N
3为什么插入力达到 48N?操作员使用了错误的插入工具(手动压机而非气动夹具)工具日志:夹具自 05-10 起处于维护状态
4为什么使用了错误的工具?没有说明在夹具不可用时应使用哪种工具的指导已审查作业指导书——没有应急方案
5为什么没有应急方案?编写作业指导书时未考虑工具维护停机的情况过程 FMEA 未涵盖该场景

根本原因: 作业指导书未涵盖工具替换的应急方案;FMEA 未将工具维护列为失效场景。

逆向检查:“因为 FMEA 未涵盖工具维护 → 所以没有应急指导 → 所以使用了错误工具 → 所以施力过大 → 所以引脚弯曲。” ✓ 逻辑成立。


常见错误——应予以否定

以“人为错误”作为最终答案 → 追问:为什么会发生这个错误?系统中有什么因素让它成为可能?

“操作员没有遵循流程” → 追问:为什么没有遵循?流程是否不清晰?是否未接受培训?是否无法遵循?

“机器失准” → 追问:为什么失准?校准周期是多久?是否漏做校准?为什么?

循环论证 →“零件不合格,因为它不符合规格,因为它不合格。”→ 将第一个“为什么”重新表述为物理机制。

停留在症状,而不是原因 →“缺陷发生是因为零件不对”——这就是缺陷本身,不是原因。

过早拆分因果链 → 每个“为什么”步骤都应有一个答案。如果有两个答案,就分别开展两条 5 个为什么分析链。

输出内容

经过验证的 5 个为什么分析必须包括:

  1. 问题陈述(经过测量并量化)
  2. 每个“为什么”及其答案、支持证据和是否已验证(是/否)
  3. 根本原因陈述
  4. 逆向检查(一句话确认逻辑链条成立)
  5. 验证方法(如何确认根本原因)
  6. 纠正措施方向——应采取哪类措施来解决该根本原因(直接用于 8D D5 或 CAPA)

输出格式

每次开始使用时,询问用户:

“您希望以哪种方式接收输出? A — 结构化 Markdown(包含格式化表格和章节,可直接复制) B — 纯表格(简化结构,适用于 Excel 或 Word) C — 叙述式报告(适用于正式文档或电子邮件的连贯文本)

默认:A。”

根据所选格式调整所有输出章节。如果平台或会话上下文已指定格式偏好,则跳过此问题。

参考文件

更新日志

版本日期作者变更
1.02026-06-01@RBraga01首次发布
1.12026-06-03@RBraga01新增双链要求(发生 + 漏检),增加证据状态跟踪

评论

支持 Markdown