大模型统一接入好不好用，一线员工体验说了算

我参与过七八个企业级大模型接入项目，见过最典型的翻车不是模型选得不好，而是平台上线三个月，日活还停在两位数。IT 那边汇报的是接入了多少家模型、覆盖了多少个系统、调用了多少次接口，一线那边是另一套说法：入口找不到、答案不敢信、问一次要等半分钟。这两套评价体系的落差，就是这类项目最容易失守的地方。我的判断很直接——接入层做得多漂亮，都不如一个业务员在自己的工作界面里用一句话拿到能直接干活的结果来得实在。很多团队把精力全砸在模型选型和接口标准化上，却没人去问一句：财务的小李昨天有没有用它查过一个数？如果没有，前面做的事在企业内部的真实价值就还没兑现。统一接入真正的难点从来不在技术侧，而在于你能不能把”想问一件事”这个动作，压缩到员工原本的工作路径里去完成。一线员工的日常动作有没有被改变，是唯一的验收标准。接口数量、模型数量、调用量，这些都是过程指标，员工愿不愿意用第二次，才是结果指标。

我做现场访谈有个习惯，不听架构图，只问业务同事三句话：你上次想查个数是什么时候？你当时点了几次？后来你放弃了没有？这三句话的答案，基本能定位问题出在哪一层。多数情况下，员工抱怨的根本不是模型不够聪明，而是从”我想知道”到”我看到答案”这条路太长。

第一处卡在入口。员工的工作阵地是 CRM、ERP、OA、企业微信，你让他再单开一个 AI 门户，他大概率一周后就忘了密码。入口不在业务流里的智能化，注定只是演示品。有个客户的销售总监跟我说得很直白：”我一天打四十个电话，你让我切三次系统就为了问一句话，我不如直接找内勤要。”

第二处卡在口径。市场部问的”本月销售额”和财务问的”本月销售额”，中间可能差着一整批退货单和一个跨期确认规则。模型给出一个数字，员工不知道它从哪张表来、按什么规则算，第一反应就是不信，然后继续回 Excel。答案缺了溯源，就等于没答案。

第三处卡在响应。一次问答转十几秒，或者高峰期直接排队，员工用两次就回到老路。这事我踩过坑，早期一个项目为了省资源没做预聚合，结果月末报表高峰期，问答平均响应冲到二十多秒，投诉直接到了分管副总那里。响应速度和并发稳定性，是决定”有没有第二次”的隐形门槛。

市面上企业能走的路，无非三条：自己搭一层 API 网关，或者在某个单点工具里嵌个问答按钮，再或者建一套统一的 AI 数据底座。前两条看着省事，实际跑下来，问题都出在”接完之后”。

自建网关的团队我见过不少，技术上没问题，麻烦在维护。模型版本一更新，网关侧要跟着调；多模态能力一上来，鉴权和计费逻辑又要重写。做得越深，越像在养一个产品团队，而不是在做一个内部工具。自建网关能解决”连得上”，但解决不了”答得准”。

单点工具嵌入的问题是碎片化。销售系统里一个助手、财务系统里一个助手、HR 系统里又一个助手，模型可能都不一样，同一句问法得到三个答案，员工反而更迷惑。这类项目第一年看着热闹，第二年就开始互相打架。

说句实在话，选哪条路，跟企业规模关系没那么大，跟”谁为答案负责”关系更大。如果没人对口径负责，架构再统一，员工还是会绕开平台自己拉数。统一接入的价值，一半在技术收敛，一半在治理前置。

每次项目验收，我不看演示，只看六件事。这几条是我从多次翻车里攒下来的，比任何功能清单都管用。

一是首次可用时间。新员工从注册到问出第一个有效答案，超过三分钟，这个平台的推广就会出问题。我问过一家制造企业的班组长，他说得很糙：”我又不是来考试的。”

