项目复盘该怎么写

项目做完就翻篇，是最可惜的事。花半小时写一份复盘，下次遇到同类问题能省下几天。

下面是我自己用的模板，四个部分。

一、原本打算做什么

先用两三句话说清楚目标和验收标准。这一部分的价值在于：过几个月回来，你能立刻想起当时的背景，而不是对着一堆代码猜自己当初想干嘛。

要写清楚：

• 解决什么问题（谁，在什么场景下，遇到什么麻烦）
• 什么算成功（可衡量的标准，而不是「做得差不多」）
• 明确不做什么（划清范围，避免无限扩张）

二、实际怎么做的

只记关键决策，不记流水账。值得留下的是这类内容：

• 在岔路口选了哪条路，为什么
• 放弃了什么方案，因为什么放弃的
• 中途需求变了没有，怎么应对的

比如「本来打算用现成的博客系统，后来发现主题改不动，换成了自己写模板」—— 这类判断比「周三写了登录页」有价值得多。

三、踩过的坑

这是整份复盘里最值钱的部分。判断标准很简单：如果重来一次，我会不会做不一样的选择？

• 环境问题：装了什么、版本冲突、平台差异
• 设计问题：哪个抽象做早了，哪个该抽没抽
• 流程问题：哪一步返工了，本可以提前避免

写坑的时候要写清楚「现象 → 原因 → 解法」，否则下次翻到还是不知道当时怎么解决的。

四、下次怎么改

把上面的坑翻译成具体动作：

这次的教训	下次的动作
上线前才发现没跑通	每个功能做完立刻在目标环境验一遍
需求中途插进来打乱节奏	动手前先确认范围，变更单开一轮
配置散在好几处	能集中到一个配置文件就集中

一个提醒

复盘的读者主要是未来的自己，所以别写成给外人看的总结报告。承认哪里做得烂没关系 —— 那才是下次能改的地方。

至于「这次做得不错的地方」，也值得写两句，但要具体：不是「团队协作良好」，而是「提前把接口约定写下来，联调时没吵过一次架」。