上周三，IT部老陈办完退休手续，把工位钥匙交还行政时，顺手递来一个U盘：‘里面是所有监控告警的排查口诀，还有几段Python脚本——别问我怎么写的，我写的时候也没留注释。’

没人接话。因为大家心知肚明：这U盘大概率会在三天后被塞进某个抽屉，半年后变成‘那个谁留下的旧东西’，再过一年，连U盘插口都认不出来了。

这不是孤例。上个月财务部小林离职前，把三年来的个税专项附加扣除审核逻辑手写了一页A4纸，贴在自己显示器边框上。她走后第三天，新同事问起‘为什么租房合同要验水印但不验公章’，没人答得上来——那张纸早被保洁当废纸收走了。

知识在组织里不是自然流动的，它是会氧化、会脱水、会过期的有机物。

我们试过建Wiki，结果首页最后更新时间停在2022年11月；试过强制要求‘交接文档必须上传系统’，结果交上来的是PDF扫描件，搜索不能、版本不清、链接失效；也试过让导师带新人‘口传心授’，可三个月后新人发现，导师说的‘一般这时候改配置就行’和实际生产环境报错日志里的报错码，根本对不上。

转机来自一次偶然的‘故障复盘’。那天数据库慢查询突然飙升，运维小吴翻遍蓝点里的‘DB优化手册’，发现其中一条写着‘索引重建建议每周二凌晨执行’——而这条规则，早在去年底MySQL升级到8.0.33后就失效了。但没人删它，也没人标它‘已弃用’。

我们忽然意识到：问题不在知识没存下来，而在知识没‘挂标签’。

于是我们在蓝点里新建了一个‘知识卡片’模板，字段不多：标题、适用系统版本、生效起止日、最后验证人、验证方式（截图/命令行回显/日志片段）、关联故障单号。最关键的，是加了一条自动规则：如果‘最后验证日’超过90天未更新，整张卡片自动变灰，并在顶部弹出浮动提示：‘此条目已超期，请确认是否仍适用’。

起初大家嫌麻烦。小吴第一次填‘验证方式’时，直接粘了段curl命令，结果系统提示‘请附带执行时间戳及返回状态码’——他只好重跑一遍，补上date && curl -I ...。但两周后，他主动在卡片里加了‘常见误操作’子项，还配了红框标注的截图。

更意外的是‘失效提醒’带来的连锁反应。上个月HR在整理入职培训材料时，发现一张‘社保增员操作指引’标着‘2023年7月起失效’，点进去一看，是去年社保局接口变更导致的。她顺手把新流程补全，还关联了当前使用的RPA机器人任务ID。

现在我们部门的知识库首页，不再按‘创建时间’排序，而是按‘最近验证时间’倒序。最新鲜的永远在最上面，最陈旧的自动沉底，还带个小小的‘⚠️待复核’角标。

上周老陈打来电话，问能不能远程帮他把U盘里的内容拆成几张知识卡片，‘我想标清楚哪几条还能用，哪几条得加个‘慎用’警告’。我说可以，他笑了：‘那这次，我试试写注释。’

其实所谓传承，未必是把火种完整交到下一个人手里；有时候，只是让每簇火苗都清楚自己还能烧多久。