加里·克莱因长期研究消防员、军事指挥官等专业人员，观察他们如何在时间紧迫、信息不完整的情况下作出决策。他的代表性成果之一，是"识别启动决策模型"。

克莱因发现，在熟悉而高压的情境中，经验丰富的人通常不会先列出所有方案，再逐项比较。他们会根据几个关键信号识别当前情境，迅速生成一个可行方案，然后在头脑中预演：如果照此行动，接下来会发生什么？前一个过程依赖模式识别，后一个过程被称为"心理模拟"。

2007年，这位长期研究专家决策的心理学家在《哈佛商业评论》上发表了一篇文章，题目是《开展一次项目事前验尸》。事前验尸的名称和核心做法，早在克莱因1998年出版的《力量的源泉》中就已经出现；2007年的文章则把它进一步整理成了一套便于团队使用的流程。

克莱因抓住了项目规划中的一个常见困境：问题往往不是没有人看见风险，而是看见风险的人觉得，现在把话说出来不合时宜。

方案已经得到领导支持，预算已经申请，上线日期已经公布，所有人都在讨论怎样把事情做成。这时再说"我怀疑它根本行不通"，听上去不像是在贡献意见，反而像是在反对项目。于是，疑虑被留在了会议之外。直到项目真的失败，复盘会上才有人说："其实我当时就觉得有问题。"

克莱因追问的是：能不能不等项目失败，就让这些不方便说出口的怀疑提前浮出水面？

事前验尸，就是他的回答。

假设一家企业准备上线一款新应用。产品已经开发完成，投放预算已经申请，上线日期已经公布，合作渠道也谈妥了。方案看起来很完整，会议气氛也很积极。

这时，负责人问："大家觉得，这个项目可能有什么风险？"

有人说资源可能不足，有人说进度可能偏紧，还有人说市场可能发生变化。每个人谈的都是"可能"，没有人愿意把话说得太重。领导点头表示重视，风险被记录在案，会议顺利结束，原来的计划却没有发生任何实质变化。

现在换一种问法。

负责人告诉所有人："现在已经到了项目验收日。这款应用彻底失败，产品已经关闭，前期投入大部分无法收回。不要再讨论它会不会失败，请告诉我：它究竟是怎么失败的？"

会议室里的注意力随之改变。

失败不再是一个需要判断概率的未来事件，而是一个必须解释的既定结果。讨论重点从"它会不会失败"转向"它为什么会失败"。那些原本不方便说出口的怀疑，也获得了一个合法的表达出口：

"为了赶上线日期，我们取消了真实用户测试。"

"渠道带来了大量注册，但这些人可能根本不是目标用户。"

"领导已经公开表态，我即使发现问题，也不敢要求延期。"

你不需要站出来反对项目，只需要完成一个规定任务：既然项目已经失败，请解释一个可能的死因。

这正是事前验尸与普通风险讨论的核心区别。它并不比普通风险讨论更加悲观，而是暂时改变了问题的前提。

普通风险讨论问："它会不会失败？"人们很容易把精力用来判断失败概率，或者证明事情未必有那么糟。事前验尸则暂时关闭这场概率争论，直接追问："既然它已经失败，究竟是什么造成的？"

它不是只靠一句"假设失败了"发挥作用，而是连续完成了四次转换：

- 把不确定的结果，改成必须解释的确定前提；

- 把对方案的正面论证，改成对失败过程的因果追溯；

- 把容易相互影响的集体讨论，改成先独立生成、再集中汇总；

- 把零散的风险故事，改成计划中的预防措施和触发动作。

少了最后一步，事前验尸只是一次悲观想象；少了独立书写，它又很容易退化成一场普通的风险讨论会。

克莱因在事前验尸中设置了一条看似简单、实则关键的规则：先让每个人独立写下失败原因，再进入集体讨论。

这项规则保护的是每个人尚未进入公开讨论的独特信息。

如果一开始就自由发言，最先开口的人，尤其是领导或专家，很容易给后面的讨论设下锚点。其他成员会更倾向于沿着已有方向补充，而那些与主流判断不一致的局部信息，往往还没来得及出现，就已经被压了下去。

