事前验尸法提示词（Pre-mortem：假设项目已经失败，倒推失败原因并提前设防，附 45 分钟会议流程）
项目计划基本定稿、正式开工前用：让模型站在客户、一线人员、财务、技术、外部合作方五个立场各写一段「项目是怎么失败的」，归并出最可能的失败原因，逐条配上预防动作和预警信号，并给出带团队现场做一次事前验尸的流程。
通用大模型 对话模型通用
我们要给一个即将启动的项目做一次「事前验尸」。请先不要评价计划好不好，直接接受这个设定：现在是 [设想的失败时点]，这个项目已经彻底失败了。 项目计划概要：[项目计划概要] 当初定义的成功标准：[成功标准] 团队与主要干系人：[团队与干系人] 有人私下担心、但没在会上说的事：[私下的担忧] 请分四段完成。 第一段，失败故事。分别站在 5 个立场——客户或最终用户、一线执行人员、财务或出资方、技术或交付负责人、外部合作方——各写一段 80 字以内的「事后回忆」，用过去时，讲清在他看来项目是怎么垮掉的。五段的原因不许重复；至少有一段涉及人和协作（没人敢说、互相等、关键人离开），不能全是技术和进度问题。 第二段，归并原因。把故事里的失败原因合并成 6–8 条，每条写成「因为某事，所以某结果」。逐条给两个判断：发生的可能性（高 / 中 / 低），以及发现时是否已来不及补救（是 / 否），并说明依据来自计划里的哪句话；计划里没有相关信息的，标【计划未提及】——这本身就是一个发现。 第三段，设防。只挑「可能性高」或「发现时来不及」的原因，每条写：现在就能做的预防动作（本周谁去做什么）、最早的预警信号（能观察到的现象，不是「进度落后」这种结果）、信号出现后的应对。预防动作要落到对计划的修改上：加一个检查点、提前一项验证、增加一个备选，而不是「加强管理」。 第四段，带团队现场做的 45 分钟流程：主持人宣布设定 → 每人独立写 5 分钟，不讨论 → 轮流每人念一条，直到念完 → 归类投票 → 定预防动作与负责人。写出主持人的开场白，以及有人说「别这么悲观」时怎么回应。 约束：失败原因必须和我给的计划内容挂钩，不写放之四海皆准的套话；不编造计划里没有的数字和人名。
高亮处换成你自己的内容：[设想的失败时点]、[项目计划概要]、[成功标准]、[团队与干系人]、[私下的担忧]
ChatGPT Plus 充值
已被复制 0 次
使用说明
怎么填变量：[设想的失败时点] 选一个结果已经见分晓的时间，比如「上线后第 3 个月」「交付后半年」。[项目计划概要] 贴里程碑、分工、关键假设，越具体，模型找到的漏洞越贴近实际。[私下的担忧] 把茶水间里听到的话写进来，这些通常最接近真相。
常见失败与调整：
- 做成了常规的风险讨论，大家礼貌地说「可能会有点延期」。事前验尸的关键是设定「已经失败」，让人从辩护计划转为解释失败，说话的顾忌会少很多。
- 现场直接开始讨论，职位高的人先开口，后面的人就跟着说。一定要先独立写，再轮流念。
示例输出
示例，仅供参考（虚构：某连锁健身房的会员系统更换项目，设想时点为上线后第 3 个月）
失败故事（节选）
- 会员：「换系统那周，我的次卡少了 6 次，前台查不到记录，让我等通知。等了两周没消息，我就没再续费。」
- 前台店员：「培训只有一个小时，还排在晚高峰之前。上线第一天排队排到门外，我们只好先用纸登记。」
- 技术负责人：「旧系统的数据格式比想象的乱，可我在启动会上没敢说需要再多两周。」
归并原因
| 原因 | 可能性 | 发现时来不及 | 依据 |
|---|---|---|---|
| 因为会员余额迁移后没有逐店核对，所以上线后出现余额错误 | 高 | 是 | 计划中数据迁移只安排 1 次，没有核对环节 |
| 因为培训压在上线前一天，所以店员不会操作 | 中 | 否 | 计划只写「上线前完成培训」，未写时长 |
| 因为技术负责人不敢提延期，所以带着隐患上线 | 中 | 是 | 【计划未提及】任何提出延期的渠道 |
设防（第 1 条）：本周由项目经理在计划中增加「迁移演练 2 次，每店抽 30 名会员核对余额」。预警信号：第一次演练的核对差异超过 1%。应对：暂停上线排期，逐条查清差异来源。
同款作品
用这条提示词做出来的作品；原作者会因此获得积分
还没有同款，来做第一个。
0 条评论
还没有评论，来抢沙发～