一个几百人规模的团队，Web 端企业内部AI助手上线满三个月，后台周活掉到个位数。这个数字值得单独写一篇，因为它几乎从不是模型能力问题。
先交代口径：本文出现的团队规模与活跃数字，是为说明诊断路径而脱敏整理的复合场景，不对应任何具体客户；所有外部基准都标注来源、样本与适用边界。文章目的不是论证"AI 助手注定失败"，而是给出在上线三个月之后仍然改得动的那几个变量。
一、需求侧已经成熟，阻碍不在"员工不肯用"
2026 年 10 月 8 日，中国互联网络信息中心发布《生成式人工智能应用发展报告（2026）》。报告里有两个数字要放在一起看。
截至 2026 年上半年，我国生成式人工智能用户规模突破 7 亿人，普及率超 50%；76.0% 的用户表示自己会让生成式人工智能回答问题，而 AI 综合助手、AI 效率办公等应用的使用次数同比增长均超过 100%（CNNIC 报告发布稿）。
这组数字的含义很具体：员工在生活里已经被训练成"遇到问题先问 AI"的人。企业内部AI助手面对的不是一群不会用的用户，而是一群已经养成习惯、却在自己工作台上找不到同类体验的人。
边界也要说清。CNNIC 的口径是网民抽样调查，衡量的是消费侧使用行为，不是企业内部系统的采纳率；"使用次数同比大幅增长"是应用类别层面的增长，不区分个人与企业场景。因此它只能支撑一个结论：到 2026 年，把采纳率低归因于"员工不接受 AI"已经站不住了。
二、失败的真实形状：不是没人登录，是登录了却没进工作路径
回到那个周活掉到个位数的团队。把三个月埋点拉齐，看到的通常不是一条平滑下滑的曲线，而是三段形状完全不同的阶段。
- 头一周注册率高——因为有一封全员邮件和一场培训；
- 第三到四周出现断崖——恰好是培训记忆失效、员工第一次真正需要它的时刻；
- 第八周之后剩下的人，几乎都在做同一类任务，而这类任务往往不在立项时设想的场景里。
这个形状与外部调研的方向一致。德勤 2026 年 1 月发布的《State of AI in the Enterprise》显示，企业在一年内把员工可用的、已获批准的 AI 工具覆盖率从不足 40% 提升到约 60%，相当于一年扩大 50%（德勤新闻稿）。
同一份调研还有一组对照：只有 34% 的企业表示自己在用 AI 深度改造业务。2026 年 8 月德勤另一份调研说得更直接——只有 5% 的组织认为自己的业务流程对 AI agent 高度就绪，仅 15% 实现了跨职能多智能体的规模化编排，只有五分之一的高管认为组织已准备好为自主运行重设计流程（德勤 8 月调研）。
三组数据放在一起，结论很清楚：工具铺开的速度远快于流程改造的速度。员工手里有了入口，但工作路径没有跟着改，于是助手变成"另一个需要主动想起来打开的东西"。这就是周活掉到个位数的成因，也是模型升级修不好的那部分。
引用时需要克制：上述均为外部自报问卷，样本分别覆盖三千余名总监至 C 级管理者、五百余名美国企业与 IT 负责人，衡量的是准备度认知，不是实测使用率。
三、入口形态在设计阶段就定死了采纳天花板
同一个问答能力，放在四个不同位置，会得到四种完全不同的留存。按"用户遇到它要额外付出多少动作"排序，我们的工程判断是：内联嵌入 > 斜杠命令 > 上下文侧栏 > 独立弹窗。
| 形态 | 用户在哪里遇到它 | 额外动作 | 自带上下文 | 采纳判断 |
|---|---|---|---|---|
| 内联嵌入 | 正在编辑的字段或文档旁 | 0–1 步 | 高，当前内容即在作用域内 | 上限最高，改造成本也最高 |
| 斜杠命令 | 已有输入框内敲触发词 | 1 步，且需记住触发词 | 中，取决于编辑器能力 | 适合已被高频使用的编辑器 |
| 上下文侧栏 | 页面右侧常驻面板 | 2 步，切换视线并重新交代背景 | 中低，常需复述上下文 | 适合长流程任务的陪跑 |
| 独立弹窗或独立页 | 新标签页、悬浮窗 | 3 步以上，离开当前界面并复制回去 | 低 | 通常只剩尝鲜 |
关于这四种形态的三个月周活区间，网上流传过一组带小数边界的对照数字。我们尝试追溯过，汇编页面引用的是二手口径，找不到可核验的一手对照实验，所以本文不采用这些百分比。上表里的"额外动作"和"自带上下文"是可以当场复核的结构差异，排序结论属于工程判断，不是实测结果。
判断依据可以讲得更实：每多一步额外动作，就多一次"这次算了吧"的机会；每少一分上下文，用户就多打一句解释，而这一句解释往往比他直接动手更慢。独立弹窗之所以几乎必然失败，是因为它把"复制、切换、粘贴回"三步留给了用户，而这三步恰恰是助手本来应该替掉的部分。
有一个当场可用的自查：如果你的企业内部AI助手需要用户先离开当前页面才能调用，它的周活上限基本已经被写死了，与模型换到哪一代关系不大。
四、四个在评审会上就该定下来的决策
这四件事的共同点是：上线之后再改，代价通常是一次重构，而不是一次配置调整。
AI 住在哪个界面
入口位置要按"用户此刻在做什么"决定，而不是按"助手能做什么"决定。把该团队的高频动作列出来，看这些动作发生在哪个页面、哪个字段，助手就应该长在那里。这条决策之所以难改，是因为它同时绑定了前端埋点、权限模型和交互测试用例。长时运行任务的改造要点，另见Web 端长时运行 Agent 的四个生产化改造点。
它被允许替人决定什么
建议把权限切成四档，并写进产品说明：只读、给建议、代填草稿、直接写回。默认档位应当是"代填草稿"——用户仍需按下确认，但不用从空白开始。直接写回一旦出过一次越权事故，内部信任的恢复周期远长于修复本身，而这段周期里重新测量的采纳率没有参考价值。
人怎么把控制权拿回来
三个动作必须在同一次交互里可见：撤销一次写操作、改条件后重跑、一键转人工。藏进二级菜单等于没有。内部的判断标准很朴素——用户第一次遇到助手做错时，能不能在几秒内自己纠正回来；如果不能，他下一次就不会再用。
它怎么解释自己
解释不是给人看的装饰，而是让人判断"要不要复核"的依据。至少要回答三件事：引用了哪份数据的哪个字段、依据哪一版规则、哪一步是模型推断而非系统事实。可观测性落地的具体清单，另见AI Agent 安全防护清单。这三条如果缺，用户对结果的默认态度会从"核对一下"滑向"干脆不用"。
五、Web 端的三项工程配套
入口和接管边界是产品决策，落到 Web 端还需要工程兜底。这三项缺任何一项，采纳率都可能在一次事故之后直接归零。
权限继承与数据边界
取数必须用当前登录用户的身份，而不是一个全局服务账号；服务账号会把"部分人可见"变成"所有人可见"。检索侧同样要过滤：向量库的片段必须继承来源文档的访问控制，否则检索增强会绕过行级权限。会话记录与技术日志也要同权限——对话内容里常常残留敏感字段。工具层怎么划权限与审计，可参考MCP 协议接入内网的权限、审计与网关。
写操作的人工确认与回滚
三条底线：提交前给出差异预览，提交带幂等键防重复，变更留痕可回放。这三种状态的具体测法，见Agent 写操作验收的三种状态。写操作验收的具体检查项，我们在Web 端企业智能体工程化决策里有更细的清单，这里不重复。
失败时的降级路径
超时或限流时降级到规则或缓存，并明确告诉用户"这次没查到"，而不是给一个看起来像样的答案。助手不能成为新单点：它挂了，原流程必须照常走得通。置信度低时要有"我无法确认"的出口，这个出口的存在本身就是信任的一部分。
六、企业内部AI助手该用四个数度量，而不是登录数
度量口径决定了抢救方向。登录数对内部工具几乎没有信息量：一次单点登录跳转就算一次登录，而员工从不"登录"一个工具，他们只是在某个流程里顺手用它一下。
| 指标 | 定义 | 常见误用 | 采集方式 |
|---|---|---|---|
| 周活席位占比 | 过去一周内产生过至少一次有效交互的人数 ÷ 有权限人数 | 用注册数或登录数当分子 | 按用户 ID 去重，剔除自动同步请求 |
| 建议接受率 | 展示后未被修改即被采用的比例 | 把"点了采用"直接记为采纳 | 对比建议内容与最终提交内容的差异 |
| 任务完成率 | 在该入口内完成目标业务动作的会话占比 | 用对话消息条数代替 | 以业务系统里产生的记录为准 |
| 首次价值时间 | 从首次打开到完成一次真实业务动作的耗时 | 用培训完成率代替 | 首次会话到首条业务写入的时间差 |
接受率要单独定义"未被修改"。很多团队统计的接受率其实是点击率：用户点了采用，然后把内容全部改掉，这个数字会把一个失败的功能显示成成功的，于是抢救方向整个错掉。
七、四周内能做的抢救顺序
- 头一周，修入口位置。把助手搬到用户已经在用的那个编辑框或列表页，先不做任何新功能，目标是让额外动作降到一步以内。
- 第二周，找五到八个种子用户。选择标准是"过去一个月在该场景里有真实高频动作"的人，不是职级最高的人。
- 第三周，砍场景。把立项时设想的五个场景收到一到两个，其余入口先下线；留下的那个要能被种子用户连续用满三天。
- 第四周，再谈推广。此时才有可展示的真实使用记录，培训内容也从"功能介绍"换成"这三个动作现在可以这样做完"。
顺序反过来的代价是可预期的：先全员推广，等于把"不好用"这个印象一次性发给全部使用者，而内部工具的第二次推广成功率通常低于第一次。治理层面的红线，另见企业 Agent 开发的五个工程治理点。
常见问题
企业内部AI助手的周活做到多少算正常？
公开领域没有可核验的统一基准，任何单一百分比都不能直接套用——它高度依赖入口形态、场景宽度以及权限是否覆盖全部目标岗位。更可靠的做法是自比：看同一批首次使用者四周后的留存，和站内已有工具（例如内部搜索）的留存对比。如果新入口的四周留存明显低于老工具，先查入口位置，不要先查模型。
用户只说"不好用"，怎么定位到具体环节？
问三个探针问题就够了：上一次想用它是什么时候？当时人在哪个页面？最后这件事是自己做完的还是用它做完的？第三个问题的答案最有信息量——如果答案是"自己做完的"，问题几乎一定出在入口或接管边界，而不是答案质量。
是不是应该先做全员培训再推广？
顺序应当反过来。培训能提升"知道有这个工具"，无法提升"在需要的时候想得起来用它"。先用小范围真实使用攒出可复述的场景，再把培训内容换成这些场景的具体操作，转化率会完全不同。
周活掉到个位数，要不要直接下线？
一般不建议，先分两种情况判断。如果剩下的人是随机分布的尝鲜者，且入口需要离开当前页面，先修入口再评估。如果剩下的人恰好是该场景的核心岗位，说明产品已经撞到一个真需求，此时缩小范围比下线更划算。下线应作为最后选项，因为内部工具二次推广的成本通常高于第一次。
参考
- 中国互联网络信息中心：《生成式人工智能应用发展报告（2026）》，2026 年 10 月 8 日
- Deloitte：From Ambition to Activation — State of AI in the Enterprise 2026（2026 年 1 月 21 日）
- Deloitte：AI Agents are Only the Beginning — AI Readiness Gap（2026 年 8 月 12 日）
如果你的团队正好卡在三个月这个节点，可以把当前入口形态和度量口径发过来一起过一遍：联系我们。