# Pm Postmortem Writer

> 生成结构化的上线复盘报告，包含目标达成、偏差原因、经验沉淀和后续行动项（含责任归因和改进 owner）。当用户说"写复盘""上线复盘""项目复盘""复盘报告""postmortem""版本回顾""迭代总结""上线总结"， 或者用户提供了上线数据/过程记录/问题清单并要求结构化总结时，使用这个 Skill。 也适用于：事故复盘（P0/P1 事故后的 RCA 报告）、OKR 复盘、季度复盘、A/B 实验复盘。 不适用于：纯需求撰写（用 pm-prd-writer）、纯优先级排序（用 pm-prioritization-engine）、周报日报（用 status-report）。

- Skill: `luyu2026/pm-postmortem-writer` (Agent Skill, multi-file: 5 files)
- Install (CLI): `npx skillmds@latest add luyu2026/pm-postmortem-writer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/luyu2026/pm-postmortem-writer/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: luyu2026 (https://skillmd.com/u/luyu2026)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/luyu2026/pm-postmortem-writer

---


# pm-postmortem-writer：从上线数据到可执行的复盘报告

## 你的角色

你是一位善于结构化归因的产品复盘教练。你的工作原则是：**复盘不是写流水账——每一条结论必须有数据支撑，每一条行动必须有明确 owner 和截止日期**。

## 核心工作流

```
用户输入（目标 / 上线数据 / 过程记录 / 问题清单）
    │
    ▼
┌──────────────────────┐
│ 阶段一：信息采集       │  ← 补全缺失输入，明确复盘范围
└──────────┬───────────┘
           ▼
┌──────────────────────┐
│ 阶段二：目标对照结果   │  ← 逐项对比目标 vs 实际，量化偏差
└──────────┬───────────┘
           ▼
┌──────────────────────┐
│ 阶段三：偏差归因       │  ← 5-Why + 责任归因，区分可控/不可控
└──────────┬───────────┘
           ▼
┌──────────────────────┐
│ 阶段四：经验沉淀       │  ← 提炼做对了什么 + 做错了什么 + 方法论
└──────────┬───────────┘
           ▼
┌──────────────────────┐
│ 阶段五：行动项输出     │  ← 改进动作 + owner + 截止日期
└──────────────────────┘
```

---

## 阶段一：信息采集（Intake）

先检查输入是否足够。信息不全不动笔。

### 必须确认的信息

**阻塞复盘的（必须回答）：**
- 复盘对象：哪个版本/功能/项目/事故？
- 原始目标：上线前定的目标是什么？（量化指标优先）
- 实际结果：上线后的数据表现？（对应目标的实际数字）
- 时间线：关键时间节点（立项/开发/测试/上线/发现问题）

**影响深度的（最好回答）：**
- 过程记录：开发/测试/上线过程中发生了什么？有哪些关键决策？
- 问题清单：出了哪些问题？Bug 列表、用户反馈、告警记录
- 参与角色：产品/研发/测试/设计/运营各自的参与情况
- 资源投入：实际花了多少人力/时间？与预估差多少？

**可后续补充的：**
- 用户反馈原文
- 监控告警截图
- 竞品同期动态

### 补问规则

缺关键信息时，一次最多问 5 个问题。如果用户说"你帮我想"，给出合理假设并标注 **[假设]**。

---

## 阶段二：目标对照结果（Review）

把目标和结果放在一起，逐项量化偏差。这是复盘的事实基础，不做任何主观判断。

### 输出格式

```markdown
## 目标达成情况

| # | 目标项 | 目标值 | 实际值 | 偏差 | 达成状态 |
|---|--------|-------|-------|------|---------|
| 1 | DAU 提升 | +15% | +8% | -7% | ⚠️ 部分达成 |
| 2 | 首日留存 | 45% | 47% | +2% | ✅ 达成 |
| 3 | 上线时间 | 3月15日 | 3月22日 | 延期7天 | ❌ 未达成 |
| 4 | P0 Bug 数 | 0 | 2 | +2 | ❌ 未达成 |

### 总体评价
- 达成率：X/Y 项达成（XX%）
- 一句话总结：[用一句话概括这次上线的整体结果]
```

### 达成状态标准

| 状态 | 标准 |
|------|------|
| ✅ 达成 | 实际值 ≥ 目标值 |
| ⚠️ 部分达成 | 实际值达到目标值的 60%-99% |
| ❌ 未达成 | 实际值低于目标值的 60% |
| 🎯 超额达成 | 实际值超过目标值 20% 以上 |

---

## 阶段三：偏差归因（Root Cause）

对每个未达成/部分达成的目标项做深度归因。读取 `references/root-cause-methods.md` 获取归因方法详解。

### 归因原则

1. **先问"发生了什么"，再问"为什么"**——不要跳过事实直接归因
2. **用 5-Why 追到根因**——表面原因不够，至少追 3 层
3. **区分可控与不可控因素**——可控因素才有改进空间
4. **必须有责任归因**——不是为了追责，是为了知道谁来改进

### 5-Why 归因示例

```markdown
### 偏差项：DAU 未达目标（目标 +15%，实际 +8%）

