上周和一位做客户支持的朋友聊天，他说团队花了两个晚上，把三年的工单记录整理成文档，交给一个对话模型，想让系统替他们总结“我们到底在哪些问题上反复摔跤”。第二天打开结果，段落齐整、语气专业，读完却什么也没留下——那些真正让客服头疼的瞬间，一个也没被写进去。
这件事有点意思。它说明的不是模型不行，而是我们对“经验”这两个字的理解，和机器的理解之间，隔着一层东西。
它会写字，但不会记事
语言模型的强项是生成“像那么回事”的文本。它读过足够多的复盘报告，知道这类文章通常先讲背景、再列原因、最后给建议，于是照着这个形状把空格填满。但它不知道那次版本为什么推迟了两周，不知道某个客户的名称一提起来整个组都会沉默，也不知道那条被悄悄改掉的规则背后是谁拍了桌子。
换句话说，它掌握的是公共语料的形状，不是你们组织内部的纹理。这两者之间的距离，不是把提示词写长一点就能填平的。
错题集往往没有被写下来
企业里真正管用的知识，很多散落在文档之外：被跳过的会议、被推翻的方案、临上线前临时改掉的一行配置。它们之所以没被记录，恰恰因为当时所有人都觉得“这还用写吗”。等到要微调一个模型时才发现，能拿出来的只有会议纪要，而纪要里通常只有结论，没有那些犹豫和返工。
所以，把人工智能接进业务流程，第一步常常不是选模型，而是把那些没被写下来的东西补上。这件事很土，很慢，也没什么演示效果。
判断能不能用，比用起来更费人
另一个容易被低估的成本是评估。一段生成的内容究竟能不能直接交给客户，得有人真的懂业务才能判断。很多时候，审一段机器写的文字比自己去写还慢，因为写的时候你知道自己在省略什么，审的时候却要逐句猜它省略了什么。
这也是不少团队试用停在演示阶段的原因：演示时输入是干净的、问题是被挑选过的；真实工单是脏的、缺字段的、带情绪的。落差就出现在这里。
先把边角料交给它
我并不觉得这轮技术被高估了。起草、改写、归类、检索、把一段散乱的会议记录整理成条目，这些活它确实能省下时间。它们有个共同特征：做错了容易被发现，人扫一眼就知道哪句不通、哪个分类放错了。
真正需要谨慎的是另一类任务——错了却不容易发现的那种。比如一份看起来无懈可击的分析，比如一段语气得体但事实有偏差的对外说明。这类输出不会报错，只会安静地流下去，等到有人发现，代价已经产生。
比较稳妥的顺序或许是：先让它处理那些有人盯着、错了立刻暴露的边角料；等团队对它的脾气熟悉了，再考虑往更靠里的位置挪。人工智能不缺少能力，缺的是被放在合适位置上的耐心。