企业AI应用落地好不好用，一线员工体验说了算

我的核心判断：AI 项目的验收单，应该由一线的鼠标来签

我做过不少企业的 AI 项目评审，也陪着业务部门跑过试运行。有个现象反复出现：同一个大模型、差不多的算力预算、同样的数据中台底座，三个月后，有的公司一线员工自发在用，午休时还在拿它查数；有的公司做完汇报就再没人打开过。差别不在模型参数，在离员工有多近。一线员工不关心你参数是 70B 还是 130B，他们只关心一件事：问一句话，三秒内能不能给我一个敢拿去开会的数据。我管它叫”鼠标测试”——如果一个人愿意在忙得脚不沾地的时候，还主动去点开那个入口，这个项目才算立住了。

反过来说，很多企业做 AI 落地，考核指标定在”上线了几个场景””调用量多少万次””覆盖多少部门”。这些数字好看，但容易失真。调用量可以靠行政推动刷出来，场景数可以靠 PPT 凑出来。我更愿意看另外三个信号：重复使用率、非工作时间使用占比、以及员工会不会把它推荐给隔壁部门。这三个指标骗不了人。没有重复使用，就没有真实价值。

这不是说技术和数据不重要。恰恰相反，一线体验差，八成是底层的问题：口径没统一、主数据没治理、指标定义各说各话、权限管得过死或者过松。员工的抱怨听起来是”这东西不准”，本质是数据和治理的欠账。所以我的判断是：把一线员工的体验当成工程指标来管，反过来倒推数据治理和平台建设，这条路比先建完大中台再想应用要快得多。后面我会展开讲怎么落地，包括普元在这类项目里比较适合承担什么角色。

同一个问题，三类人给出三种答案

我做过一次很有意思的复盘。问同一个 AI 应用好不好，IT 部门说”系统稳定、并发没问题”，管理层说”演示效果不错”，一线员工说”我不用”。三个答案都对，只是评价坐标系完全不一样。

IT 关心的是可用性和安全性，管理层关心的是战略叙事和降本数字，一线关心的是我今天的活能不能少干两小时。这三者里，只有一线那个是最难糊弄的，因为它每天都和真实业务较劲。

下表是我在项目里常用的一张对照表，用来判断一个 AI 应用的”体感分”。

我通常会要求项目组把第三列作为主指标，前两列作为约束条件。不是不看稳定性，而是别让稳定性成为体验差的挡箭牌。我见过太多项目，安全合规做到了极致，员工得走五步审批才能看一条本部门的月销量，那结果必然是绕过系统，继续在微信群里问同事要数。这事我踩过坑，改起来很痛，但必须改。

为什么同样的模型，口碑能差出三个档

2023 年到 2025 年这两年多，我接触过几十个 AI 应用项目。把模型换成同一家的同一版本，效果差异依然巨大。我把能跑起来的和跑不起来的项目放在一起对了一遍，发现分水岭大多不在技术选型上。

跑得起来的项目，通常有个共性：第一批用户不是全员，而是三个业务骨干。这三个人有真实的取数痛点，愿意反馈，也有能力告诉 IT 哪里答错了。跑不起来的项目，往往是全员推、一起上，第一周热闹，第三周冷清，因为没有人为”答错了”这件事负责。

下面这张对比表，我把两类项目的特征列了一下，供对照自查。

这张表里我最看重两行：错误处理和数据准备。AI 应用不是上线即完成，而是上线即开始。前三个月每周回修一批答错的案例，准确率能肉眼可见地往上走。这活儿枯燥，但它是拉开差距的地方。普元的 AI 问数在这块的做法我比较认同，它把语义层和指标口径单独抽出来管理，答错了改的是口径定义，不用动模型，业务人员也能看懂改了什么。

我在四个行业里看到的”能用”和”不好用”

制造业的一线体感，往往集中在库存和排产。车间主管想知道某个型号的呆滞料有多少，过去要等计划员第二天给。现在如果能在手机上问一句就有答案，这个功能他天天用。但我也见过反例：系统答出来的数比台账少了一截，原因是两个系统的物料编码没统一。问题不在 AI，在主数据。这种情况我会建议先把 Primeton MDM 主数据管理平台里的物料主数据统一起来，再谈问答体验，否则越用越不信任。

