用AI做一次事前验尸，找出项目计划还没回答的问题

从假想失败中，找出现在值得问的问题。

你已经为一个小软件拟好计划。请AI列风险，可能得到一串熟悉的类别：技术问题、需求不足、进度拖延。什么信息，才会让你改变接下来先做哪件事？

事前验尸（premortem） 发生在实施之前：暂时设定计划已经失败，再解释它怎样走到这个结果。失败是练习的前提，不是对项目的预测。这个设定给讨论一个可以倒着追问的终点。

原方法让团队做什么

Gary Klein在2021年的说明中，让团队先了解计划，再假定它已失败。成员各自写原因，随后轮流提出不同原因，再考虑应对。Klein将其解释为更容易说出保留意见的安排；团队成员带着不同经验参与讨论。

问题的改变有实际意义。“有什么风险？”容易停在类别上；“这个计划怎样失败了？”则要求解释决定与事件之间的联系。这份解释仍有待考察，不是发现了已经发生的事。

为什么设定失败，以及研究还没回答什么

1989年，Deborah Mitchell、J. Edward Russo与Nancy Pennington通过两项学生实验，研究对假想个人及工作结果的解释。他们分别改变事件在过去或未来，以及结果确定或不确定。结果确定性比单纯时间视角更影响解释；确定结果引出更多动作式原因。作者提醒，原因更多未必意味着解释更好。实验没有测试AI或软件项目成败。这里的启发是用具体故事寻找问题，不把细节当成准确性的证据。

用在一个需要决定工作先后的计划上

假设一位虚构的独立软件经营者准备做客户审稿工具。初步计划是先打磨稿件总览，再加入邀请与评论。

事前验尸先设定一个结果：

四周试用结束，客户仍通过邮件给意见，经营者仍在手工归并评论。

一种可能的解释是：

收到邀请的联系人，将邀请转发给真正审批的人。对方无法完成加入工具，于是意见回到邮件，经营者继续在产品之外合并回复。

整条链都是编写的假说，事件尚未发生。它的用途，是暴露计划中的一个假设：即使真正审批的人不是最初收件人，邀请流程也能让对方完成审稿。

更好的总览未必能回答这个问题。事件链指向了一件值得先查清的事：

真正审批的人收到转发邀请后，能否看到稿件并提交意见？

它比“客户可能不喜欢工具”更能帮助安排工作先后，因为它指出了具体人物、起点，以及产品计划依赖的动作。

继续打磨总览前，先调查审批人能否通过转发邀请完成审稿。

建议的下一步是：扩建总览之前，请一位预期审批人尝试这一段流程的某个版本，观察对方怎样进入稿件并尝试提交意见。实际情况可以帮助判断，是否应该先处理邀请流程。本例没有开展这次尝试。

失败故事还没有确定加入为什么会有困难，因此也不足以决定某种修法，例如取消登录。它完成的是更小的一件事：将宽泛担忧变成一个值得在继续打磨之前回答的问题。

让AI帮助展开假说

单人使用时，可以先写下自己的担忧，再请AI补充。这是本文的应用安排，不是1989年研究的实验结论。把短计划与失败结果一起提供，请它把推理展开：

下面是我的项目计划和自己的担忧。做一次事前验尸：假设四周试用结束，客户仍在邮件里给意见。请描述一条可能导向这个结果的动作链，标出假设及需要进一步解释的跳步。指出它依赖的计划假设，再提出一个我现在能调查、且答案会改变工作先后的问题。事件保持为假想，不替客户回答，也不声称修法已经验证。

读回答时，关注会影响下一决定的那个联系。本例中，是转发邀请能否让实际审批人完成审稿。如果AI从“邀请被转发”直接跳到“客户拒绝使用产品”，先问清中间可能发生什么，再接受这份解释。

同一个模型分别扮演创始人、客户和项目经理，仍然是一个来源在生成可能性，不能重现Klein团队练习中的独立意见。把问题带给能够回答的人，让假想失败帮助你决定需要向他们了解什么。