使用场景: 工程团队，故障后复盘 45 分钟宕机
这样组织的原因: 如果停在「为什么 2」（磁盘满了），解决方案就是一次性扩容。继续追问到「为什么 5」，发现了一个流程漏洞——下一个高写入功能上线时同样的问题会再次出现。
使用场景: Scrum 团队，连续三个 Sprint 未完成承诺后的回顾会
这样组织的原因: 团队此前试图通过加班来解决速度问题（把「为什么 1」当成根本原因）。5 个为什么揭示了真正的问题是流程漏洞，而不是努力程度不够。
使用场景: 客户成功团队，分析每周都会出现的同类工单
这样组织的原因: 客服团队已经发了 6 个月相同的临时解决方案邮件。5 个为什么把修复从被动的绕过变成了主动的平台决策。
使用场景: 产品团队，复盘采用率比预期低 60% 的功能上线
这样组织的原因: 技术团队交付了一个可用的功能。5 个为什么揭示问题从来不是技术问题——而是一个把「开发完成」等同于「完成」的产品流程漏洞。
使用场景: 销售经理，分析企业客户失单规律
这样组织的原因: 销售团队最初把失单归因于定价。5 个为什么追溯到产品流程失效——企业买家一直在提合规需求，但没有正式渠道把这些转化为路线图优先级。
使用场景: HR 和工程经理，分析某团队 40% 年度人员流失
这样组织的原因: 人员流失最初被归因于薪酬问题。5 个为什么揭示工程师离开是因为缺乏有意义的工作——而这个问题只需要一个简单的管理流程改变就能更早干预。
回到模板页，替换成你自己的内容，就可以继续使用这套结构。
使用这个模板： /editor/new?template=five-whys
使用这个 5 个为什么模板