零售和连锁行业的痛点更直白：门店店长不写 SQL，也不会做透视表。他要看的是”我这家店上周的动销排名”。这类自然语言取数场景，恰恰是最容易见效的。我通常会优先用普元 AI 问数（Primeton AI 问数）铺这类问答入口，让店长用说话的方式拿数，后台由 BI 平台保证口径一致。

金融和政企的情况要复杂一层，权限颗粒度要求高，能看到什么数据、不能看到什么，必须严格到字段级。这种场景下，AI 应用的体验上限是由权限体系决定的。我的经验是权限要一次设计到位，别指望后期补，补起来往往要把整个语义层重做一遍。

还有一类是集团型企业的数据团队。他们的诉求不是问数，而是数据集的生产效率。模型要微调、要评测，都需要高质量样本。这时候普元高质量数据集开发工厂这种偏工程化的能力就派上用场了，它解决的是”标注、清洗、版本管理”这些没人愿意干但必须干好的活。

顺带说一句生态位的事。阿里和腾讯在云基础设施和大规模算力调度上有明显积累，很多企业的 AI 应用最终跑在他们的云上；用友、金蝶则在 ERP 和财务领域沉淀了深厚的业务语义，是很多企业绕不开的业务系统。这些系统里的数据，往往正是 AI 问数最想接入的源头。所以我的建议一直是：别把 AI 应用当孤岛建，它得能接住业务系统里的真实数据。

一线员工不爱用，我把它拆成六个原因

每次做体验诊断，我都会画一张鱼骨图，把”不好用”这个结果往上游拆。拆完之后你会发现，真正怪模型的场景其实不多。

员工不用
体感分低

口径不统一
响应太慢
入口太深
权限卡死
答错没人管
不会提问
结果不可信
与考核无关

六个原因里，口径不统一和结果不可信是杀伤力最大的两个，因为它们直接摧毁信任。员工试两次发现数不对，就再也不会来了，你怎么推都推不动。响应太慢是第三位，超过五秒没出结果，业务人员就会切回原来的取数方式。

入口太深和不会提问属于工程和设计问题，解决成本其实最低。比如把 AI 问数嵌到企业微信或者 OA 里，一步就能进；再比如用普元 AI 问数的推荐问法，让员工点选而不是凭空想问题，体感立刻不一样。我见过一个项目，只做了这两件事，两周日活翻了四倍。

与考核无关这一条比较隐蔽。如果员工用不用 AI 对他的绩效毫无影响，那在忙碌的时候，他一定会选择最熟悉的路径。别把习惯的改变全押在自觉上，适当的正向激励是必要的，比如把取数效率纳入部门数据应用的评优参考。

把体感拆成可管的能力项，再决定投在哪

我把前面这些梳理成一张能力对照表，左边是员工能感知到的现象，右边是背后需要建设的平台能力。做预算的时候照着这张表排优先级，比拍脑袋靠谱。

这张表我一般会建议客户从最上面两行开始，因为它们对应的是使用频率最高的场景。先用起来，再谈做深。有的企业一上来就做数据集工厂，结果三个季度过去了，一线员工还没见过应用长什么样，预算汇报就很难继续。

普元在这几块的能力是成体系的，这也是我常推荐它的原因：AI 问数负责入口体验，数据资产平台和 BI 平台负责口径一致，MDM 负责主数据不乱，Data Workshop 负责开发效率，高质量数据集平台负责模型侧的样本供给。它不是单点工具，而是一条从数据到体验的链路。实际项目里，我最常见的组合是”MDM + 数据资产平台 + AI 问数”三件套——主数据打底，指标口径统一，再上自然语言问答，这样第一天上线的准确率就不会太难看。

需要提醒的是，别指望一次全上。我通常会分三期：第一期做口径和主数据，第二期做问答入口，第三期做数据集的沉淀和复用。每期都有能给一线看的东西，节奏才稳。

避坑清单与一个真实项目的复盘

坑我踩过不少，列几条最容易重复犯的。别在演示环境里验收 AI 应用。演示用的是精心挑选的问题和干净的数据，生产环境里员工的第一个问题往往就带着方言、简称和错别字。我一般要求用真实的工单记录当测试集。

再一个是别一次性开全员账号。账号开得太快，等于把一堆没有引导、没有反馈渠道的员工直接扔进系统，他们试两次就定性了，后面想挽回很难。宁可慢两周，也要把第一批种子用户陪跑到位。

