那些没有写进文档的行业经验,AI怎么学?

差别可能藏在一句没写进手册的话里：这批先别急着安排，这个客户得再确认，这个数字不能直接用。

新人听不懂，就问为什么。老师傅想了想，说这个做久了，一看就知道。

我觉得，企业AI项目最值得追问的地方，就在这句“一看就知道”后面。

我们很容易花时间讨论知识库放多少文档、工作流接哪些工具，却没有问过：业务人员在作出判断时，到底看见了什么，而系统还看不见什么？

没有写下来的知识，并不都是神秘的直觉。其中可能有观察线索、条件组合、历史教训，也可能混着过时的习惯。它们需要被拆开，才能讨论哪些值得交给AI。

直接问一个人“你有什么经验”，常常会得到一串正确但宽泛的答案：注意交期、关注质量、结合客户情况。

这些话没有错，新人听完却依然不知道下一步怎么做。

换一种问法会具体得多。拿一项已经完成、允许讨论的任务，请当事人按当时的顺序重新看一遍：最先打开了哪份材料，在哪一步停住，什么信息让他改变了原来的安排。

以订单交期判断为例。表面上，输入可能只有数量和交付日期。熟悉业务的人还可能查看物料是否真正齐套、上一批有没有遗留问题，以及当前排期里哪些承诺不能轻易调整。

这时候继续追问：为什么先看这项？如果没有这个信息，还能不能判断？有没有看起来相似，最后却采用了另一种处理的任务？

重点是把人的注意力沿着工作展开，而非要求他现场写出一部行业教材。有些动作已经熟练到当事人不会主动提起，只有回到具体材料旁边，他才会意识到自己额外做了检查。

复盘也有局限。人可能记错顺序，或者把后来才知道的结果放进当时的理由里。因此最好同时保留能核对的材料、修改记录和确认过程；当时不知道的，就不要补写成早已预见。

先找到一次判断怎样发生，再讨论它能否成为方法。这一顺序，比先要求专家贡献一套通用规则更容易开始。

只看一个做对的例子，很难知道经验到底起了什么作用。

假设两个订单数量接近、交期相似，业务人员却认为一个可以接，另一个需要继续确认。如果只把最终结论录进知识库，AI看到的可能只是两份相互矛盾的答案。

更值得比较的是，哪些条件不同。材料是否通用，工序是否经过验证，客户是否允许替代方案，某项确认是不是还停留在口头上。

把不同条件摆在一起，原来笼统的“这个不好做”，才有机会变成可以讨论的判断。

还要找反例。一个被判为容易的任务，为什么后来返工？一个被认为风险较大的任务，最后又为什么能够完成？前者可能暴露遗漏，后者可能依靠了没有记录的额外支持。

不要急着把反例当成噪声删掉。它可能恰好说明规则的边界：原来这条经验成立，需要某个前提；前提变了，结论就不该照搬。

当然，相似不能只靠文件名或业务标签判断。先问使用者平时怎样区分任务的难度，再选择值得比较的材料。否则把两项本来差异很大的工作硬凑在一起，整理出来的规则也未必有意义。

这一阶段可以允许结论不完整。有些线索暂时只能写成待核对条件，不必为了让流程图好看，就给每个分支安排一个确定答案。

行业经验不只在人脑里，也会留在日常工具里。

一张长期使用的Excel，可能同时保存了数据、计算方法和人为补救。某一列看起来只是一个数，背后可能连着另一张表；某个结果原本由公式算出，后来又被手工覆盖。

因此，让AI读懂表头和公式，只是开始。还需要知道每列由谁填写，什么时间更新，哪个数是原始事实，哪个数是估算，哪个数已经获得确认。

尤其要留意那些不容易被识别成规则的地方：为什么某行标了颜色，为什么这个客户使用单独的工作表，为什么有些任务要在表外再发一次消息。

颜色和位置本身不一定有业务含义，不能让模型自行猜测。它们只是值得找人核对的线索。

公式依赖也需要看。检查一个结果时，可以顺着它使用的单元格追查输入，再看修改这个输入会影响哪些结果。但依赖关系只能说明数字怎样算出来，不能自动解释当初为什么这样算。

比如，表里有一个可以人工调整的系数。真正要问的是：谁可以改，什么时候改，改动依据是什么，有没有留下说明。把这个系数直接搬进系统，可能只是把一项需要确认的安排变成了默认事实。

我不太赞成一上来就宣布用新系统替换旧表。先弄清旧表替团队承担了什么工作，再决定保留、简化还是重做。否则表格消失了，原来藏在里面的提醒和检查也可能一起消失。

有些人确实知道怎样做，只是不擅长解释。给他看具体任务、让他演示，往往能补出不少细节。

但另一种情况不同：团队内部本来就没有统一标准。

