总结一套简洁可执行的复盘写法。核心原则：重点不是”写很多”，而是”下次能复用”。

复盘四问

  1. 目标是否清晰？ — 项目开始时有没有可量化的目标？
  2. 过程是否可量化？ — 进度/质量/效率有没有数据支撑？
  3. 风险是否提前暴露？ — 有没有早点踩坑的机会？
  4. 下次最该先改什么？ — 只选一条，贪多嚼不烂

实例演示：后台管理重构项目

一问：目标是否清晰？

初始目标是”重构后台管理界面”——太模糊。实际拆成了两个量化目标：

  • 列表页加载时间从 3s 降到 1s 以内
  • 表单提交成功率从 87% 提到 95%+

如果一开始就定这两个，技术选型会完全不同。教训：目标必须带数字。

二问：过程是否可量化？

数据记录：

  • 开发周期 18 天，预估 14 天，偏差 +28%
  • 前端 3 人，后端 1 人，人力比不合理（后端瓶颈）
  • Bug 总数 34，其中 12 个是联调阶段才暴露的接口对齐问题

偏差主要来自”前后端并行开发但接口文档没提前对齐”。如果先定接口再并行，至少省 4 天。

三问：风险是否提前暴露？

最大的坑：上线前一周才发现旧数据迁移方案有遗漏字段。如果第一周就用生产数据镜像做一次全量迁移演练，这个问题能在第二周暴露。

四问：下次最该先改什么？

先写接口文档，前后端签字确认后再写代码。 只改这一条，就能解决本次最痛的接口对齐问题。其他优化（自动化测试、CI 流水线）留给下次。

复盘模板

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
## 项目名称：XXX
## 时间：YYYY-MM-DD ~ YYYY-MM-DD

### 一问：目标
- 量化目标 1：
- 量化目标 2：

### 二问：过程
- 实际周期 vs 预估：
- 人力投入：
- 关键数据（Bug数/上线次数/回滚次数）：

### 三问：风险
- 最早可在什么时候暴露：
- 当时为什么没发现：

### 四问：改什么
- 下次只改一条：（具体动作）

保存到项目根目录 RETRO.md，每次做完项目花 20 分钟填完。