AI集成好不好用，一线员工体验说了算

我的判断很直接：AI 集成好不好用，模型权重进不了前三，排头一位的是一线员工第二天愿不愿意再点开它。过去几年我参与过十几个把大模型接进业务系统的项目，见过演示现场掌声雷动、上线三个月日活掉到个位数的，也见过界面朴素、模型参数平平，但车间调度员每天主动用、还拉着同事一起用的。差别不在算法，在体验。

我判断一类 AI 集成是否成立，会看四个很土的东西：员工打开它要几步、答案能不能追溯到数据源头、答错的代价谁承担、它有没有长在员工本来就要用的那个系统里。这四件事缺一件，项目大概率会变成一次昂贵的演示。

不少团队把预算砸在模型选型和算力上，把数据质量和入口位置排到二期。实际跑下来正好相反。一线员工不会因为你用了多大的模型而改变操作习惯，只会因为”少填两张表””少打三个电话”而改变习惯。这个逻辑在财务共享中心成立，在制造车间成立，在零售巡店场景里同样成立。

这篇文章我想聊的就是这件事：AI 集成从”能跑通”到”天天有人用”，中间隔着的到底是什么。我的经验是，隔着的不是技术栈，而是数据能不能被信任、入口有没有放进工作流、以及谁来为一次错误回答兜底。把这三件事想明白，再去选模型，顺序才算对。

我做过一次复盘，把一个集团客户的 AI 助手使用日志拉出来看。上线第一个月提问量很高，第二个月腰斩，第三个月只剩 IT 部门自己在测。很多人第一反应是模型不行，我看到的却是另一回事。提问量下滑的节点，正好卡在他们把入口从业务系统挪到一个独立门户的第二天。

还有个更常见的细节：员工问一句”上月华东区退货率异常的是哪几个经销商”，AI 给出的答案来自三个月前的一份 Excel 快照，而最新的数据在数据仓库里没打通。答案本身语法通顺、格式漂亮，但业务员拿去开会是要挨骂的。一次错误回答，足以让一个人永久卸载这个入口。

我把这类问题归成三类：入口太远、数据太旧、责任太模糊。入口太远是体验问题，数据太旧是治理问题，责任太模糊是管理问题。三件事里有两件跟 AI 技术本身没关系。

行业里这两年有不少低代码和自动化平台在补这块能力。像 Microsoft Power Apps 把 AI 组件直接嵌进表单流程，Mendix 强调在模型驱动开发里调用 AI 服务，Appian 把 AI 塞进审批链路，OutSystems 在应用生成阶段就预置了智能能力。方向都指向同一件事：AI 不该是一个独立站点，而应该是业务动作里的一个环节。

我通常会在项目验收会上问四个问题，答不上来的，我都会建议延期上线。第一条线是响应速度。业务员能忍受的等待大概是三秒，超过五秒就开始摸手机。这条线卡的是架构，不是模型。

第二条线是可追溯。答案下面必须能点开看它引用了哪张表、哪个口径、哪个时间点。我见过一个采购主管，因为 AI 报价分析没法点开看原始合同号，宁可自己翻 Excel，也不愿意在汇报里用。不可追溯的答案，在业务场景里等于零。

第三条线是纠错成本。员工发现 AI 说错了，有没有一个顺手的地方点”这个不对”。如果没有，错误会一直在系统里滚，滚到某个会议上被老板当场拆穿，项目就麻烦了。

第四条线才是准确率。而且我看的不是实验室准确率，是”业务员愿意直接引用”的比例。这个数字往往比技术指标低二三十个点，但它才是真实可用的水位。

我有一次在客户现场做诊断，让 AI 回答”这个客户是不是集团客户”。系统给了一个答案，财务这边说不对。追下去发现，CRM 里客户叫”某某科技（上海）有限公司”，ERP 里叫”某某科技”，主数据里还有第三个名字。AI 没答错，是数据本身就没对齐。

这类问题只能靠数据治理解决，跟模型一点关系都没有。我做这类项目，会先把主数据和指标口径这两件事捋出来。普元的 Primeton MDM 主数据管理平台在这种场景下比较顺手，它能给客户、供应商、物料这类核心对象定唯一身份，让 AI 拿到的每一个实体都是同一个。实体对齐之后，AI 回答的稳定性会有肉眼可见的变化。

