07 员工 know-how 如何变成组织资产

07 员工 know-how 如何变成组织资产

预算批了，工具买了，账号开到每个人头上，培训也做了两轮。

三个月以后，老板在会上问了一句：那业务为什么没变快？

这个场面在上了 AI 的公司里反复出现，荒诞，但很常见。

表面看，是员工不会用 AI。再往下看，不是。

真正的问题是：AI 不知道这家公司是怎么工作的。

它不知道退款审批里有哪些例外。不知道老销售为什么对某类客户特别谨慎。不知道招聘那边的人看到一个候选人的履历，为什么会皱一下眉。也不知道运营负责人为什么在某个时间点，就是不敢加投放预算。

这些东西不在系统里，不在流程文档里，也不在知识库里。它们在人脑里，在聊天记录里，在老员工一句“这个事以前出过问题”里。

员工用了 AI，个人可能变快；但这些判断没有沉下来，组织不会变聪明。

这就是 AI 时代的知识断点。

不是没有知识库，是没有组织记忆

很多老板一听知识断点，第一反应是：那就建知识库。

这个反应太轻了。知识库通常装的是文档、制度、流程、FAQ、历史材料，解决的是“东西在哪里”。

但组织记忆解决的是另一个问题：

这家公司以前怎么判断、怎么犯错、怎么修正、怎么在下一次避免同样的问题？

要回答这个问题，靠的不是文档堆积，是判断沉淀。

YC（Y Combinator，硅谷那家孵化了 Airbnb、Stripe 的创业营，每年公布一份“我们想投什么”的清单）在 2026 年的创业方向清单里，把一个方向叫 Company Brain——公司大脑¹。讲的是把企业里散落的 domain knowledge，也就是这家公司专属的业务门道，抽出来、理清楚、持续更新，让 AI 能读懂公司到底怎么运转。这个判断很有启发。但放到一家开了二十年的传统公司里，还要再往前问一步：

你公司里的这些门道，员工愿不愿意交出来？

员工不交，AI 读不到。员工只交表面材料，AI 学不到。员工走了，经验跟着一起走。每个人都只把 AI 用在自己账号里，组织拿到的就不是组织记忆，是一堆孤岛。

每个员工都有外挂，公司却没有大脑。

所以先别急着批知识库预算。先想清楚：你要的是一个装文档的柜子，还是一套记得住判断的系统。这两件事的成本、周期、阻力完全不一样。

know-how 不是文档

说 know-how，先别把它神秘化。它就是“这个人知道怎么做”，但这个“怎么做”，通常说不清。

Polanyi（波兰尼，最早把“隐性知识”这个词讲清楚的哲学家）讲隐性知识时有一个核心意思：人知道的东西，常常多于他能说出来的东西²。他举的例子是认脸——你能从一百万张脸里认出一个人，却说不出你是怎么认出来的。日本学者 Nonaka 和 Takeuchi（野中郁次郎和竹内弘高，研究日本企业为什么能持续出新产品）后来讲组织知识创造，也把隐性知识和显性知识的转换放在核心位置³。OECD（经合组织，发达国家的政策研究机构）在讨论知识经济时，还区分过 know-what、know-why、know-how、know-who 这几类知识⁴。

这几类知识落到公司里，就是三句话。知道制度叫什么，是 know-what。知道为什么这么设计，是 know-why。知道遇到具体情况该怎么处理，是 know-how。AI 最容易读到前两类，最难读到第三类。

比如招聘。流程可以写成文档，面试题可以放进系统，岗位要求可以列成表格。但一个做了十年的 HR，看一眼就知道这个候选人跟团队气质合不合。他能看出这个人是不是短期漂亮、长期有风险。他还知道要人的那个业务老板，现在是真缺人，还是只是焦虑。这几件事，都很难写成标准答案。

再比如客服，系统里能查到订单、价格、售后政策。但一个老客服知道某个高价值客户现在最在意的是效率还是情绪，知道这个投诉该硬按规则还是先稳住关系，这些也不是一条 FAQ 能装下的。

know-how 的难点不在“知道”，在“情境”。离开情境，经验就失真。

