AI 系统上线没人用？企业部署真正的终点叫“激活”

本文是《企业 AI 落地实战FDE 从 0 到规模化》第 5/10 篇。上一篇解决了“选谁作为第一批客户”本篇进入上线后的真实战场怎样让目标用户不需要催促也会在日常工作中稳定使用 AI。本文根据范冰《前线部署工程师人工智能时代的客户价值交付秘籍》开源版 v1.0.6 梳理与解读。一个企业 AI 系统完成了部署账号也发给了全部员工。上线仪式当天管理层宣布“公司进入 AI 时代”三周后后台显示大多数账号只登录过一次。员工仍然在 Excel 里整理数据在微信群里问老师傅甚至私下用个人 ChatGPT 完成工作。系统上线了部署却没有完成。因为上线是行政事件激活才是行为事件。目标用户在不需要持续催促的情况下把系统稳定用于真实工作并反复获得可感知的价值。这篇文章不讨论如何办一场热闹的发布会而是给出一套首月激活方法热修复、评估回路、工作流嵌入、场景封装、信任校准和组织经营。一、别再用账号数证明 AI 被采用账号数回答的是“谁有资格用”激活率回答的是“谁真的在用”。一个更接近业务事实的定义是激活率 在观察周期内完成关键业务行为的目标用户数 ÷ 目标用户总数图 1激活率衡量的是目标用户是否完成关键业务行为而不是是否登录过系统。这里有三个限定分母是目标用户不是采购账号分子要完成关键行为不是登录一次观察周期要能覆盖真实工作节奏。例如一套门店异常系统的关键行为不是“打开首页”而是区域经理阅读异常、下发处理任务并回写结果一套客服智能体的关键行为不是“发起对话”而是建议进入工单并被坐席采纳。激活指标必须与工作流绑定否则“日活”也可能只是管理层要求下的打卡。二、用户不用通常不是因为他“抗拒新技术”企业用户绕开官方 AI通常有三个直接原因。1. 不顺手旧流程虽然笨但已经形成肌肉记忆。新系统只要多一次登录、多一次复制粘贴、多一次等待就可能输给旧习惯。用户不会因为“公司战略重要”而每天忍受产品摩擦。2. 不可信AI 的错误不是平均分问题而是信任问题。系统连续答对十次用户可能觉得理所当然一次严重错误被发到群里整个部门会记住几个月。特别是在财务、法律、医疗和安全场景中无法解释“为什么得到这个结果”的系统很难被放进核心流程。3. 与自己无关很多企业 AI 产品展示的是通用能力却没有回答某个具体岗位“明天早上第一件事怎么变得更容易”。空白聊天框让用户自己想用法本质上是把产品设计工作转嫁给用户。三、激活的第一武器像处理线上事故一样做“热修复”企业部署早期最重要的产品节奏不是双周版本而是反馈能否在天级甚至小时级闭环。上午车间主任说戴着手套点不准按钮下午按钮尺寸已经调整。今天客服主管说输出缺少供应商编码明天这个字段已经进入结果卡片。热修复的价值不只在功能本身。每一次快速响应都在向用户证明这套系统不是交付完就没人管的项目而是在围绕他们的真实工作生长。执行时要守住三条纪律反馈直达写代码的人。不经过多层传话避免上下文失真按使用阻塞度排序。先修明天阻止用户继续使用的问题每天问一个问题。今天的改动让用户明天哪个动作更顺了热修复不是无边界地接受定制。它只服务一个目标尽快消除从第一次使用到第一次价值之间的摩擦。四、不要让用户来找 AI让 AI 出现在用户原有工作里许多企业 AI 系统输在入口。用户每天在邮件里审批、在工单里处理问题、在表格里分析数据却被要求登录一个新的聊天网站再手动复制上下文。更有效的设计原则是用户的主战场在哪里AI 就出现在哪里。可以对应成几类工程动作用户原有工作更合适的 AI 入口在 Excel 中分析表格插件、自动填充、异常侧栏在邮件中审批邮件内摘要、风险提示与操作按钮在工单系统处理问题工单卡片中的建议、证据与回写在企业微信接收任务消息推送、交互式卡片和结果确认在 ERP 中执行业务原页面嵌入建议不要求切换系统少一次跳转往往比多一个模型能力更能提高采用率。五、把“问 AI”封装成业务动作空白对话框适合探索不适合高频生产任务。成熟的企业 AI 产品会把提示词、上下文、工具调用和评估规则封装在一个业务动作背后生成上周异常报告核对这批发票草拟客户回复检查合同风险条款为这笔告警整理证据链。按钮背后可以是一条复杂的智能体工作流但用户看到的只是自己熟悉的任务。这样做有三个好处降低用户组织提示词的门槛让输入、输出和权限边界可控让每次使用都能进入统一评估与监控。企业产品不应考验用户“会不会提问”而应帮助用户“把工作完成”。六、先做副驾驶Copilot再谈自动驾驶Autopilot面对高风险或高抵触场景直接全自动化通常会同时触发两种恐惧用户担心系统犯错用户担心自己被替代。更稳妥的路径是分三级推进阶段AI 角色人的角色适用目标建议给出草稿、标签或排序全量确认建立初步信任协作自动处理低风险部分处理例外与抽检校准边界自动执行高置信、可回滚动作监控与升级处理扩大效率图 2自动化应沿“建议—协作—自动”逐级推进每一级都由质量、风险和可回滚性决定。什么时候可以升级不靠主观感觉而看数据人工采纳率是否稳定严重错误率是否低于业务阈值低置信输出是否能正确转人工决策是否可审计、可回放出错后是否能够回滚。副驾驶不是保守而是在效率、风险和组织接受度之间建立可验证的过渡。七、用持续评估闭环给信任“充值”AI 系统的质量是概率性的也会随数据、业务规则和模型版本变化而漂移。因此上线前通过一次验收远远不够。激活期需要一条持续评估闭环真实业务样例 ↓ 业务专家定义“什么叫好” ↓ 模型与工作流输出 ↓ 自动指标 人工抽检 ↓ 错误分类、修复与重新评估 ↓ 生产反馈继续进入样例库评估集必须从客户真实案例中生长并由业务专家共同打分。这样做不仅改善模型也改善关系。用户亲眼看到自己的反馈如何进入规则、质量如何逐轮提高比听一场“准确率提升”的汇报更容易建立信任。八、经营三类人支持者、影响者与受损者激活不是纯产品问题还会重新分配组织里的时间、权力和专业地位。支持者为项目押上信誉的人给他数据、故事和内部汇报材料让他能够向管理层说明项目的价值。项目出现问题时供应商要站到前面而不是让支持者独自承担。影响者没有职位权力却掌握同事信任的人他们可能是资深分析师、车间老师傅或部门里“问他就行”的人。邀请他们第一批试用把采纳的建议公开写出来。用户更愿意接受自己尊敬的人共同参与建造的系统。受损者流程改变后可能失去角色的人不要把他们简单写成“阻力”。可以把审批者变成例外处理者把老师傅变成评估标准的教练把被自动化释放的人力导向更高价值的工作。只有让他们在新流程中看到自己的位置地下抵抗才可能转化为参与。九、三个案例告诉我们激活靠的不是一次培训西班牙对外银行从种子用户到全行扩展按原书引用的公开案例西班牙对外银行没有一开始就全员推广而是先给一批种子用户提供安全可用的平台让员工自己探索场景并建立内部 AI 先锋网络与高级用户群体。扩张发生在上一阶段使用数据被验证之后。这个节奏说明先让习惯形成再让规模放大。Vivid Seats业务、产品与工程共同投入票务平台 Vivid Seats 引入 Sierra 智能体时不是把项目丢给单一 IT 团队而是让产品、客户体验和工程团队共同测试。原书引用的案例结果显示其上线周期不到四周自助解决率和客户满意度都得到改善。真正值得注意的是组织方式客户没有旁观供应商交付而是成为共同建造者。N 公司48 小时修复一次公开失误门店异常日报上线第一周把两家门店的促销高峰误判成异常。团队没有解释模型“总体表现不错”而是在 48 小时内接入促销日历并在群里公开感谢报错的区域经理。一次可能摧毁信任的错误被转化成了“反馈真的会改变系统”的证据。十、上线首月激活作战表第 1 周观察与清障建立用户反馈直达工程师的通道记录首次价值时间 TTFV每天更新使用阻塞清单处理权限、入口、字段和性能等高频摩擦对严重错误做到公开、快速、可解释地修复。第 2 周形成固定动作把高频提示封装为业务按钮嵌入用户已有系统配置默认模板和基于真实数据的首屏内容让关键影响者参与评估和规则修订。第 3 周校准信任与边界按真实样例评估质量建立低置信转人工和高风险人工确认统计采纳、驳回和错误原因对不同用户角色开展场景化培训。第 4 周检查组织能否自行运转培养客户内部讲师和答疑人把操作文档按任务组织并嵌入产品公布使用与价值数据确认 FDE 减少在场后使用是否保持稳定。十一、不要只看 DAU激活仪表盘应该有哪些字段类别建议指标采用目标用户激活率、周活趋势、连续使用周数深度关键动作完成率、使用场景数、工作流覆盖率价值首次价值时间、节省人时、错误率或处理时长变化质量评估达标率、严重错误率、人工接管率信任建议采纳率、用户纠错率、重复使用率组织内部讲师数、支持者覆盖、受损者干预状态如果系统已经上线可以先检查一个数字目标用户中有多少人不需要催促就会稳定完成关键业务动作如果这个数字答不出来项目还没有完成激活。下一篇我们把镜头移到技术底座一个 AI Demo 进入生产环境为什么最难的通常不是模型而是数据、权限、评估、系统集成和遗产系统AI 工具补给站https://pay.ldxp.cn/shop/5XW5R5KP参考与说明本文主要依据范冰《前线部署工程师》开源版 v1.0.6 第 4 章和 8.5 节梳理西班牙对外银行、Vivid Seats、约翰迪尔与 N 公司等案例来自原书及附录 C文中数据均应结合原资料统计时间理解激活率、关键行为与自动化阈值必须按具体业务校准本文提供的是方法框架不构成通用承诺涉及员工岗位变化、数据采集与自动化决策时应同步完成合规、劳动关系与伦理评估如需转载、商业改编或用于付费内容请遵守原书版权声明并取得相应授权。