用途：通过结构化的5-Why Why链，基于证据追查并验证可链接到纠正措施的系统性根因。适用于具有单一线性原因链的品质问题，尤其适合过程失效、设备失效和程序性不符合。若存在多条潜在原因路径，不应合并为一条链，而应分别运行独立的5-Why链，并用证据确定哪条被确认。复杂多因问题建议先用鱼骨图找出候选根因，再用5-Why逐条深入。
主要能力：
- 按执行清单推进：问题需以可测量数据定义（实际值对规格）；构建线性Why链，一次一条原因路径，不分叉；每个Why须有客观证据支持，而非意见或“可能”；做逻辑一致性倒推检查；识别系统性根因，而非“人为错误”或症状；用复现测试和消除测试验证根因；输出应能支撑纠正措施（PCA或CAPA）的制定。
- 在8D的D4中使用时要求两条独立链：发生链，起始问题是“缺陷为什么发生”，找出发生根因（RCO），即产生缺陷的过程或设计失效；逃逸链，起始问题是“缺陷为什么在到达客户前未被检出”，找出逃逸根因（RCE），即检测系统失效。两条链独立运行，不可混用，因为纠正措施不同：发生链面向预防，逃逸链面向检测。
使用方式：
- 前置条件：问题已清晰定义（必要时用Is/Is-Not界定范围）；调查团队能接触发生缺陷的过程、机器或系统；有实物证据或生产记录。
- 工作流：第一步精确陈述症状，用事实和可测量的问题陈述，例如“零件号Y、批次2026-05-12，尺寸X实测23.5mm，规格为25.0±0.5mm”；第一个Why回答“为什么[具体症状]会发生”。第二步构建Why链，遵守四条规则：每个答案有证据（测量数据、生产记录、机器日志、直接观察、实物样品；不接受“大概”“也许”“有人说”）；每个答案逻辑上引出下一个Why，用“因为[Why N]，所以[Why N+1]”做可逆性检验，逻辑不通则链断裂；保持链条聚焦，一条链一条原因路径，遇到分叉则分别调查；止于系统性根因，判断标准是修复它可防止缺陷再次发生，典型系统性根因包括缺失程序、培训体系不足、过程设计缺口、缺少防错、测量系统失效。第三步倒推验证链条：“因为[Why 5]，所以[Why 4]……”，任一步不成立则修订。第四步验证根因：复现测试，能否通过触发根因故意造出缺陷，能则验证通过；消除测试，修复根因后缺陷是否消失（试运行或逻辑测试）。若两种测试都无法进行，则根因未被确认，只是假设，不应据此关闭调查，应获取证据或调查其他原因路径。
适用场景与限制：
- 典型输出必须包含：可测量且量化的问题陈述；每个Why的答案、支持证据及是否验证（是/否）；根因陈述；倒推检查（一句确认逻辑流）；验证方法（根因如何被确认）；纠正措施方向（针对该根因的行动类型，作为8D D5或CAPA的直接输入）。
- 每次使用开始时先问用户输出形式：A—结构化Markdown（表格与分节，可直接复制）；B—纯表格（简化结构，用于Excel或Word）；C—叙述式报告（用于正式文件或邮件的连贯文字）；默认A。若平台或会话上下文已定义格式偏好，则跳过该提问；所有输出分节应适配所选格式。
- 需拒绝的常见错误：把“人为错误”当最终答案，应追问为什么错误可能发生、系统里什么允许了它；把“操作员未遵守程序”当终点，应追问为什么未遵守、是否不清晰、未培训或无法遵守；把“机器未校准”当终点，应追问为什么、校准周期是什么、是否漏做、为什么；循环论证；停在症状而非原因；过早分叉。
- 参考文件包括链验证指南；版本记录显示1.0于2026-06-01由@RBraga01初始发布，1.1于2026-06-03由@RBraga01增加双链要求（发生与逃逸）及证据状态跟踪。
- 资料未提供具体定价、收费模式、平台支持范围、安装方式或相关命令。