先写后说，让每个人在接触他人的观点之前，先形成自己的判断。

回到那款新应用。独立书写结束后，团队开始轮流汇总：每人每次只说一个尚未被提及的原因，直到没有新的内容。主持人此时只负责记录和澄清，不急于评价，更不能马上解释"这个问题已经解决"。一旦收集风险变成了现场辩护，成员很快就会重新闭嘴。

团队写下的死因，可能来自四个层面：

- 产品价值：产品解决的并非用户的高频需求；为了赶日期，团队取消了真实用户测试。

- 增长与商业：注册量很高，留存却很低；红包吸引来的不是目标用户；获客成本上涨后，预算无法持续；渠道只负责导流，却不承担用户质量。

- 数据判断：不同部门使用不同的数据口径，虚假增长长期没有被发现。

- 组织协同：项目负责人明知存在问题，却因为领导已经公开表态而不敢要求延期；多个部门都参与了项目，却没有人对最终结果负责。

不过，列出死因还不够。团队还要把零散原因连接成一条能够解释失败过程的因果链：

为了按时上线，用户测试被一再推迟；产品最终按照内部判断发布，核心需求始终没有得到验证；投放扩大后，新增很高，留存却持续偏低；获客成本无法收回，团队又因为不愿承认早期判断错误而继续追加预算；最终，项目在投入进一步扩大后被迫关闭。

"用户风险"只是一个模糊标签，这条失败链却能告诉团队：事情可能从哪里开始，又会怎样一步步恶化。

经过筛选，团队发现，真正需要优先处理的并不是"上线可能延期"，而是"为了按时上线，跳过用户价值验证"。于是，计划发生了具体变化：上线前必须完成小规模真实用户测试；设置留存率和真实使用行为的最低阈值；指标未达标时暂停扩大投放；将渠道新增与有效用户分开统计；明确唯一业务负责人，并为必要的延期保留决策空间。

事前验尸没有取消项目，它只是提前找到了最关键的失败路径，并在投入扩大之前将其截断。

克莱因提出的事前验尸，后来得到了丹尼尔·卡尼曼的大力推广。

克莱因长期研究专家直觉的力量，卡尼曼则更关注认知偏差如何扭曲判断。两人对直觉是否可靠曾有过分歧，还合作发表过一篇讨论直觉适用边界的论文，但在事前验尸上，他们达成了共识。

卡尼曼在《思考，快与慢》中解释，当领导明确宣布自己的意图之后，团队对计划可行性的怀疑往往会逐渐减弱。到了最后，继续表达疑虑，甚至可能被看作对团队和领导不够忠诚。

事前验尸改变了异议在会议中的身份。成员不必公开扮演反对者，也不必证明项目一定会失败；他们只是在执行同一个任务：解释项目为什么已经失败。

卡尼曼认为，这种方法操作简单、成本较低，通常不会直接导致计划被取消，却很可能促使团队对计划作出公认有益的修改。

克莱因看到的是，一线成员掌握的风险信息缺少安全的表达出口；卡尼曼看到的是，群体过早形成一致意见后，反面信息会受到压制。事前验尸同时回应了这两个问题。

因此，它最大的敌人往往不是乐观，而是过早一致。

当会议中不断出现"方向已经确定""领导非常重视""现在只讨论怎么执行"时，风险并没有因此消失，只是失去了进入正式讨论的资格。事前验尸重新赋予异议一个安全身份：你不是在反对项目，而是在帮助团队提前完成一次复盘。

事前验尸有明确的调用时点：方案已经具体到足以分析，但资源尚未大规模投入，计划仍然有修改空间。

方案太粗，团队只能提出"资源不足""沟通不畅"之类的泛泛风险；投入已经无法撤回，即使发现问题，也很难改变结果。最合适的时机，恰好处在两者之间。

出现以下信号时，尤其值得做一次事前验尸：

- 方案已经获得明显支持。会议开始反复强调"方向已经确定"，只允许讨论执行细节。

- 共识形成得异常迅速。这未必说明方案正确，也可能说明权威已经定调，成员不愿承担反对成本。

