为什么项目经验总跟着人走
很多公司的知识资产，其实是"人肉资产"——老工程师一走，踩过的坑又得新人重踩一遍。不是大家不想留，而是留的方式不对：周报里写"本周推进顺利"，复盘会开完纪要躺在群里，真正有用的"哪条路走不通"从来没人专门记。
我们早年也这样。一个项目做完，经验藏在交付负责人的脑子里，下一个项目换个人接，又从第一性原理吵一遍。后来我们意识到，沉淀经验如果只靠"项目结束后顺手写两句"，基本等于没沉淀。于是把"交付资产沉淀"当成一项正式工作，有明确的动作、责任人和时间窗，而不是散落在每个人好习惯里的随机行为。
我们用了四个动作，把经验拧成资产
1. 收口（Collect）——结项当天必须交一份偏差单。
每个项目结项，强制做一页"这次和预期不一样的地方"。不写成就，只写偏差：哪里多花了时间、哪个假设被打脸、客户哪个诉求我们一开始没听懂。这页纸不进漂亮的项目总结，专供内部复盘。坚持下来的原因很简单——偏差是下次最值钱的信息，而它只在记忆新鲜时完整。
2. 结构化（Structure）——三栏归类，拒绝长文档。
偏差按"场景—根因—对策"三栏归类，进共享知识库。我们刻意不用那种几十页的复盘报告，因为没人会读。三栏的好处是，新人遇到相似场景，检索"场景"就能直接看到别人踩过的根因和可用的对策，平均几分钟解决问题。
3. 模板化（Template）——第二次出现即对账成模板。
凡是第二次出现的对策，就抽成检查清单或代码片段，下个项目直接套。比如某类接口的异常处理、某类报表的取数口径，第一次手写，第二次挂进模板库，第三次起变成默认值。模板不是束缚，是把"已知正确"固化下来，让人把精力放在真正未知的部分。
4. 回灌（Validate）——用满三个项目才进规范。
模板用满三个项目，再正式写进交付规范。这一步最反直觉，但最重要：我们不让一次巧合变成定律。一个对策如果只在单个项目里灵验，进规范反而会误导后来人。满三个独立场景验证，才算"可信资产"正式入库。
一张表看"人肉资产"和"可复用资产"的差别
| 维度 | 人肉资产 | 可复用资产 |
|---|---|---|
| 载体 | 某个工程师的脑子和聊天记录 | 知识库条目 + 模板 |
| 流失风险 | 人走即失 | 沉淀即留 |
| 上手成本 | 新人跟岗半年 | 清单对照一周 |
| 复用方式 | 靠口述传承 | 靠检索调用 |
| 质量一致性 | 取决于谁在带 | 取决于模板是否更新 |
最后一行是我们后来补的——人肉资产最大的隐患不是慢，是"同一个坑，A 项目组踩过、B 项目组还在踩"，而可复用资产让质量不依赖个人状态。
落到一个具体例子
某科研院所的权限模型，第一版我们调了四周。根因是"角色—数据域—操作"三者关系没在一开始建模清楚，客户每次提新需求都在打补丁。我们把这套建模方法抽成模板，附上常见数据域清单和冲突处理规则。
第二个同类项目，三天定稿；第三个项目，客户提的需求里有七成可以直接套模板，剩下三成才是真定制。省下的不是那几周工时，是"每次都从零吵一遍"的内耗——而内耗这种成本，传统工时表根本记不下来。
一句话
经验如果不被结构化，就只能叫经历；被结构化、被复用，才叫资产。
金兰信息——把每一次交付的偏差，变成下一次交付的起点。