用途：当你需要一个失败事件的根因，或用户提到“为什么会这样”“这总是坏”“写事后复盘”“找出真正原因”时使用。适合事故、停机、缺陷、错过截止时间或流程失败，以及快速修复后问题仍反复出现的情况。若只是拼写错误、原因已显而易见的单行 bug，或需要数据分析而非因果链的指标问题，则跳过。
主要能力：
- 链条：先写下可观察的问题陈述（发生了什么、在哪里、何时、影响），然后对上一个答案连续追问“为什么”。每个“为什么”回答的是前一个答案，而不是原始问题。数字五是参考，当原因落在团队可控范围内、且修复它能防止问题时即可停止。
- 检查：用“因此”从下往上反向检验整条链，每一步必须由下一步推导得出。若最后答案是“人为错误”“时间不够”或“运气不好”，再问一次为什么，因为这些描述的是缺失的防护，而不是原因。
- 分支：当一个“为什么”有多个有效答案时，各自展开成独立链条；若原因分散，可按人员、流程、工具、环境、数据或度量（鱼骨图视角）分组，并对前两三个继续追链。
- 对策：对每个根因给出遏制（立即止损）、修复（消除原因）、预防（设置复查或护栏），并指定负责人和日期，或标注“待分配”。
使用方式：开始前需先收集资料，阅读日志、提交、工单、时间线和配置，再回答任何“为什么”。把每个答案标记为已验证（有证据）或假设（合理但尚未核实）。仅当工具无法获取事实时，才最多提三个问题。小请求可走轻量路径：用 3-5 行写出链条，每个根因配一个对策。
限制与常见误区：不要跳到偏爱的原因再倒推链条来为之辩护；不要问“谁”而不是“为什么”，追责会过早终止链条；复杂故障不要只用单链思维；不要停在无人能改变的原因上而不追问为何没有后备方案；汇总时不要把假设行当作结论。