知识不在系统里，在人脑里
预算批了，工具买了，账号开了，供应商也来演示了两轮。三个月以后，企业回头看，发现 AI 其实并没有真正接手任何一件事。
这个现象有个真实的原因，但管理者往往最后才想到它。不是模型不够强，不是员工不愿用，而是 AI 根本不知道这家公司的工作是怎么运转的。它不知道你们的退款审批有几道例外，不知道销售主管是怎么评估一个候选客户的，不知道为什么某类合同给了折扣而另一类没给。这些东西不在系统里，不在文档里，也不在任何 AI 能读到的地方——它们在员工的大脑里，在微信记录里，在"老李跟你说过的那些话"里。
YC 在 2026 年的 Request for Startups 里把这件事说得很直接：AI 转型最大的堵点不是技术，是"domain knowledge"——每家公司都有关键的工作 know-how，但它们散落在邮件、工单、Excel 和每个员工的大脑里，AI 根本读不到这些东西。
Tom Blomfield——Monzo 联合创始人，后来加入 YC 担任合伙人——把解决方案叫"公司大脑"：一套把知识从碎片来源里提取、结构化、持续更新、变成 AI 可执行的技能文件的系统。不是静态文档，而是一张关于公司如何运作的活地图：退款怎么处理，定价例外怎么决策，工程师怎么响应事故。他把这个判断说得很直接——没被记录的，对 AI 来说就不存在。老员工凭经验知道某类客户不能给超出一定幅度的折扣，凭经验知道某个候选人跟团队气场不合——这些判断若只存在于直觉里，对 AI 来说是一片空白。不是 AI 不行，是 AI 没有原料可以学习。
这不是一个轻松的问题。提取员工的工作 know-how 分三层：技术层是怎么把隐性知识转变为机器可读的结构；方法层是哪些节点值得提取，怎么按优先级做；博弈层是员工有没有动力配合，组织有没有给出合理的激励机制。三层都不解决，公司大脑就停留在概念层，或者更糟——得到一堆表面整洁但核心知识被掏空的废数据。
组织 AI 学习能力的上限，等于组织的记录能力上限。这是 YC 提出的判断，也是今天每一个认真做 AI 转型的管理者迟早要撞上的墙。先看清这道墙，才知道接下来要拆的是什么。
管理者的检查动作：这周，在你的团队里找一个最会干活的人，问他一个问题——"你做这个判断的时候，有没有被记录进任何系统？"如果答案是否，你就找到了公司大脑的第一个空白。
know-how 是什么，为什么最难提取
管理者在说"提取员工经验"的时候，"经验"是个太模糊的词，模糊到让提取工作从一开始就走偏。
房晟陶在《首席组织官》里把员工知识拆成三层，将其应用于组织场景（这套 know-what/how/why 分类更早见于 OECD 1996 年知识经济报告及哲学传统中"知道是什么"与"知道怎么做"的区分，房晟陶将其引入组织管理实践）：Know-what——知道是什么，知其然，偏知识、信息和见识，是认知的基础和起点。Know-how——知道怎么做，偏技能，偏工程实现，与经验高相关，是实现结果的关键。Know-why——知道为什么，知其所以然，偏原理和信念，是演绎和创新的关键。
三层之中，Know-how 最难学、最难传、也最难被机器直接复现。Know-what 可以靠阅读和记忆习得，Know-why 可以靠推理和总结得到，但 Know-how 不行——它与长期实践高度相关，没有走过足够多的路，直接给你看再多资料也形成不了。面试官判断候选人靠不靠谱，不是靠看了几本招聘教材，是靠评估了几百个人之后形成的模式识别。这种东西，没有办法"教"，只能"做过"。
在组织场景里，Know-how 还有一个额外的难度：可转移性极弱。同样一套绩效管理方法，在一家公司能跑通，换了文化差距大的组织就失效。不是因为这个方法错了，而是组织 Know-how 本身就嵌套在具体的情境里，离开这个情境，Know-how 就失去了它的工作条件。
这解释了为什么"把文档沉淀好就行了"这个思路行不通。文档沉淀的主要是 Know-what——规则、流程、政策。Know-how 很难用文档描述清楚，因为它的核心是"在这种情况下，凭经验判断应该怎么做"——这里面的情境依赖、经验积累和判断逻辑，是文字很难完整传达的。
这里有一个关键转折，是 AI 带来的。生成性 AI 大幅降低了 Know-what 和 Know-why 的获取门槛——你不需要读完所有原理书，模型帮你总结；你也不需要想清楚所有背后的逻辑，AI 给你推导。Know-what 曾经是资深员工的优势，现在已经开始被 AI 平权了。但 Know-how 不行。真正的组织判断力，仍然嵌套在经验里，仍然需要实践检验。
AI 没有消灭 Know-how，而是把它的稀缺性抬得更高了。这是本篇立论的哲学基础：提取 Know-how 之所以重要，不只是因为它散落在个人身上，还因为在 AI 时代，它变成了组织里越来越稀缺的那部分——是人比机器多出来的真实资产，是机器最难直接复制的东西。正因如此，它也变成了最值得被结构化、被保留、被传递的东西。
对管理者的意义：在设计知识提取机制之前，先区分你要提取的是哪一层知识。如果提取的主要是 Know-what（流程、规则、政策），做一个结构化文档库就够了。如果要提取 Know-how，需要的是不同的方法——不是让员工写手册，而是把他们的判断结构显性化，让机器能够学习"他们在什么情况下、凭什么做出这个判断"。这两件事的差距，比大多数管理者预期的要大得多。
提取从哪里开始——流程分解，找到判断密度最高的地方
知道了要提取 Know-how，接下来的本能反应是"找那个最资深的员工来做访谈"。但这个动作大概率会白费力气——不是员工不愿意说，而是你根本不知道该问什么。
提取 Know-how 的第一步不是访谈，不是培训，也不是让员工写经验总结。而是把工作流程拆开看：这个岗位的工作由哪几个阶段组成，每个阶段需要什么类型的判断，哪些节点是知识密度最高的地方——只有先回答这些问题，你才知道该去提取什么。
这里有一个反直觉的发现：AI 最容易介入的节点，往往不是员工知识最有价值的节点。信息查询、标准化回复、表单填写——这些环节 AI 可以高效接管，但员工在这里积累的所谓"经验"，价值并不高。真正值得提取的 Know-how，藏在那些高复杂度、高风险、低标准化的节点里——判断一个异常情况该怎么处理，评估一个边界案例该走哪个通道，在矛盾信号里做出取舍。那里，AI 介入潜力最低，但人类判断的浓度最高。
这意味着提取工作的优先级应该颠倒过来：最难自动化的地方，往往是最值得结构化的地方。
用任务复杂度、风险等级、标准化程度三个维度来分析每个流程节点，可以得出大致判断：低复杂度、低风险、高标准化的节点，AI 介入潜力高，但 Know-how 提取价值低；高复杂度、高风险、低标准化的节点，AI 介入潜力低，但恰恰是员工 Know-how 最集中的地方，是提取工作最值得花时间的地方。
一个实操建议：在开始任何知识提取项目之前，先做一张流程图，把这个岗位的工作节点全部列出来，然后逐节点回答两个问题——这个节点今天有没有被 AI 处理？这个节点处理出错的后果有多严重？凡是"尚未被 AI 处理 + 出错后果严重"的节点，就是 Know-how 密度最高的地方，也是提取工作最应该优先投入的地方。
管理者第一动作：拿出你最想让 AI 接管的岗位，把它的工作过程拆成五个以上的节点，然后逐节点问：如果 AI 在这里出错，谁负责，后果多严重？凡是你答不出来的节点，就是这个岗位的 AI 转型风险最高的地方。
把 know-how 写进 Agent——不是写手册，是显性化判断结构
找到了 Know-how 的高密度节点，接下来的问题是：怎么把它变成机器能学的东西？
大多数管理者在这里做的事情是访谈——让资深员工开会讲，让 HR 记录，整理成经验手册或培训材料。这条路不是不能走，但效果有一个根本性的上限：手册能捕获 Know-what，很难捕获 Know-how。员工能描述自己做了什么，很难完整描述自己为什么这么判断，以及在哪些情况下会判断得不一样。
把 Know-how 结构化为 Agent，需要的不是让员工写手册，而是把他们的判断结构显性化。一个完整的 Agent 身份定义需要八个模块：它相信什么（行为锚点）、它管什么不管什么（职责边界）、遇到典型情况它怎么决定（if/then 规则）、它的推理步骤是什么（思维框架）、什么算低质量输出（质量直觉的显性化）、工作流程是什么（可交付物的流向）、如何持续改进（成长机制）、以及跨场景可迁移的底层能力有哪些（元技能）。这八个模块对应的不是功能列表，而是一个人的判断结构的全部重要切面。
最重要的不是"这个人知道什么"，而是"这个人面对模糊情况时怎么选，遇到矛盾要求时如何取舍"。判断结构可以训练，泛泛的经验不行。把员工经验固化为 Agent，最大的陷阱就是把"知道很多"当成了 Know-how——前者可以用文字堆满，后者只有在判断结构被写清楚以后才真正完成了转化。
提取流程可以拆成四个阶段。领域边界发现：这个人的专业判断集中在哪几块，他最拿手的那类决策触发条件是什么，覆盖的情境有多宽？按需设计：根据这个岗位是否涉及写操作、跨会话记忆、多方协作，确定 Agent 身份设计的侧重点。检验深度：把这个 Agent 的名字换掉，如果换了别的名字它的身份定义还成立，说明它没有真正捕捉到这个人的独特判断，只是在描述通用职能——不成立才算捕捉到了领域深度。验证可用性：独立、足够小、边界清晰、可替换、可复用——五条标准缺一不可。
两年前我开始系统性地把自己的判断写进我自己搭的一套多 Agent 知识生产体系。每次犯了一个错，我不是写反省笔记，而是把它整理成一条可以调用的规则——用机器能读懂的方式描述触发条件、本质和反制机制。积累到今天，这些规则已经形成了一套规则库，变成了所有 Agent 启动时的底层约束。这不是知识库，这是工作过程数据化的实践。
我自己也做过一次有代价的验证：某组织的一个 AI 项目里，组织写了 20 个 Agent 岗位说明，但实际在线运行的只有 1 个。问题不是技术问题，是写了 Agent 的"职位描述"，但没有写进判断结构——大多数岗位是写完没插电的描述，不是能运作的 Agent。这个差距，管理者在验收时往往看不出来，因为文档看起来都很完整。
判断结构可以训练，文档描述不能。这是把 Know-how 变成 Agent 和把 Know-how 写成手册之间最本质的区别。
管理者第一动作：找你最想固化的那个员工的核心判断，用以下四句话描述它：他通常在什么触发条件下做这个判断；他会优先考虑哪些因素；他认为什么样的输出算及格；哪些情况下他会破例。如果你能回答这四句话，你就完成了把 Know-how 结构化的第一步。如果回答不了，说明你的知识提取还停在 Know-what 层，还没有真正触到 Know-how。
博弈层——员工为什么可能不配合
讲到这里，技术路径是清楚的：找到高密度节点，把判断结构显性化，按照八个模块写进 Agent 身份。如果这一切只是技术问题，那就好办了。
问题是，Know-how 不是散落在一个没有意志的系统里，而是散落在有想法的人身上。
2026 年，GitHub 上出现了一个叫"同事.skill"的开源项目，核心功能是把一个同事的工作方式、判断模式、处理风格提炼成 AI 可以学习的技能文件。这个项目在 GitHub 上已积累破万 star——这个关注规模说明，把同事 know-how 提炼成 AI 可用文件的需求，不是个别人的异想天开。
但在同一段时间，GitHub 上还悄悄出现了另一个项目：反蒸馏 Skill。它的核心功能是把员工自己的 skills 文档输出成"看起来完整专业、实际上核心知识已被抽掉"的版本，保留私人备份。这个项目的开源说明，关于保护自己判断资产的需求，已经有人在用代码回答了。
同一平台，同一时期，两个方向相反的工具同时开源——一个在提取，一个在防提取。这不是偶发现象，是一个真实的组织信号：当技术能力让 know-how 的提取变得可行时，员工已经开始在保护自己的利益了。
这不是员工对 AI 的反抗，也不是员工不愿意贡献知识。反蒸馏工具的出现，是在没有合同保护时的自助防御——如果贡献了 Know-how，AI 学会了，组织受益了，但员工的岗位价值下降了，没有任何机制保障他因为贡献而获益，他为什么要贡献真货？
这里有一个简单但冷酷的逻辑：员工 Know-how 贡献的质量，取决于他相信这件事对自己有利的程度。高信任、有收益设计、有透明边界的情况下，员工会贡献高质量的判断结构——真正能让 AI 学到好东西的那种。低信任、无契约保护、收益不透明的情况下，员工会学会掺沙——表面上写了一堆看起来很完整的经验总结，但核心判断已经被悄悄抽掉了，保留在系统之外。组织得到的是高质量形式、低质量内容的数据噪音。AI 学了个寂寞。
Know-how 提取不只是技术工程，也是信任工程。你能不能得到真实的 Know-how，不取决于你用了多好的提取工具，而取决于员工是否相信贡献这件事对他有利。技术解决的是"怎么固化"，但没有解决"员工为什么愿意贡献高质量的"。
管理者在这里最常见的失误，是把博弈层当成沟通问题来解决——多开几次培训，多讲讲 AI 的好处，让员工"转变观念"。但观念不是问题，利益结构才是。如果员工贡献 Know-how 的实际后果是让自己的不可替代性下降，而组织没有对应的收益设计，那么任何沟通都只是拖延战术。
管理者第一动作：在启动知识提取项目之前，先回答这个问题：如果员工把最核心的判断交出来，他能得到什么？如果你回答不了这个问题，你的提取项目就还没有建好运作条件。
提取什么、留什么——注入度与判断剩余框架
就算解决了信任问题，管理者还面临另一个实操难题：即使员工愿意配合，你也不知道该优先提取什么。
我用两个维度分析员工 Know-how 的提取优先级。
第一个维度是注入度——这个员工每天向系统贡献了多少工作过程。每次他写一条规则、做一个案例批注、把失败原因记录下来、为一个流程建检查表，这些都是注入。注入度高的员工，每天的判断在持续转化为系统可以学习的结构；注入度低的员工，他的判断全部存在大脑和个人沟通记录里，对组织的 AI 系统来说是一片空白。
第二个维度是判断剩余——AI 跑完这个环节之后，这个员工仍然需要做的那部分判断有多少、有多难。有些工作环节 AI 接管以后，人几乎不需要再介入；有些工作环节，无论 AI 多强，最后的决定权还是在人这里——因为那里的判断涉及价值取舍、风险承担、客户关系或政策边界，这些东西机器可以辅助但不能替代。
这两个维度决定了提取的方向：优先提取注入度高的工作过程，优先保留判断剩余高的岗位片段。
用这两个维度做一个四象限分析，就能给出大致的处理方向：
注入度低、判断剩余低——AI 替代最自然发生，提取优先级最低。
注入度高、判断剩余低——Know-how 提取价值最高的地方，有大量可学习的过程数据，提取后可以让后续的 AI 跑得更好。
注入度高、判断剩余高——"提取 + 人升级"的区域。提取让 AI 能理解背景和上下文，但决策权保留在人这里，人在更好的信息支持下判断。
注入度低、判断剩余高——最复杂。员工的判断价值很高，但工作过程从来没有被系统记录。这里需要的不是立刻提取，而是先激励这个员工开始把判断写进系统，让注入度先提高，再谈提取。
员工写下来的规则、案例、检查表、失败复盘，如果只是散落在文档里，就还是旧知识库。组织要把它们视为可复用资产：谁贡献的，贡献给哪个流程，被调用了多少次，修正过哪些错误，带来什么质量变化。这是让"注入度有资产记录"的具体操作——也是让贡献 Know-how 对员工有利的最直接机制。
注意：这两个维度是分析工具，不是证明过某种效果的公式。它们帮你做的是排序——先提取什么，后提取什么，什么暂时别提取——不是承诺提取以后 AI 学习质量一定提高多少。
管理者第一动作：拿出你团队里最核心的两三个岗位，逐一问两个问题：这个人今天每天的工作有多少比例被记录进了系统（注入度）？AI 全面接手这个岗位之后，还有哪些判断必须由人来做（判断剩余）？用这两个问题给岗位排序，注入度高且判断剩余高的岗位，是 Know-how 提取的第一优先级实验场。
提取到尽头是什么——接力一个没被正面回答的问题
到这里，本篇的论证链已经走完了一个完整的弧度：散落的 Know-how 是 AI 转型的真堵点，提取它需要先做流程分解，需要把判断结构显性化写进 Agent 身份，也需要解决员工为什么愿意配合的信任问题，还需要一个优先级框架来决定提取什么、保留什么。
但这个论证还有一个更高的维度没有触碰：为什么这一切是不可回避的？
Daniel Miessler 在 2024 年的一篇技术博客里，把这个逻辑推到了一个极强的版本。他写道，"公司不过是一堆算法的集合"——这是他的基础命题。另一处他写到，"不管产品多特别、公司多独特，它运作的方式依然是一条一条的步骤管道"。还有一句他说得更狠："可解释性，是新的货币。"他的意思不是 AI 会替代人，而是 AI 带来的流程透明化，会让每一个工作步骤的算法逻辑都暴露出来——包括那些一直藏在员工大脑里的隐性判断。这个过程不是你选不选择发生的，而是 AI 进入组织以后它就开始发生了。
这个判断是对的，而且它的力度比大多数管理者想的要强。员工长期赖以不可替代的那层隐性判断，会被一一还原成算法图谱上的节点。这是 Know-how 显性化压力不可回避的深层逻辑。
Miessler 的分析是对的，我充分承认这一点。但他在文末留了一句话，说打算在后续文章里聊——"这个模型里，哪些人类工作我认为可能留下来"。在我读到的后续文章里，没有一篇正面回答这个问题——包括"The End of Work"里他写"理想的员工数量是零"，"The Bubble Is Labor"里他论证连雇佣本身都将趋向消失。他能把算法图谱吞噬一切论证到底，却始终没给出那个正面答案——什么工作会留下来，留给谁，凭什么留。
我想接的，正是他回避的那个空白。
留下来的，不是"某些工作"，而是算法图谱永远画不出来的那个节点——判断。
Know-how 显性化压力是真实的，流程显性化是一个结构性趋势，员工的隐性 Know-how 面临越来越强的显性化压力——这些他都说对了。但他没有说的是：提取到尽头，不是空无一人。是人退到了另一个位置，一个算法图谱天然画不出来的地方。那里放的是：面对不确定时的取舍，没有标准答案时的选择，以及不应该让机器替你做的决定。
这不是一个技术局限，也不是一个暂时的过渡状态。这是分工的终点：AI 做流程，人做判断。
提取了 Know-how，不是为了让人消失，而是为了让人的角色变得更清晰——从用时间完成流程，变成用判断力把关结果。这个转变，是理解"人在回路中"命题的基础，也是整个 AI 时代组织重写的核心。
这周先做三件事
知道这些还不够。管理者的问题永远是：下周先做什么？
找到注入度高的岗位。 在你的团队里，谁的工作过程已经在系统里留下了最多记录？每天的 prompt 记录、批注记录、操作日志、案例库——哪个人、哪个岗位，今天积累得最多？那就是注入度最高的地方，也是 Know-how 提取的第一优先级。不是最资深的员工，是在系统里记录最多的那个人或那个流程。
检查数据契约空白。 你的团队里，员工在向 AI 工具输入判断、贡献工作过程的时候，有没有人明确告诉他们：这些数据属于谁、会被用来做什么、他们会因为贡献而得到什么？如果没有，这就是数据契约的空白。空白不等于没有风险，等于风险被掩盖了——员工不知道自己的知识被用来做什么，掺沙的动机就会在某个时间点被触发。在这里主动说清楚，比事后处理信任危机要容易得多。
做一个有主权的提取实验。 不是全面铺开，不是给所有岗位都做知识提取。先找一个愿意配合的、判断价值高的员工，和他一起做一个小实验：你们共同决定哪些判断值得提取，你们共同确认提取以后这些数据怎么用，他的贡献会在什么机制下被看见和认可。然后把这个过程记录下来，看员工的反应——他愿不愿意，他贡献的质量如何，他觉得这件事对他有没有价值。这个实验的结果，比任何关于知识管理的理论讨论都更有参考价值。
三个动作里，找注入度最好做，一周内可以完成；检查契约空白最关键，决定提取质量的上限；做实验最有学习价值，真正让管理者看见 Know-how 提取在自己组织里是什么样的。
Know-how 提取是技术工程，更是信任工程。信任不是靠讲道理建立的，是靠员工亲眼看见贡献这件事对自己有利建立的。先做实验，再谈推广。