隐性知识：Context is all you need

推荐语

隐性知识才是AI落地的关键瓶颈，掌握火候比模型参数更重要。

核心内容：
1. 隐性知识在AI应用中的核心作用
2. 企业数据治理与隐性知识的本质区别
3. 隐性知识在业务场景中的具体表现

杨芳贤

53AI创始人/腾讯云(TVP)最具价值专家

天凉了，想吃点热乎的。家里人炖排骨，食谱上写得明明白白：排骨一斤，焯水，加葱姜、料酒，大火烧开，小火慢炖一个钟。真做起来，这小火是多小？灶眼里的火苗，是贴着锅底，还是离着一指？说是炖到酥烂脱骨筷子一戳便知，可戳下去的力道深浅，食谱上也没写。

这，就是手上的功夫，心里的数。

上个月在 Anthropic 的经济指数报告里，有一段话也是类似的含义：

The upshot is that deploying AI for complex tasks might be constrained more by access to information than on underlying model capabilities. Companies that can't effectively gather and organize contextual data may struggle with sophisticated AI deployment, creating a potential bottleneck for broader enterprise adoption—particularly for occupations and in industries where tacit, diffuse knowledge is crucial to business operations.

——By Anthropic 2025-09-16

大概意思是：企业中想让 AI 干好那些复杂的活儿，瓶颈不在它模型能力强不强，聪不聪明，而在你能不能提供更好的信息输入，把事儿给它「讲明白」。尤其针对那些依赖隐性知识来维持业务运作的岗位和行业。

你别说，你还真别说，这种英文的、来自大公司或者 KOL 的材料给人的感觉就是这样，看起来说的都是些口水话，但仔细推敲下去还真有很多门道。

结合自己最近的观察，发现确实如此。AI 大模型百亿千亿参数的多的是，点状答疑解惑样样精通，可一旦干起真活儿来，就一个比一个拉跨。规矩它都懂，就是差了点「火候」。

这火候，便是那些只可意会、不好言传的 Context。

那什么样的 Context 才算好呢？

• 那些躺在 OA、邮件、审批等各种数据库中的零碎信息，条条框框一清二楚，但这不算。

• 那些经过数据治理归置在数仓中用于分析统计的信息，琳琅有致环肥燕瘦，这也不算。 

真正的高质量、有壁垒、难获取的 Context，堪称独门秘方，就是企业内部的隐性知识（Tacit Knowledge）。

相比于那些能被明确定义、结构化存储、标准化传输的显性数据，隐性知识的特点有二：

• 分散：存在于不同部门、不同层级的组织或个体，大隐隐于市那种。

• 主观：更强调人的经验智慧、直觉判断，而不是小眼镜片式的理性。

举几个熟悉的场景：

1、用户需求的探究后置。需求文档上写的是一回事，用户真正舍得花时间跟你推敲细节的，往往是在文档之外的交付中和交付后。这种需求的不断随机跳动摇摆，就足够新员工揣摩个大半年。

2、产品研发的妥协折中。架构设计纸面上写得的不得了——模块清晰、接口齐全、指标漂亮。但实际开发时，就得各种找平衡——技术选型要结合环境而不是最佳实践；架构拆分要考虑运维成本而不是性能；编码设计要凭先例经验而不是求新求全。

3、项目交付的关键动作。真正能让一个项目顺利交付的，往往不是规范化流程，而是在节点推进时如何巧妙施压。什么时候需要提前半步和用户沟通，什么时候要留一步给厂商供货余地，以及与各种人事乘除斗法，这都是极具「非标化」的。

4、一线员工的临场判断。面对复杂的现场系统环境，标准手册给出的处理方案往往是理想化的。而一线工程师能在几分钟内判断出，是网络、配置还是权限的问题，这种直觉就得源自“纸上得来终觉浅，绝知此事要躬行”的日积月累。

5、流程背后的潜规则。制度里写得是逐级汇报，但老同事知道，某些问题如果等层层上报，那错过就是一辈子了。反而是先和谁打个招呼，在哪个环节提意见，才能既不打乱节奏又能顺利推动。难把握的，是其中先后顺序和轻重缓急的拿捏。

过去十年，企业都在尝试切除信息孤岛。做软件就是做工具，工具给人用，问题最终还是得人来解决。

现在，更值得关注的是认知孤岛。AI 要代替人直接解决问题，它需要的，是被赋予更多「人味儿」（除了被背锅）。

