踩过坑才懂：好用的技术复盘方法，根本不是写周报

上个月跟南京软件园出来的几个老研发蹲在路边吃牛油火锅，锅里的牛蛙滚得冒泡的时候，有人吐槽刚给甲方交完线上事故的复盘报告，三页纸写得工工整整，转头另一个项目又踩了几乎一模一样的坑。

一桌人瞬间哄笑，原来人人都遇过这种事。复盘报告写了一堆，经验教训总结了好几条，下次该错还是错。

问题出在哪？根本不是大家不上心，是用的方法错了。

别拿总结当复盘，这完全是两码事

很多人对技术复盘的认知，还停留在“把做过的事再写一遍”“出了问题写个检讨”。说白了就是流水账凑字数，给领导交差用的。

我三年前在一个电商项目组待过，当时上线新的商品详情页图片压缩功能，峰值带宽直接超了生产阈值三倍，整个站卡了快十分钟，损失多少先不说，复盘会开了两个小时，最后写出来的结论是“开发人员安全意识不足，下次上线前要做好充分测试”。

你说这个结论有啥用？谁不知道上线前要测试？问题是为什么没测出来？

果不其然，三个月后换了新的CDN厂商，同样的问题又来一遍，还是带宽超预期，还是临时砍流量救火。

本质上就是把总结当成了复盘。总结是我做了什么，做成了什么样，复盘是我当时为什么做了这个决策？有哪些默认的想法错了？下次我具体要改什么？

差了整整一个维度。

我一直用的切口式技术复盘，三步就能落地

我不搞那些复杂的框架，平时做项目复盘，就从一个小切口往下挖，三步走完基本能挖到根，也不会浪费太多时间。

第一步先拉不带判断的时间线。就是把从需求提出到问题发生的每一个节点，只写事实，不写评判。比如刚才那个图片压缩的事，时间线就是：产品提“要提升图片加载速度”→开发选型选了新的WebP压缩→测试测了清晰度、加载速度单测没问题→运维按照原图片大小配置了CDN带宽阈值→上线大促流量翻三倍→带宽跑满。

就这么简单，别上来就写“开发粗心没测”，先把发生了什么理清楚。很多时候理完时间线，问题在哪就已经出来了——整个链路里，没有一个节点干了“预估新压缩方案的总带宽”这件事。

第二步挖所有人都没说出口的默认假设。这是复盘最核心的一步，绝大多数问题的根都在这。那个案例里，整个团队从上到下都默认了一个前提：“图片压缩了，单张体积变小，总带宽肯定比原来低”。没人把这个假设说出来，没人质疑它对不对。

实际上呢？新压缩格式虽然单张体积小，但是触发了浏览器的分片请求，同一张图拆成了好几个请求，总请求量涨了一倍多，额外的握手头加上分片冗余，总带宽反而涨了快40%。这个藏在水面下的假设，就是问题的根。

第三步写可验证的改进行动。绝对不能写“提高安全意识”“加强测试流程”这种正确的废话。要写具体到谁做，什么时候做，做完能验证的动作。刚才那个问题，最后改的两个动作是：所有变更了静态资源格式/大小的上线，必须出总流量预估表，运维签字确认才能发；压测报告必须包含峰值总带宽换算，不能只测单接口性能。后来再也没出过同样的问题。

踩过三次坑才摸清楚的复盘边界

说实话，方法再好，踩错边界也没用。我之前刚学复盘的时候，也踩过好几个坑，现在都记在我的小本子上。

第一个，别一上来就找责任人。很多团队复盘开成批斗会，出了问题先把经办人拉出来骂一顿，下次再出问题，所有人都想着怎么把责任推出去，小问题藏着掖着，最后憋成大事故。技术问题绝大多数都是系统性的盲区，不是某个人故意搞破坏，盯着人不放，永远解决不了问题。

第二个，不是只有出了事故才要复盘。你做一个项目顺顺利利上线，bug比预期少一半，上线后性能比预估好很多，这种也要复盘。我前年做一个内部低代码工具，上线三个月核心链路没出过大bug，复盘的时候挖到，原来是我们每次改完核心代码，都会拉测试做五分钟的小回归，不攒到最后一起测。这个方法直接用到了后来所有的新项目，省了不知道多少测回归的时间。好的经验比错的教训更值得挖。

第三个，别什么都拿出来深度复盘。你改个按钮的位置，上线后发现不对，改回来就行了，犯不着拉全组开两个小时会。只有核心链路出问题、影响到用户、重复踩同类型坑的时候，才值得花时间深度复盘。我现在定的规矩是，深度复盘的会不能超过一个小时，超过了就是方法不对，绕远路了。

不过话说回来，很多公司的复盘本来就是走个过场，给老板交差，你没法改变公司的制度，那至少给自己做复盘嘛。每次写完给老板的报告，自己花十分钟在笔记本上记两笔：这次藏着的错假设是什么，下次我要改哪个小动作。攒多了，就是你自己独有的踩坑指南，别人拿不走。

技术这条路，本来就是踩着坑往上走的。怕的不是踩坑，是同一个坑踩好几遍，踩完了还不知道自己为啥踩进去。好的技术复盘方法，从来都不是给别人看的漂亮文档，是给自己攒家底的错题本。