人走了，那些"只有他知道"的东西也走了
你的核心开发离职了。
代码在 GitLab 上，文档在 Confluence 里，Wiki 密密麻麻写了 200 页。交接会开了三天，连数据库密码都整理成了表格。你拍拍胸脯跟老板说：没事，一切都在。
然后新人接手第一周，系统崩了四次。
不是代码丢了，不是文档没了。是那些从来没人写进文档的东西——”这个接口在周三下午高峰期要手动扩容”、”那个配置文件的第 37 行千万别改，改了整个支付链路会雪崩”、”这个报警可以忽略，那个报警必须在 5 分钟内处理”。
这些东西，跟着那个人的离职邮件一起消失了。
你以为文档够全就不怕人走？太天真了
很多管理者有个朴素的信仰：只要文档写得够详细，谁走都不怕。于是搞知识库建设，搞文档评审，搞 Wiki 填写 KPI。
结果呢？Wiki 确实有了 200 页，但该出的问题一个没少。
这不是执行力的问题，这是认知的误区。
团队里的知识其实分两种。一种是”显性知识”——写在代码注释里的、画在架构图上的、记在 API 文档里的。这些能写出来、能搜到、能传给任何人。
另一种是”暗知识”——只存在某个人脑子里的经验、直觉和潜规则。比如”为什么当初选了 Redis 而没选 Memcached”、”这段看起来很丑的代码为什么不能重构”、”上次大促出事故时到底按了哪三个按钮才恢复的”。
团队里最值钱的知识，至少有一半是暗知识。
这些知识有三个要命的特点：写不出来、问不出来、只有踩坑的时候才会浮现。你让老员工写交接文档，他能写出来的都是显性知识。那些暗知识？他自己都不知道自己知道。
骑自行车的人写不出平衡教程
这不是我瞎说，有个搞哲学的老头早就研究明白了。
匈牙利裔英国学者迈克尔·波兰尼在 1958 年提出了一个概念：“我们知道的，远比我们能说出来的多。”
他举了个绝妙的例子：你会骑自行车吧？骑得还挺溜。但你能写一份”如何保持自行车平衡”的操作手册吗？
写不出来。
你能感觉到身体要往左倒了，然后本能地调整重心，但你没法把这个过程翻译成文字。这就是暗知识——它藏在你的肌肉记忆里，藏在你的直觉反应里，藏在你都说不清的”感觉”里。
技术团队的暗知识也是一样的东西。
你的首席架构师看一眼系统监控面板就知道”今天晚上可能要出事”，但你让他说清楚凭什么判断，他会说”就是……感觉不太对”。你的运维老兵接到一个报警，手指比大脑快——先敲三行命令再想为什么，因为上次半夜三点被叫起来的肌肉记忆还在。
这些东西，你让他们写文档？写出来的只是冰山一角。
师傅带徒弟，不是靠说明书
想明白了暗知识的本质，解决方案也就清楚了——别指望把暗知识变成文档，那条路走不通。
手工艺行业早就想明白这件事了。一个老木匠怎么把手艺传给徒弟？不是给一本《木工操作指南》，是让徒弟站在旁边看三年，然后上手干三年。师傅刨木头的时候，力度怎么控制、纹路怎么判断、哪里该留余量——这些全在”一起干活”的过程中传递。
暗知识无法被写下来，但可以在人和人之间流动。
所以关键不是逼团队写更多文档。文档解决的是显性知识的问题，你已经有 200 页了，够了。你真正需要的是设计一套让暗知识自然流动的工作方式。
好消息是，虽然暗知识写不下来，但它有个特点：它特别擅长在人和人之间”传染”。 就像你从来不会因为读了一本书学会游泳，但你跟一个会游泳的人下水扑腾几次就会了。
下面三个方法，不是让你写更多文档，而是让暗知识在团队里自然流动。
第一招：结对，把暗知识”传染”出去
结对编程这个概念不新，但多数团队把它当成”提高代码质量”的工具。错了，结对最大的价值是暗知识传递。
别只在写代码的时候结对。最有价值的结对场景是——处理线上事故。
下次生产环境出问题，别让老兵一个人上去救火。拉上一个新人，让他坐在旁边看。老兵在排查的时候会自言自语：”这个日志量不对，我先看看连接池……果然，上次也是这个问题。”
新人在旁边听到的这句”上次也是这个问题”，比任何事故报告都有价值。因为老兵告诉了他一个从来不会写进文档的信息：这个系统的历史故障模式。
结对运维、结对排障、结对做技术方案评审——这些场景里流动的暗知识密度，是坐在工位上看 Wiki 的一百倍。
不需要搞得很正式。就一条规则：凡是只有一个人会处理的事情，下次必须带一个人。
第二招：事故复盘要录视频，别只写报告
结对解决了”一对一传染”的问题，但如果你想让暗知识扩散得更广呢？
你们团队的事故复盘是不是这样的：出了事，写一篇 Post-Mortem，列原因、列改进措施、发到群里让大家看。
问题是，文字复盘丢掉了最有价值的东西——讨论过程。
真正有料的不是那份报告，是复盘会上老兵们的对话。”你当时为什么先看了那个指标？”“因为我 2023 年踩过一次坑，那次也是从这里开始的。”“啊？那次是什么情况？”“当时也是凌晨两点，连接池打满了，我们以为是流量暴增，排查了俩小时才发现是上游一个服务在疯狂重试……”
你看，”你知道为什么吗”后面跟着的那段话，就是暗知识的出口。它以对话的形式自然涌出来了，但如果你只写报告，这段对话会被压缩成一行”根因：连接池配置不当”。所有的上下文、所有的判断依据、所有的历史教训——全丢了。
所以复盘会要录屏，或者至少录音。完整的讨论过程比精心整理的报告有价值十倍。因为暗知识就藏在那些跑题的闲聊、突然想起来的旧事、和”对了我跟你说个事”里面。
新人回看这些录像，学到的不是”出了什么事”，而是”老兵们是怎么想问题的”。这才是暗知识传承的真正形态。
第三招：ADR，给暗知识留一个”案发现场”
前面说暗知识没法写成文档，这话说得有点绝对。有一种暗知识是可以写下来的：技术决策背后的”为什么”。
我见过最惨的案例：一个团队的支付系统里有一段”丑得令人发指”的代码，新来的架构师看了忍不了，花两周优雅地重构了一遍。上线当天，支付成功率从 99.9% 掉到 97%。排查半天才发现，那段丑代码里藏着一个针对某银行网关的特殊重试逻辑——三年前的一次事故后加上去的，当时的人早就走了，没人知道为什么。
如果当初有一份 ADR（Architecture Decision Record，架构决策记录），这场灾难就不会发生。ADR 的格式很简单：
- 我们面临什么问题
- 我们选了什么方案
- 我们考虑过哪些备选方案
- 为什么选了 A 不选 B
- 这个决策有什么已知的代价
最后那两条是暗知识的核心领地。”为什么选了 A 不选 B”——这个信息在任何代码注释和 API 文档里都不会出现。但如果没有它，就会不断有新人踩进同一个坑里，然后一脸委屈地说：”我只是想让代码更好看啊。”
你的系统里有多少”看起来很蠢但其实有深意”的代码？每一段背后都有一个没写下来的 ADR。
ADR 不需要写得很长。半页纸，说清楚”选了什么、为什么、放弃了什么”就够了。把它想象成案发现场的封条——不是告诉你发生了什么，而是告诉你”别动这里，背后有故事”。
别再往 Wiki 里加页数了
回到开头那个场景：核心员工离职，200 页 Wiki 没能接住。
现在你知道为什么了。那 200 页解决的是”是什么”的问题——系统架构是什么、接口参数是什么、部署流程是什么。但团队真正需要的是”为什么”和”踩过什么坑”。
文档传的是知识，人传的是智慧。
防止暗知识流失，靠的不是更多文档，而是让知识在人和人之间流动起来。让新人跟着老兵一起救火，让复盘会的讨论被完整录下来，让每个技术决策的”为什么”被写进 ADR。
这三件事做到了，就算核心员工明天离职，你的团队也不会抓瞎。
所以下次有人要走的时候，别急着让他写交接文档。让他带着新人一起处理两周的工作——该排障排障，该开会开会，该救火救火。
那两周里流动的暗知识，比他憋三天写出来的文档值钱一万倍。