先说一个反直觉的判断：员工不用，大多数时候不是培训问题。
这类项目最常见的处理顺序是——发现使用量低，于是组织培训；培训完短暂回升，两周后回到原点；再培训，再回落。几轮之后，结论变成"员工意识不到位"。
这个归因最省事，也最没用。因为它假设系统是好的、只是人不会用，而这个假设通常没有被验证过。
MIT 的 NANDA 项目在 2025 年发布的《The GenAI Divide》里有个被反复引用的数字：约 95% 的企业生成式 AI 试点没有产生可测量的损益影响。这个比例一直有争议，但它至少说明一件事——项目上线之后失效，是常态而不是例外。
下面是一个排查顺序。顺序本身很重要：前 3 条不解决，后面做什么都没用。
第 1 条：先验系统，不是先验人
在组织任何培训之前，先自己完整走一遍员工的真实任务。不是演示用的问题，是他们上周实际处理过的那些。
判据很简单：你自己用得下去吗。
如果你连着问 10 个真实业务问题，有 3 个答得含糊、1 个答错，那么员工放弃使用是理性行为，不是意识问题。人不会持续使用一个需要自己反复核对的工具——核对的成本比自己做还高。
这一步要量的是几个必须分开看的指标。以开源评测框架 RAGAS（docs.ragas.io）的口径为例：
- 上下文召回率——该找到的资料，找到了几成
- 上下文精确率——找出来的资料里真正相关的占几成
- 答案忠实度——每句话能不能在资料里找到依据
- 答案相关性——有没有真的在回答问题
这 4 个要分开量，因为处方不同。召回率低是资料切分或检索的问题，忠实度低是模型在编——把它们混成一个"准确率"，只会知道变差了，不知道该往哪修。
第 2 条：看它在不在工作流里
第 2 个高频原因：这个工具需要员工额外打开一个地方。
一个每天要用二十次的能力，如果入口在另一个系统、另一个网页、另一个 App，那么它每次被使用都要克服一次切换成本。而员工原有的做法——问同事、翻旧文档、凭经验——入口成本是零。
判断方法：数一下从"产生这个需求"到"拿到答案"，员工要点几次。如果超过 3 次，采用率不会高。
可行的方向是把能力放进他们已经在用的地方（办公平台、业务系统内部），而不是要求他们记住一个新入口。这件事的技术难度通常低于它带来的差别。
第 3 条：看它替谁省了时间
这一条最容易被忽略：上线一个系统，通常有人省时间，有人多花时间。
典型情况是：一线员工需要多做一步录入或确认，而受益的是管理层看到的报表。这种结构下，采用率取决于监督强度，一旦不盯就回落——因为对实际操作的人来说，它是净负担。
排查方法：把参与这条流程的每个角色列出来，逐个问一句"这套东西上线之后，你这个岗位是多做了还是少做了"。
如果答案里有一个岗位是"多做了"，而这个岗位恰好是使用频次最高的那个，那么问题不在培训。要么把负担挪走，要么给这个岗位一个真实的收益。
前 3 条都过了，再看这几个
上面 3 条排除之后，剩下的原因才轮得到常规办法：
不知道能干什么。 这时候培训才有意义，而且最有效的形式不是讲功能，是给 5–10 个本岗位的真实例子，直接可复制。
怕出错担责。 员工不确定"用它出的结果，错了算谁的"。这需要一句明确的话：哪些环节的结果可以直接用，哪些必须人工确认，出问题怎么算。含糊的授权会让谨慎的员工选择不用——而谨慎的员工往往是业务骨干。
用过一次不好，就不再回来。 第一次体验决定了后面几个月。所以上线前的那一版必须先在小范围跑通，而不是全员开放之后再修。
没人负责收反馈。 用户说了没用，反馈量会在几周内归零。而那时候你会以为"没人反馈说明系统很好"——实际上是失去了唯一免费的质量信号。反馈机制必须闭环：有地方说、有人接、有时限、修完通知反馈的人。最后一条决定了会不会有第二次反馈。
该怎么量采用率
用登录数或点击数看采用率会得到虚高的结论。更接近真相的是这 3 个：
| 指标 | 怎么量 | 说明 |
|---|---|---|
| 任务完成率 | 用它完成整件事的次数 ÷ 该场景总发生次数 | 打开了但中途放弃不算完成 |
| 回访率 | 用过 2 次以上的人数 ÷ 用过 1 次的人数 | 这个数字最诚实 |
| 无监督使用比例 | 没人提醒的情况下的使用量 | 靠盯出来的使用量不可持续 |
其中回访率最值得盯。一个人用过一次没有第 2 次，说明这次体验不值得他再来——这比任何满意度调查都准确。
一句实在话
采用率低是一个结果，不是一个原因。
把它当成原因去解决（"提高员工的使用意愿"），会一直做无效动作。把它当成结果去追问（"是什么让不用比用更划算"），通常两三轮就能问到真问题。
而真问题往往在系统这一侧，不在人那一侧。