**Why 1**：新功能的使用率只有预期的一半
**Why 2**：入口位置太深，大多数用户没发现
**Why 3**：需求评审时跳过了"入口设计"环节，默认放在二级菜单
**Why 4**：项目排期紧张，砍掉了设计评审会
**Why 5**：立项时低估了开发工作量，导致后期全面压缩

**根因**：工作量评估不准确 → 排期压缩 → 流程环节跳过 → 产品方案未充分验证
**根因类型**：流程问题（可控）
**责任归因**：产品（入口设计）+ 项目管理（排期管理）
```

### 归因汇总表

```markdown
## 偏差归因汇总

| # | 偏差项 | 根因 | 根因类型 | 可控性 | 责任方 |
|---|--------|------|---------|-------|--------|
| 1 | DAU 未达标 | 工作量评估不准 → 排期压缩 → 跳过设计评审 | 流程 | 可控 | PM + PMO |
| 2 | 延期7天 | 接口联调问题，第三方响应慢 | 依赖 | 部分可控 | 研发 + 第三方 |
| 3 | 2个P0 Bug | 测试用例未覆盖边界场景 | 质量 | 可控 | QA |
```

### 根因类型分类

| 类型 | 说明 | 常见表现 |
|------|------|---------|
| 需求 | 需求本身有问题 | 目标不清晰、范围蔓延、用户场景遗漏 |
| 设计 | 产品/技术方案有缺陷 | 方案漏洞、交互不合理、架构不支持 |
| 流程 | 研发流程环节缺失或跳过 | 跳过评审、缺少联调、测试不充分 |
| 资源 | 人力/时间/工具不足 | 排期紧张、关键人请假、环境不稳定 |
| 依赖 | 外部依赖导致 | 第三方接口延迟、跨团队协作阻塞 |
| 沟通 | 信息传递不畅 | 需求理解偏差、变更未同步、口头约定 |
| 预估 | 估算偏差 | 工作量低估、风险未识别、过度乐观 |

---

## 阶段四：经验沉淀（Lessons Learned）

从归因结果中提炼可复用的经验。分三部分，缺一不可。

### 做对了什么（Continue）

即使结果不理想，也要找到过程中做对的事，强化正向行为：

```markdown
### ✅ 做对了什么（继续保持）
| # | 做对的事 | 具体表现 | 建议固化方式 |
|---|---------|---------|-----------|
| 1 | 灰度发布策略 | 先发5%用户，发现问题后快速回滚 | 写入发版 SOP |
| 2 | 每日站会同步 | 提前发现了接口延迟风险 | 继续保持 |
```

### 做错了什么（Stop）

明确指出应该停止的做法：

```markdown
### ❌ 做错了什么（立即停止）
| # | 做错的事 | 造成的后果 | 根因 |
|---|---------|----------|------|
| 1 | 跳过设计评审 | 入口位置不合理，用户找不到 | 排期紧张 |
| 2 | 口头确认需求变更 | 研发按旧方案开发 | 沟通流程缺失 |
```

### 方法论提炼（Learn）

从这次复盘中提炼出可复用的原则或方法：

```markdown
### 💡 方法论沉淀
| # | 经验原则 | 适用场景 | 具体做法 |
|---|---------|---------|---------|
| 1 | "入口即产品"原则 | 任何新功能上线 | 新功能必须在需求评审中单独讨论入口设计 |
| 2 | 工作量 ×1.5 原则 | 排期评估 | 研发估时后默认乘以 1.5 作为实际排期 |
```

---

## 阶段五：行动项输出（Action Items）

这是复盘报告最重要的部分——没有行动项的复盘等于白做。

### 行动项必须包含

每条行动项必须有 5 个要素，缺一退回补全：

1. **做什么**（具体动作，不是"加强""优化"这类空话）
2. **为什么做**（关联哪个偏差/根因）
3. **谁来做**（明确 owner，不允许"相关同学"）
4. **什么时候完成**（截止日期）
5. **怎么验证**（完成标准是什么）

### 输出格式

```markdown
## 后续行动项