这就是为什么很多企业做知识库，最后越做越像资料库。资料越来越多，真正能帮新人做判断的东西没多少。

有人会问：这么难提，那能不能干脆别提？

不能。技术博主 Daniel Miessler（长期写 AI 与安全的独立作者，读者以工程师为主）在 2024 年写过一篇文章⁵，把这件事推到了极致。他说公司说到底就是一堆算法的集合，不管产品多特别、公司多独特，它运作起来还是一条一条的步骤管道。他还有一句更狠的：可解释性是新的货币。他的意思很直白——一旦 AI 能看见公司每一步是怎么走的，它就会挨个识别里面的冗余，然后把冗余消灭掉。这是个人博客的判断，不是研究结论，但方向不难感受到。

员工的隐性经验不宜只靠“别人看不见”来守。它像一间暗室：哪些判断能被照亮、记录、复用，要放到具体工作里试，不能先假定所有灯迟早都会亮。

即使更多判断能被提取，人还剩什么？Miessler 在文末说，后面会专门写哪些人类工作能留下来。他在另外两篇文章里继续推演压缩人类用工的可能⁶。这里不替他全部的后续写作下结论。我更想往组织里追问：任务交出去了，决定权和后果交给谁？

这本书不靠圈出几个“AI 永远做不了”的工种来回答。AI 可以参与判断，但能给出判断，不等于已经获得拍板的授权。经验能被提取，责任不会跟着自动转移。

所以这一节你回去只做一件事。拿你手上最依赖某个人的那条流程，问自己一句：这个人明天不在了，接班的人能不能从系统里看懂他当时是怎么判断的。答不上来，这条流程就是你的第一个提取对象。

提取从流程节点开始

提取 know-how，不是先找最资深的人做访谈。访谈当然有用，但它不是第一步。第一步是拆流程。

你要先问自己几句话。这条流程里，哪几个节点最依赖人的判断？哪几个节点出错代价最高？哪几个节点最难标准化？哪几个节点新人永远学得慢？

这些地方，才是 know-how 密度最高的地方。

AI 最容易接走的，往往不是组织经验最值钱的地方。

信息查询、格式整理、标准回复、数据汇总，AI 很快能做。但这些地方沉淀的经验，往往价值没那么高。

真正值钱的地方，是那些高复杂度、高风险、低标准化的节点。

比如：

• 异常订单到底该不该升级；
• 一个客户投诉到底是情绪问题还是规则问题；
• 一个候选人到底是能力不够还是组织不适配；
• 一次投放数据异常，到底是内容问题、渠道问题，还是节奏问题。

这些节点，才是组织判断的矿。

所以管理者第一步不是“让大家总结经验”。

第一步是画出流程节点，然后标出三件事：复杂不复杂，出错代价高不高，能不能标准化。

复杂、代价高、又很难标准化的地方，就是最值得提取的 know-how。

标完这三件事以后，可以先分出优先试用的候选节点，和需要重点核查的节点。这是排查顺序，不是两块永久的安全区与危险区。

优先试用的候选节点，通常有五种形态：初稿生成、信息整理、标准化判断、复核辅助、异常识别。

把空白页先填出来，是初稿生成。把散在几个地方的材料归并成一份能拿来判断的东西，是信息整理。在规则已经写清楚的地方做初筛，是标准化判断。帮人发现遗漏、冲突和风险点，是复核辅助。比如一份客户合同发出去之前，先把付款条件和交付时间跟上一版对一遍，对不上的地方标出来给人看。把不正常的情况提前拎出来，是异常识别。

这五种形态说的是工作内容，不是安全等级。初稿若只供讨论，和直接变成客户承诺，不是一回事。要靠后续复核挡住错误，复核者就得有信息、有时间、有权限，来得及在结果被依赖前纠正。人排在后面，不等于错误就被挡在前面。

很多公司只想到第一类，以为 AI 进流程就是“帮我写个初稿”。其实后面四类的组织价值往往更高，尤其是复核辅助和异常识别。它们不产生新东西，但它们让人的注意力落在该落的地方。