- 项目依赖大量未经验证的假设。用户会接受、渠道会配合、成本不会上涨、关键人员不会离开——假设越多，潜在的失败路径越多。

- 项目跨越多个部门或专业。管理者掌握的是全局，真正致命的信息却可能分散在技术、运营、销售或一线执行人员手中。

- 项目即将跨过不可逆门槛。例如签订重大合同、启动大规模投放、全面上线、正式并购。在跨过门槛之前，团队尤其需要确认自己遗漏了什么。

方案完全空白时，不适合开展事前验尸。没有清晰的目标、资源、时间表和实施路径，团队只能凭空想象风险。事前验尸不是用来代替第一版方案设计的。

它也不能被某个人用来证明"我早就说过这个项目不能做"。它的任务是改进计划，而不是为反对项目寻找更多理由。必要时，事前验尸当然可能暴露出足以叫停项目的根本问题，但"叫停"应当来自证据和验证，而不是来自谁讲出了最吓人的失败故事。

一次能够真正落地的事前验尸，可以分为四个步骤。

第一步：设定回看时点和失败状态

先确定团队站在未来的哪一天回看，以及什么结果算作"彻底失败"。

"项目做得不太理想"太模糊。更有效的设定是："现在已经到了项目验收日，产品因为核心指标长期不达标而关闭，大部分投入无法收回。"

回看时点应与项目周期相匹配。三个月的营销活动可以站在活动结束日回看，两年的产品项目则可以站在关键验收节点回看，不必一律设定为"一年以后"。

第二步：独立写下所有可能的死因

主持人明确宣布项目已经失败，请每个人在几分钟内独立写下所有可能的原因，尤其是那些平时不方便公开谈论的问题。

这一阶段不要讨论，不要相互提示，也不要一边写一边替原方案辩护。目的不是尽快形成共识，而是尽可能保留每个人掌握的独特信息。

第三步：逐人汇总，还原失败链条

每人每轮只说一个尚未出现的原因，直到所有信息都被记录。主持人可以追问事实和含义，但不要现场反驳。

汇总之后，再把零散死因连接起来，追问：

只有把原因连接成路径，团队才能找到真正可以干预的节点。

第四步：筛选关键风险，修改原有计划

团队可以从三个维度判断优先级：发生的可能性有多大，一旦发生损失有多重，以及发生后是否容易逆转。

对优先风险，至少要回答四个问题：

- 现在可以采取什么预防措施？

- 哪些早期信号说明风险正在出现？

- 指标达到什么阈值时必须采取行动？

- 谁负责监测，又由谁决定暂停、调整或退出？

克莱因原始流程的核心，是独立生成失败原因、逐人汇总，并据此加强计划。责任人、监测指标、预警阈值和触发动作，属于将这一方法接入项目管理闭环时的增强设计。它们并非克莱因最初版本中的硬性步骤，却决定了风险清单能否真正改变执行。

会议结束后，团队必须能够回答一个问题：原来的计划具体改变了什么？

如果答案是"什么都没有改变"，这次事前验尸就只是一次情绪释放。

个人做重大决策时，也可以使用一个简化的四问版：

1. 假设到了预定验收日，这件事已经彻底失败，它是怎么失败的？

2. 哪些原因是我现在已经隐约知道，却不愿认真面对的？

3. 哪些风险最可能发生？哪些风险一旦发生，损失最大或最难挽回？

4. 本周可以改变什么，让这些失败路径更难出现？

个人使用时不需要逐人汇总，但仍然应该先完整写下死因，再统一筛选。否则，你很容易边想边替自己原来的决定辩护。

实际运用中，还有五个常见误区需要避开。

第一，不要让权威过早限定答案。克莱因在原始流程中让项目负责人先报告一个原因，用意是示范坦诚；但在权力距离较大的团队里，负责人首先发言也可能形成新的锚点。可以保留"先独立书写、再轮流汇总"的骨架，同时让负责人最后分享。这是为了降低权威影响而作出的流程优化，并非原始方法的固定要求。

第二，收集死因时不要急着反驳。某个风险刚被提出，就有人立刻解释它为什么"不可能发生"，会议很快会重新变成方案辩护会。

