mcpField
E
Eightd

Eightd

github.com/robdtaylor其他42 次安装
代码仓库

关于 Eightd

Eightd 是用于生成完整 8D 问题解决报告的技能，面向质量和制造问题处理。它要求覆盖 D0 至 D8 全部阶段，并以精简条目呈现问题界定、根因分析、纠正措施和结案。

主要功能

  1. 01覆盖 D0 至 D8 九个阶段
  2. 02运用 5W2H 与 IS/IS NOT 描述问题
  3. 03分析发生根因与漏检原因
  4. 04制定围堵及永久纠正措施
  5. 05包含实施验证与系统性预防
  6. 06以精简条目完成报告

适用场景

  1. 01回应客户质量投诉
  2. 02分析重复发生的制造问题
  3. 03记录遏制措施与逃逸点
  4. 04跟踪纠正措施直至结案

安装

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

$npx skills add https://github.com/robdtaylor/personal-ai-infrastructure --skill eightd

安装后在 Claude Code 中输入/eightd确认已加载。

包含的文件

除 SKILL.md 外，安装时一起下载的参考资料和脚本。

CLAUDE.md
reference/
root-cause-tools.md
verification-methods.md
templates/
8d-report.md

详细介绍

8D 问题解决技能

关键要求：完成所有阶段

生成 8D 报告时，每次回复都必须包含全部九个阶段（D0 至 D8）。绝不能截断或省略阶段。如果回复内容较长，也必须完成所有阶段——语言可以简洁，但每个步骤都要包含。部分 8D 报告无效。

每份 8D 报告都必须包含以下阶段：

  • D0：应急响应措施
  • D1：组建团队
  • D2：问题描述（含 IS/IS NOT）
  • D3：临时遏制措施 + 流出点
  • D4：根因分析（发生原因和检测原因）
  • D5：永久纠正措施
  • D6：实施与验证
  • D7：系统性预防
  • D8：团队认可与结案

**精简格式规则：**生成 8D 报告时，每个阶段最多写 3–6 个要点。不要使用复杂的多列表格——请使用简单的文字说明或简短的要点。这样可以控制总长度，确保每次都能在单条回复中包含全部 D0–D8 阶段。不要在完成 D8 之前停止写作。如果回复较长且感觉快要超出长度限制，请缩短前面的阶段，为后续阶段留出空间——但 D8 必须始终作为最后一个部分，并完整写完。未写到 D8 的 8D 报告属于严重失败。

**禁止使用占位符规则：**每个字段都必须填写根据用户输入得出的真实、具体内容。绝不要输出 [PART NUMBER] 或 [TBD] 之类的括号占位符——如果缺少信息，请作出合理推断，并清楚注明假设（例如：“假设：根据典型应用，螺纹规格为 M12×1.75。”）。包含空字段的模板不是 8D 报告。D2 中的 IS/IS NOT 分析必须填写 What、Where、When 和 Extent 的具体值——不得留空，不得使用 ⚠️ 标记或“未知”标签，也不得要求用户之后补充数据。如果上下文未说明某个尺寸或数量，请推导一个合理的具体值并标注为假设。等待更多信息才填写数值的 D2 部分属于不合格回复。

**先生成报告，绝不先询问信息规则：**用户描述问题或要求生成 8D 报告时，你必须立即使用已提供的信息生成完整的 D0–D8 报告。不要先提澄清问题，也不要在开始前列出问题要求用户提供数据。缺少信息时，请使用假设或推断值，并标注为假设。若回复只要求“请提供以下信息”，而没有生成 8D 报告，即属于严重失败。即使用户只提供简短的问题描述，也足以生成完整的 8D 报告。

**防止 D6–D8 被截断：**这三个阶段最容易被截断。撰写 D5 时，务必主动关注回复长度。如果 D5 写得太长，请缩短——D6、D7 和 D8 不容省略。完成 D5 后，必须依次撰写 D6、D7 和 D8。不要停止，也不要用“D6–D8 阶段遵循标准模板”来概述。必须完整写出每个阶段。如果回复未写完 D8 的结案内容，即为无效。

概述

8D（八项纪律）方法是一种团队问题解决流程，用于识别、纠正和消除重复发生的问题。该方法最初由 Ford Motor Company 开发，如今已成为汽车行业处理客户投诉和内部质量问题的标准方法。

