pre-mortem

事前验尸——先失败，再动手

为尚未发生的项目进行复盘。揭示“列出所有风险”这类提示词会遗漏的真实风险。

源自 Gary Klein 在 MIT Sloan 的研究，如今已成为 AWS 和其他运营成熟型组织的标准做法。

事前验尸的 5 个步骤

步骤 1. 想象自己身处 6 个月后的未来

项目已经上线。这是一次显而易见、公开的失败。Reddit 上有一个相关讨论串。CEO 正在追问出了什么问题。

步骤 2. 写下事后复盘的报纸标题

用一句话写清楚。具体、明确。示例：

• ❌ 不佳：“我们遇到了一些质量问题。”
• ✅ 良好：“2026-09-12，Stripe webhook 处理程序按原始请求体哈希去重，因此 Stripe 在网络短暂中断后重试投递时，3 万名客户被重复扣款。”

这个标题会迫使你明确指出具体的失败模式。

步骤 3. 列出导致这一具体失败的所有原因

集思广益，列出 10-15 个原因。要具体。每一项都应提及：

• 一个真实的组件 / 文件
• 一种真实的失败模式（竞态条件、架构不匹配、凭证过期）
• 一个真实的人为因素（值班人员没看到警报、运行手册已过时）

不要接受“测试不充分”这类含糊说法。应改成“我们没有针对去重键冲突情况编写基于属性的测试”。

步骤 4. 按可能性 × 严重性排序

针对每个原因评分：

• **可能性：**1-5（1=十年一遇，5=每月发生）
• **严重性：**1-5（1=表面问题，5=数据丢失 / 违规）
• **风险评分：**可能性 × 严重性

风险评分最高的 3 项 → 这是优先级最高的缓解措施。

步骤 4b. 对风险分类——真老虎 / 纸老虎 / 大象

评分后，将每项风险分为以下三种类型之一：

🐯 真老虎——你本人认为可能导致项目脱轨的真实问题

• 基于证据、过往经验或明确的逻辑
• 应让你夜不能寐
• 需要采取具体行动
• 按紧迫性对每只真老虎分类：
  • 上线阻断项：上线前必须解决（核心功能损坏、合规阻碍、数据完整性风险）
  • 快速跟进项：上线后 30 天内必须解决（性能问题、次要功能）
  • 持续跟踪项：上线后持续监控，若成为问题再修复（边缘情况、锦上添花的功能）

📄 纸老虎——他人可能提出，但你认为并非真实风险的担忧

• 表面上听起来合理，但发生可能性低或被夸大
• 不值得投入大量资源
• 值得记录，以便与利益相关方达成共识并避免反复争论
• 对每项都说明你为何认为它不是真实风险

🐘 大象——团队心知肚明，却没有公开讨论的事情

• 令人不安的担忧：技术债、团队矛盾、不切实际的时间表、无人喜欢的设计
• 尚不确定——你不确定这是不是问题，但也没人调查
• 上线前值得明确提出——沉默的大象会在上线后变成真老虎

步骤 5. 针对风险排名前三的原因，在计划中写下防护措施

每项防护措施都应是对计划的具体改动：

• 一项本可以发现问题的测试
• 一个断路器 / 功能开关
• 一条运行手册条目
• 一个带有具体 SLO 的监控警报

如果前三项原因中有任何一项无法在时间 / 预算范围内缓解，请向用户说明：“此计划接受 X 风险，且不采取缓解措施。”

模板——添加到 PLAN-*.md

## Pre-mortem

Six months from now, this project failed. Headline:

> <one-sentence failure headline>

### Top reasons (likelihood × severity)

| Cause | L | S | Risk | Mitigation in plan |
|---|---|---|---|---|
| <specific cause> | 4 | 5 | 20 | <Task #N: write idempotency test> |
| ... | | | | |

### 🐯 Tigers (real risks — require action)

| Tiger | Classification | Mitigation | Owner | Due |
|-------|---------------|-----------|-------|-----|
| <risk> | Launch-Blocking | <concrete action> | <team/person> | <date> |
| <risk> | Fast-Follow | <concrete action> | <team/person> | <date> |
| <risk> | Track | <monitoring approach> | <owner> | post-launch |

### 📄 Paper Tigers (overblown — document to align stakeholders)

- **<concern>**: Not a real risk because <reason>. If <condition> changes, revisit.

### 🐘 Elephants (unspoken — needs open discussion)

- **<concern>**: Nobody is talking about this. Suggested conversation: "<how to raise it>".

### Accepted risks (no mitigation)

- <risk> — accepted because <budget/scope reason>. Owner: <name>.

各类型的常见失败模式

快速入门 — 各类型最常见的事前复盘原因：

类型	常见失败
金融科技 / 商务	幂等键冲突；重试风暴期间发生重复扣款
医疗健康	通过调试日志泄露 PHI；未与供应商签署 BAA
web3	预言机数据过时；债券曲线遭遇闪电贷攻击
mlops	训练与服务不一致；未检测到模型漂移
iot-embedded	OTA 导致某个没有恢复途径的地区设备变砖
data-platform	延迟到达的数据覆盖正确值
ai-system / agent-product	提示词注入窃取其他用户的数据
enterprise-saas	RLS 漏洞导致跨租户数据泄露
cli-tool	具有破坏性的标志没有确认机制（相当于 rm -rf）
library	次版本升级中出现不兼容变更

事前复盘中的反模式

❌ 风险描述含糊。“性能可能会有问题。”应具体说明：哪个操作、在什么负载下、SLO 是什么。

❌ 无边界的风险。“AWS 可能会宕机。”没错，但这无法采取行动。应聚焦于你能够缓解的风险。

❌ **防御性罗列。**罗列已经缓解的风险，只为显得周全。只列出当前计划尚未解决的风险。

❌ **省略标题。**没有标题，团队就不会相信这个失败场景确实可能发生。

何时跳过

• nano project_size — 事前复盘会增加额外负担。
• 具有完整测试覆盖的纯重构 — 已有防护措施。
• 只有一行复现步骤的 Bug 修复 — 风险边界明确。