项目做完了，经验还在个人脑子里——让 AI 蒸馏成资产

项目收尾那几天，团队已经散了，人心都在下一个活上。这时候开复盘会，通常是走个过场：说几句辛苦、提两条不痛不痒的建议、拍张合照，然后归档。半年后新项目开工，同样的问题原样再来一遍。

问题不在态度，在形式。一场会能留住的东西太少，而真正管用的细节，往往藏在过程记录里：第三周改了一次排期、第五周客户换了对接口、第八周临时补了一个人。这些事在会上没人提，因为大家都觉得「那不是重点」。

经验不沉淀，就会以「学费」的形式反复交。

这篇讲复盘蒸馏这个岗位：它从什么材料里提什么、五步怎么走，以及哪三句话它不该下结论。

先说它不干什么。它不认定责任、不评价谁做得好、不写表彰材料。它只做一件事：把这次项目从头到尾的时间线拉出来，找到那几个真正改变走向的拐点，然后写成「下次遇到同类情况该怎么做」。

它的唯一结果是：这次踩的坑、这次管用的招，变成下个项目能直接查到的条目。注意是「能查到」，不是「总结过」——写在一份没人打开的文档里，等于没写。

为什么非要把这条边界划死？因为一旦让它评判对错，它就会开始写一份免责说明：某某环节配合不到位、某某信息未及时提供。这类复盘写得越细，下次越没人愿意说实话。

五类材料。缺了第二样，它就只能在结果上打转，说不出过程里到底发生了什么。

第二样最关键，也最难凑。多数公司的过程记录是碎的：周报在邮件里、变更单在群里、纪要在一个人的本子上。所以复盘的第一件实事，往往不是开会，是先把这些碎片收拢到一个地方。

还有一个容易被忽略的对照材料：同类项目的记录。单看一个项目，很多问题是「偶发」；把三个同类项目摆在一起，同一个环节反复出问题，那就是流程问题，不是运气问题。

硬纪律：只写有记录支撑的事。记录里没有的，宁可写「当事人回忆，待核」，不许当成事实写进结论。

流程五步：拉时间线、找拐点、归因、提炼动作、入库分发。

第一步拉时间线，把项目从启动到交付按周排开，标上每次变更、每次人员调整、每次客户反馈。这一步做完，很多问题自己就显形了。

第二步找拐点，是整个岗位的分水岭。拐点就是「从这里开始不一样了」的那个时点：某次会上定了新范围、某个人离开、某个环节开始返工。找到拐点，讨论才有焦点；找不到，就只能泛泛谈感受。

第三步归因，只允许落在三个层面：计划层面（一开始就估错了）、执行层面（做法和计划不一致）、协作层面（接口没对齐）。归到「态度问题」是最省事也最没用的写法。

第四步提炼动作，每条必须带场景：什么情况下、看到什么信号、第一步做什么。写「加强前期调研」没人能用；写「客户超过两个部门参与时，开工前必须做一次跨部门对齐会」，下次才有人照着做。

第五步入库分发，把提炼出来的动作放进下次真会用到的位置：开工检查表、方案模板的备注、新人培训的第一课。放进一个叫「历史归档」的文件夹，等于没沉淀。

这段直接复制去用。留意第六条——不许评判人，这条不写死，它一定会写出一份让所有人都不想再参加复盘的文档。

最后一条最容易被跳过。沉淀这件事，最后一步不是写，是把它塞进别人不得不用到的位置。

它能把过程还原、把拐点找出来，但下面三句，得由人来判断。

第一句：「这次主要是某某配合不到位。」定责是管理的权力，不是复盘的工具。一旦复盘带上定责的味道，下一次所有人都会学会少说两句。

第二句：「这是偶发情况，下次不会了。」偶发还是必然，看的是同类项目里出现过几次。没查过同类项目就说偶发，等于赌运气。

第三句：「我们已经总结过了。」总结过和用上过是两件事。判断标准很简单：新项目开工时，有没有人真的去翻过那份东西。没有，就等于没沉淀。

说到底，复盘最怕的不是没开，是开了、写了、归档了，然后一切照旧。真正的分水岭不在会议那天，在下个项目开工那天——有没有人因为上次那份东西，少走了一步。它负责把经验变成条目，你负责让条目出现在该出现的地方。