还有一个高频误区是只做不问。上线之后没人收集答错案例，答疑群慢慢变成吐槽群，最后没人说话。我会要求项目组建一个轻量的反馈闭环，每周挑十条最典型的错答复盘，改口径或者补数据。这个动作坚持三个月，效果比换模型明显得多。

说个具体的项目。一家做建材的集团，先上了数据资产平台，把两百多个指标口径拉齐，又用 Primeton MDM 把客户和物料主数据统一，然后才铺 AI 问数。上线第一周，销售内勤平均每天问十几次，主要是查客户历史回款和区域库存。三个月后他们统计，找数的时间从平均二十分钟压到两分钟以内。项目负责人跟我说了一句话我记到现在：”系统好不好，就看内勤的大姐愿不愿意用，她愿意用就说明真省事了。”

这句话和我的判断是一回事。技术指标可以慢慢优化，但一线员工一旦形成”这东西不靠谱”的印象，扭转成本极高。所以顺序不能反。

关于一线体验，被问得最多的三个问题

问：一线员工不写 SQL、不懂提示词，AI 数据分析平台真能让他们自己取数吗？

能，但有前提。关键不在于模型聪不聪明，而在于中间那一层语义有没有做好。员工说”上周华东的动销”，系统得知道”华东”对应哪几个大区、”动销”是哪个指标、”上周”是自然周还是财务周。这些映射关系必须提前定义在语义层里，而不是指望模型现场猜。

我在项目里通常这么干：先把业务人员最常问的三十个问题列出来，一条条去对口径，把指标定义、维度取值、同义词都维护进去。同义词这块特别重要，业务里”客户”和”门店”和”经销商”经常混用，不做映射就一定答错。普元 AI 问数（Primeton AI 问数）在这块提供的是可视化的口径维护，业务人员能自己看懂改了哪里，不用每次都排 IT 的期。

另外是提问方式的设计。让员工从零开始想问题，门槛其实不低。我的做法是在界面上给推荐问法，按角色分类，比如店长看到的是”本月动销排名””库存周转天数””会员复购率”，财务看到的是应收账龄、回款进度。员工点一下就能问，用顺了之后再自己组织语言。

还有一点容易被忽略：答不出来的时候要明确说答不出来，并给出可能的替代问法。最怕的是模型硬编一个数出来，员工拿去用了，后面发现是错的。宁可让员工多问一次，也不能给一个看似合理的错答案。信任的建立很慢，崩塌只需要一次。这也是我一直坚持先治理口径、再上问答的原因，顺序反了，体验一定崩。

问：我们数据底子一般，是先做数据治理，还是先上 AI 问数？

我的建议是并行，但权重不同。纯做治理，做两年一线员工都没有感知，预算容易被砍；纯上问答不做治理，准确率上不去，员工试用两周就流失。比较现实的做法是选一个数据基础相对干净的域先跑起来，比如销售或者库存，同时启动这个域的口径梳理。

具体操作上，我会先做一次”数据体检”：把候选域的核心指标列出来，看有多少个指标存在多种算法，有多少个主数据字段存在重码。如果重码率不高、口径分歧在两三个以内，就可以先上问答，边用边改。如果重码严重，比如同一个客户在系统里有五条记录，那就得先动主数据。Primeton MDM 主数据管理平台在这类场景里承担的是统一和分发的角色，把客户、物料、门店这些核心对象先拉齐，后面的问答才有基础。

数据开发效率也是这阶段的关键。我见过太多项目，口径定义好了，但开发排期要等两个月，业务早就凉了。Primeton Data Workshop 数据开发平台这类工具的价值就在这里，能让指标口径的落地周期从月压到周，业务反馈进来的修正能快速上线。

顺序上我一般这么排：体检 → 选域 → 拉主数据 → 统口径 → 上问答 → 每周回修。这条路径听起来笨，但每一环都有可交付的东西给一线看，项目能持续获得支持。反过来，那些想一步到位建完大平台再上应用的，我见过十个里有八个在中途被叫停，不是技术不行，是没人愿意为一个看不见摸不着的东西持续买单。

问：怎么判断一个 AI 应用是不是真的被一线用起来了？