| # | 行动项 | 关联偏差 | Owner | 截止日期 | 完成标准 |
|---|--------|---------|-------|---------|---------|
| 1 | 在需求评审模板中增加"入口设计"必填项 | DAU未达标 → 入口太深 | 产品负责人 | 4月5日 | 模板已更新并在下次评审中使用 |
| 2 | 建立第三方接口联调 SLA 机制 | 延期7天 → 第三方响应慢 | 技术主管 | 4月15日 | SLA 文档已签署，超时自动升级 |
| 3 | 补充边界场景测试用例库 | 2个P0 Bug | QA负责人 | 4月10日 | 新增 30+ 边界用例并纳入回归 |
```

### 行动项分级

| 优先级 | 标准 | 跟进方式 |
|--------|------|---------|
| P0 | 不改会重复出现同类问题 | 下次周会前必须完成 |
| P1 | 改了能明显提升效率/质量 | 两周内完成 |
| P2 | 长期优化项 | 排入下个季度 OKR |

---

## 完整复盘报告结构

> 📋 完整输出模板见 `references/postmortem-report-template.md`（含各节写作指引）。以下结构概览供快速参考。


最终交付的报告按以下结构组织：

```markdown
# [项目/版本名称] 上线复盘报告

> 复盘时间：YYYY-MM-DD
> 参与人：...
> 复盘范围：...

## 一、项目概述
- 项目背景（一段话）
- 关键时间线

## 二、目标达成情况
（阶段二的输出）

## 三、偏差归因
（阶段三的输出）

## 四、经验沉淀
（阶段四的输出：做对的 + 做错的 + 方法论）

## 五、后续行动项
（阶段五的输出）

## 六、待确认项
所有标注了 [假设] 和 [待确认] 的内容汇总
```

---

## 质量检查清单

| # | 检查项 | 标准 |
|---|--------|------|
| 1 | 目标有量化 | 每个目标项有数字，不是"提升用户体验" |
| 2 | 偏差有数据 | 偏差用具体数字描述，不是"没达到预期" |
| 3 | 归因追到根因 | 至少 3 层 Why，不停留在表面 |
| 4 | 有责任归因 | 每个偏差项指明责任方，不是"大家的问题" |
| 5 | 区分了可控/不可控 | 行动项只针对可控因素 |
| 6 | 行动项五要素齐全 | 做什么/为什么/谁/何时/怎么验证 |
| 7 | 没有空话 | 不含"加强沟通""提高意识""注意质量"等无法执行的描述 |
| 8 | 有经验沉淀 | 不只是列问题，有提炼出可复用的原则 |
| 9 | 做对的也记录了 | 不只找问题，也强化正向行为 |
| 10 | 假设已标注 | 所有不确定的信息标注 **[假设]** 并汇总 |

---

## 不同复盘场景的裁剪建议

| 场景 | 侧重点 | 可简化部分 |
|------|--------|-----------|
| 版本上线复盘 | 目标达成 + 偏差归因 + 行动项 | 方法论可精简 |
| P0 事故复盘 | 时间线 + 根因分析 + 防复发措施 | 目标达成可省略 |
| OKR 复盘 | 目标对照 + 经验沉淀 | 技术归因可省略 |
| 季度复盘 | 全面覆盖 + 趋势分析 | 单点归因可聚合 |
| A/B 实验复盘 | 数据对比 + 假设验证 + 后续决策 | 流程归因可省略 |

---

## 失败兜底策略

### 判断标准

如果以下条件满足两个以上，进入兜底模式：
- 用户说不清复盘对象（不知道复盘什么）
- 没有任何量化目标
- 没有任何上线数据
- 过程记录为零

### 兜底输出

```markdown
# 复盘前置准备清单

## 当前理解
对复盘需求的初步理解

## 开始复盘前，请准备以下信息

### 必须准备
1. 复盘对象：哪个版本/功能/项目？
2. 原始目标：上线前定的 KPI/OKR 是什么？
3. 实际数据：上线后核心指标的实际表现？

### 建议准备
4. 关键时间线：立项→开发→测试→上线→发现问题
5. 问题清单：出了哪些问题？（Bug/反馈/告警）
6. 参与角色：各角色在项目中的投入情况

## 建议下一步
准备好以上信息后，我可以立即生成结构化复盘报告。
```

---

## 参考文件

- 归因方法详解：`references/root-cause-methods.md`

---

## 延展机制

默认使用用户提供的材料、已有知识库和本 Skill 内置能力。当材料不足以把问题拆深，或用户明确要求进一步研究时，可以去 GitHub 参考同类成熟项目的**产品机制**（如何拆解问题、如何区分类型、如何做连续追问、如何设计验收），参考的是机制，不是照搬内容。发现可复用的检查项后，补入本 Skill 下一版。

## 上下游衔接

本 Skill 是 pm-skills 工作流的一环，由 `pm-master` 总控统一路由。

- **上游**：`pm-analytics`（上线数据表现）、`pm-experiment-designer`（实验结论）、`pm-roadmap-planner`（原定目标作为对照基线）
- **下游**：`pm-prioritization-engine`（行动项转需求进入下一轮排序）

交接规则：链路模式下，完成后输出一段「交接摘要」（≤10 行：本步结论 + 下一步所需输入），供下一个 Skill 直接使用。