质量问题 8D 复盘
给品质经理、测试经理、项目经理、SQE 用。把一个测试异常、生产不良或客诉，整理成能开会、能派活、能跟进的 8D 材料，并同时出两份：
- 老板版：一页，讲清多严重、影响多大、现在怎么挡住、要老板拍什么板。
- 团队执行版：每个动作有责任方、截止节点、完成判据。
AI 负责把事实理清、把原因列全、把验证方法设计好；根因确认和责任认定，以实验结果和人的判断为准。
第一步：确认输入（缺什么一次问完）
必需：
- 问题现象：发生了什么、在什么条件下（测试项目和条件、使用场景）。
- 数据：样品总数、不良数、不良样品编号/批次；有测试记录就全给。
- 产品与阶段：产品类型、阶段（EVT/DVT/PVT/量产/售后）。
建议提供（没有就在报告里列为"待补信息"，不阻塞起草）：
- 不良样品的已做排查（拆机、互换、复测）及结果。
- 物料批次、供应商、生产线/班次、软件版本。
- 同批次良品的数据（对比用）。
- 是否已出货、库存多少（决定围堵范围）。
- 汇报对象：老板/客户/供应商（决定措辞）。
- 汇报日期或距今几天（决定老板版里"什么时候能有结果"怎么写，以及验证能排几项）。
用户只说一句"××测试出问题了帮我写 8D"：只追问"样品多少、坏了几个、坏的样品做过什么排查"三件事；用户说"先写"就直接起草，所有缺的数据标【待补：××】。
第二步：先核数据（D2 前置）
- 算不良率：不良数 ÷ 样品数，写出算式。
- 样本量提醒（统计说明见
references/02-分级与判定标准.md第三节）： - 样本少时不良率的波动很大，要写明"基于 n 台"。
- 0 不良不等于没问题：n 台 0 不良，只能说明真实不良率的 95% 置信上限约为 3/n（例：20 台 0 不良，上限约 15%）。用来判断改善验证样本是否够。
- 检查数据之间是否自相矛盾（例如不良编号数量和不良数对不上、测试方法前后说法不一），矛盾就先列出来请用户确认，不自己改数。用户不回答时，写进 D2 末尾"记录中的矛盾（未改动，待确认）"，并进待补信息清单。
- 两组比较（如 EVT 10 台 0 不良 vs DVT 20 台 3 不良、改善前后对比）：小样本两组差异通常不足以下结论。只写"样本量不足以区分两组，可作为方向线索"，需要定量判断时提示用户用 Fisher 精确检验，不自己估 p 值。
- 来源要分清：测试记录里的数据算事实；同事的口头说法（"EVT 有泡棉、DVT 取消了""可能是驱动问题"）写成"××口述，待书面核实"，可以作为假设线索，不当作已确认事实。
第三步：按 8D 展开
步骤和每步的检查项见 references/01-8D步骤检查表.md，写法可参考 references/05-示例-耳机高温高湿.md。核心要求：
D0 应急判断（先于一切）：回答三件事——是否涉及安全/合规；有没有已出货、在库、在制的同类产品；要不要立即隔离。
- 品质可以立刻做、不用等老板批的：隔离冻结在库/在制品（贴标、停止流转和送样）、保全不良样品现状、暂停该批次抽样外发、从冻结品中抽少量做破坏性验证（知会项目即可）。这类动作成本低、可撤销或损耗小，在报告里写"立即执行"。
- 需要老板或评审拍板的：停线、报废、批量返工、推迟节点、回退降本方案、通知客户。这类放进老板版决策项。
D1 团队：按问题涉及的领域列需要的角色（结构、硬件、软件、测试、SQE、供应商、生产），不编人名，写"责任方：结构工程"之类。具体人名在表下统一写一次"具体人员【待补：各角色负责人】"，不要逐行标黄。
D2 问题描述（现象）：用 5W2H 写，只写看到的，不写猜的。再做一张"是/不是"对比表：问题在哪些条件下出现、在哪些条件下不出现。对比表是后面缩小原因范围的关键，信息不足的格子写【待补】，并在验证计划里安排去补。
D3 临时围堵：分四个范围考虑——在制品、库存、在途/已出货、测试中样品。每个写动作、责任方、判据。没出货就写"未出货，不涉及"，不要编库存数。
D4 原因分析：
1. 按"人·机·料·法·环·测"（或设计/物料/工艺/软件/测试方法）列所有合理假设，参考 references/03-常见失效假设库.md。
2. 每个假设标：可能性（高/中/低）、支持它的证据、反对它的证据、还缺什么证据。可能性必须由证据说话，不能凭感觉。
3. 必须分开写两条：发生原因（为什么会坏）和流出原因（为什么之前的测试/检验没拦住）。
4. 根因状态只能是三种之一：已验证（有实验证据复现或排除）/ 疑似（证据指向但未做验证实验）/ 未知。用户没给验证结果，最多是"疑似"。
5. 不良样品表现不一样时（例如有的复位就恢复、有的复位不恢复），可能是不止一种失效模式：按失效模式分组，每组分别给假设和根因状态（如"模式一（D03、D17）：疑似；模式二（D11）：未知"），不要硬凑成一个原因。
验证计划（D4 与 D5 之间）：每个高/中可能性假设至少一个验证方法，写清：做什么、用几台、什么设备、预期结果分别意味着什么（"若××则支持假设 A，若××则排除"）。优先用能区分假设的实验（互换、ABA 复位、对照组），而不是只能"再测一遍"的实验。
分级：按 references/02-分级与判定标准.md 给缺陷等级（致命A/严重B/一般C/轻微D），写判据。不良率和是否涉及安全/合规都要考虑。公司有自己的分级标准时以公司为准。
责任边界（初判）：按设计/物料/工艺/供应商/软件/测试方法列"初判方向 + 依据 + 还需什么证据才能确认"。必须标注"初判，最终责任以验证结果和双方确认为准"。不写"某供应商负全责"这类结论。
D5 永久对策：针对已验证或高可能性的疑似根因，发生原因和流出原因各给对策；每条写验证方法和通过判据（含样本量，参考 3/n 规则）。根因还是疑似时，对策写成"若验证确认××，则采取××"。
D6 实施与效果确认：写效果确认计划（什么时候、多少样品、什么判据），不写"已改善""不良率降为 0"等还没发生的结果。
D7 预防再发：标准化——测试规范、检验标准、设计检查清单、FMEA、工艺文件分别要改什么；横向展开——哪些同平台/同结构/同供应商产品要排查。
D8 总结：只留框架和待填项（关闭日期、经验教训），问题没关闭就不写"圆满解决"。
第四步：出两份材料
格式见 references/04-输出模板.md。
老板版（一页内）：
1. 一句话：什么问题、多严重、现在挡住了没有。等级写成"严重（B 级）"这种老板能看懂的说法。
2. 影响：不良率（附样本量）、涉及阶段/批次、是否影响节点、是否已出货。
3. 原因：最可能的方向 + 根因状态（已验证/疑似）。
4. 正在做：围堵 + 验证，各一句。"什么时候出结果"只能引用用户给的日期，没给就写【待补：预计出结果时间】，不替团队做时间承诺。
5. 需要老板决策的事：1–3 条，只放 D0 里"需要拍板"那一类（停线、报废、返工、推迟节点、回退降本、通知客户），不要把品质能直接做的隔离冻结也拿来请示。每条写：选项（通常是做/不做或 A/B 方案）、建议、不按建议做的风险。没有要决策的就写"无，按计划推进"。
6. 不写术语缩写不解释，不贴大表。
团队执行版：
- 行动表：编号 / 8D 步骤 / 动作 / 责任方 / 截止节点 / 完成判据 / 状态（未启动 / 进行中 / 已完成 / 受阻）。
- 验证计划：和完整报告一起发时，团队执行版只列"验证编号 + 负责方 + 顺序"，不重复整张表；团队执行版单独发时，把验证计划整表放进去，否则编号无处可查。
- 待补信息清单（含记录中的矛盾）。
- 截止节点用"验证结果出来后 × 天内""下一轮测试前"这类相对节点；用户给了日期才写具体日期。
需要给供应商的版本时：只写事实、数据、要求对方提供的分析和时间节点，不写内部的责任猜测。
第五步：交付
完整报告顺序：基本信息 → 老板版 → 8D 正文（D0–D8，含验证计划、分级、责任初判）→ 团队执行版（含待补信息）。
一般交三个文件：完整 8D 报告、老板版（单独一页）、团队执行版（单独发群或贴任务系统）。老板版和团队执行版单独存时，把该节标题升为一级标题 #，前面补一行产品、阶段、报告版本。
需要 Word 时，存成 Markdown 后运行本技能目录下的脚本（只用 Python 标准库，不用装包）：
python <本技能目录>/scripts/md2docx.py 8D报告.md 8D报告.docx --landscape
python <本技能目录>/scripts/md2docx.py 老板版.md 老板版.docx
python <本技能目录>/scripts/md2docx.py 团队执行版.md 团队执行版.docx --landscape
完整报告和团队执行版表格列多用横版；老板版用竖版。日期以用户说的为准（用户说"今天周二"就按周二排），不按系统日期改写。
- Markdown 第一行已经有
#标题时不要加--title，否则 Word 里标题会出现两次。 - Windows 上命令用
python或py；macOS/Linux 用python3。 - 表格单元格里需要换行用
<br>；单元格内容不要出现|。 - 【待补：××】等标记在 Word 里会标黄。转完看一眼脚本报告的标黄数量，超过 30 处说明待补标得太碎，合并同类项（如人名、日期统一一处说明）。
交付前自查
过 references/02-分级与判定标准.md 末尾的自查清单。重点：
- D2 有没有混入猜测（"疑似 FPC 松动导致黑屏"不能写进现象）。
- 每个假设有没有正反证据，有没有"是/不是"对比表支撑。
- 发生原因和流出原因是否都写了。
- 根因状态是否如实（没做验证就不能是"已验证"）。
- 对策是否有验证判据和样本量。
- 老板版是否一页内、有没有决策项。
硬规则
- 不做统计推断以外的估数：可以写 3/n 上限和"若真实不良率为 p，抽 n 台至少见 1 台不良的概率 = 1-(1-p)^n"这类可复算的算式；不估 p 值、不外推量产不良率。
- 不编数据：测试数据、不良率、样本量、拆解结果、失效分析结果、库存数，用户没给就写【待补：××】。不写"经分析发现""拆解确认"等没发生的事。
- 不提前定根因：没有验证实验结果，根因只能写"疑似"；多个假设并存时不挑一个当结论。
- 不做最终定责：责任只写"初判方向+依据"，并标注需人工确认。
- 不预写效果：D6/D8 只写计划和判据，不写"已改善""已关闭"。
- 样本量说清楚：不良率必须带"n 台中 x 台"；小样本结论要写明不确定性。
- 标准只引用用户给的或写"以公司/客户标准为准"：不凭记忆写标准编号、条款和限值。
- 对外版本不带内部猜测：给供应商或客户的版本只写事实和请求。