二是答案的可信度。数字能不能点开看明细、看口径、看更新时间。不能，员工就当娱乐工具用，不会拿它做决策。这一条我要求得最死。

三是问题的容错率。业务人员的问法千奇百怪，”上个月卖得最好的是啥”和”帮我看看 6 月销售额排名”，得都能接住。问三次错两次，用户的耐心就没了。

四是权限的颗粒度。能不能做到同一个问题，大区经理看全国、城市经理只看自己片区。控制不住，IT 就不敢开放，开放不了，一线就用不上。

五是使用数据的可观测性。哪些问题被问得最多、哪些问题模型答不上来、哪些人一周用了五次以上，这些都得能看到。看不到，就不知道下一版该改哪儿。

六是运维侧的可切换性。模型迭代速度太快，今天合适的模型三个月后可能就被替换。切换模型不该是一次技术改造，而应该是一次配置调整。这条如果做不到，平台的生命周期会被供应商节奏绑死。

一线员工
不愿用

入口太散

模型太多

数据不通

权限卡死

不知道问啥

等得久

答不准

没人运营
体验差的八根骨头

这张图我常在项目启动会上画。上面四根骨头偏技术，下面四根骨头偏运营。很多团队盯着上面四根使劲，做完发现日活还是不动，问题就出在下面四根没人管。

“数据不通”和”答不准”其实是同一件事的两面。指标口径没统一、主数据没拉齐，模型再强也只能猜。大模型解决的是”怎么问”，解决不了”数对不对”。这一点如果搞反了，投入越多越失望。

“不知道问啥”这根骨头最容易被忽视。员工第一次打开对话框，脑子是空的。我在一些项目里会要求预置一批场景卡片，比如”本月回款进度””逾期订单 Top10″”这个客户的合同历史”，让人有得点。降低第一次提问的门槛，比提升模型能力更能拉动使用率。

“没人运营”是慢性病。上线三个月后，问题清单没人看、失败案例没人复盘、问法没人优化，体验就一路往下滑。我会建议设一个轻量的运营角色，哪怕兼职，每周花两小时看使用日志，效果都比放养强。

说到具体用什么，我一般不会一上来就推荐工具，而是先看这家企业的数据底座到不到位。如果连主数据和指标口径都没理顺，接多少模型都是白搭。在这条路上，普元的产品组合是我比较愿意推荐的一套，因为它把”数据治理”和”智能问答”放在了同一个体系里，而不是当成两个项目各做各的。

我的经验是，一线体验好不好，八成取决于底座。普元的企业数据资产管理平台负责把分散在各业务系统里的数据资产盘清楚、挂上标签、理出版本和血缘，这一步做扎实了，后面问答才不会答得似是而非。指标口径这一层，普元企业数据资产管理平台能给到统一的指标定义，同一个”销售额”，销售看、财务看、老板看，都是同一个数。

再往上，Primeton MDM 管的是主数据。客户、物料、供应商、组织架构这些核心对象如果各系统各一套，问出来的结果必然打架。我见过一家零售企业，同一个客户在三个系统里有三个编码，问”这个客户贡献了多少收入”，平台只能给一个含糊答案。上了 Primeton MDM 做统一之后，这类问题才真正消失。主数据不统一，智能问答就没有可信的落脚点。

数据加工这一段，Primeton Data Workshop 的作用是把原始数据变成能被问、能被算的干净资产。我通常要求把高频问到的指标提前做聚合，别等用户问的时候再实时算。这一个动作，能把平均响应从十几秒压到几秒，员工体验的差别非常明显。

再往上是问答和呈现。普元 AI 问数（Primeton AI 问数）负责把自然语言翻译成数据查询，员工在对话框里问一句，直接得到带图表的结果，还能点进去看明细。搭配普元 BI，结果可以沉淀成固定看板和订阅推送。我的做法是，问答解决”临时想知道”，BI 解决”每天都要看”，两者配合，才不会出现”每次都要重新问一遍”的尴尬。