第三，不要只找执行问题。"沟通不到位""团队不够努力""协同效率太低"很容易被写出来，但更应该检查的是：目标是否选错，用户需求是否真实存在，商业模式是否成立。

第四，不要用多数投票消灭少数洞察。一个只有一人提出的风险，可能恰好来自只有他掌握的现场信息。是否值得重视，应看证据和后果，而不是看有多少人赞成。

第五，不要让风险清单停在纸上。没有预防措施、责任人和触发条件，识别再多风险也不会自动改善结果。

事前验尸有一个必须说清楚的边界：团队想象出来的死因仍然是假设，不是已经发生的事实。

一个故事越具体、越完整，人们越容易觉得它"很可能发生"。但叙述得逼真，并不等于判断得准确。团队成员还可能共享同一个盲区，于是所有人都想到了相似的风险，却共同遗漏了真正致命的问题。

因此，事前验尸负责生成失败假设，不能代替对假设的验证。团队仍然需要利用用户研究、历史数据、专家判断和小规模试验，判断这些风险究竟是否成立。面对重大决策，还应结合外部专家、红队和压力测试，主动寻找团队内部看不到的盲区。

它与极端情景模拟也不是同一个工具。

极端情景模拟通常先设定一种具体的极端冲击，或一组极端但仍有可能发生的条件，例如需求骤降、成本翻倍与供应链中断同时出现，再检验系统能否承受。事前验尸不预设某一种冲击，而是从"项目已经失败"这个确定前提出发，反向生成多条可能的失败路径。

前者关注的是：如果特定冲击出现，系统扛不扛得住？

后者关注的是：既然项目已经失败，哪些我们尚未重视的原因可能导致这一结果？

克莱因在《哈佛商业评论》的文章中举过一个真实案例。一个团队准备把先进算法提供给军事空中行动规划人员。事前验尸中，一名此前始终沉默的成员指出：其中一个算法很难在现场使用的部分笔记本电脑上运行，计算可能耗时数小时，而一线人员需要迅速得到结果。如果找不到替代方案，整个项目在实际环境中就不可行。

算法开发人员其实已经设计出一条高效的计算捷径，只是此前一直没有提及。团队改用这条捷径后，项目最终取得了成功。

这个案例说明，事前验尸的价值不只在于列出更多风险，更在于让团队成员已经掌握、却一直没有进入正式讨论的现场信息浮出水面。

2010年，贝丝·维诺特、加里·克莱因和斯特林·威金斯让178名大学生评估一份虚构的H1N1校园应对计划，并比较五种计划评估方法。结果显示，事前验尸组对计划成功的信心下降幅度最大，且显著高于利弊分析组和只列缺点组。

这项研究支持了一个相对克制的结论：与其他几种方法相比，事前验尸更能打破参与者对既有计划的信心。

但它没有证明参与者发现了更多或更准确的风险，也没有证明真实项目因此更容易成功。参与者是平均年龄约19岁的大学生，他们既没有制订这份计划，也不负责执行。它提供的是对作用机制的初步支持，而不是"事前验尸能够提高项目成功率"的直接证明。

事前验尸也不是开会当天完成的一次性动作。会议形成的风险清单，不能在项目启动后被束之高阁。原先识别的早期信号是否出现，预防措施是否落实，团队是否重新开始报喜不报忧，都需要持续观察。

当目标发生重大变化、项目范围明显扩大、核心负责人更换，或者外部环境突变时，原来的失败路径可能已经失效，新的失败路径也可能随之出现。这时，需要重新做一次事前验尸。

逆向思维提供的是"反过来想"的一般方向；极端情景模拟检验的是系统能否承受特定冲击；事前验尸则是一套面向具体方案的结构化程序。它不仅要求你假设失败，还要求团队独立书写、汇总异议、还原失败的因果链条，并把想象中的死因转化为现实中的计划修改。

真正成熟的团队，不是从不谈失败，而是在投入扩大之前，先给失败一次充分发言的机会。

当你站到未来回头看，那些被乐观、权威和一致意见遮住的东西，往往会重新变得清晰。