这「人味儿」的核心，就是那些隐性知识。它不是冰冷的数据，而是带着温度的经验；不是标准的 SOP，而是中式圆融的智慧；不是逻辑的推演，而是直觉在闪现。

它是一个老师傅在无数次重复中形成的手感，是一个团队在长期磨合中形成的默契，是一代人言传身教留下的心法。

再厉害的模型，也算不出人心里的那杆秤。

---

问题又来了，如何才能建立起隐性知识库并为我所用呢？

我不知道，这属于专业的 Context Engineering 的范畴，或许也会成为新的竞争高地——围绕企业知识、规则与偏好，构建可持续沉淀与演进的上下文体系。

但以我业余且微不足道的理解力，觉得用对付显性数据的办法来「收集」隐性数据，大概率不管用，还会把那股最宝贵的「人味儿」给弄丢。

所以，与其说「收集」，不如换个思路，叫「养」。

我们习惯了把知识变成文档，变成手册，变成数据库里的条目。就像是把蝴蝶做成标本，形还在，神没了。

隐性知识是活的，它长在人的脑子里，体现在人的手上，流淌在人与人的交往里。生硬地把它抽出来、记下来，往往就成了干巴巴的教条。

我能想到的，大概就以下这些虚的念头。

闲聊时光

真正非共识的经验交流，常常发生在楼道抽烟口、茶水间、饭桌上，在那些看起来不务正业的闲聊里。

今天张飞提一嘴他踩过的坑，明天李逵讲一个他打交道的小窍门。这些碎片化的、带着情绪和场景的「扯淡」，可能胜过很多正式的会议纪要。

要鼓励，甚至刻意创造这样的场域和时间，让大家有空闲聊，有心情闲聊。

AI 拜师

最好的传承，是师徒间的言传身教。

老师傅带着徒弟，让他看，让他试，在旁边时不时点拨一句。知识的传递，就在这一问一答、一看一学之间。

有朝一日，AI 也能当一回学徒，它「跟着」一个团队，观察他们如何讨论，如何争吵，如何妥协，如何最终解决一个棘手的问题。

它记录的不是结果，而是整个过程的活剧本。

故事叙述

我发现很多用户不喜欢听标准解决方案，就喜欢听故事。

故事里有当时的天气，有当时客户的脸色，有团队里谁和谁的争执，有不同厂商间的口角和八卦，曲曲折折，坑坑洼洼，如此一来，对方心里也就有了底。

所以啊，多建一些「故事会」而不是「知识库」。

定期地，可以没有主题，就请团队里有经验的人来讲故事。

不求提炼，不求升华，就让他原汁原味地讲。其他人可以随时插话、提问。AI 混在其中，就做一个忠实的录音师，把这场带着语气、情绪、互动的故事完整记录下来。

这些故事，就是最鲜活的案例集。

关注异常

流程手册记录的都是常规操作。但一个组织真正的智慧，体现在它如何处理失败和异常。

一次意外的系统崩溃，一个极其难缠的客户，一次突如其来的需求变更……复盘这些事件时，不要只写一份政治合格的报告，而是要追问：“当时你心里怎么想的”、“为什么你决定先做 A 而不是 B ”、“你最担心的是什么”……

隐性知识里，有很大一部分是关于「如何避免犯错」的智慧。这种智慧，非得从失败里才能长出来。

把这些决策背后的心路历程挖出来，才是挖到了宝藏。

保持在场

隐性知识是动态的，是在解决问题的「当下」产生的。事后再去回忆、总结，总会失真。

因此最好是守着火苗，若只是去分析一堆烧尽的炭灰，温度早已经没了。

比如，在一个项目讨论会上，AI 可以实时地将大家的七嘴八舌转成文字，并根据对话的上下文，自动关联过去的文档和记录。当有人提到一个过往事件时，AI 能立刻把相关背景资料推送到屏幕。它不打断，只是默默服务，帮着大家把散乱的思绪给理顺了。

它把人从繁琐的回忆和记录里解放出来，让脑子能一心一意地用在创造和思考上。

同时，知识在它最新鲜、最热乎的时候，就被原封不动地「拓」了下来。那些灵光一闪的念头，那些只在特定场景下才会生效的窍门，那些藏在语气和停顿里的犹豫与果决，都连着那口热气，一并存了下来。

---

说到底，我们不是在为 AI 收集智慧，而是在这个过程中，重新珍视「人」的价值。

养出隐性知识最好的方法，或许就是创造一个让人们愿意分享、乐于交流、敢于试错的环境。

人心似田，四时皆有味。

知识如水，渠成自然来。