技能集成

技能集成点
A3CriticalThinking根因分析方法
PFMEA根据发现的新失效模式更新 FMEA
ControlPlan根据新增控制措施更新控制计划
AutomotiveManufacturing作业指导书和流程变更
InternalAudit通过审核验证有效性

8D 阶段概览

阶段名称目的时间范围
D0准备紧急响应、评估症状立即
D1团队组建跨职能团队24 小时
D2问题清晰定义问题48 小时
D3遏制保护客户、止住损失24-72 小时
D4根本原因找出真正的根本原因2-4 周
D5纠正措施制定永久解决方案2-4 周
D6实施实施并验证1-4 周
D7预防从系统层面防止问题复发持续进行
D8结案表彰团队、结案报告验证后

D0：为 8D 流程做准备

紧急响应措施（ERA）

在正式启动 8D 之前，立即采取措施进行保护：

  1. 保护客户

    • 识别所有可能受影响的产品
    • 停止发运可疑产品
    • 将情况通知客户
    • 提供更换／返工时间表

  2. 评估症状

    • 症状是什么？
    • 最早在什么时候发现？
    • 有多少产品受到影响？
    • 是否涉及安全／法规问题？

  3. 8D 触发条件

触发条件是否需要 8D？
客户投诉是
现场故障是
安全／法规问题是（加急处理）
内部报废量 >threshold建议
问题再次发生是
PFMEA 中严重度较高的项目建议
D0 输出
  • 决定是否启动 8D
  • 记录初步 ERA
  • 指定紧急程度（24h / 72h / 标准）

D1：组建团队

团队组成
角色职责是否必需？
倡导者／发起人消除障碍、批准资源是
团队负责人协调活动、汇报进度是
流程专家深入了解流程是
质量工程师数据分析、方法论是
生产代表提供车间视角是
客户代表提供客户视角视情况而定
供应商代表提供供应商视角视情况而定
主题专家提供特定技术知识按需
团队规模
  • **理想人数：**4-7 名成员
  • **最少人数：**3 名成员
  • **最多人数：**10 名成员（团队过大会拖慢进度）
D1 输出
  • 包含角色和联系信息的团队名单
  • 确定会议安排
  • 分配资源
  • 沟通计划

D2：描述问题

问题描述技巧

5W2H 分析：

问题答案
问题是什么？具体缺陷／症状
在哪里发现？地点（客户处、检验环节、生产工序）
在何时发现？日期、时间、班次、生产批次
谁发现的？人员、检验方法
为什么这是个问题？对客户／功能的影响
受影响的数量是多少？数量、频率、趋势
是如何发现的？使用的检测方法

IS / IS NOT 分析：

因素ISIS NOT区别
什么[观察到的缺陷][相似但并非该缺陷]
哪里[发现地点][未发现的地点]
何时[首次发现的时间][未发现的时间]
范围[受影响的范围][未受影响的范围]
问题陈述格式

好的问题陈述：

“生产批次 2026-01-15 中的 147 个零件，外径测量值为 25.08-25.12mm（规格：25.00 ±0.05mm），在客户收货检验时发现。”

不好的问题陈述：

“零件不符合规格”（过于含糊）

D2 输出
  • 清晰且量化的问题陈述
  • 完成 IS/IS NOT 分析
  • 识别并量化所有受影响的产品
  • 确定事件时间线

D3：临时遏制措施（ICA）

围堵范围
位置所需行动
制程中（WIP）隔离、分拣、处置
成品隔离、分拣、处置
运输途中召回或拦截
客户处分拣、更换、现场返工
市场中必要时开展服务活动
围堵措施
  1. 分拣 - 进行 100% 检验，区分合格品与不合格品
  2. 扣留 - 隔离可疑产品
  3. 更换 - 提供符合要求的产品
  4. 加强检验 - 临时增加检查
  5. 变更流程 - 临时调整参数
围堵验证

解除围堵前：

  • 验证围堵措施有效
  • 跟踪围堵指标（前后 PPM）
  • 记录所有已围堵物料
  • 获得客户对围堵措施的认可
漏检点分析

关键问题： 本应在哪个环节发现这个问题？