再看需要重点核查的节点。它们往往不是明显做不了，而是动作看着简单，后果容易被漏看。

对外承诺、客户赔付、员工评价，都要点名核查。不是给整个领域贴一张“必须人审”的标签，是看清具体动作会改变什么。

写一封回复、算一笔金额、给一个评分，形式上都像可以自动化。但草拟、发送和直接生效，是不同节点。客户已经据此作出安排，员工已经受到影响，再改系统里的一条记录，未必能把后果一并改回去。能否恢复，要核路径和剩余影响，不能只看有没有撤销键。

AI 可以参与这些工作，组织不能把责任一并交给它。超出授权、需要新取舍的事项，由有权者事前决定；规则内的固定动作能否自动执行，要看具体限制，以及控制和后果承接是否经过验证。第十一章会把这些条件拆开。不能因为涉及赔付就一律要求人按，也不能因为金额小就直接放行。

管理者在这一步要追的是后果路径：这个输出会被谁使用，在哪一步影响决定，错误靠什么发现、阻断或处置？后果会跑出流程，要查；留在内部，也要查权限、敏感信息和累积损害。条件没核清，先不要接进真实运行。

这张初筛图不是上线许可。它先把需要补证据的地方摊开，后面才知道该提取什么、验证什么。

举一个脱敏场景。

一家制造企业原来有大量维修知识，散在老工程师脑子里、外采配件说明书里、历史工单里、图片和视频材料里。前线维修人员到客户现场，碰到复杂问题，经常还要打电话回总部问。

表面看，这是客服和维修效率问题；往下看，这是组织记忆问题。

因为真正影响现场处理速度的，不只是“有没有说明书”。是老工程师脑子里那几条经验：哪些故障看起来很像、其实原因完全不同。哪些配件说明书写得很完整、但现场条件下不能照搬。哪些问题应该先排查最简单的那一项，哪些必须立刻往上升级。

如果只是把资料丢进知识库，新人还是不会判断。

如果把历史工单、维修步骤、异常处理、老工程师的排查顺序、总部支援记录一起结构化，情况就变了。前线人员不只是搜到资料，更能看到过去类似问题怎么被判断、怎么被修正、最后怎么解决。

这才是组织记忆。

这类项目一旦跑通，第二条流程会更快。因为你已经知道怎么拆资料、怎么标注判断、怎么处理权限、怎么让一线使用、怎么把新问题写回系统。第一个流程沉淀的不是一套资料库，是一套组织学习的方法。

所以这里要讲的不是“建知识库”，是把一次次工作现场里的判断，沉淀成下一次能直接调出来用的上下文。

你回去先画一张图就行。挑一条最要紧的流程，把节点一个个列在纸上，每个节点后面标三件事：复不复杂、错了亏多少、能不能标准化。再沿着输出往下追：谁会依赖它，权限够不够，错了靠什么拦、谁来处理。能确认的写依据，不能确认的留缺口。一张纸先把问题摊开，不拿它替上线签字。

不是写手册，是写判断结构

找到高密度节点以后，下一步不是让老员工写一份经验手册。手册能写出流程，却很难写出判断。

员工最容易写出来的是：“遇到 A 情况，按 B 流程处理。”

但真正值钱的是：“为什么这次 A 情况不能按 B 处理，而要先看 C 信号。”

把 know-how 变成组织资产，要写的是判断结构。

一个判断结构，至少要说清四件事：

第一，触发条件。什么情况出现时，需要启动这个判断？

第二，判断依据。这个人优先看哪些信号？哪些信号容易误导？

第三，质量标准。什么样的输出算及格，什么样的输出只是看起来完整？

第四，例外处理。哪些情况要破例，破例以后谁复核？

这四件事写清楚，AI 才有可能学到“这个组织怎么判断”。

否则你喂给 AI 的只是资料。资料不是能力，只有进入判断结构，才可能变成组织能力。

我搭建一套内部多 Agent 协作与治理原型时，最早也踩过这个坑。开始以为把资料放进去，系统就会变聪明。后来才知道，真正让它稳定下来的，是把现场问题捕捉下来，把判断结构化，经过复核固化为规则，沉淀成可回用的案例，再在下一次任务里调用。把犯过的错、判断的触发条件、反制规则和复盘结果写成可调用的规则，这一步是结构化，不是反省。

