一套AI项目的数据看上去相当亮眼：5000次提问，90%的满意度，老板觉得这个项目稳了。然而，当你把目光投向最初的业务目标——新人独立上岗时间、业务错误率、带教老师投入时间——却发现，这些指标纹丝不动。这究竟是怎么回事？

拆解这个企业知识库案例时，第一反应很直接：“失败了吧。”但仔细想想，这个判断可能下得太早了。它确实没有改善最初想改善的几项新人培训结果，但员工愿意使用，行政问题也解决得不错。我们不能因为它没有实现最初的目标，就假装这5000次使用完全没有价值。

更准确地说，这个工具并非无用，只是大家用它解决的事情，和老板一开始想解决的事情，并不是同一件事。

5000次提问，员工到底在问什么？

使用次数很高，并不代表原来的问题已经解决。看到一套AI系统被提问5000次，我们很容易先被这个数字吸引。但提问次数本身并没有告诉我们，员工问的是不是企业原本想解决的问题。

如果大家问的主要是Wi-Fi密码、报销流程和会议室预订，至少说明一件事：这些行政问题，大家确实不想再到处找人问了。这不是没有价值。原来需要去群里问、翻文件，或者打断行政同事，现在可以直接得到答案，员工当然会觉得方便。

可这套系统最初叫“新人培训AI助手”。企业希望改变的，不只是新人能不能找到Wi-Fi，而是他们能不能更快独立做业务、少犯错误，带教老师能不能少回答一些重复的专业问题。这些结果都没有发生。

所以先别急着问“5000次算不算多”，要看看大家问的这些问题，和老板一开始想解决的事到底有没有关联。如果这些高频问题全部解决，新人上岗时间还是不会变化，那系统可能确实好用，只是这个项目已经跑偏了。

工具有价值，和项目做成了，不完全是一回事

最开始说“失败吧”，其实说得有点快。先看好的一面：35名员工愿意使用，累计问了5000次，满意度也不低，至少说明大家知道入口在哪里，也愿意把一部分问题交给它。可再看老板原来想解决的问题，它又确实没做成。新人没有更快上岗，错误没有减少，带教时间也没有下降。企业最初希望改善的三件事，基本都停滞不前。

但它也不是一点东西都没做出来。至少从这5000次提问里，企业发现大家很需要一个行政问答入口。这个功能要不要保留，可以继续看它省了多少重复沟通。但它不能拿来证明“新人培训项目已经成功”。

说白了，产品有人用，和项目做成了，不完全是一回事。所以先把账算清楚：哪一部分可以留下，哪一部分得重做。否则数据好看的时候，大家只讲使用量；业务没变化时，又说员工不会用，绕到最后还是说不清这个项目到底解决了什么。

有人用、答得对、真的有用，是三回事

后来把这些数据摊开看了一遍，发现它们其实在回答三件完全不同的事。35个人用过、问了5000次，说明这个入口有人用，不是上线以后就被遗忘了。但它答得对不对，要看另外一些东西：引用的是不是有效版本，不确定的时候会不会停，该转给人的问题有没有转对。老板最后真正关心的，还是新人有没有更快上岗、少犯错误，带教老师有没有少花时间。

这些数字都有用，但谁也替代不了谁。有人用，只能说明大家愿意打开它。答得对，说明这套系统比较靠谱。原来那几个业务结果真的变好了，企业才知道这笔投入到底值不值。

当然，也不能只盯着最后的业务数字。如果指标暂时变好了，员工却根本不愿意用，这个结果很难持续。反过来也一样，大家都喜欢，回答也挺准，但老板最想解决的问题没变化，项目还是没做完。

之前说满意度“其实啥用没有”，这句话也说重了。满意度不能证明项目成功，但可以留下来看看员工愿不愿意继续用、对回答信不信。别删掉，也别把它放在最前面就行。

转人工越少，AI就越好吗？

这个案例里还有一个很容易被误读的数据：真正影响上岗的业务判断，AI经常转人工。第一反应可能是，转人工太多，说明知识库还不够完整。那就继续补资料，想办法把转人工率降下来。但有些问题本来就应该找人工。

比如涉及特殊客户、例外审批，或者现有资料根本没有明确答案。AI如果为了降低转人工率，硬给一个看起来完整的建议，风险反而更大。所以这里不能只数转人工多少次。更关键的是：该回答的时候，它有没有根据有效资料答对；不该回答的时候，它能不能停下来；转给老员工时，能不能把新人已经说过的话、相关规则和具体卡点一起带过去，别让两个人又从头讲一遍。

有些问题，AI说一句“不确定，我帮你找负责人”，比硬给一个答案更有用。该停就停、该找人就找人，也算做对了。

下一步，不要继续扩充整个新人培训库

如果这个项目准备调整，我不会先告诉员工：“以后多问一点业务问题。”因为员工不问，可能不是不知道可以问，而是已经试过，发现关键问题最后还是要找人。如果AI本身还没有能力处理这些问题，宣传得越多，只会让更多人体验一次失败。

更实际的做法，是先从一个真正影响上岗的任务开始。比如，新人第一次独立制作客户方案。先去看他在哪几个地方最容易卡住。是不了解客户需求，找不到合适案例，不知道方案该怎么取舍，还是写完以后无法判断能不能发出去？再把过去新人问过的真实问题、优秀带教老师当时怎么判断、哪些情况必须找负责人确认，整理成一小段可以测试的知识和案例。然后用历史问题检查：AI应该回答的有没有答对，应该转人的有没有转对。先让一组新人试用，看制作时间、错误和带教等待有没有变化。这比继续往一个泛化的“新人培训库”里增加资料，更容易知道问题有没有真的被解决。

数字变好了，也先别急着把功劳全算给AI

假设调整以后，下一批新人上岗真的更快了，我们还要多问一句：这次变化确定是AI带来的吗？新人可能本身经验更好，带教老师可能换了，培训内容也可能刚好做了调整。甚至那一批人遇到的业务更简单，都有可能让结果变好。AI日志只能证明员工在某个时间使用过，不能单独证明结果由AI造成。

所以开始试点前，至少要先记录原来的时间、错误和带教投入。尽量选择能力接近的新人，使用相同的任务和考核标准，一组先用，一组稍后再用，或者分阶段上线。最后再去看，AI是否真的出现在那些关键任务里，使用以后又具体减少了哪一段等待、错误或重复解释。不一定每家公司都有条件做很严格的对照，但至少别只拿上线前后两组数字，就把所有变化都算成AI的功劳。

先打开最近一个月的提问记录

如果你们公司已经有一套AI助手，今天可以先不用看总提问量。打开最近一个月的记录，找出提问次数最多的20个问题。再把项目启动时，老板最希望改善的那件事写在旁边。这20个问题里，有多少真的和那件事有关？哪些问题应该由AI直接回答？哪些问题本来就应该转给人？如果这些高频问题全部解决，老板最在意的结果会不会发生变化？

如果答案是“基本不会”，那说明系统可能解决了别的问题，但这件事已经做偏了。这时候不用急着否定整套系统，也不要继续用使用次数证明成功。先重新选一个和业务结果直接相关的任务，再确定需要什么知识、怎么测试，以及做完以后看什么变化。

如果你们公司也有一套“大家都在用，但老板说不清到底产生了什么价值”的AI工具，可以按照“原来想改善什么＋员工最常问什么＋哪个业务指标没有变化”的格式来梳理。拆解这个工具只是有人用，还是已经解决了企业真正想改善的问题。