乐于分享
好东西不私藏

AI助手不是买来的,而是从团队经验中蒸馏出来的

AI助手不是买来的,而是从团队经验中蒸馏出来的

上一篇我讲,每个数字化岗位都应该有一个贴着自己职责运行的 AI 助手。

那么问题来了:这个助手去哪里买?

我的答案可能会让人失望。买不到。

你可以买模型、买算力、买知识库工具,也可以请人帮你接好接口。但一个真正懂你们公司、懂这个岗位、知道什么情况该怎么判断的助手,只能从团队自己的工作里长出来。

这件事,我愿意叫它“经验蒸馏”。

把文件喂给 AI,为什么还是不好用

很多企业做知识库的第一步,是找一个大目录,把文件全部丢进去。

几天以后,大家开始测试。AI 确实能找到内容,也能总结得很通顺。可一到真正的工作现场,问题就出来了。

它不知道哪个版本才是现在有效的。

它不知道文档里的做法是正式规则,还是当时为了救火留下的临时方案。

它更不知道,一个看起来只要改个字段的需求,背后可能正在绕开一条管理规则。

文件记住了当时写下来的内容,但很多真正值钱的东西,根本没有完整写在里面。

这些年我做流程、系统和项目复盘,越来越明显地感受到:老手和新手的差距,往往不在“看过多少文件”,而在“遇到这种情况时,他先看什么、怀疑什么、问哪几个问题”。

这才是经验。

文件、版本、例外与判断不能混为一谈:资料只有经过治理,才可能成为岗位助手的基础。

经验的最小单位,是一条判断链

如果我们只把经验整理成问答,AI 很容易变成一本会说话的手册。

它能告诉你“通常应该怎么做”,却不一定知道“这一次是不是也该这么做”。

所以我认为,经验蒸馏的最小单位,不是一份文件,也不是一个标准答案,而是一条完整的判断链:

``text 遇到什么情况 → 看到什么证据 → 做出什么判断 → 采取什么动作 → 结果如何,后来怎么修正 ``

举个常见的例子。

业务部门说:“我们想在订单上加一个紧急标记,让生产优先处理。”

新手可能马上开始设计字段。有经验的人通常会先停一下:谁有权设紧急?紧急的依据是什么?它和已经确认的生产计划冲突时,谁拍板?这次调整挤掉了哪张订单?以后怎么查?

你看,表面上是加一个字段,实际上是要补一条责任规则。

如果只收录“怎么加紧急字段”,助手学会的是功能。如果把上面的判断链也整理出来,它才开始理解管理。

一条可复用的经验,必须保留场景、证据、判断、动作与修正。

企业里有哪些东西值得蒸馏

我们之前盘过六类来源:历史文档、项目案例、问题记录、流程规则、操作手册和复盘经验。

这六类资料的价值不一样。

信息项 01

来源

历史文档

最值得提炼的内容

业务背景、方案演变、正式结论

常见风险

版本过期,起草稿与正式稿混在一起

信息项 02

来源

项目案例

最值得提炼的内容

限制条件、取舍、阻力、结果

常见风险

容易只记成功做法,忽略当时条件

信息项 03

来源

问题记录

最值得提炼的内容

症状、原因、责任和处置过程

常见风险

只关工单,没有追到根因

信息项 04

来源

流程规则

最值得提炼的内容

角色、条件、动作、例外和升级

常见风险

只写正常路径,不写异常怎么处理

信息项 05

来源

操作手册

最值得提炼的内容

标准步骤、必填资料和常见错误

常见风险

有操作无判断,新场景不会变通

信息项 06

来源

复盘经验

最值得提炼的内容

原来怎么想、错在哪里、下次怎么做

常见风险

容易停在感想,没有形成新规则

这些资料先要分类、辨别可信度和处理边界,然后才能进入岗位助手。不是资料越多越好。一堆相互矛盾的文件,只会让错误变得更难发现。

经验蒸馏怎么做

这件事不需要一开始就做全公司知识工程。我更建议从一个岗位、一类高频问题开始。

第一步:选一个真正值得做的场景

优先选反复发生、已经有一些资料、又比较依赖老手判断的问题。

如果一件事一年只出现一次,或者每次都完全不同,未必适合第一个做。

第二步:把资料和人的记忆放在一起

只读文件不够。要让岗位上的人指出:哪些是旧规则,哪些是特例,哪些地方最容易被误解。

第三步:把判断链写出来

每条经验至少要写清场景、证据、判断、动作和后果。如果还有异常升级和权限边界,也要一起写。

第四步:用旧问题回放

找几个已经处理过的案例,看助手能不能找到同样的关键证据,给出可解释的建议。如果只是碰巧答对,却说不清依据,还不算过关。

第五步:让人继续纠偏

经验不会在第一次整理时就完整。每次试用后,要记录哪里判断错了,是资料过期,还是规则本来就没有说清。

蒸馏不是一次导入,是一个持续修订的过程。

从资料来源到回放纠偏,经验蒸馏是一条持续修订的岗位能力链。

怎么判断第一版有没有用

我不会先看它收了多少万字,也不会先数知识条目。

我更关心下面几件事:

  • 它能不能覆盖这个岗位最常见的问题;
  • 它给出判断时,能不能指出依据;
  • 它是不是知道什么情况应该停下来问人;
  • 新人有没有因此少走一些重复的弯路;
  • 老手的纠偏能不能回到系统里,让下一次变得更准。

这些东西如果没有变好,知识库再大,也只是一个更方便的资料柜。

有一条边界,不能等出事后再补

企业经验里一定会有客户信息、人员评价、权限设计、价格、成本和项目决策。这些知识不能因为“对 AI 有用”就全部混到一起。

内部助手、受限场景和公开演示,必须从资料进来的第一天就分开。

否则你蒸馏出来的不是助手,而是一个谁都说不清边界的风险源。

收口

AI 助手的门槛,不在采购清单上。

它考验的是一个团队能不能把过去的做法、取舍、失败和修正,整理成可以被新人理解、被 AI 调用、被下一次工作检验的判断链。

谁先把这些判断链留下来,谁才真正开始积累自己的 AI 能力。

你可以从今天做的一件事

从团队最常被追问的问题里选一个,不要急着写标准答案。

先找一个真正处理过它的人,问清五句话:

  1. 当时发生了什么?
  2. 你先看了哪些证据?
  3. 你怎么排除了其他可能?
  4. 你最后采取了什么动作?
  5. 如果重来一次,哪里会改?

这五句话整理好,就是你的第一个经验蒸馏单元。

下一篇,我会继续把它往团队里推一步:当不同岗位都开始有自己的助手,企业该怎样建立一张真正可管理的 Agent 矩阵?