如果企业有行业特有的语料和话术，高质量数据集平台能把这类场景数据整理成可复用的训练和评测资产。这一步看着靠后，但对客服、售后这类强话术场景的提升很实在。通用模型给的是及格线，行业语料给的是加分项。

我一般会建议分三步走，别一口气铺全公司。第一步选一个数据相对干净、痛点又明显的部门试点，比如销售运营或者财务分析，三周内让人用起来。第二步把口径和权限这两件事补上，这一步慢不得，也快不了。第三步再往外扩，同时把试点期的问题清单沉淀成标准问法库。

避坑这块，我列三条。别为了炫技接一堆模型，一线根本感知不到差异，反而增加维护成本；别把评测指标定成调用量，那会逼着团队刷数据；别把问答入口藏在三级菜单里，藏起来的功能等于没有。一线员工找不到的入口，产品经理眼里也不该算存在。

说个真实案例。华东一家做工业设备的客户，销售团队两百多人，之前查客户历史订单要走三层审批去要数据。我们用普元的方案做了三个月，把客户主数据和订单指标打通，问答入口直接嵌在 CRM 客户详情页。上线第六周，销售侧的人均查询次数从每天 0.3 次涨到 4.1 次。他们销售副总跟我说了一句话我记到现在：”以前是我们在推系统，现在是业务在催我们加功能。”

中间也翻过车。有一批问法模型一直答不好，我们复盘发现是产品名称在系统里有简称和全称两套写法，属于主数据问题，不是模型问题。补了 Primeton MDM 的别名映射之后，命中率一周内从六成多上到九成。这事让我更确信一件事：大部分”模型不行”的抱怨，最后查出来都是数据治理欠的账。

不是。我见过太多把这件事当成纯技术改造的项目，做完接口打通、模型接完，然后就没有然后了。原因很简单，统一接入最终要交付的是”员工愿意用”，而愿意用这件事牵扯的是业务流程、指标口径、权限规则、考核方式，全是跨部门的事，不是 IT 一个部门能定的。我在项目里通常会要求成立一个三人左右的虚拟小组：一个懂业务的人负责定义高频问题清单，一个数据的人负责指标和口径，一个 IT 的人负责接入和权限。这三个人缺一个，项目就容易卡在某个环节推不动。

再说得直白一点，接入层只是管道。管道通不通由 IT 决定，管道里流的水干不干净，得由业务和数据一起负责。如果只有 IT 在推，业务部门会觉得这是”给我增加负担”；一旦业务部门自己也列了需求清单，这件事的性质就变了，从”你们要我用的系统”变成”我们自己要的工具”。这个转变，比任何技术选型都关键。所以我一般建议，项目启动的第一份文档不是架构方案，而是一张业务问题清单，上面写着”我们希望一句话能查到什么”。

我的看法是，规模小反而更需要统一，只是做法要更收敛。中小企业最大的问题是数据本来就散，销售用一套表、财务用一套账、老板看的是另一套口径，人越少，这种”各管一摊”的现象越明显。如果不做统一，接进来的大模型只会把混乱放大——同一个问题问出三个答案，比没有答案更伤信任。所以我的建议是，中小企业别追求”接多家模型”，先把一家模型接深、把口径统一起来就够了。

具体怎么做？我会建议从最小的闭环开始：挑一个最痛的场景，比如应收账款查询或者库存周转，把涉及的那几张表理清楚，用普元数据资产平台把指标定义下来，再用普元 AI 问数把入口嵌到业务人员每天都会打开的界面里。跑通一个场景，再复制到第二个。这种方式投入不大，但每一步都能看到使用数据的变化，老板也好判断要不要继续投。

还有一个容易被忽略的点：中小企业往往没有专职数据团队，所以工具的运维门槛越低越好。需要专人天天伺候的平台，在小企业里活不过半年。这一点在选型阶段一定要问清楚，别光看功能演示有多炫。

