技术 · 进阶
复盘写成整改清单？你缺的是三层法
事实带证据，根因到流程，动作能执行
复盘不是给领导交差的 KPI，是给自己攒的避坑地图。本页给一套不依赖任何工具的轻量流程：**第一层还原事实（每条挂证据）→ 第二层刨根因（问到流程 / 系统层）→ 第三层落动作（谁、什么时候、核对什么、留什么记录）**，并给出三个最常见误区：以为必须拉一群人开会、以为必须大动干戈、以为复盘是负责人的事。
方法 · 一图看懂
1
第一层 · 还原事实 — 按时间顺序逐节点摆「谁做了什么、结果是什么」，每条后面挂证据（git 记录 / 日志 / 聊天记录 / 变更单）；⛔ 不许写「我记得当时没改配置」
2
第二层 · 刨根因 — 对关键节点追问「为什么流程 / 系统没拦住这个错」；结论只要停在「开发粗心 / 测试疏忽」，就等于没说
3
第三层 · 落具体动作 — 写成「谁 / 什么时候 / 核对什么 / 留什么记录」的句子，换个人拿到也能不走样地执行
4
定规模：要不要开会、要不要大改 — 自己负责的小问题 20 分钟写笔记；跨部门大事故才拉齐相关方；先问「改一行代码 / 加一个报警能不能挡住」，能就不重构
原理 · 为什么有效
复盘的价值不在「我错了」，在「下次同一个坑挡得住」。停在「人不小心」，等于把结论落在不可改的东西上——注意力没法靠决心提升，流程里的缺口可以补。第一层强制挂证据，是为了切断记忆美化：人回忆事故时天然会给自己找合理解释，只有提交记录、日志和变更单不会替谁遮掩。第三层把结论压成一句可执行的句子，是为了让动作脱离复盘者本人也成立——否则换个负责人，坑照样踩。
适用场景
适合：线上事故、需求返工、同一类问题反复出现、多角色交接掉链子。
不适合：需要立刻止血的现场（先恢复，再复盘）；纯偶发的第三方故障（如云厂商宕机，加降级预案 + 报警就够，硬挖「惊天大根因」是浪费）；以及一眼能看出、一行代码就能修的小 bug —— 直接修，别开会。
自测 · 6 问
我的时间线里，每一句都挂得上证据吗？还是有一半靠回忆？
我的根因那句话里出现「粗心 / 疏忽 / 忘了 / 沟通不到位」了吗？出现就说明还没到底。
我的动作写到「谁、什么时候、核对什么、留什么记录」了吗？还是只有「加强管理」？
我是为了让老板满意，才把整改清单列得又长又狠吗？
这次真的需要拉一屋子人开会吗，还是我自己写个笔记就够？
这个小问题，改一行代码或加一个报警能不能直接挡住？
怎么上手 · 验证步骤
顺序：出事后 24 小时内先写第一层，趁证据还在（日志会滚、群消息会沉）；第二层单独找一段安静时间做，别在会上一边被追问一边想；第三层写成动作清单后，再决定要不要拉人。三个误区先绕开：
1. 以为复盘必须拉一群人开会 —— 自己负责的小问题 20 分钟写笔记就够，开会容易变成批斗会，没人说真话，跨部门大事故才需要对 齐
2. 以为复盘必须大动干戈 —— 很多小问题改一行代码、加一个报警就够，反例：缓存雪崩本可以「过期时间加随机偏移」解决，却全量换缓存架构，改出多个新问题、耽误三个月
3. 以为复盘是负责人的事 —— 经验是自己的，别人拿不走，三年下来对问题的敏感度差的就是这一截。
把第三层的动作清单念给一个没参与这次事故的同事，问他两件事：① 你现在能做这一步吗，知道找谁、核对什么、记录留在哪吗？② 照这条做，这次的错还发不发生？两个都答「是」才算过关，有一个答不上，动作还得往下拆。再回读一遍根因那句话——只要里面还有「粗心 / 疏忽 / 忘了 / 沟通不到位」，退回第二层重写。