理论学习和失败模式了解之后，本节将提供具体的操作指南，帮助你在实际项目中应用Pre-mortem技术。
清晰地描述失败的状态。要具体，不要模糊。
关键要素：
示例：
现在是3个月后，我的待办清单App已经彻底失败了。
具体表现是：
- 日活跃用户不足5人
- 我自己也回到了使用便利贴的日子
- 代码已经2个月没有更新了
失败场景模板：
现在是[时间周期]后，我的[项目名称]已经彻底失败了。
具体表现是：
- [具体失败指标1]
- [具体失败指标2]
- [具体失败指标3]
我回到了[描述失败后的状态]。列出可能导致失败的原因。要深入挖掘，不要停留在表面。
头脑风暴技巧：
数量要求：
示例：
这个项目失败是因为：
对每个失败原因进行分类、评估可能性和严重性。
分类框架：
| 失败原因 | 类型 | 可能性 | 严重性 | 优先级 | 备注 |
|---------|------|-------|-------|-------|------|
| 原因1 | 需求/技术/场景/习惯 | 高/中/低 | 高/中/低 | ⚠️/⚡/✓ | 具体说明 |
| 原因2 | | | | | |
评估标准：
可能性评估：
严重性评估：
优先级确定：
针对高优先级风险制定具体的预防措施。
预防措施原则：
预防措施模板：
| 优先级 | 失败原因 | 具体预防措施 | 执行时间 | 负责人 |
|-------|---------|-------------|----------|-------|
| ⚠️ | 复杂度失控 | 严格限制在3个核心功能内 | 立即执行 | 本人 |
| ⚠️ | 技术选择错误 | 选择成熟技术栈 | 开发前 | 本人 |
| ⚡ | 用户习惯难改 | 提供数据迁移工具 | 测试阶段 | 本人 |
根据预防措施调整项目需求和优先级。
调整清单：
缩小项目范围，专注核心功能
调整技术方案，选择更合适的技术
重新定义目标用户群体
修改项目时间计划
增加用户研究阶段
制定推广和留存策略
以下模板可以直接复制使用：
# Pre-mortem分析：[你的项目名称]
## 项目基本信息
- **项目名称**：
- **项目类型**：[App/网站/自动化脚本/数据分析/其他]
- **目标用户**：
- **核心功能**：
- **预计完成时间**：
## 第一步：失败场景设定
现在是[时间周期]后，我的[项目名称]已经彻底失败了。
具体表现是：
- [描述失败的具体状态]
- [描述你回到了什么状态]
## 第二步：失败原因列举
这个项目失败是因为：
1. ________________________________
2. ________________________________
3. ________________________________
4. ________________________________
5. ________________________________
6. ________________________________
7. ________________________________
8. ________________________________
9. ________________________________
10. ________________________________
（至少写10条，越多越好）
## 第三步：分类与评估
| 失败原因 | 类型 | 可能性 | 严重性 | 优先级 | 备注 |
|---------|------|-------|-------|-------|------|
| 原因1 | 需求/技术/场景/习惯 | 高/中/低 | 高/中/低 | ⚠️/⚡/✓ | |
| 原因2 | | | | | |
| 原因3 | | | | | |
| 原因4 | | | | | |
| 原因5 | | | | | |
## 第四步：预防措施制定
| 优先级 | 失败原因 | 具体预防措施 | 执行时间 | 负责人 |
|-------|---------|-------------|----------|-------|
| ⚠️ | 原因1 | [具体的预防措施] | [时间] | [人员] |
| ⚡ | 原因2 | [具体的预防措施] | [时间] | [人员] |
| ✓ | 原因3 | [具体的预防措施] | [时间] | [人员] |
## 第五步：需求调整
基于以上分析，决定：
缩小项目范围，专注核心功能
调整技术方案，选择更合适的技术
重新定义目标用户群体
修改项目时间计划
增加用户调研阶段
制定推广策略
[其他调整措施]
## 风险监控计划
- **定期检查**：[多久检查一次]
- **关键指标**：[要监控的关键指标]
- **预警信号**：[什么情况需要重新评估]
- **应急方案**：[如果发生问题如何应对]
## 下次Pre-mortem时间
1个月后
项目中期
重要里程碑前
需求变更时项目进行过程中，定期重新做Pre-mortem，因为情况会发生变化。
执行时机：
邀请不同角色的人参与Pre-mortem，发现更多潜在风险。
参与者角色：
执行方法：
把Pre-mortem发现的问题，用JTBD框架重新验证用户的真实需求。
验证问题：
针对不同复杂度的项目，采用不同深度的Pre-mortem。
个人项目：
团队项目：
企业级项目：
使用在线工具和模板提高效率。
推荐工具：
Pre-mortem不是一次性的活动，需要持续跟进。
跟进机制：
表现：
避免方法：
Pre-mortem不是要你变得悲观，而是要你变得现实。目标是识别可控风险，而不是放弃项目。保持建设性态度，关注"如何避免"而不是"可能会失败"。
表现：
避免方法：
要深入挖掘"为什么"。如果"用户不喜欢"，要问"为什么会不喜欢？"
表现：
避免方法：
识别风险只是第一步，关键是制定预防措施并落实到行动中。
表现：
避免方法：
Pre-mortem应该是一个持续的过程：
项目背景：开发一个学习辅助App
Pre-mortem分析：
项目背景：为公司开发财务报表自动化系统
Pre-mortem分析：
项目背景：为销售部门做客户行为分析
Pre-mortem分析：
可以给AI提供项目信息，让它帮助识别潜在风险：
请帮我做一个Pre-mortem分析。
项目信息：
- 项目名称：[项目名称]
- 项目类型：[App/网站/系统/工具]
- 目标用户：[用户描述]
- 核心功能：[功能列表]
- 技术方案：[技术栈]
请从以下维度帮我分析可能的失败原因：
1. 需求层面：用户需求、市场定位、竞争环境
2. 技术层面：技术选型、实现难度、维护成本
3. 场景层面：使用习惯、迁移成本、用户体验
4. 习惯层面：用户粘性、持续使用、推广难度
每个维度请列出至少3个可能的失败原因。基于以下Pre-mortem分析结果，请帮我评估每个风险的优先级：
[粘贴Pre-mortem分析结果]
请按以下格式整理：
⚠️ 高优先级风险：[原因] - [评估理由]
⚡ 中优先级风险：[原因] - [评估理由]
✓ 低优先级风险：[原因] - [评估理由]
并为每个高优先级风险建议具体的预防措施。✓ 预防胜于治疗：提前识别风险比事后补救成本更低
✓ 客观分析：基于数据和事实，而不是感觉和假设
✓ 持续改进：Pre-mortem应该是一个持续的过程，不是一次性活动
✓ 团队协作：多人视角比单个人更全面
✓ 具体行动：每个风险都要有具体的预防措施和责任人在开始你的项目之前，确保你能回答以下问题：
我做过Pre-mortem分析吗？
我列出了至少10个可能的失败原因吗？
我识别出了高可能性、高严重性的风险吗？
我为这些风险制定了具体的预防措施吗？
我把预防措施落实到项目计划中了吗？
我设立了风险监控机制吗？
| 概念 | 定义 | 核心问题 |
|---|---|---|
| Pre-mortem | 假设项目已经失败，追溯可能的原因 | 如果失败了，是因为什么？ |
| 风险评估 | 评估失败可能性和影响程度 | 这个问题多严重？ |
| 预防措施 | 针对风险的具体行动方案 | 如何避免这些失败？ |
| 风险监控 | 持续跟踪风险指标的变化 | 风险是否在可控范围内？ |
现在轮到你了。无论你想做的是一个小工具、一份数据分析、一个自动化脚本，还是给家人做的小网页，都可以用这个方法做一次Pre-mortem。
项目选择：
如果你有团队，邀请团队成员一起做Pre-mortem。不同视角会发现不同的问题。
项目进行过程中，定期重新做Pre-mortem，根据新情况调整策略。
通过系统的逆向思维实践，你可以显著提高Vibe Coding项目的成功率。记住：预测失败，比追求成功更有效。
这不是悲观，而是智慧。不是放弃，而是准备充分。不是限制创新，而是让创新走得更远。