这件事做久了，才会出现变化：下一次遇到类似问题，不再靠我临场想，是系统先把过去的判断拿出来提醒我。

这才叫组织记忆的雏形。

所以别让老员工写手册。让他坐下来，就那一个高密度节点，把前面四件事写满一页纸。一页纸比一本三十页的手册管用。

员工为什么愿意贡献真东西

讲到这里，技术路径大概清楚了，但最难的地方不是技术。know-how 不在一个无生命的数据库里，它在员工身上。

员工会想：我把自己的判断交出来，是为了让组织放大我，还是为了替代我？

这个问题不回答，后面都不稳。

如果员工相信贡献 know-how 是一次组织偷袭，他不会贡献真东西。他会配合，但只配合表面。

他会写流程，不写关键判断；写原则，不写例外；写结果，不写真正的取舍。

组织最后拿到的是一堆很完整、很漂亮、但没什么用的材料。责任不在员工，在没有被设计过的机制。

这件事已经不是推演了。GitHub 上有一个项目，专门把同事的工作方式、判断模式、处理风格提炼成 AI 能学的技能文件，到 2026 年 7 月已有两万多个星标——这是提取那一侧。同一时期，另一个项目也悄悄开源了，名字叫“反蒸馏”。它干的事是：把员工自己写的文档，输出成一个看起来完整专业、其实核心判断已经被抽掉的清洗版，真东西留一份私人备份。这是被提取那一侧⁷。

一边有人写代码提取，一边有人写代码防提取。这不是员工在反抗 AI，是在“贡献了但没有收益”这件事上的自我保护。你不能说他错。你只能说，这家公司还没把新合同写出来。

新合同没写出来的时候，最难的还不是员工藏着不交。是有的人根本不接这份新合同。

这件事我自己遇到过。我们做交付的时候已经全线用 AI 了。我以前是做 HR 的，一行代码不会写，但我用 AI 自己开发、自己交付。团队里有一位资深程序员，背景很硬，比我懂工程。

我跟他说过很多次：执行让 AI 去做，你来做审核。公司出钱给他开了顶配的 AI 编程工具，一个月两百美金那一档。他不放心 AI 写出来的东西，还是坚持自己那套写法，开发速度慢下来。

我们看得到他的交付量，也看得到他的 AI 调用量。中间我和合伙人跟他谈过几次，也做过培训劝导，我甚至带着他一起开发。客户那边也表达了不满，觉得进展太慢。

后来逼到没办法，我和合伙人亲自下场，反而快了。

那一刻我才看明白一件事，而且看明白的不是他不行。他是资深程序员，对一个软件工程的节奏该怎么把控，判断非常好——那份判断力今天仍然值钱。问题是他没往这个方向用。他把它整个压在执行上，压在跟 AI 比谁写得快这件事上。

判断力没挪到该在的位置，于是从团队最值钱的资产，变成了团队的瓶颈。

他不改，我只能把他送走。我们觉得也挺可惜。同一段时间里，另一些资深程序员直接改了思路，把判断力留在手上，交付质量和速度一起往上走——他们活得更好。

员工贡献给组织 AI，不应该是为了替代自己，而应该是为了放大自己。这句话必须落到机制里，至少要做三件事。

第一，贡献要被看见。谁沉淀了高质量判断，谁修正了系统错误，谁让一条流程变稳定，这些贡献要能被记录。

第二，贡献要被认可。口头表扬不算认可，进入绩效、晋升、项目机会和角色升级才算。

第三，贡献要有边界。员工要知道哪些经验会被提取，提取后怎么用，谁能访问，出了问题谁负责。

没有这三件事，就不要急着做大规模 know-how 提取。

你提取不到真货。

提取什么，留下什么

即使员工愿意配合，也不是所有东西都要提取。

我用两个维度看这件事。

第一个维度叫注入度，就是这个员工每天有多少工作过程进入了系统，比如批注、规则、案例、失败复盘、判断依据、流程修正。