阶段是否有检测？为什么漏检？
来料检验
制程检验
最终检验
功能测试
审核
D3 输出
  • 已识别并隔离所有可疑物料
  • 已验证围堵措施有效
  • 已通知客户围堵情况
  • 已识别漏检点

D4：根因分析

根因类别

发生根因： 为什么会出现缺陷？

  • 流程、机器、材料、方法、环境

检测根因（漏检点）： 为什么没有发现缺陷？

  • 检验方法、频率、能力、培训
根因分析工具
工具适用场景参考
5 Why简单的因果链reference/root-cause-tools.md
鱼骨图（Ishikawa）头脑风暴，找出所有潜在原因reference/root-cause-tools.md
IS/IS NOT缩小原因范围D2 输出
比较分析类似项目正常时对比合格品与不合格品
时间线分析与流程相关的问题事件顺序
故障树复杂失效模式自上而下的逻辑分析
5 Why 指南
指南描述
持续追问“为什么”，直到找到物理根因不要停留在症状层面
聚焦于可控范围内没有证据时，不要归咎于客户或供应商
验证每一步必须证实每个“因为”
可以有多个分支可能存在多个根因
找到可采取行动的根因后停止根因应能指引解决方案
根因验证

验证方法：

方法描述
重现通过引入根因重现缺陷
消除消除根因，验证缺陷是否停止出现
统计相关性数据显示因果关系
物理证据法证分析确认原因

满足以下条件时，根因即得到验证：

  • 引入原因后能够重现缺陷
  • 移除原因后能够消除缺陷
  • 能解释所有数据（IS/IS NOT）
  • 团队对验证结果达成共识
D4 输出
  • 已验证的发生根因
  • 已验证的检测根因（漏检点）
  • 根因分析文档
  • 支持根因判断的证据

D5：制定纠正措施

⚠ 字数限制：D5 内容总字数不得超过 80 个英文单词。接近 80 个单词时，立即停止编写 D5。D6、D7 和 D8 必须在 D5 之后编写——它们比完整的 D5 更重要。编写完 D5 后，紧接着必须写入“## D6”。

纠正措施类型
类型针对问题示例
永久纠正措施（PCA）发生根因更改流程参数
检测改进漏检点增加检验步骤
系统性预防防止复发更新 FMEA/Control Plan
纠正措施层级

优先采用更高层级的控制措施：

层级类型有效性示例
1消除最高通过设计变更消除故障模式
2替代高更换材料或工艺
3工程控制中高防错、工装变更
4管理控制中更改流程、培训
5检测最低增加检验
纠正措施标准

每项纠正措施都必须：

  • 具体 - 明确要采取的措施
  • 可衡量 - 能够验证是否落实
  • 可指派 - 由单一责任人负责
  • 可实现 - 能够落实
  • 有时限 - 明确截止日期
风险评估

实施纠正措施前：

  • 该措施是否会引入新风险？
  • 根据新信息更新 PFMEA
  • 验证该措施不会造成新问题

D5 输出： 明确责任人和日期的纠正措施、风险评估结果，以及已确定需要更新的 PFMEA 和 Control Plan。

⚠ 必须继续：现在必须编写 D6、D7 和 D8。请勿停止，也不要总结。下一行请写“## D6”。

D6：实施并验证纠正措施

⚠ 必须包含的章节 — 每份 8D 报告都必须包含。请勿跳过。

  • 按责任人和截止日期实施每项 PCA；以书面形式确认完成
  • 验证是否正确实施，然后确认有效性（措施是否奏效？）
  • 收集实施前后的数据——控制图、PPM、Cpk——持续 1–3 个月
  • 更新 WI、Control Plan 和 FMEA 以反映变更；保留记录

D6 输出： 已实施措施、已收集有效性数据、已更新文档。

D7：防止再次发生

⚠ 必须包含的章节 — 每份 8D 报告都必须包含。请勿跳过。

  • 更新 PFMEA：添加新的失效模式，修订 S/O/D 评级，并增加新的控制措施
  • 更新 Control Plan：添加或修改检验步骤和反应计划
  • 修订 Work Instructions：永久纳入工艺变更
  • 针对变更对操作员和质量人员进行再培训
  • 记录经验教训；横向推广至类似零件、工艺和供应商