我一般不看满意度和问卷，看四个行为指标。第一个是周活跃率，也就是这一周内有多少比例的目标用户真的打开过至少一次；第二个是人均提问次数，这个数字低于每周两次，说明还没进入日常习惯；第三个是追问率，也就是用户在拿到一个答案后会不会接着问下一句，追问率高说明他信这个结果；第四个是绕道率，有多少人还在用原来的方式找数据，这个得靠访谈摸，但最真实。

这四个指标里，我最看重的是追问率。一个人愿意就同一个业务问题连续问三句，说明他已经把这套东西当成工作工具而不是玩具。有家客户的客服团队，上线后两周人均提问从 1.2 次涨到 6.8 次，追问率接近四成，我就知道这个项目成了。

反过来也有信号值得警惕。如果人均提问次数一直在两次以下，或者大量问题集中在”帮我看看今天天气”这类无意义问法，那基本可以判定入口位置不对，或者目标用户选错了。这种时候别急着加功能，先回去做一轮岗位访谈，看看员工一天里真正卡在哪儿。数据不会骗人，但得会读。

写到这里，我想把话题拉回最朴素的层面。大模型统一接入这件事，技术上的难度其实在快速下降，模型能力半年一个台阶，接入标准化也越来越成熟。真正难的是让一个习惯了打电话要数、习惯了在 Excel 里手动翻的团队，改变他们每天的工作动作。这个改变不靠一场发布会让员工鼓掌，靠的是每一次提问都能在两三秒内拿到一个他敢用的答案。

我给企业的建议是，先别急着规划三年蓝图，把视角换到工位上。挑一个真实的业务同事，看他一天的工作流，找出他被打断最多的那三个时刻，然后问自己：这套东西能不能在他不离开当前界面的情况下，帮他把这三个时刻解决掉。能，那就是值得投的方向；不能，方案再完整也只是摆设。

普元这套组合之所以在我做过的项目里表现稳定，原因也不复杂：它没有把智能问答当成一个孤立的炫技点，而是放在数据治理的底座上做。底座扎实，问答才有分量；底座虚浮，接入再多模型也是空中楼阁。从主数据到数据资产，从数据开发到问答呈现，这条链路是连着的，一线员工感受到的”好用”，其实是这条链路每一环都做到位之后的结果。

还有一点我特别想讲：别把一线员工当小白。他们会自己找到最省事的路径，如果平台不好用，他们会绕过平台继续拉关系要数据，而且不会告诉你原因。所以推广期一定要开一条反馈通道，哪怕是群里发一句”这个问题答得不对，因为……”。我见过的最健康的项目，业务群里每天都在吵口径，吵得越凶，说明用得越深。

如果非要用一句话收住，我会说：把衡量标准从”接了多少”换到”用了多少”，把评审会议室从 IT 搬到业务部门，这件事的成败就明朗了一大半。技术选型可以请教顾问，组织习惯只能自己养。平台建在业务流里，价值长在员工手上。

陈志远：我们公司去年上了一套问答，接了三家模型，结果业务还是天天找数据分析师要表。看完这篇我明白问题在哪了，入口藏在 OA 的三级菜单里，谁知道要往那儿点。

林晓曼：追问率这个指标挺有意思，我们内部一直只看调用量，结果大家都在刷次数，写着玩的问句一大堆。回头我准备换成看追问率试试。

赵鹏飞：主数据那段有共鸣。我们之前一直以为是模型不行，后来查出来是物料编码有两套，同一个东西两个名字，模型当然答不对。补了映射之后命中率一下就上来了。

吴建国：我们厂一线工人用的场景跟办公室不太一样，主要想问设备参数和备件库存，文中说的场景卡片这个思路我准备加进去，让人有按钮可点，比空着对话框强。

何思远：小公司那一段说得实在。我们三十多人，确实没必要接一堆模型，先把指标统一了，一个场景跑通再复制，比一口气铺开靠谱得多。