注入度高，说明他的工作正在变成可学习的组织材料。

注入度低，说明他的判断还在个人脑子里。

第二个维度叫判断剩余，就是 AI 做完以后，人还剩下多少必须亲自做的判断。涉及价值取舍、风险承担、客户关系、组织政治、员工评价的地方，判断剩余通常很高。

这两个维度组合起来，可以给管理者一个排序。

注入度高、判断剩余高的岗位，是最值得做“提取 + 人升级”的地方。

因为这些岗位既有可学习材料，又还有必须由人保留的判断。提取不是为了替代这个人。是让他站到更高的判断位置。

注入度高、判断剩余低的岗位，适合做流程自动化和知识复用。

注入度低、判断剩余高的岗位，不能急着提取。要先设计记录机制和激励机制，让关键判断开始进入系统。

注入度低、判断剩余低的岗位，才可能自然进入自动化替代。

这套划分与其说是公式，不如说是排序工具。它帮老板决定：先提取谁，先改哪条流程，先把哪类经验变成组织记忆。

你可以现在就试一下。拿你们最核心的那五个岗位，每个岗位在纸上打两个分：他每天有多少工作过程进了系统，AI 做完之后他还剩多少判断必须亲自做。两个分都高的那个岗位，就是你这个季度第一个要动的地方。

一个人离职那天，公司留下了什么

检验这一章的办法不用等到年底。一个人离职就够了。

他走的那天，公司到底留下了什么？

如果留下的只是他的账号、他的文件夹、他没交接完的几个客户，那么有三件事就摆在明面上了。

过去三个月他所有的高质量 AI 输出，都没有沉淀下来，他怎么用 AI 做判断，也没有被别人复用。他攒下的提示词、模板、检查表、复盘记录，一直是他的个人资产，从没变成公司的资产。他经手的客户洞察、项目复盘、异常处理，从来没进过一个统一的地方。

接他班的新人只剩一个办法——去问另一个老员工。因为除了问人，他没有别的路能拿到前人的判断。

前面那位资深程序员走的时候，反过来问了我一句：那套 AI 工具，能不能接着给他用。

公司掏钱让他用的时候他不用，离开了倒惦记上了。

这就是为什么下周开会时，“知识库建得怎么样了”是个太宽、也太容易被糊弄的问题。它问的是仓库大小，不是组织记性。

真正该往下追的是这几句。AI 输出有没有版本管理和质量标准？谁负责维护这些知识，而不是上传完就结束？这些知识有没有真的进流程，还是躺在一个没人打开的库里？员工贡献的判断，有没有被看见、被认可？

最后一问最狠，也最该由一号位亲自问出口：如果这个人明天离职，他最关键的判断资产，公司还能留下多少？

这些问题追的是同一件事——组织有没有变聪明。如果答案大多是否，说明公司在增强个人，不在增强组织。员工用 AI 越熟练，个人效率越高，但效率不进组织记忆，公司只会更依赖个人。这就是 AI 生产力悖论在组织里的样子：个人越来越强，组织没有累加。

老板要看的从来不是某个人一天省了几个小时。要看这个人的好判断，下一次能不能被别人拿去用。要看这条流程犯过的错，下一次会不会少犯。要看这个部门的产出，是不是更稳、更多、也更说得清楚。

第一刀落在哪个节点上

真要动手，第一刀落在一个流程节点上就够了。挑 know-how 密度最高的那个——高复杂度、高风险、低标准化。一次异常审批、一次客户投诉、一次候选人判断、一次投放异常复盘，都行。挑好了，就把它的判断结构写出来。不是写流程怎么走，是写清楚那四句话：什么时候触发，看哪些信号，什么算好结果，什么时候要破例。

写完还有一件事不能省，也是最容易被跳过的一件：找那个员工把话说清楚。这件事怎么保护他，他的贡献怎么被看见、怎么被认可、怎么不会变成一次组织偷袭。这话说不清，就先别大规模推广。

know-how 提取是技术工程，更是信任工程。信任不来自培训，来自员工亲眼看见：交出经验的人，后来过得更好了。