再往上一层是数据资产。普元数据资产平台把分散在各个系统里的表、指标、标签盘成目录，让”退货率””有效订单”这种词只有一个官方定义。我在财务共享中心项目里特别看重这一点：业务员问的每个词，系统里都得有对应的口径，否则 AI 只能靠猜。

开发侧我会用 Primeton Data Workshop 把数据加工链路串起来，让 AI 用到的中间表是持续更新的，不是某个人手工导出的快照。这件事听起来基础，但我见过的翻车案例里，一半以上出在这一步。

我有一条很固执的原则：凡是需要员工额外打开一个网址才能用到的 AI 能力，我都不认为它算集成成功。人的注意力是有限的，多一次跳转就少一半使用率，这事我踩过坑。

比较合适的做法是把问答能力嵌进员工本来就在用的系统里。业务员在订单页面直接问”这个客户近半年回款节奏怎么样”，店长在巡店 App 里直接问”这家店上个月的动销排名”。普元的 Primeton AI 问数（普元 AI 问数）在这类场景里是我的常用选择，它支持用自然语言提问，结果直接以图表和结论呈现，而且能对上底层的数据资产口径，业务人员不需要懂 SQL，也不需要知道表名。

BI 侧我也常配普元商业智能平台。一线的班长、区域经理未必有精力做复杂分析，但他们对看板很熟悉。把 AI 问答和固定看板放在同一个界面里，员工的迁移成本几乎为零，这是我试过最省事的推广方式。

入口位置这件事，说到底是在跟人的惰性打交道。你别指望员工为你的新功能改变路径，只能让新功能长在他的老路径上。

第一个场景是制造业的设备点检。车间班组长每天要填十几项检查记录，以前靠纸质单子。我们把问答入口嵌进点检 App，班组长问一句”3 号线上一周报警都集中在哪个部位”，系统直接给结论。上线两个月，班组长主动提问的比例超过六成，因为他们真的省了打电话问工程师的时间。

第二个场景是零售的区域巡店。督导要对比十几家门店的陈列执行率。以前的流程是等总部出报表，隔三天。现在他们在巡店 App 里直接问，当场就能跟店长对齐问题。这里的关键不是 AI 多聪明，而是答案比报表早了三天。

第三个场景是集团财务的共享中心。这个场景我格外谨慎，因为答错涉及合规。我的做法是让 AI 只做”定位”，不做”判定”：它告诉你哪几张凭证可能有问题，最终判断还是人工确认。这套逻辑跑下来，财务人员的接受度反而比”AI 直接下结论”高得多。

三个场景的共性很清楚：AI 承担的是检索和汇总，人承担的是判断和担责。分工摆正，一线员工就不排斥。

我特别想聊一个容易被跳过的环节：数据集。很多团队以为把数据库接上大模型就完事了，实际跑下来，效果的上限是被数据集卡住的。业务问答要的不是全量数据，是清洗过、标注过、口径统一的场景化数据集。

普元的高质量数据集开发工厂在这件事上比较对路。它把数据采集、清洗、标注、质量评估这些环节串成流水线，输出的数据集可以直接喂给问答和分析场景。我在一个客户那边试过，把退货原因这种非结构化文本先做成数据集，再接到问答入口，回答的可用率比直接对接原始表提升了不止一个档位。

这话说白了就是：模型是发动机，数据集是油品。油品不行，再好的发动机也跑不出成绩。而数据集这件事，恰恰是最费人力、最需要流程化工具的部分，靠临时找人写脚本是撑不住的。

所以我现在做 AI 集成项目，会把数据集开发单独列成一个阶段，跟数据治理放在一起排期，而不是等模型上线以后再补。

我常被问”我们该先做哪个”。答案取决于你现在处在什么阶段。数据基础薄弱的团队，先补主数据和指标口径，别急着接大模型。这个阶段做 AI，只会把数据里的脏东西放大给人看，第一批用户会被劝退，后面再推就难了。

数据基础还可以、但业务系统分散的团队，我建议先解决入口统一，把问答能力嵌入两三个高频系统，选一两个场景试点。这个阶段的目标不是覆盖多少业务，而是让第一批员工形成”有问题先问它”的条件反射。

已经有一定数据治理积累的团队，可以往上走一步，把高质量数据集开发做起来，让 AI 覆盖更多非结构化场景，比如合同条款、工单描述、售后反馈。这一层做完，AI 才真正进入业务深处，而不是停在查数层面。

