很多人写复盘，写得像”事情经过流水账”：几点发生、发生了什么、我们怎么处理的、最后解决了。写得挺全，但看完没太大用——因为它只回答”发生了什么”，没回答”为什么没拦住，以及下次怎么不犯”。

真正有用的复盘，价值不在”把过程讲清楚”，而在”防止下次再犯“。我自己写复盘的标准，是让一篇复盘去回答三个问题。

三问：让复盘真正”防复发”

第一问：这次到底哪个环节错了？ 不是”谁推负责”，也不是”运气不好”，而是具体定位到根因。比如”接口字段对不上、最后靠随机数填”，根因不是”那天运气差、数据恰好缺”，而是”根本没提前定义字段映射，导致各方各做各的“。要往下挖，挖到”我改哪一处，这件事就不会发生”为止。

很多复盘败在”止步于表面现象”。表面是”联调时发现字段对不上”，根因是”没做映射表“。不挖到根因，下次你还会在同一个地方栽跟头。

第二问：为什么原来的防线没拦住？ 任何一次事故，往往都已经有”本该拦住它”的环节，但它失效了。你得问：是哪道防线本该拦住、它为什么没拦住？ 比如”我们本应该在联调前做一次字段核对，但没做”;或者”做了，但只核对了字段名、没核对格式和单位”。

这一问的价值是”找到那道破防的墙“，而不是只盯着”这次掉下去了”。修墙，比修”这次掉下去”更有用。

第三问：下次怎么避免再犯，且能验证？ 这是最关键的一问，但也是最容易写空的一问。”下次注意”“加强沟通”“提高意识”——这些都是空话，没法验证。要把改进落到可执行、可检查：

  • “下次在联调前，双方先产出并签字一份字段映射表（字段名、格式、单位、空值约定）。”
  • “加一个自动检查：联调脚本里先比对两边字段，对不上直接报警。”

只有能说清”我具体改哪一处、怎么验证改到位了“，这条改进才是真的。否则就是自我感动。

拿一个例子走一遍

举个例子：”联调时发现字段对不上，只能靠随机数填。”

  • 根因：前期没定字段映射，各方按自己的理解定义字段。
  • 防线缺口：本该在接入前做字段核对，但没做；联调脚本也没有字段校验。
  • 防复发：接入前先出字段映射表，并在联调脚本里加字段一致性校验，对不上即失败而非静默。

走完这三问，这个复盘就有了”下次不再犯”的抓手，而不只是一段”那天发生的事情”。

避开的三个坑

  1. 只讲过程，不讲根因 → 白写。
  2. 把”运气/偶然”当根因 → “这次只是碰巧”说明你没挖到底。
  3. 改进写成”提高重视/加强沟通” → 空话，没有可验证的动作。

一句标准

写复盘时问自己一句：“这篇看完，我知不知道下次具体要改哪一处、怎么验证改到位了？” 能答出来，这篇复盘就有价值；答不出来，它就只是一篇事故说明。

复盘不是用来”交代”的，是用来”不再犯”的。