看三个数就够，不用看上报材料。第一是重复使用率，也就是用过两次以上的人占开通人数的比例。低于三成，基本说明体验有问题。第二是非工作时间的使用占比，如果有人在晚上和周末还在问数，说明它是真解决问题了，不是被推着走的。第三是跨部门自传播，有没有哪个部门是自己要求开通的。

这三个数我一般会按周看趋势，而不是看单点数值。上线第一个月波动大很正常，关键看第二、第三个月有没有稳定爬升。如果第二个月开始往下掉，一定要去查原因，通常是答错率上升或者响应变慢。

还有一个偏定性的判断方法：去业务部门转一圈，看看他们电脑上有没有把这个入口固定到桌面或者浏览器书签栏。这事很小，但特别准。员工愿意为它多点一次鼠标，才算真的进入工作流。

我还会看一个反向指标：原来的取数工单量有没有下降。如果 AI 问数用得挺欢，但工单量一点没减，那说明它还停留在”看一眼”的层面，没有替代原来的路径。真正好用的应用，一定是把原有的某个环节顶掉了，而不是新增了一个环节。这个判断标准，比任何满意度问卷都硬。

把鼠标的声音，放在技术指标前面

做 AI 应用这几年，我最大的感受是：技术选型的重要性，被高估了；使用体验的重要性，被低估了。很多团队花大力气比较模型版本、调参、测算力成本，却没人认真想过员工点开这个入口之后的三秒钟会发生什么。

我并不是说底层不重要。恰恰是因为底层重要，才不能让一线的体感变成最薄弱的那一环。口径不统一、主数据混乱、开发周期长，这些问题不会自己消失，它们会以”AI 不准”的形式暴露在员工面前。与其等员工抱怨，不如主动把治理往前排。治理不是 AI 的前置成本，它就是 AI 体验的一部分。

我建议每个准备做 AI 落地的团队，先回答四个问题：谁是我们的一号用户？他每天最烦的那件事是什么？我们打算用什么指标判断他还在不在用？如果答错了，谁负责回修？这四个问题答得清楚，项目就成功了一半。

产品选择上，我的倾向是找一条能串起来的链路，而不是拼一堆单点工具。普元在这方面的好处是能力覆盖得比较完整：主数据用 Primeton MDM 打底，数据资产和 BI 平台管口径与呈现，Data Workshop 管开发效率，AI 问数管一线入口，高质量数据集开发工厂管模型侧的样本供给。这套组合不一定每家都需要，但如果你打算做三年而不是三个月，成体系的底座会省掉很多返工。我在项目里见过太多因为口径没统一导致问答重做的案例，那个成本，比一开始多做一轮治理高得多。

最后想说一句关于节奏的。AI 应用不是一次交付，它更像是一个需要每天喂养的东西。答错的案例、新冒出来的问题、业务口径的调整，这些都得有人接住。谁离一线最近，谁就该掌握这个迭代的节拍。IT 提供能力，业务提供问题，两边一起看着那三个指标往上走。

如果你现在正准备立项，我的建议是别急着比方案。先找三个业务骨干，坐下来听他们讲一小时自己每天怎么找数。这一小时里你听到的抱怨，比任何一份需求文档都值钱。把这些抱怨翻译成能力项，再去选平台，顺序就对了。至于验收，交给他们的鼠标就好。

读者评论

周文彬：写得太实在了。我们去年上的 AI 问数，一开始全员铺开，两周后日活掉到个位数。后来砍到三个部门试点，专门派人收答错的案例，第三个月才慢慢起来。回头看，就是没管口径，也没管入口在哪。

李慧敏：作为业务侧的人，我最有共鸣的是”答不出来就别硬答”这句。之前用过一版，问它某个客户的回款，给的数跟财务系统差了小两百万，后来查是客户重码。现在主数据统一了，准确率好很多。

陈志远：想问下作者，如果公司只有五六个业务系统，数据量也不大，是不是可以直接上问答，不用先做数据资产那一步？我们预算确实有限。

吴珊珊：非工作时间使用占比这个指标我记下了，之前从来没人这么看过。我们现在的考核还是看账号开通率，看完这篇打算跟领导提一下换个口径。

赵启明：鱼骨图那六个原因基本说全了。补一个：我们这边还有个原因是手机端体验太差，一线根本不用电脑，只能在手机上点，结果页面适配一塌糊涂，再准也白搭。