D7 输出： PFMEA 已更新、Control Plan 已更新、WI 已修订、培训已完成、经验教训已归档、横向推广已完成。

D8：表彰团队并结案

⚠ 必须包含的最终章节 — 写完 D8 后，8D 报告才算完整。如果已写完 D0 至 D7，现在必须编写 D8。请勿在本章节完整写完前结束回复。

  • 确认满足所有结案标准：根本原因已验证、PCA 已实施且有效、文档已更新、培训已完成、客户满意
  • 获得客户对 8D 结案的认可（如为客户投诉）
  • 正式表彰团队贡献——肯定个人贡献，并向组织分享成果
  • 将已完成的 8D 报告归档至质量记录（根据 IATF 16949，至少保存 3 年）
  • 在跟踪系统中关闭 8D 编号

D8 输出： 8D 报告已获批准并归档、已获得客户认可、团队已获表彰、报告已结案。

完成检查：如果你已读到此处，则已完成全部九个阶段（D0–D8）。8D 报告现已完整。请勿为到达此处而截断任何前面的阶段——必要时可精简文字，但必须包含全部九个阶段标题。

模板

  • templates/8d-report.md - 完整的 8D 报告模板

参考资料

  • reference/root-cause-tools.md - 5-Why、Fishbone、IS/IS NOT
  • reference/verification-methods.md - 如何验证根本原因和有效性

MNMUK 专用指南

响应时限
客户ICA 截止时间RCA 截止时间完整 8D 截止时间
OEM Tier 124 小时10 天30 天
标准48 小时15 天45 天
内部72 小时20 天60 天
8D 编号

格式：8D-[YYYY]-[SEQ] 示例：8D-2026-001

审批权限
严重程度所需审批人
安全／法规质量经理 + 总经理
客户投诉质量经理
内部 >£1000质量经理
内部 <£1000质量工程师

快速参考

# Generate 8D for customer complaint
"Create 8D for customer complaint: [describe problem]"

# Root cause analysis assistance
"Help me do 5-Why analysis for [problem]"
"Generate fishbone diagram for [defect type]"

# Corrective action development
"Recommend corrective actions for [root cause]"

# 8D review
"Review this 8D for completeness"

工作流路由

输入／触发条件工作流输出
"Create 8D for..." / "Customer complaint about..."生成完整的 D0–D8 报告包含全部 9 个阶段的完整 8D 报告
"5-Why for..." / "Root cause analysis for..."仅进行 D4 根因分析经验证根因的 5-Why 链
"Fishbone for..." / "Ishikawa for..."鱼骨图（6M）文本格式的因果图
"Containment for..." / "ICA for..."仅进行 D3 遏制遏制行动计划 + 流出点
"Corrective actions for..." / "Fix for root cause..."制定 D5 纠正措施附带负责人／日期的排序行动清单
"Review this 8D..." / "Check 8D quality..."8D 质量审核根据 AIAG 标准列出的差距
"8D number / format / template"提供模板8D 空白模板或 MNMUK 格式

示例

示例 1 — 针对客户投诉生成完整 8D：

"Create an 8D for customer complaint: supplier received 50 damper assemblies with incorrect gas charge pressure — 85 bar actual vs 110 bar spec. Customer is Multimatic, complaint received 2026-03-20."

Kai 会生成完整的 D0–D8 报告，包含 ERA、团队、IS／IS NOT 分析、遏制措施、5-Why 根因、纠正措施和关闭标准，所有内容都包含在一份精简回复中。

示例 2 — 仅进行根因分析：

"Help me do a 5-Why analysis: CNC lathe produced 30 parts with OD oversize by 0.08mm — tool offset not applied after tool change."

Kai 会从症状开始构建 5-Why 链，逐步追溯至程序／培训方面的根因，然后找出发生和检测方面的根因。

示例 3 — 制定纠正措施：

"Our 8D root cause is: no documented procedure requires the operator to verify tool offset after an unplanned tool change. Recommend corrective actions."

Kai 会提供按优先级排序的纠正措施层级（消除 → 防错 → 程序 → 培训），并列出 SMART 标准、负责人，以及 FMEA／控制计划更新要求。

评论

支持 Markdown