夜雨聆风有篇文章的标题我很喜欢，《Bottle your judgment and make it outlive you》。直译过来稍微有点怪，大概是，把你的判断力装进瓶子里，让它比你活得更久。
这个说法听着有一点科幻，甚至还有一点吓人。好像要把一个人脑子里的东西抽出来，塞进机器，最后做出一个数字分身。但文章真正聊的并不是克隆人，而是每家公司、每个团队都遇到过，却一直没什么好办法解决的老问题。
一个真正厉害的人离开时，到底带走了什么？公司里的文件通常还在，项目记录还在，会议纪要也还在。甚至连他做过的方案、发过的邮件、留下的批注都能找到。可过一段时间，大家还是会慢慢发现，有些东西确实跟着那个人一起走了。
以前开会卡住，他往往听几分钟就知道问题出在哪。两个方案摆在桌上，数据各有道理，他却能判断哪一个看起来漂亮，落地后一定会出事。碰到规则之外的情况，他也知道这一回该守住，还是该破例。
你问他为什么，他多半讲不清楚。不是故意藏着，也不是不愿意教。他可能只会皱着眉说一句，我觉得这里不太对。再追问下去，答案往往就变成了，做久了自然就知道。
最值钱的东西，偏偏就藏在这句「自然就知道」里面。
Michael Polanyi 很早就给这种东西起过一个名字，默会知识。人知道的，永远比能说出来的多。一个老编辑扫两眼就知道标题不行，一个资深产品经理听完需求就能闻到风险，一个设计师看着间距总觉得别扭，却未必能立刻告诉你究竟差了哪四个像素。
这种能力不是背规则背出来的。它是一个人在成千上万次选择里，慢慢磨出来的手感。哪些细节可以放过，哪些地方一步都不能退，哪些数字很热闹但没什么用，哪些反常信号必须立刻追下去。
Dorothy Leonard 和 Walter Swap 把它叫作 deep smarts，深层智慧。这个词挺准，因为它既不是知识，也不只是经验，而是经验被压缩之后留下的判断。
问题也在这里。它通常只装在一个人的脑子里。
过去公司保存这种判断力的办法，说起来甚至有点可怜。多带带新人，多写写文档，多开几次复盘会。如果这些都来不及，那就只能尽量留住这个人。
一个人一走，一座小型图书馆也跟着关门了。
所以这两年，大家总在争论 AI 会不会替代人，我反而越来越觉得，这个问题问窄了。AI 还有一个没那么抓眼球，却可能更有用的方向，它能不能帮一个人把脑子里的判断慢慢掏出来，交给身边的人继续使用？
注意，不是让 Claude 或 ChatGPT 替他做决定，而是让这些模型帮他解释，自己究竟是怎么做决定的。
Dan Maccarone 在原文里写了两个很有意思的创始人。两个人都想让公司继承自己的判断，走的路却完全相反。
其中一个在努力把自己「下载」出来。他不断把过去的决策、邮件、推理过程和工作方法交给模型，让模型一点点熟悉他的思路。时间久了，模型不只说话像他，有些时候，连做出的判断都开始像他。
他并不是真的想复制一个自己。他只是受够了所有问题都要等他亲自出现。他希望自己的判断可以移动，可以被团队调用，不再锁死在一个人的时间和精力里。
另一个创始人对这件事非常警惕。他不相信一个人的品味和判断能被压成几条规则，更不希望团队学会模仿他的口气，却没有学会真正看问题。
在他的公司，新人不是读完一份手册就算完成入职，而是要跟着老人做事，要去现场，要感受那个团队在真正工作时是什么样子。很多东西没有文档，只能靠靠近、观察和一遍遍练习传下去。
这让我想到《功夫梦》里的那套训练。Daniel 不是看了一本空手道手册就学会出拳的。他反复擦车、刷墙，做那些当时根本看不懂的动作。直到有一天，身体先于语言理解了它们。
这个创始人的担心完全有道理。一个人把过去所有文章和决策记录都交给模型，模型学到的仍然只是能被写下来的那部分。它知道你曾经怎么选，却不一定知道你为什么突然破例。它记住了规则，却没有经历过那些让你学会害怕的失败。
可只靠师徒制也有问题。它很慢，很贵，而且极其依赖运气。新人得刚好遇到愿意教的人，也得有足够多的真实项目可以练。好不容易有人学会了，如果他后来也离开，公司还是会把同样的损失再经历一遍。
一个方法容易把经验压扁，另一个方法根本放大不了。那到底选哪个？
其实不用选。
日本管理学家野中郁次郎研究组织知识时，提出过一个很重要的想法。知识在组织里不是从人脑搬到文档就结束了，它更像一圈不断转动的循环。人在共同工作中吸收那些说不清的经验，再努力把其中一部分表达出来。写下来的方法进入新的实践，又在实践中被修改，最后重新变成更成熟的判断。
文档和师徒制从来不是竞争关系，它们本来就应该接在一起。能写下来的，尽量写。写不下来的，安排人靠近真实工作去学。规则交给系统保存，破例的手感交给实践。AI 负责扩大前一部分，人负责完成后一部分。
听起来并不复杂，真做起来却挺费劲。
很多人理解的知识沉淀，是把硬盘里的文件全部丢进 Claude，或者在 ChatGPT 里建一个项目，把邮件、方案、会议纪要一股脑塞进去，然后期待它突然长出自己的脑子。
大概率不会。
没有结构的资料堆得越多，得到的往往不是第二大脑，而是一团更会说话的混乱。模型会抓住材料里出现得最频繁的观点，记住声音最大的那句话，再用一种比原作者更确定的语气讲出来。
真正值得记录的，不是你最后选了 A，而是你为什么没有选 B。当时面对的是什么局面，目标到底是什么，哪些信息最关键，哪些看似重要的数据其实被你忽略了。你担心什么，做了哪些取舍，在哪些条件下会改选 B，还有哪条底线，无论短期收益多诱人都不能碰。
这些才是判断力的骨架。
所以真想做这件事，可以从一个很小的动作开始。下一次做完重要决定，别急着只保存结果，给自己留一页决策记录。不用写得像公司公文，就按当时真实的思路，把犹豫过什么、排除过什么、为什么下这个判断写清楚。
过一两个月再回来看看结果。如果判断错了，错在信息不足，还是错在原来的规则根本不成立。如果判断对了，也别只写一句效果很好，继续追问，当初真正起作用的信号是哪一个。
积累十几份这样的记录，再交给 Claude 或 ChatGPT 去归纳。让它找出反复出现的原则、互相冲突的选择，以及你总在强调却很少真正遵守的东西。
这一步可能会有点难受。因为人在解释自己的时候，经常会发现，自己以为在坚持原则，实际只是形成了习惯。也会发现有些挂在嘴边的方法，到了关键时刻一次都没用过。
但这恰好是整个过程最有价值的地方。
你原本是为了教会模型，结果先把自己教明白了。
英国作家 E. M. Forster 有句很有意思的话，大意是，我得先看看自己说了什么，才知道自己到底在想什么。很多专家一辈子都不用认真回答这个问题。他们靠手感工作，事情也确实做得不错，于是那些判断规则一直沉在水面下面。
AI 给了人一个把它们捞上来的理由。更妙的是，你为了训练模型写下来的东西，恰好也是早该交给团队的东西。那些关于条件、例外、红线和失败的记录，比一百页标准流程更接近真实工作。
当然，别因此高估那个被训练出来的数字版本。
我很喜欢原文里的一个提醒，应该像信任一个很聪明的新员工那样信任它。这个新人读完了公司所有资料，记忆很好，反应很快，也特别愿意回答问题。唯一的问题是，他一天真实的工作都没做过。
他没有被客户突然改需求折磨过，没有经历过一次看似正确的决定怎样把项目拖进坑里，也没有在现场感受过某个微小异常为什么让所有老员工同时安静下来。最麻烦的是，他不知道自己没有这些经验。
真人会迟疑，会说我不确定，会因为某个细节停下来多看一会儿。模型却很容易把一个只有六成把握的判断，说得像板上钉钉。它复制了你的答案，却把你做决定时的犹豫给弄丢了。
所以，训练一个像自己的模型，绝不能成为停止培养人的理由。恰恰相反，有了这套系统以后，新人更应该尽快进入真实项目。先用模型理解基本方法，再带着问题去观察高手怎么处理例外。做完以后复盘，看看文档里的规则在哪些地方失效，为什么失效。
然后把这些新经验重新写回系统。
这个循环一旦转起来，所谓的公司知识库才不再是一座堆满旧文件的仓库。它开始像一个活的东西，跟着团队一起犯错，也跟着团队一起修正。
回到设计这件事，道理其实完全一样。
很多团队沉淀设计系统，最后只留下组件、字号、颜色和间距。按钮该多高，弹窗怎么摆，什么情况下用哪个颜色，写得非常清楚。可真正影响产品质量的那些判断，经常没有留下来。
为什么这个页面故意没有提高信息密度，为什么这次没有沿用成熟组件，为什么数据更好看的版本反而被放弃，为什么有些视觉不一致是可以接受的，有些不一致却会伤害用户理解。
如果这些理由不在，设计系统就很容易变成一套外观管理手册。新人能照着画，却不知道什么时候不该照着画。
所以设计团队也应该保存自己的判断记录。不要只把终稿放进 Figma，也把被放弃的方案、评审中的争论、做出取舍的条件留下来。再让新人真正参加评审，看看资深设计师怎样从模糊反馈里找出问题，怎样在商业目标、用户感受和开发成本之间做选择。
一边写下来，一边站近一点。
文章最后用了一个特别好的乐队比喻。一个翻唱乐队可以把你的曲目练得一模一样，每一个音都没错，但当整个房间突然安静下来时，它未必知道下一首该唱什么。
模型也是这样。它可以记住你的全部曲目，却很难判断此时此刻，这个房间最需要哪一首。
这种判断还得有人来做。
所以我现在不太喜欢「把自己克隆进 AI」这个说法。它太狂妄，也太容易让人误以为，人的全部可以被几百份文档完整复刻。
我们真正能做的，是把自己打开一点。把那些已经能够说明白的经验写下来，别再让团队一次次从头踩坑。把那些暂时说不明白的部分，放进真实工作里，通过观察、练习和反馈交给下一个人。然后允许后来的人修改它，而不是永远模仿你。
装进瓶子里的，不该是一个人的标准答案，而应该是他看过的信号、付过的代价，以及做出判断时走过的那条路。
AI 不会让一个人永远活着。
但它或许能让一个人用很多年才换来的东西，不必在他转身离开那天，跟着一起消失。