用途：对一个问题连问“为什么”3-7 次（5 是平均值而非硬性规则），从症状挖到可改的流程/系统/设计层，而不是在症状层面修补。适用于事故或 bug 复盘（postmortem）、同类问题重复出现、表层修复明显不够、流程问题诊断，以及用户报告“为什么我们老是 X”这类需要根因分析的信号。
主要能力与操作步骤：1）准确陈述问题，必须含指标+时间+范围，例如“2026-05-25 14:00-15:00 us-east-1 登录失败率 32%”，而非笼统的“登录有问题”；2）问 Why #1 得到答案 A1，A1 必须是事实而非评价；3）把 A1 当作问题继续追问，得到 A2；4）重复直到到达“可改流程/可改系统/可改设计”的根因，通常 3-7 层，终止判断是根因属于“下次能从流程层面预防”而非“这次某人疏忽”；5）验证因果链，从根因正向推演能否解释最初问题，不能则链条断了需重做；6）提出针对根因的行动，如加 lint rule、改 oncall 流程、重设计权限模型等流程/系统级行动。
决策 Checklist：问题陈述含指标+时间+范围；每个 Why 的答案是事实而非评价；答案里没有人名（Why 后面跟机制不跟人）；根因属于流程层面可预防的层级；从根因能正向推演回最初问题（双向验证）；行动针对根因而非症状。
限制与反模式：单次偶发、无规律可循的问题可能是噪声，应先观察；复杂系统问题（Cynefin Complex 域）不适用，因为 5 Whys 假设线性因果，而复杂系统是多因加涌现；团队氛围若是“找罪人”，5 Whys 容易变成责备链；真正 unknowable 的问题（如某次 ML 模型输出为何如此）应使用统计方法。常见陷阱包括数到 5 就停、找罪人、没验证因果链、只走一条 why 链忽视并行多因、过早跳到方案。必要时可配合鱼骨图（Ishikawa）处理多分支。
与其他框架的关系：Pre-Mortem 是事前 5 Whys；可配合 OODA Loop 的 Orient 步骤；Second-Order Thinking 向未来追，5 Whys 向过去追，时间方向互补。参考：大野耐一《丰田生产方式》(1978)、Eric Ries《The Lean Startup》(2011)。