01. 暗知识——FDE给企业构建AI知识库踩坑随想
摘要 ：给企业做AI知识库，打造智能体与本体模型时，FDE们会遇到一种落差： 字段与制度定义了一套世界，现场业务却还有另一套走法。
修订说明（2026-10-13）：本文保留原稿的观点。订单与设备两例是示意场景，不是经独立核验的企业案例；专家路由、审批闭环与组织激励是设计建议，原稿没有项目对照日志证明效果。文末资料用于概念与理论定位，不能单独证明工程成效。
AI SaaS ToB 行业产品老兵，创业者，欢迎关注并理性讨论。
02. 知识缺口
“这个没有文档/文档里没写。”
给企业搭建 AI 知识库时，这句话是不是非常耳熟。
制度、流程和产品说明已经放进系统，会议纪要和项目复盘也在，业务人员遇到具体问题，还是会合上电脑，去问一个“老法师”。
比如客户为什么突然不续约。CRM 里有合同、工单和拜访记录，系统能整理出一份风险摘要，却未必知道客户刚换了采购负责人；新负责人和旧技术对接人曾经在哪件事上谈崩，也未必写进任何字段。
再比如设备反复报警，维修手册列出标准排查步骤，老师傅听到一段异响，先去检查的却是手册没有标注的零件。
这些例子指向的是：组织里有些知识存在于实践、关系和当下情境中，文档只是其中一部分。
我姑且把这类文档之外的信息称为“暗知识”。这只是我自己发明的一个工作性概念，不是新的学术分类，也不同于机器学习中与知识蒸馏相关的 Dark Knowledge。
我想用这个词来表达并提醒：有些信息尚未记录，有些不能完整写下，还有些即使写下来也不能脱离情境使用。
“暗”描述的是它相对于正式系统的可见程度，并不表示它正确、不可记录，或者应该受到保护。未经核实的传闻，不能因为没有写进文档就升级成知识。
03. 真实世界被压平了
AI知识库的标准启动姿势是“数据资产盘点”：拉一张表，标上责任部门、更新周期和覆盖率。这些工作有必要，但表格填完，不等于业务问题解决了。
同一件事问销售、交付和产研，可能拿到三个不同却各有依据的解释。销售看到采购关系，交付看到使用障碍，产研看到产品限制。它们有时相互矛盾，有时只是同一块现实的不同侧面。
但知识库的结构要求 单一真实源（Single Source of Truth） ：一个条目只能有一个标准答案。FDE在实施的时候，只能把充满情境的冲突，裁成一段公文式总结。
写得越规范，内容越失真。
写得规范本身没有错。 失真发生在适用条件被删掉之后。
04. 三种暗知识
把所有“AI 答不上来”的情况都归到一个概念下，容易让问题变得神秘。至少要先分清三种成因。
第一种，能写，只是还没写。 操作流程漏了一个步骤，产品说明没有更新，某个字段没人维护。这是普通的知识治理问题：找到责任人、补充材料和管理版本。把它包装成不可言说的经验，只会给FDE在实施时偷懒的惰性找个更高级的名字。
第二种，能做，却难以完整说清。 资深销售从付款节奏里察觉异常，老工程师从设备声音里判断故障。部分线索可以记录，部分能力却要靠反复练习才能获得。让他写一份《直觉沉淀指南》，未必能让新人拥有同样的判断力。这里涉及的是 默会知识（Tacit Knowledge）与能力形成 。
第三种，说得清，却不便公开说。 客户内部的人事矛盾、跨部门协作的真实阻力，可能三分钟电话就能讲明白。但公开记录会涉及隐私、信任，以及权力和责任。有些信息应当受限流转，有些需要正式报告，还有些本来就不该采集。这里的难点是 治理与激励 。
三者可能同时出现在一个问题里。文档漏项可以补，手艺需要练，关系信息需要核实和授权。换一个更大的模型，不能自动替代这三件事。
05. 管理学（管理人类的学问）早就遇到过同样的问题
1911 年，泰勒在《科学管理原理》中主张通过系统研究改进工作方法，把工人的经验整理为可传授的标准。标准化由此获得了强大的管理语言。[2]
后来，霍桑研究及其引发的人际关系学派，把群体规范、协作关系和人的感受带进组织分析。实验结果的解释一直存在争议，但这段研究史留下了一个重要的问题：只研究操作方法，能不能解释一群人如何共同工作？[3]
巴纳德在《经理人员的职能》中讨论正式组织与非正式组织的关系。组织架构图之外，人还会依靠熟悉、信任和共同经历形成协作网络。指令能不能落地，往往也取决于这些联系。[4]
借用这个视角， 一部分暗知识，可以看作非正式组织在知识维度上的投影。 它藏在谁愿意告诉谁、谁知道该问谁，以及谁能听懂一句没说完的话里。但两者并不完全重合：个人手艺未必依赖非正式网络，非正式组织也会传播偏见和过时经验。
知识库建设时，一旦试图用正式文本包办这些关系，就容易把“可以被设计的部分”当成“全部”。这个错误有个特点： 它在很多地方都对，所以你会以为它在所有地方都对。
Polanyi 在《The Tacit Dimension》中写道：“We can know more than we can tell.”
我们所知道的，可以多于我们能说出来的。[5]
一条明确规则，仍然可能依赖没有被完整表达的判断。新人和老法师读的是同一本手册，看到的却未必是同一个故障。
用IT的语言比喻一下：显性表达是对经验的一次有损压缩，它能方便传递，却不能保证接收者已经具备使用它所需的能力。 从“材料进了系统”到“系统能够可靠判断”，中间还有一段需要验证的距离。
06. 东方哲学早就不指望”写下来”这件事
西方知识管理的主流叙事有个隐含目标： 把默会变成显性 。背后是一种信念，能被清晰表述的才是可靠的，说不清楚的就是还没成熟。从笛卡尔开始，“清楚明白”就是真理的标准；后来泰勒被搬进工厂，SECI 被搬进知识管理。
禅宗讲”不立文字，直指人心”。文字有用，有些东西的传递本来就不该走文字这条管道。
《庄子·天道》里，做车轮的轮扁对齐桓公说，您读的都是古人的糟粕。做车轮，榫眼松了就滑、紧了就卡，不松不紧那个分寸，“得之于手而应于心，口不能言”，我没法教给儿子，所以我七十岁了还在自己做轮子。
这个故事的终点不是”读书无用”。重点是 轮扁并不觉得自己有问题 。他接受手艺的传递方式就是手传手，不是纸传纸。
有意思的是，中国企业在建知识库这件事上，热情一点不比西方低。越是习惯于通过人来传递知识的组织，越容易在”制度化”上用力过猛，把”没有文档”当成落后，把”有文档”当成现代化。这是 把工具当成了目的 。
07. 为什么还要建本体和知识库
哈耶克 1945 年在《知识在社会中的运用》中强调，经济活动依赖大量分散在个体手里的知识，它们涉及特定的时间与地点。如何利用这些知识，比假设它们已经完整地交到一个中心手里，更接近真实问题。[8]
把这个论点放到企业里，可以得到一个设计提醒：即使知道了今天谁处理过什么，也不能保证知道明天谁能解决新问题。人员会变，业务会变，有些能力只有在具体任务里才显露出来。
因此，值得质疑的是一张 完整而静态、由中心一次性绘制的全知图谱 。而不是知识图谱没有价值，也不意味着共享模型必然失败。一个允许现场维护、允许过期，也允许纠错的索引，仍然可以减少大量无效寻找。
交易费用不会因为上线一个AI对话框就消失。 科斯用协调成本解释企业的存在及其边界。借用这一视角看知识系统，检索只是成本的一部分，后面还有核验、解释，以及建立信任与承担责任的成本。技术能降低其中一些，也可能把另一些转移给员工。[9]
项目还会受到建设者激励的影响。 被蒸馏的“老法师”是否真的愿意为一个AI对话框冒失去工作的风险被完整蒸馏？
知识库当然值得建。问题出在把可检索、可汇报的部分，当成了组织全部的知识能力。
08. Ontology 的价值，在行动里
静态文档库、RAG 与企业业务本体，并不是三代必然相互替代的产品，也不天然共享“收集全部知识”的假设。
文档库保存表达；RAG 把检索到的材料提供给模型，用来支持回答；计算机科学中的 Ontology（本体） 则对一个领域的概念、实体类型、属性、关系及其约束作出明确的形式化规定。它可以描述“客户—合同—订单”的关系，也可以描述人员与项目，但本体并不等于找人的通讯录。[11]
Palantir Foundry 中的企业业务本体又向前走了一步：在对象、属性和关系等语义元素之外，把 Action Types、函数和权限控制 接了进来。Action 可以按预先定义的逻辑修改对象与关系，并通过配置触发对外部系统的调用。它的价值不仅是解释业务，还包括让业务操作进入受控的执行路径。[12]
比如，AI检索问答可以告诉你某张订单为什么被锁；配置了相应能力的工作流，则可以在核验权限、订单状态和审批条件后，执行阻断发货、申请例外放行或调整信用额度。订单从“冻结”到“待审批”再到“获准放行”，可以按明确的状态转换规则运行。[13]
这正是企业即便承认暗知识存在，仍然有理由构建业务本体的原因： 不必先把企业全部理解完，也能把一部分重要操作做得更一致、更可追溯。
但需要搞清楚：
- 第一，状态机要由业务与工程团队设计，通用本体并不天然附带完备的执行机制；规则确定，也不意味着外部业务结果确定。
- 第二，RAG 应用可以接工具执行动作，只是检索与生成本身不提供这些控制，必须另建执行层。
这里真正的问题是，系统有没有把已经建模的部分，当成整个现实。Action 放大了系统的用途，也放大了错误判断的后果。
09. FDE 的现场踩坑和落差
打造业务系统与本体模型时，FDE会遇到一种落差： 字段与制度定义了一套世界，现场业务却还有另一套走法。
举两个栗子🌰：
场景一： 系统规定账期逾期 30 天自动锁单，现场却经常手工放行。暗知识解释：这是战略采购商，回款受母公司结算节奏影响，业务过去凭回款承诺函继续发货。而这次所谓的承诺函，只是一张微信截图。
这里还不能下结论。它可能是合理例外没有进入制度，也可能是授信规则过时，还可能是有人拿“战略客户”给违规操作找理由。截图只提供调查线索，不能自动成为放行依据。
场景二： 高精机床报警，老法师根据一段异响和焦味，优先检查传感器垫片。这个判断（暗知识）可能来自长期经验，也可能是一次碰巧猜中。要让它成为可复用的经验，需要结合检修结果、后续运行与其他故障记录验证；要让新人获得能力，还需要共同排查和现场训练。
因此，FDE 需要在获得授权后，回看特批记录、手工改价单，以及人工状态变更和线下转单，寻找标准流程反复失效的位置。
系统绕行点，是正式模型与现场实践出现裂缝的显影剂。 它值得追查，却不能直接证明背后存在一条有价值的暗知识。文档缺口、流程僵化、系统不好用，临时应急、默会经验和利益博弈，都可能留下相似的痕迹。
绕行点的价值在于定位问题；问题背后的知识与缺陷，需要另外辨认。
10. 先判断问题在哪个域
Snowden 的 Cynefin 框架，为这种辨认提供了一组有用的区分。它关注的是当前情境中的因果关系，以及据此应采用的处理方式。[14]
在 清晰域（Clear） ，因果稳定，适用规则比较明确，按流程处理通常有效。在 繁复域（Complicated） ，原因不直观，但可以通过专业分析找到；设备诊断、复杂的技术配置，常有这样的部分。这里适合“感知—分析—响应”，知识库和业务模型可以支持专家分析，并把已经验证的规则落实到执行中。
在 复杂域（Complex） ，参与者会相互影响，干预也会改变局面，因果模式往往只能在事后辨认。客户组织重组之后，谁愿意支持续约、哪种沟通会引起反感，就可能具有这种性质。把上一次成功的话术写成必胜规则，下一次未必有效。更合适的方式是 探测—感知—响应（Probe–Sense–Respond） ：做后果可控的小规模尝试，观察反馈，再调整行动。[15]
如果现场已经进入混乱、需要立即止损的状态，则要先采取稳定局势的行动，再重新判断，不能拿探索当作拖延处置的理由。
这里有两个容易混淆的地方。 默会知识是一种知识特征，复杂域是一种情境特征，二者不能画等号。 老师傅凭声音识别机械故障，可能仍然处于可分析的繁复域；涉及人的问题，也不一定都属于复杂域。同一项业务还可能同时包含几个域：订单状态转换可以规则化，客户是否接受新的结算条件却未必如此。
Cynefin 因而提供了判断工具，却不替具体场景保证分类正确。在复杂域里，本体仍然可以记录对象、约束行动权限，并追踪尝试与结果；它不必替人预先写出一个必然正确的解法。
11. 知识地图，只承诺帮人找到下一步
企业需要在知识库和业务模型之外，增加一张 局部而动态、允许纠错的知识地图 。它可以指出相关材料、负责的团队，以及可能有帮助的人。本文讨论的专家路由，是这张地图中的一部分。
它不承诺穷尽谁知道什么，只承诺：在这个场景、这个时间，有哪些值得尝试的下一步。
一条路标可以来自经授权的工单和项目记录，也可以由员工主动维护。推荐时说明依据与最近确认时间，允许本人拒绝、纠正，也可以转派或退出；没有人响应时，还要有团队入口和升级路径。路由失败也应反馈给维护者，过期的路标就该撤下。
一张局部索引，可以在不完整的情况下发挥作用，也可以在使用中不断修正。 地图的价值在于减少下一次寻找的成本，而非证明企业已经被完整理解。
本体可以为这张地图提供人员、项目和技能的关系模型，但它不等于专家路由；专家路由也不要求一定先建本体。共享索引可以集中部署，判断和维护则可以留在更接近现场的人手里。
12. 把知识系统做成路由，也做成闭环
第一步，从一个高摩擦场景入手。挑一类反复特批的订单，或一类重复发生的故障，查清绕行究竟来自材料遗漏、规则不当、系统障碍，还是实践经验或违规行为。先找到原因，再决定补文档、改流程，还是训练人员或增加建模。
第二步，把能稳定处理的部分接入执行。以逾期订单为例，先由业务核实什么情况下可以例外放行，再定义证据要求、审批人、额度，以及有效期与状态转换。Action 执行前检查当前状态和权限，防止重复放行；执行后核对外部系统是否真正生效，失败时有明确的重试、补偿或人工接管路径。审批通过不等于发货成功，按钮点完不等于业务闭环。这里说的是应当落实的工程要求，不能假设选了某个平台就会自动具备。
第三步，把需要判断的部分交到合适的人手里，同时保留责任边界。老王提供客户背景，不等于老王批准了信用例外；提供事实线索、给出专业建议、作出业务决定和执行操作，应当能区分各自的角色。最终决定应由有授权的业务负责人作出，不能用“系统推荐了老王”转移自己的决策责任。敏感问题经授权进入合适的小范围讨论，系统只记录处理所需的信息与决策依据，不必把人际细节公开贴在专家名下。
把人做成路标，也是在重新分配劳动、风险和权力。 老员工的经验可能构成个人议价能力，系统却要求他随时贡献、随时留痕。一旦失败，建议还可能被事后解释成承诺。没有配套安排，少说、迟答或只给标准答案，就会成为可以理解的选择。
组织因此需要明确的善意协作保护：在授权范围内，基于当时信息诚实提供建议，不因结果不佳就自动承担最终决策责任；故意隐瞒、越权操作和应尽职责，则仍须按既有责任制度处理。这需要落实为组织认可的规则，系统提示本身不能创造免责。
心理安全也不能只停留在口号上。Edmondson 对制造企业团队的研究发现，团队心理安全与学习行为相关；这支持我们重视提问、暴露不确定性和讨论错误的条件，但不等于任何免责或奖励方案都会有效。[18]
答疑与带教应有受保护的工时、负荷上限，并在声望、绩效或报酬中得到认可。认可的是帮助解决问题和培养他人的贡献，不能只按回答条数奖励；同时培养替补与共同处理能力，避免系统把所有请求都集中到同一个老王身上。
第四步，让每次处理回到系统。问题解决后，把核实过且获准共享的部分补入文档；重复例外经过评估后，形成带条件、责任人和失效日期的规则；依赖实践的部分进入带教；仍然不确定的判断保留情境与适用范围，不能因为成功过一次就升格为标准答案。在复杂情境中，小规模尝试也要事先约定观察信号、损失边界与停止条件。
第五步，用结果决定是否扩大。先留出当前基线，再观察解决时间、专家推荐是否相关、实际错误与返工、动作执行结果，以及专家负荷和敏感信息暴露情况。既看已经转给人的问题，也抽查那些系统直接答完、无人追问的问题，才能发现被流畅回答遮住的缺口。出现越权或错误放行，应能暂停相应自动动作；错误率与负担上升，就先修正，不能只拿处理速度证明成功。
暗知识并不是知识库的原罪，也不是一切非正式做法的通行证。把它们分清，知识系统才能知道哪些应该记录，哪些可以执行，哪些需要共同判断，哪些必须停止。
回到开头那句话：“这个文档里没写。”有时候答案是把文档补上；有时候答案是修正一条规则；有时候需要让一位熟悉现场的人参与；还有时候，最负责的做法是承认系统不知道，并说明下一步由谁接手。
知识库的成功，在于遇到缺口时，能不能把问题带到正确的下一步，并确认那一步真的走完。
13. 资料与注释
以下资料支持文中的概念界定与理论转述；两处工业场景为原稿情境的示意性改写，并非经独立核验的企业案例。工程与组织治理措施是本文提出的设计建议。
- Hinton、Vinyals、Dean，《Distilling the Knowledge in a Neural Network》，2015。这里只用于区分机器学习与组织管理语境。
- Frederick W. Taylor，《The Principles of Scientific Management》，1911。
- 哈佛商学院 Baker Library，霍桑实验历史档案，说明人际关系学派的影响及实验解释争议。
- Chester I. Barnard，《The Functions of the Executive》，初版 1938；参见第九章关于非正式组织的讨论。
- Michael Polanyi，《The Tacit Dimension》，初版 1966；链接为再版介绍。
- Ikujiro Nonaka，《A Dynamic Theory of Organizational Knowledge Creation》，1994。
- Dave Snowden，《What We Cannot Say》，2026-05-08；该观点不代表所有知识管理研究者。
- F. A. Hayek，《The Use of Knowledge in Society》，1945；本文对企业知识地图的讨论属于延伸应用。
- Ronald H. Coase，1991 年诺贝尔奖演讲；本文对检索、核验和信任成本的划分属于应用分析。
- James M. Buchanan，1986 年诺贝尔奖演讲；企业项目激励分析属于类比。
- Thomas R. Gruber，《A Translation Approach to Portable Ontology Specifications》，1993；另见本体定义说明。
- Palantir 官方文档：Ontology 概述、Action Types 概述、Action Rules。这是 Foundry 的产品能力，不是所有本体系统的定义。
- Palantir 官方文档：Submission Criteria。订单、放行与授信是本文配置示例，不表示开箱即用或跨系统原子性。
- Cynthia F. Kurtz、David J. Snowden，《The New Dynamics of Strategy》，2003；术语还参见Cynefin 框架应用说明。
- Dave Snowden，《7 Principles of Intervention in Complex Systems》，2012。
- 《庄子·天道》轮扁斫轮一节；关于带教与知识系统的推论属于本文阐释。
- Karl Popper，《The Poverty of Historicism》，第 21、24 节；这里借用方法论，不作为软件项目的直接证明。
- Amy Edmondson，《Psychological Safety and Learning Behavior in Work Teams》，1999；不能用该研究直接验证本文提出的工时与责任安排。
证据边界：第 2–6、8–10、14–18 项帮助界定概念或讨论组织问题；第 11–13 项主要说明 Foundry 的产品机制。没有一项直接测量本文提出的专家路由或业务闭环在特定企业的效果。真实复盘还需得到授权的工单、动作日志、审批结果和对照基线。
14. 原文来源
原文发表于微信公众号“中老年叨叨”（2026年9月25日 09:05）。查看微信公众号原文。