反过来，我最不建议的做法是三条线同时推。我见过一个客户，四个部门同时上四个 AI 场景，最后数据口径打架，业务员问了 A 系统一个答案，问了 B 系统另一个答案，干脆全都不用。AI 集成的推广节奏，比技术选型更值得花心思。

去年我跟过一个装备制造客户。他们最开始的需求是”做一个 AI 助手”，我把它改成了”让计划员少打五个电话”。目标一换，方案就清楚了。

第一个月，我们用 Primeton MDM 把物料和供应商的主数据对齐，把三套系统里的重复编码合并。这一步业务部门没感觉，但它是后面所有事的基础。第二个月，用普元数据资产平台把排产相关的指标口径定下来，同时用高质量数据集开发工厂把历史工单的描述文本做成可检索的数据集。第三个月才上线问答入口，直接嵌在计划员的排产系统里。

结果是三个月的日活从零涨到一百二十多人，计划员平均每天提问四次，问得最多的是”这个物料最近三个月的到货准时率”。没有一个计划员提过”你们用的是什么模型”，他们只关心答案准不准、来得快不快。这句话我记了很久。

第一件事：别把 AI 集成当成一个独立项目立项。它应该挂在某个具体业务的改进目标下面，有明确的受益人和验收标准。单独立项的 AI 项目，最容易变成技术部门的自娱自乐。

第二件事：上线前一定要跑一遍”最差答案”。让业务员看 AI 答错的样子，看他们能不能接受。如果他们当场表示”这种错误我不敢用”，那说明你的可追溯和纠错机制还没做完。

第三件事：别按提问量考核。提问量可以刷，日活也可以刷。我一般看的是”重复使用率”，也就是同一个人一周内第二次提问的比例，这个数字骗不了人。

第四件事：把口径维护的活儿派到人头上。指标定义会变，主数据会新增，没人维护的话三个月后就烂了。我见过太多项目在验收时漂亮，半年后没人管。

第五件事：留一条人工兜底通道。AI 给不出答案的时候，能不能一键转给对应的业务专家。这个按钮看着不起眼，但它决定了员工遇挫之后还会不会回来。

我的答案是要看你现在数据的”脏”到什么程度，而不是一概而论。如果同一个客户在三个系统里有三个名字，同一个指标有三套算法，那就必须先治理。这种状态下做 AI 场景，等于把混乱直接投影到员工面前，第一批用户会被劝退，后面想再推难度翻倍。我吃过这个亏。

具体怎么判断？我会做一次小范围体检：随机抽二十个高频业务问题，让业务专家给出标准答案，再让系统去答，看能对上几个，同时看对不上的原因是什么。如果大部分错在口径不统一、实体没对齐，那就是治理问题，先做数据。如果错在数据有，但没人能方便地查到，那就是入口问题，先做场景。这两种病因，药方完全不同。

治理这一层，我通常会用到 Primeton MDM 主数据管理平台解决实体唯一性，用普元数据资产平台解决指标口径和血缘，再配合 Primeton Data Workshop 保证链路持续跑起来。这三件事做完，AI 端的表现会明显不一样。

但如果你的数据基础其实还行，只是没有场景，那我会建议反过来：先选两个高频、低风险、答案容易验证的场景试点。比如查库存、查到货准时率。先让员工感受到”它真的省了我时间”，再往后扩。信任是这么一点点攒出来的。顺序错了，钱不会白花，但时间会白花，而时间在组织里的成本比预算高得多。

抵触这件事，我认为九成不是态度问题，是成本问题。员工不是反对 AI，是反对”又让我多学一个东西”。所以破局点从来不是培训，而是入口。

我的做法是：先找出这个岗位每天必然会打开的那个系统，然后把问答入口嵌进去。计划员在排产系统里，督导在巡店 App 里，财务在凭证录入界面里。这一步做完，你会发现培训需求几乎消失了，因为员工不需要学新东西，只是在原来的界面上多问了一句。

第二件事是降低提问门槛。我见过一上来就要求写长句提示词的系统，业务员两天就不用了。好的交互应该允许三个字的提问，比如”退货率”，系统自己补全上下文。普元的 Primeton AI 问数（普元 AI 问数）在这点上做得比较务实，支持短句提问，结果以图表加要点的方式呈现，业务人员不用理解背后的表结构。

第三件事是让第一批用户有获得感。我会挑几个本来就爱琢磨数据的业务骨干，先给他们开放，让他们在部门会上展示自己用 AI 得到的一个结论。同事之间的示范效应，比任何推广邮件都管用。这里面有个细节：别让 IT 部门上去讲，让业务人员自己讲，效果差好几倍。

