AI项目上线后没人用-先看数据再决定救不救

AI项目上线后没人用-先看数据再决定救不救先说一个 AI 项目组最不想看到的场面。上线那天热热闹闹全公司发了邮件供应商驻场培训了两天头一周后台登录量蹭蹭涨。一个月后供应商撤了后台的日活曲线一路往下掉最后停在一个两位数上不动了。系统还开着考卷上说的那些功能都还在就是没人用。半年后的续费会上这笔十几万甚至几十万的开销成了财务问的第一句话。这种半死不活的系统处理方式通常是两种都不可取一种是不管它等着下次换供应商推倒重来一种是让领导发通知强制使用用量上来了工单里全是吐槽。这篇讲第三种路先看数据判断这个系统是「没被用上」还是「真的不行」再决定是救、是改、还是体面地关掉。AI系统没人用先分清「没被用上」和「真的不行」AI 项目上线后没人用先用两个数据诊断别急着下结论业务考卷答对率和上线后答错问题的回流修复条数。考卷分数还在线上、答错的题也在一条条修说明系统本身没坏是入口和习惯出了问题这类占多数考卷分数撑不住、回流也停了才是真的不行讨论救它之前先回到底层场景、验收、知识库、人工接管这四件事有没有做扎实。三种没人在用的样子入口丢失、信任崩塌、旧账烂尾没人用不是一个状态是三种不同的病对症的方子完全不一样。第一种入口丢失系统是个孤岛。功能都在但员工干活的动线里没有它。客服在工单系统里处理问题AI 助手在另一个网页里要另开一个窗口、再登录一次忙起来谁都想不起来点开它。这种系统不是被拒绝的是被遗忘的后台数据一看就露馅大部分账号登录过一两次之后再没回来。解法是把入口装进动线这一种最好救。第二种信任崩塌用一次伤一次。员工试过AI 答错了而且错得不小——答错价格、答错政策照着办事就出纰漏。出一次这种事整个部门会集体回到老办法而且再也不信。后台数据的样子是登录不少但每次对话一轮就退出没人问到第二轮。这同样是上线时人工接管没设计好的账得先把兜底通道修起来把信任一点点挣回来周期以月计。第三种旧账烂尾源头就没选对。场景低频、没有标准答案、错了兜不住立项时三个条件一个不占上线那天就是它这辈子最聪明的一天。这种系统不该救该体面关闭把里面攒的答案库和业务考卷导出来给下一个项目接着用。判断口诀很朴素救一个源头就错的项目比重新立一个对的更贵。三种病共用一条纪律先看数据再动刀。不做诊断就上手段十有八九把第一种病当成第二种治把该修入口的系统推倒重来钱和信任一起赔进去。三个口子接进动线让员工顺手就用上入口丢失型的系统不用改产品把三个口子接进员工已有的干活动线两周就能看到用量抬头。口子一聊天工具就是前台。员工不缺一个新系统缺一个随手能问的地方。把 AI 接进企业微信、钉钉、飞书里的机器人在天天聊天的窗口里它就能问。判断口子装没装对就一条员工需要不需要「记得打开它」。要员工记得的入口都会被忘掉顺手够得着的入口才活得下来。口子二系统里嵌助手。客服在工单系统里就让 AI 出现在工单系统里处理页面侧边一个「问 AI」它带着当前工单的内容上下文答的比通用助手准。销售在 CRM 里就嵌进 CRM。AI 该长在业务流程旁边不是长在 IT 部门的服务器上。口子三人工通道就是推广位。员工问老员工的时候把 AI 的答案递过去做参考——老员工回一句「AI 这个答案你可以看看」比十封全员邮件都管用。这一步同时还是在攒回流老员工说 AI 答得不对的每一次都该变成一条新考题。三个口子共用一个原则顺着员工已经在走的路走别修一条新路让人改道。入口改造不是 IT 部门发个通知是产品动作两周做完然后看两个数日活有没有抬头一轮对话完成率有没有上去。救一个差生系统四周重上线分数撑不住的系统别在入口上浪费时间按四周重上线的节奏把它当一个新项目救。这套打法没有一行新代码用的全是已有的资产。第一周重跑考卷摸底。用上线前的业务考卷原题重跑一遍多少分就是多少分别用感觉替分数。考卷在 60 分以下的同时回查两个源头立项三条件——高频、有标准答案、错了能兜住——当初是不是就没满足知识库是不是从文档仓库直接倒进来的从来没改成过答案库。第二周只修高频问题的知识块。把上线以来转人工的记录全部拉出来按问题频次排序修前 20 个问题的答案块。20 个高频问题通常盖住大部分咨询量这周的产出不是「知识库更全了」是「问得最多的那几个问题AI 答对了」。第三周把接管通道铺好再灰度。明确什么情况转人工、带着完整对话记录转给谁、答错的怎么回流。然后小范围灰度先给最配合的那个部门用天天在一线挨骂的反馈比任何评审会都值钱。第四周考回 85 分再全量。重跑那张考卷85 分达标就全量放开分数不上线就继续修不硬放。这个 85 分是立项验收时就该写死的及格线救系统时同样适用。四周救活的系统有个额外的好处这轮下来考卷、答案库、接管通道、灰度节奏全部补齐了等于把原来缺的课补上了。救活的系统往往比一次就成功的系统更抗造因为它修过真实出错的每一层。救不回来就体面关闭带走资产再关灯有一种可能要在动工前就说清楚不是每个系统都救得回来。诊断指标差的、重上线四周分数仍然不达标的关闭是正确决策硬撑着只会持续消耗信任和预算。关闭要体面核心动作是带走资产再关灯。带走答案库。这几个月修过的每一条答案块、回流进来的每一道新考题都是真金白银换来的导出来存好。它们跟模型无关、跟供应商无关下个项目用任何系统都接得上。带走考卷。那张 20 到 50 道题的业务考卷是这个场景最贵的方法论沉淀出卷子花的功夫一分都不会浪费。写一份三句话复盘。当初为什么立这个项、死在哪一步、下个项目先做哪件不一样的事。三句话就够写进部门的立项检查清单里比任何总结会都有用。关掉一个旧系统不丢人同一个坑摔两次才丢人。企业 AI 落地这条路多数公司都要交一次学费区别只在学费换来的是资产还是沉默成本——带走答案库和考卷的学费变成了资产骂一句「AI 没用」就翻篇的下次从零再来。FDEForward Deployed Engineer前沿部署工程师进现场处理「没人用」的系统时第一动作从来不是改产品是拉数据考卷重跑一遍回流记录翻一遍先判断是入口问题、信任问题还是源头问题。三种病三张方子——修入口的两周见效补知识块的四周重上线源头错了的体面关闭带走资产。没人用的系统最怕的不是没得救是不诊断就动手该修入口的推倒重来该关闭的硬撑续费把本该留下来的答案库和考卷一起埋进去。· · ·回到开头那个停在两位数的日活曲线。它先不急着判死刑也不急着发强制使用的通知。把考卷重跑一遍把转人工的记录拉出来排个序两个动作做完这个系统该救、该修还是该关答案自己会浮出来。系统死掉不可惜可惜的是死得不明不白连资产都没带走。