用途
Five Whys Plus 用于在故障已经定位到某个组件、路径或子系统，且直接原因已知，但复发原因或系统性根因尚不明确时，构建一条以证据为链接的因果链，从已知的直接故障追溯到可行动的系统性根因，并给出能够阻断该故障的对策。
它适用于以下情况：故障已定位；直接原因已知但系统性根因未知；仅针对症状的修复已失败且故障再次出现；需要预防措施来解决“为什么直接原因会成为可能”。
主要能力
- 以证据链接因果链：每一步追问“为什么”时，将前一个答案作为新的结果，提出原因，并引用日志、代码、配置、指标或证人等证据，同时命名并排除其他可能原因。
- 在深入之前分支：询问还有什么可能产生相同结果，保留所有有证据支持的独立路径，将保留的分支视为一个因果集合，而不是强行归结为单一根因。
- 反事实检验：对每条路径和整个集合进行检验，询问“移除该原因能否阻断该路径”，再询问“移除保留的根因集合能否阻断观察到的故障”。保留那些独立充分、移除后能阻断自身路径的分支，不因其他分支仍可能导致故障而拒绝它们。
- 每个分支的停止标准：只有当原因有证据、可控、可行动、能防止复发、非归咎于人（不仅仅是“某人犯了错”）且对该路径反事实成立时，才停止该分支。如果触及人为错误，继续追问为什么该错误会成为可能。
- 为每个保留根因给出对策：命名系统性修复、可执行动作以及如何检查复发，优先消除使直接原因成为可能的条件，而非仅修补直接症状。
- 验证或受阻时停止：当停止标准通过且已指定对策，或进一步步骤缺乏证据时停止，不凭习惯填充。
使用方式
按以下步骤操作：
- 陈述已定位的问题。记录可观察症状、已确认的组件/路径、时间窗口、范围和影响。如果缺少定位，停止。
- 用证据链接“为什么”。将前一个答案作为新的结果；提出原因；引用日志、代码、配置、指标或证人；命名并排除其他可能原因。如果只是推测，停止。
- 在深入之前分支。询问还有什么可能产生相同结果；保留所有有证据支持的独立路径。将保留的分支视为因果集合，而不是强行归结为单一根因。
- 对每条路径和整个集合进行反事实检验。对每个候选原因询问：“移除该原因能否阻断该路径？”然后询问：“移除保留的根因集合能否阻断观察到的故障？”保留那些独立充分、移除后能阻断自身路径的分支；不要因为另一个分支仍可能导致故障就拒绝它们。
- 对每个分支执行停止标准。只有当原因有证据、可控、可行动、能防止复发、非归咎于人（不仅仅是“某人犯了错”）且对该路径反事实成立时，才停止该分支。如果触及人为错误，追问为什么该错误会成为可能。
- 为每个保留根因给出对策。命名系统性修复、可执行动作以及如何检查复发。优先消除使直接原因成为可能的条件，而非仅修补直接症状。
- 验证或受阻时停止。当停止标准通过且已指定对策，或进一步步骤缺乏证据时停止。不要凭习惯填充。
输出格式如下：
Problem: <localized symptom + component> Chain: Why1: <cause> | Evidence: <...> | Ruled out: <...> WhyN: ... Causal set check: would removing all retained roots block the failure? yes/no Roots:
- <systemic cause> | Pathway counterfactual: <...> Countermeasure: <action that removes the enabling condition> Verification: <how to confirm this pathway is blocked>
适用场景
- 故障已定位到具体组件或路径，直接原因已知，但需要找到系统性根因以防止复发。
- 仅针对症状的修复已失败，故障再次出现。
- 需要制定预防措施，解决“为什么直接原因会成为可能”。
限制
以下情况不应使用本方法：
- 故障尚未定位，或存在多个候选原因——应先进行区分。
- 根因已有证据且可行动——直接修复即可。
- 没有证据能回答下一个“为什么”——应先收集证据。
- 一次性错误，没有流程、工具或设计上的促成因素。
- 需要选择性缺陷分析（IS/IS-NOT 分析）的情况。
- 在承诺之前进行前向故障预测。
验证时，如果任何步骤缺乏证据、从未考虑替代方案、保留的根因未通过其路径反事实检验，或完整因果集合无法解释故障，则应推翻该因果链。
当根因已修复并验证，或问题仍处于定位前阶段时，停止应用本方法。
过度应用防护：对于单个已知的一行缺陷，跳过完整因果链；不要以归咎于人结束；不要在没有数据的情况下虚构深度。