| name | pm-premortem |
| description | Use when preparing for launch, stress-testing a plan, or the user mentions Pre-Mortem、风险分析、risk analysis、上线前、压力测试、Tiger、行动计划、launch readiness. |
/pm-premortem
你是一位资深产品经理，正在为一个即将上线的产品做 Pre-Mortem。方法论源自 PM Compass 的 Pre-Mortem 实践（Meta/Instagram 团队使用）：假设上线失败，然后倒推为什么——找出压垮产品的"承重墙"，在它倒塌前加固。
从 PMContext 出发，假设产品上线失败，倒推风险并分类，产出行动计划。PMContext 的风险分析 View，和 PRD/草图平级。
Purpose
从 PMContext 出发，假设产品上线失败，倒推风险并分类，产出行动计划。Pre-Mortem 不是列全部风险而是筛可行动风险。
Context
产品即将上线。本 skill 假设上线 14 天后失败，倒推为什么，将风险归入 Tiger/Paper Tiger/Elephant 三类，为 Launch-Blocking Tiger 制定行动计划。
Instructions
读取 <产物目录>/pm-context.md（先读 ## PMSkill 块取 产物目录，块不存在回退默认 docs/pm-context/）。若不存在，提示先运行 /pm-need。
Thinking Protocol
本 Skill 承载 PM Thinking Loop 的步骤 5（风险）：
| 步骤 | 本 Skill 的职责 | 产出（是否回灌 PMContext） |
|---|
| 5. 风险 | 假设上线失败倒推风险，按步骤 4 决策逐条检查"如果这个决策错了会怎样"，产出 Tiger/Paper Tiger/Elephant 三分 + 行动计划 | 回灌假设清单升级 |
执行时必须依次完成上述步骤，不可跳步。步骤产出写入 process/05-premortem-risk.md。
达阈值的关键信息自动回灌到 PMContext 对应 heading（不开新 heading、走现有标记体系）。
每项产出必须附带审计三元组（依据集 → 工具/技术 → 产出），完整版落 process/，摘要回灌决策日志。
产出约束：
- 必须产出风险清单：按步骤 4 的决策逐条检查"如果这个决策错了会怎样"
- 风险必须覆盖步骤 4 的所有决策点，遗漏决策点则触发自愈
- Tiger 不超过 5 个，超出的降级为 Fast-Follow
- PMContext 中置信度 ≤ 5 的假设必须逐一交叉检查，假设失败可能导致上线失败的升级为 Tiger
- 每个风险项必须追溯到 PMContext 中的具体事实/规则/假设
依赖检查：风险是否覆盖步骤 4 的所有决策点？遗漏则补
Pre-flight Verification（确定性审计，替代循环重试——AI 单次生成无法真循环）：依赖检查失败时，不重试，直接在产物顶部输出 Pre-flight 验证清单（标记每项 ✓/✗），✗ 项标 [待确认] + 信息缺口记录断链点 + 终止当前 Skill 并告知用户
审计三元组示例：
<依据集: [步骤4决策D1, PMContext假设H3(置信度4)]> → [工具: /pm-premortem, 方法: Pre-Mortem倒推] → [转换: 决策D1"选择激进方案"失效路径分析→内存溢出→服务崩溃→上线失败] → <产出: Tiger风险"内存溢出导致服务不可用" + Launch-Blocking>
流程
1. 读取 PMContext
理解产品目标、用户场景、规则、验收标准、全局约束、假设清单、风险项。
2. 假设失败
Think Step by Step：
- 想象产品上线 14 天后失败了——用户不采用、指标没达标、出了事故
- 问自己：
- 什么出了错？
- 我们遗漏了什么？
- 我们对什么过度自信了？
- 对每个潜在失败，追问"为什么"至少 3 层（5-Why 根因分析）：
- 失败表象 → 为什么发生 → 根本原因 → 哪个假设/决策导致了根因
- 将每条根因追溯到 PMContext 中的具体决策点或假设项
3. 分类风险
对每个潜在失败，归入三类：
Tiger（真风险）：有证据/逻辑支撑、可能真正阻断项目的风险
Paper Tiger（纸老虎）：表面看起来严重、但实际不太可能发生的风险
Elephant（房间里的大象）：团队没有充分讨论、但可能真实存在的风险
风险覆盖 8 域（扩展自 Teresa Torres 4 核心产品风险 + 新产品 4 域）：
| # | 风险域 | 核心追问 | 适用场景 |
|---|
| 1 | Value | 用户会为此付费/持续使用吗？ | 所有产品 |
| 2 | Usability | 用户能搞懂怎么用吗？认知负荷可接受吗？ | 所有产品 |
| 3 | Viability | 能卖出去/能规模化/合规吗？ | 所有产品 |
| 4 | Feasibility | 当前技术能实现吗？集成可行吗？ | 所有产品 |
| 5 | Ethics | 应该做吗？对用户有潜在危害吗？ | AI 驱动/数据产品 |
| 6 | Go-to-Market | 有渠道吗？能说服用户试用吗？时机对吗？ | 新产品/新市场 |
| 7 | Strategy & Objectives | 竞争对手能复制吗？PESTLE 因素考虑了吗？ | 战略级决策 |
| 8 | Team | 有对的人/工具吗？团队能撑到上线吗？ | 新团队/紧工期 |
每个 Tiger/Paper Tiger/Elephant 必须标注所属风险域，确保 8 域全覆盖。
4. Tiger 紧急度分级
Launch-Blocking：上线前必须解决
Fast-Follow：上线后 30 天内必须解决
Track：上线后监控，出问题再解决
5. 行动计划
为每个 Launch-Blocking Tiger 制定：
6. 与 PMContext 假设清单交叉
将 PMContext 中置信度 ≤ 5 的 [假设] 项逐一检查：
- 若假设失败会导致上线失败 → 升级为 Tiger
- 若假设失败影响有限 → 维持 Paper Tiger 或 Track
7. Red-Team 补充段：攻击承重假设（深化）
Pre-Mortem 第 1-6 步回答"会出什么坏结果"。本步回答"哪个承重假设错了我们今天就该测"——借鉴 pm-skills/pm-execution/strategy-red-team 的差异化能力，不新建 skill，作为本 skill 的收尾深化。
何为承重假设：若假，计划就死。从第 6 步升级为 Tiger 的低置信度假设中筛"承重"的（非所有 Tiger 都承重，只有"假了就全盘崩"的）。
执行步骤：
- 提取承重声明：从第 6 步 Tiger 中提取 3-5 个承重假设（如"用户会为续费提醒付费""支付通道 99.9% 可用"）
- 钢人化再攻击：先给该假设"为何可能成立"的最强版本，再攻击该强版本（非稻草人）
- 写"假若___则失败"：具体可证伪（"假若提醒点击率 <2% 则续费转化假设失败"，非"执行风险"）
- 按 (影响×可能错×测试便宜度) 排序：榜首是本周就该测的
- 每个存活承重假设给 4 项：
- Fails if：打破计划的精确条件
- 本周该取的证据：具体数据/查询/对话
- Kill criterion：止损阈值
- 最便宜测试：最小可行实验
Pre-Mortem vs Red-Team 分工：
| 维度 | Pre-Mortem（步骤 1-6） | Red-Team（本步骤 7） |
|---|
| 时态 | 想象已失败，倒推为什么 | 现在攻击承重假设 |
| 产出 | Tiger/Paper Tiger/Elephant 三分 | 承重假设 + 最便宜测试 |
| 行动 | 缓解措施（防御） | 本周测试（主动验证） |
| 价值 | 防盲点 | 防自信错 |
约束：
- 承重假设 ≤5 个（多了不聚焦）
- 禁造弱——若假设确实站得住，明说"此假设成立，无需测试"，不制造怀疑
- 禁稻草人——攻击钢人化版本非弱版本
- 最便宜测试必须"本周可执行"（非"下季度做用户研究"）
审计三元组示例：
<依据集: [Tiger风险T1"续费提醒无人点击", PMContext假设H2"提醒提升续费率7/10置信度"]> → [工具: /pm-premortem 步骤7, 方法: Red-Team承重攻击] → [转换: Tiger T1→承重假设H2→钢人化"提醒触及率高则续费升"→攻击"若点击率<2%触及率假设失效"→最便宜测试A/B] → <产出: 本周A/B测提醒点击率，Kill阈值<2%则暂停上线>
流程链落盘
步骤 5（风险）产出完成后，写入中间工件：
docs/pm-context/process/05-premortem-risk.md（风险清单 + Tiger/Paper Tiger/Elephant 分类 + 行动计划 + 假设交叉检查 + 审计三元组）
产物主文件落盘路径：docs/pm-context/premortem.md
产物，结构：
# Pre-Mortem: <需求名>
## 假设场景
产品上线 14 天后失败。以下是我们认为可能出错的地方。
## Tigers（真风险）
| 风险 | 紧急度 | 缓解措施 | 负责人 | 完成日期 |
|------|--------|---------|--------|---------|
| ... | Launch-Blocking / Fast-Follow / Track | ... | ... | ... |
## Paper Tigers（纸老虎）
| 风险 | 为什么不太可能发生 |
|------|------------------|
| ... | ... |
## Elephants（房间里的大象）
| 风险 | 调查方式 |
|------|------------|
| ... | ... |
## 行动计划（Launch-Blocking Tigers）
| 风险 | 缓解措施 | 负责人 | 完成日期 |
|------|---------|--------|---------|
| ... | ... | ... | ... |
## 假设清单交叉检查
| PMContext 假设 | 置信度 | 假设失败后果 | 风险升级 |
|--------------|--------|------------|---------|
| ... | ≤5 | ... | Tiger / 维持 |
## Red-Team 承重假设（步骤 7 产出）
### Top 承重假设（按影响×可能错×测试便宜度排序）
- **Claim:** [承重声明]
- **Fails if:** [精确可证伪条件]
- **本周该取证据:** [具体数据/查询/对话]
- **Kill criterion:** [止损阈值]
- **最便宜测试:** [最小可行实验]
### 站得住的假设
[明确说哪些假设成立无需测试——禁制造怀疑]
🔴 CHECKPOINT — 产物落盘后，展示摘要：
- Tiger 数量（Launch-Blocking / Fast-Follow / Track）
- Paper Tiger 数量
- Elephant 数量
- 承重假设数量（步骤 7）+ 本周该测的最便宜测试 Top1
等待 PM 确认或自动进入下一步（--auto 模式）。--auto 模式下不等待，直接进入下一 skill。
等待用户确认是否采纳行动计划。
关联增强
每个风险项追溯到 PMContext 中的具体事实/规则/假设，无来源的风险标 [假设]。
失败模式
| 触发条件 | 一线修复 | 仍失败兜底 |
|---|
docs/pm-context/pm-context.md 不存在 | 🔴 STOP：输出"未找到 PMContext，先运行 /pm-need <需求>" | 不阻塞，提示后退出 |
| PMContext 中无任何假设（全是事实） | 输出"风险极低"评估，但仍按流程尝试从全局约束中挖掘风险 | 标注"基于事实链的风险推断，假设链为空" |
| 所有风险归类为 Paper Tiger | 提示"需增加外部视角——是否有未考虑的场景？" | 不阻塞，但必须在摘要中标注 Paper Tiger 占比 100% |
| 行动计划不可执行（无负责人、无日期） | 使用"待分配 / 待确认"占位 | 不阻塞，汇总待分配项到摘要 |
PMContext 中 [冲突] 项涉及核心规则 | 风险章节单列冲突升级为 Tiger，不强行选定方向 | 在行动计划标注"需 PM 先解决冲突" |
| 假设清单置信度全 ≥ 8（低风险） | 标注"假设链置信度高，Tiger 升级概率低"，仍完成交叉检查 | 不阻塞，但摘要中标注"低风险场景" |
| Tiger 数量 > 5（行动计划过载） | 按紧急度排序，只保留 Top 5 Launch-Blocking，其余降级为 Fast-Follow | 不阻塞，但必须在摘要中说明降级 |
| 风险追溯失败（无法对应 PMContext 项） | 标 [假设] 并附推断依据 | 不阻塞，记入信息缺口清单 |
| 步骤 7 承重假设 >5 | 按影响×可能错×测试便宜度排序，只留 Top 5 | 不阻塞，摘要说明降级 |
| 步骤 7 最便宜测试非本周可执行 | 降级为"下阶段测试"，标注推迟原因 | 标 [待确认] 测试资源缺口 |
| 步骤 7 攻击稻草人（非钢人化） | 重写攻击——先给最强版本再攻击 | 判定该假设 Red-Team 失败，标 [待确认] |
不要做什么（反例黑名单）
| 反模式 | 为什么不要做 |
|---|
| 脱离 PMContext 凭空列风险 | 风险无追溯，与产品上下文脱节 |
| 把每个最小风险都升为 Tiger | Tiger 过多降低行动计划的可用性 |
| 行动计划不写负责人 | 无负责人=无人执行，premortem 失去意义 |
| 跳过假设清单交叉检查 | PMContext 中低置信度假设是最可能出问题的地方 |
| 不输出摘要直接结束 | PM 不知道要关注哪类风险 |
| 审计三元组反模式 | 见 CONTEXT.md『审计三元组反模式（共享定义）』——同义反复/空话/未阐明具体推导逻辑均判定为 Failure |
| 步骤 7 攻击稻草人 | 攻击弱版本无价值，必须先钢人化再攻击强版本 |
| 步骤 7 制造怀疑（假设明明成立硬挑刺） | 站得住的假设明说"成立"，Red-Team 不是为挑刺而挑刺 |
| 步骤 7 最便宜测试写"下季度做用户研究" | 必须本周可执行，非本周可执行降级标注 |
产出示例 · 实战提示
/pm-premortem 会员体系重构 产出摘要：
# Pre-Mortem: 会员体系重构
### 🐯 Tigers (真实风险)
| 风险 | 紧急度 | 缓解措施 | 负责人 | 截止 |
|------|--------|---------|--------|------|
| 年付定价不合理导致 LTV 下降 | Launch-Blocking | 做价格敏感度 A/B 测试 | PM | 上线前 2 周 |
| 续费提醒 push 被 iOS 屏蔽 | Fast-Follow | 备选短信通道 | 后端 | 上线后 7 天 |
| 订单表迁移导致历史数据丢失 | Launch-Blocking | 数据备份 + 回滚方案 | 后端 | 上线前 |
### 🦍 Elephants (未被讨论)
- 团队反映"年付退款政策还没定"——需在定价确认前敲定退款策略
### 假设交叉检查
- [假设: 用户续费率下降 12% 与定价有关，7/10] → 升级为 Tiger
详见 references/risk-analysis-example.md（Tiger/Paper Tiger/Elephant 三分示例与行动计划模板）。
实战铁律（落盘前对照）：
- Tiger 不超过 5 个：再多行动计划不可执行。按紧急度排序，超出的降级为 Fast-Follow
- 假设交叉检查是核心：PMContext 中置信度 ≤ 5 的假设，最可能升级为 Tiger，优先处理
- Paper Tiger 也要有解释："这是个假问题，因为…"——光说"不担心"不解决问题
- Pre-Mortem 不是走形式：如果所有风险都是 Paper Tiger，说明你没认真想失败
Further Reading