例如，同一项加急需求，销售首先关心客户承诺，生产人员关心已有排期，采购人员关心物料条件。大家给出不同判断，可能因为承担的工作和代价不同。

如果这些意见都来自熟悉业务的人，究竟该让AI学谁的判断？

继续让模型总结“客户真正想要什么”，很容易把尚未讨论的取舍包装成一个已经存在的答案。

可以先把分歧留下：谁采用了什么标准，各自依据哪些材料，改变哪些条件以后愿意接受另一种安排。哪些属于事实争议，哪些需要负责人决定，也应当分开。

FDE在这里的工作，是帮助参与者把问题说具体，并找到能确认的人。不能因为负责开发，就顺手替客户决定业务优先级；也不能因为模型能够给出漂亮解释，就把它当成团队已经认可的口径。

还有些经验暂时无法被稳定检验。不同人看同一项任务判断差异很大，结果又受许多外部因素影响。这类工作可以先让AI整理证据、指出缺失材料，保留由人作决定的环节。

还没形成共识的判断，不会因为被写进提示词，就自动成为规则。

当条件逐渐清楚，下一步才轮到技术选择。

有些内容适合保留为可查询的材料，例如规格说明、已经确认的制度和操作要求。系统应当让使用者能够定位依据，并知道适用版本。

有些内容适合明确的计算和校验，例如必填字段、确定的换算、已经确认的条件判断。能用清楚规则稳定处理的部分，没有必要每次让模型自由发挥。

另一些内容依赖多份材料的结合，可以让AI帮助提取线索、提出候选判断，再把依据和不确定项交给人检查。这里最重要的输出，未必是一个直接结论，也可能是需要继续确认的问题。

涉及现场感知的经验还要多看一层。如果老师傅依靠声音、触感或实际操作作判断，而系统只有文字描述，缺的可能是观察条件。把访谈稿写得更长，不能补出从未采集的信息。

同一项任务也可以混合安排：先检查材料是否齐全，再按规则计算，让模型整理说明，最后由业务人员确认仍有争议的部分。

选择之前，先问：这项经验靠什么成立，系统获得了必要的信息吗，判断错误后谁能发现？技术应当对应这些条件，而不是把所有线索都塞进一个越来越难检查的提示词。

把材料整理成系统以后，最容易得到的认可，是让原作者拿熟悉的任务再走一次。

他知道缺什么，也知道结果哪里需要修正。系统留下的空白，可能又被他的经验悄悄填上了。

更有意义的验证，是在授权范围内选择没有参与整理的人，请他只依靠现有说明和系统输出完成任务。原作者可以观察，先别在每个停顿处补答案。

记录的也不只是结论是否一致。材料能不能找到，适用条件是否看得明白，遇到例外时是否知道停下，交给后续同事时还需不需要重新解释，都影响复用。

测试材料应当包含普通任务、临界情况、材料缺失和规则不适用的情况。用于检验的任务与整理时反复讲解的任务也要有所区分，避免把记住几个熟悉答案误当成已经学会方法。

如果专家之间本身存在分歧，先约定怎样确认结果，不必强迫系统模仿其中某个人。原作者的判断也可能需要被检查，他的作用是提供重要经验，并不等于拥有永远正确的标准答案。

对结果的要求还应当匹配用途。用于提醒人工检查的候选线索，与直接改变正式业务安排的结论，需要的证据和确认条件不会相同。

把经验写下来，并不意味着可以永久沿用。

设备换了，材料变了，客户要求调整了，过去常见的例外也可能已经有了新的处理办法。没有版本和适用条件的经验，时间久了会变得难以判断。

每项被采用的方法，至少应当能够找到当前负责人，知道它依据什么材料、适用于什么范围，以及最近一次确认发生在什么条件下。

出现失败任务时，也不要只修改一次回答就结束。要看变化发生在原始材料、业务规则、判断过程还是使用方式，再更新对应部分，检查其他相关任务是否受到影响。

还有一件事不能只靠技术解决：愿意贡献经验的人，需要获得整理和验证的时间，也应当看得见自己的贡献。把他手里的活一点不少地留下，再额外要求他完成访谈、标注和答疑，合作很难长期持续。

经验涉及的客户信息、内部规则和个人材料，也要分别确认共享范围。让更多人学会方法，不代表可以把所有原始资料一起传播。

我更愿意把这类项目理解为一次共同整理工作。行业人员提供观察与判断，工程人员把条件表达出来，使用者用真实任务暴露缺口，再一起修正。

下一次听到“这个一看就知道”，先别急着要求AI给出同样的答案。

把那项工作拿出来，请当事人指给你看：第一眼看的是哪里，什么变化会让他改主意，以及哪一种情况，他也要找别人确认。行业知识往往就是从这些能被继续追问的细节开始留下来的。