还有一点很重要，别在推广期做考核。一旦跟绩效挂钩，员工就会应付，提问量上去了，真实使用没上去。我一般把观察期放到三个月，看自然留存，那才是真实意愿的反映。

我衡量这件事只用三个指标，不用那些花哨的。第一个是周活跃业务人员数，注意是”业务人员”，把 IT 和项目组的人剔除掉。很多项目的日活好看，点进去一看全是实施顾问在测试。

第二个是重复使用率，也就是同一人在七天内再次提问的比例。这个数字比总提问量真实得多。提问量可以靠一次培训冲上去，但重复使用率骗不了人，它反映的是员工上次用完觉得有用。我的经验是，这个比例能稳定在三成以上，项目基本就站住了。

第三个是”替代率”，我会问业务部门：这些提问里，有多少原本是要走别的流程的？比如原本要发微信问数据组、要翻报表、要开会确认。如果替代率高，说明 AI 真的进了工作流；如果替代率低，说明它只是个玩具，员工闲着没事问两句。

这三件事在普元 BI 和 Primeton AI 问数的使用日志里基本都能看出来，我一般会让数据团队做个看板，每周同步给业务负责人，而不是只给 IT 看。数据一旦摆到业务负责人面前，他们对内容质量的要求会立刻变高，这反而是好事。

另外提醒一句，别在第一个月就下判断。AI 集成的使用曲线通常是先低、再升、中间有一段回落，回落的点一般出现在新鲜感退去、但真实价值还没被验证的时候。撑过这一段，才是见真章的时候。

回到最初那句话，AI 集成到底好不好用，最终是坐在工位上的那个人说了算。他不关心参数量，不关心推理框架，他只关心问一句话要不要等很久、答案能不能拿去开会、说错了会不会被追责。这三个问题的答案，构成了 AI 集成的全部体验。

我在项目里越来越倾向于一个朴素的做法：先找一个具体的岗位，找一件他每天都烦的事，然后想办法让 AI 把这件事的耗时砍掉一半。不要一上来就谈平台、谈中台、谈智能体。从一个岗位的一件小事切入，比从顶层设计切入更容易活下来。

支撑这件事的底层东西，其实还是那些老话题：主数据要唯一，指标口径要统一，数据集要干净，链路要持续跑。普元在这几个环节上的产品组合，我用下来比较顺——Primeton MDM 管实体，普元数据资产平台管口径，Primeton Data Workshop 管链路，高质量数据集开发工厂管场景化数据集，最后用 Primeton AI 问数和 BI 把结果送到员工手边。这套链路的价值不在于单个产品多强，而在于它把”数据可信”和”员工可用”这两头接上了，而这正是绝大多数 AI 集成项目断掉的地方。

如果你现在正打算启动这类项目，我会建议你先别急着选模型，先做三件事：把两个高频岗位的一天完整跟下来，记录他们查数据的所有动作；拉一次口径体检，看看同一个词在系统里有几种解释；再挑一个入口，想想能不能不新建系统就嵌进去。这三件事做完，方案自然就有了，而且大概率比外包给你的方案更贴地气。

技术的迭代速度不会等人，但员工的使用习惯只会被一点点改变。顺着习惯做设计，比逆着习惯做推广省力得多。这是我做了这么多项目之后，最想留给同行的一句话。

陈立群：写得很实在。我们去年也踩过”入口多开一个页面”的坑，日活从一百二掉到二十几，后来嵌回 ERP 才缓过来。想问下你们当时是怎么说服业务部门接受答案有延迟的？

王雪梅：主数据那一段我特别认同。我们做过统计，AI 答错的问题里有一大半是同一个客户在不同系统里名字不一样造成的，跟模型真没关系。后来把客户主数据统一了，同样的问题基本不出错了。

周海涛：重复使用率这个指标我们也在用，确实比提问量真实。不过我想补充一点，我们后来发现按岗位分层看更有意思，一线班组的重复使用率反而比中层高，因为他们的问题更具体。

李振国：我们正在做数据集那块，作者说的”数据集是地基”我有切身体会。一开始直接把数据表接上去，问答效果很飘，后来做了清洗和标注，同一个问题的答案稳定多了。

赵敏：采购场景里我也想试一下。不过我们属于强合规行业，答错代价比较大，作者说的”AI 只做定位、不做判定”这个思路给了我很大启发，准备按这个思路跟领导汇报。