上线只是开始，使用率才是验收标准
「上线三个月，日活只剩个位数」——这是企业 AI 项目最常见的结局，也是最容易被误读的一个。常见的归因是「员工不习惯用 AI」「大家还是喜欢问同事」，听起来合理，实际上掩盖了真正的工程问题。
把使用率拆开看，它其实是一个乘法：
使用率 = 入口便利度 × 单次有用率 × 可做的事的范围 × 知道它能干什么的人占比四个因子任意一个接近零，整体就接近零。而大多数项目只优化了其中一项（通常是「模型答得好不好」），另外三项从来没被当成指标看过。
下面把最常见的五个原因拆开讲，每个都说清楚「症状是什么」和「怎么改」。
症状：后台数据显示绑定人数不少，但日活很低；问一圈发现大家都说「知道有这个东西，就是没打开过」。
如果 AI 助手是一个独立网页或独立 App，你实际上是在要求员工改变工作习惯：本来在飞书里跟同事说一句话就能解决的事，现在要先切到浏览器、登录、再提问。多出来的这几步，在企业场景里几乎等于劝退。
怎么改：让助手长在员工本来就在用的聊天工具里。飞书、企业微信、钉钉、微信、QQ、Teams、WhatsApp 都可以作为入口，员工像 @ 同事一样 @ 它。管理侧要能完成各平台的绑定：扫码绑定飞书/企微/微信，配置 QQ 机器人、Teams 机器人、WhatsApp 机器人号码等，绑定一次全公司可用。
一个可验证的判据：从员工产生疑问，到他把问题发出去，中间需要几次点击？超过 3 次就该重做入口。
症状：试用期大家问得很热闹，两周后没人问了。翻聊天记录会发现，问题集中在「今天天气」「帮我写首诗」这类没有业务价值的内容。
原因是：当助手只能给建议、不能真的把事做完时，员工试两次就得出结论——「还不如我自己做快」。真正能提升使用率的是能动手的能力：读文件、写文档、执行命令、上网查资料并核对、记住个人偏好。比如「把上周客户会议纪要整理成跟进要点，顺便起草一封感谢邮件」，只会聊天的助手回你一段建议，能动手的助手直接把文件写出来。
怎么改：先找出你们公司里「重复发生、步骤固定、有明确产出物」的三件事（例如周报汇总、客户跟进记录整理、制度问答），把这三件事做成可执行的技能模板。别一开始就追求全能，先让员工在真实任务上感受到「它真的把活干了」。
症状：员工问「年假怎么请」，助手答的是《劳动法》通用条款，而不是公司自己的请假流程；问「报销标准」，答的是「一般企业通常……」。
这类回答会迅速摧毁信任。员工第一次发现答案跟公司实际规定不符，之后就不会再问了——而且会告诉同事别问。
怎么改：把公司自己的文档接进去，让助手先查知识库再回答，并且每条关键信息标注出处；找不到就明确说没有，不拿通用答案冒充公司规定。文档上传后自动切分、建立索引，通常几分钟就能用。
再往上一层是部门维度：客服部的话术手册可见范围锁定在客服部，财务规章只给相关部门看，知识库按部门各建各的、跟组织架构对齐。这样员工问出来的答案才是「我们部门的规定」，而不是「网上的说法」。
症状：所有能力默认关闭，员工问什么都是「抱歉，我没有权限」；或者反过来，一开始全开、出了小事故后一刀切全关。
这两种极端都会杀死使用率。全关的状态下，员工无法形成任何正向体验；全关之后的一刀切，会让之前积累的使用习惯一起消失。
怎么改：按岗位发能力，而不是全开或全关。做法是把「怎么办一件事」的步骤存成技能模板，按部门分配——报销规章给财务和全员查，代码规范只给研发；后台对常用命令做全局启停，哪些命令对员工开放由管理员一键控制。内部系统通过标准协议（如 MCP）接入，每台服务器的启停、哪些 Agent 能加载哪些远程工具，都能按部门分别管控。
同时把「可追溯」补齐：谁在什么时候问了什么、助手做了什么、动了哪些文件，都能回看。这是 IT 敢放开权限的前提，也是使用率能上去的前提——权限和使用率是一起涨的，不是先后关系。
症状：日活不高，但每次做演示的时候大家都很兴奋；演示完过两天又回到原样。
这是最容易被忽略的一个原因：员工不是不想用，是不知道「在什么场景下该用它」。企业内部没有形成具体的使用场景描述，助手就只是一个「听说过但想不起来用」的工具。
怎么改：把能力翻译成岗位语言，而不是功能清单。不要发「我们上线了 AI 助手，支持知识库问答与文件操作」这种通知；要发「销售同事：把上周的客户会议纪要丢给它，它会整理成跟进要点并起草感谢邮件」这种场景卡片。
有效做法通常有三条：
使用率低的时候，最常见的错误是立刻开始改功能。正确顺序是先量出问题在哪一环，再动手。下面这套流程 7 天可以跑完，不需要额外系统。
从后台拉四组数：绑定人数、近 7 天活跃人数、人均提问次数、提问内容分布。重点不是总量，而是分布——如果提问集中在少数几个人身上，说明是「种子用户在用、其他人没进来」；如果提问集中在无业务价值的内容上，说明是能力或场景问题。
把用户分成三类：活跃用户（每周用 3 次以上）、尝鲜用户（用过 1-2 次就停）、未使用用户（绑定但从未提问）。三类人的问题完全不同，混在一起看会得出错误结论。
每类各找 3-5 人，只问：①你上次想用它是什么时候？②当时为什么没用？③如果它能替你做完一件事，你希望是哪件？不要问「你觉得这个产品怎么样」——得到的只会是客气话。
把访谈结果对回上面五个原因。经验上，「尝鲜用户」流失大多是原因一或原因二（入口麻烦、能力太弱）；「未使用用户」大多卡在原因五（不知道能干什么）；「活跃用户抱怨」通常是原因三或原因四（答案不准、权限不够）。
挑影响面最大的一环改，改完盯两周的活跃人数曲线。一次改多项，最后无法判断哪一项起了作用。
诊断完进入执行阶段，下面这份清单按周排，可以直接拿去用：
| 周次 | 动作 | 完成判据 |
|---|---|---|
| 第 1 周 | 入口收口：至少在员工日常使用的 IM 里可用，不需要装新软件 | 新员工从入职到第一次提问 ≤ 3 次点击 |
| 第 1 周 | 知识接入：公司制度、流程、手册上传并建立索引 | 抽查 10 个高频问题，答案与公司规定一致且带出处 |
| 第 2 周 | 场景卡片：每个部门 3 张，写清「什么时候用 + 怎么问」 | 每个部门至少 1 人在群里按卡片提问并得到可用结果 |
| 第 2 周 | 种子用户：每部门 1-2 人，先在真实任务上跑通 | 种子用户每周主动使用 ≥ 3 次 |
| 第 3 周 | 能力按岗位发：技能与命令按部门启停，不是全开或全关 | 至少 3 个部门有各自专属技能 |
| 第 3 周 | 可追溯：操作日志、成本记录、问题上报通道就位 | 能回答「上周谁让它动过哪些文件」 |
| 第 4 周 | 复盘：把有价值的对话沉淀成技能，下架没人用的技能 | 技能数量净增，且每个技能近 7 天有调用 |
这份清单里，第 1 周的两项是地基。入口没解决，后面所有推广动作都是在给一个没人打开的工具做宣传；知识没接入，第一次提问就会消耗掉员工的信任。
最后给一份自评表，10 题，每题 1 分，低于 6 分建议先别做推广动作，回去补地基层：
| # | 自评项 | 达标标准 |
|---|---|---|
| 1 | 入口 | 在员工日常使用的 IM 里可直接提问，无需安装新软件 |
| 2 | 首次体验 | 新员工 5 分钟内能独立完成一次有效提问 |
| 3 | 动手能力 | 至少 3 件真实任务能由助手产出可用文件 |
| 4 | 知识准确度 | 抽查 10 个制度类问题，答案与公司规定一致 |
| 5 | 出处标注 | 关键答案能指出依据来自哪份文档 |
| 6 | 部门隔离 | 不同部门看到的知识范围不同 |
| 7 | 权限分级 | 不同岗位能做的事不同，且不是全关 |
| 8 | 可追溯 | 能查到谁在什么时候让它做了什么 |
| 9 | 场景认知 | 随机抽 5 名员工，至少 4 人能说出一个使用场景 |
| 10 | 种子用户 | 每个主要部门至少有 1 人每周使用 ≥ 3 次 |
第 9 题特别值得单独看。它测的不是产品能力，而是「员工脑子里有没有这个工具的位置」——这一项不过，其他九项再好，使用率也上不去。
AI 助手的使用率问题，本质上是产品与组织的问题，不是模型的问题。换一个更聪明的模型，不会让员工多打开一次；把入口放对、把公司知识接上、把能力按岗位发下去、把场景讲清楚，才会。
如果只能记一句话：使用率是设计出来的，不是推广出来的。