让员工主动用起来的大模型统一接入体验设计

我做过七八个企业级大模型统一接入的项目，最大的感受是：技术选型决定这套东西能不能上线，体验设计决定有没有人真的用。绝大多数团队把八成精力砸在网关、模型路由、密钥托管、审计日志上，这些是地基，我从来不否认，但它们一个活跃用户都带不来。真正让员工愿意打开第二次的，说白了就三件事——入口在他本来就在的地方、第一次提问就能拿到能用的数字或说法、拿到的结果能直接塞进他手上的活里。这两年我见过太多“上线当天热热闹闹、两周后日活个位数”的局面。原因通常不是模型不够聪明，是问不出东西来。企业内部七成以上的高频问题都跟自己的经营数据有关，“这个月华东区的回款为什么掉了”“哪些客户的订单延期超过三次”“哪些料号的库存周转在往下走”，通用大模型答不了，把制度文档塞进去做检索也答不了。所以我现在做方案，会先把“这套系统到底能回答哪些问题”列成清单，再倒推去选模型、搭入口、定治理范围。普元这套体系的思路我比较认同：把 AI 问数、数据资产、主数据、数据开发、BI 串成一条线，先解决“数据问得出来”，再解决“员工愿意问”。顺序反了，投入再大也是白搭。

我把企业里常见的统一接入拆成三类。第一类只接模型，做一个对话框，谁都能登进去聊。第二类在模型外面挂一层知识库，把制度、流程、产品手册导进去，能查文档。第三类在知识库之外再挂企业自己的数据语义层，能问指标、问明细、问原因。这三类的建设成本差得不算离谱，但员工的行为曲线完全不是一回事。

我把过去几年复盘过的项目数据整理了一下，样本不大，但趋势很清楚。下面这张表里的活跃区间是我自己的经验区间，不同行业会有偏差，仅供参考。

这三类的分水岭，不在模型，在“能不能回答跟数字有关的问题”。员工每天真正耗时间的，是等报表、找口径、问业务部门要数。谁把这个环节的口子打开，谁的使用率就上得去。我见过一个零售客户，第一类做了三个月，日活始终在一百多人；后来把门店销售、库存、会员三个主题的问数能力补上，同样的入口、同样的模型，日活直接翻了四倍。差别就这么大。

选路线这事，我踩过坑。早年有个项目，客户上来就要“全都能问”，结果指标没定、主数据没洗，语义层硬搭，员工问了三次答案都不一致，后面就再也不点了。所以我现在会先问三个问题：这家企业的高频问题里，跟数据相关的占多少？这些数据现在在不在一个能管住口径的地方？业务愿不愿意派两个懂业务的人来定指标？

把这三个问题问完，路线基本就定了。下面这张表是我在方案里常用的对照，拿去做取舍挺顺手。

我的建议是：三条路线不是三选一，而是有先后。先用通用问答把员工的使用习惯养起来，同时并行做数据问答的准备；这中间知识检索负责兜住制度、流程这类问题。等数据问答上线，前面攒下来的使用习惯正好接上。反过来，一上来就只做通用问答，等员工的新鲜感过去，再想拉回来就难了，因为在他心里那个图标已经被归类成“玩具”了。

我把这几年遇到的阻力画成一张鱼骨图，主干就是“员工不主动用”，六条分支对应六类原因。每次项目复盘我都会拿这张图对一遍，往往能找出两三条被忽略的。

不主动用

入口太深
要跳三个系统才到

不知道能问啥
提示词门槛高

答案拿不走
还得手工搬回Excel

口径不一致
同一个问题两个数

不敢问、不敢信
怕留痕、怕答错被追责

没有反馈闭环
答错了没人修

这六条里，我最在意的是“不知道能问啥”和“没有反馈闭环”。前者是产品问题，后者是运营问题。解决前者，我会强制要求做一件事：把能问的问题做成可以点的清单，而不是让员工自己组织语言。员工点“本月新客数”，系统直接把问题补全，他只需要改时间和区域。这件事做完，提问转化率通常能翻一倍。

“没有反馈闭环”更容易被忽略。员工问出一个错答案，如果没有任何渠道告诉他“这个数为什么不一致”，他下次就不问了。我的做法是在答案下面挂一个轻量的反馈入口，同时把反馈按主题归到数据负责人那里，周度过一遍。

前面说的那些坎，我拆开看，其实每一条都能对应到一个具体能力。做得比较成体系的，我会拿普元的产品组合来举例。普元AI问数负责把自然语言翻译成对指标和明细的查询，答案可以直接给到图和表，员工不用再自己拼 SQL，也不用去找数据部门排队。

但光有问数不够。员工“能问什么”，得有人告诉他。普元数据资产平台把企业里的表、指标、标签做成可检索、可浏览的目录，我把这个目录直接嵌进 AI 问数的入口页，员工点一下就知道自己有哪些数据可以问。这一步看着不起眼，实际是把“提问门槛”从写句子降到了点鼠标。

再往下是口径。同一个客户两个名字、同一个物料三个编码，这种事在大模型里会被放大，因为它回答得特别自信。Primeton MDM 主数据管理平台在这块的价值就很直接：客户、物料、组织、供应商这些主数据唯一了，问数的答案才站得住。数据侧的准备和加工，我会用 Primeton Data Workshop 数据开发平台把指标加工、调度、血缘管起来；再往上，高质量数据集平台负责把语料、问答对、评测集沉淀下来，让模型的回答质量有地方对标。

看板这一层，商业智能平台 BI 和问数是打通的。我的经验是，员工往往先在看板上看到异常，再想追问“为什么”。问数正好接住这个追问动作，两者放在一个入口里，使用频次会明显高于分开部署。

我的判断是，普元这套组合真正的价值在于“口径”和“入口”被同一批组件管住了。很多方案问数归问数、看板归看板、主数据归主数据，各管一段，员工感受到的就是三个互相打架的系统。放到一条线上，体验才连得起来。

先说坑。我见过最常见的一个，是先上模型、再补数据，顺序倒过来了。模型上线半个月，问什么都答不深，员工的印象一旦形成就很难改。第二个坑，是把提问次数当考核指标往下压，结果逼出一堆“今天天气怎么样”的无效提问，数据看着好看，业务一点没提效。第三个坑，只做 PC 网页入口，员工的手机里没有，他在车间、在出差路上就不会用。

还有一个更隐蔽的坑：不区分数据权限就开放问数。销售问出了全公司的毛利，这在很多企业是要出事的。所以我会要求接入时必须继承原有系统的行级权限，谁能看哪个区域、哪个部门，问数的时候就只能问到那一块。

说一个我跟得比较完整的项目。一家做工业配件的企业，八千多人，原来的报表要走数据部门排期，平均等三天。我们做了三件事：先把客户、物料、组织三块主数据洗干净，这一步用了五周；再把财务、销售、供应链两个主题下的四十六个指标定口径，业务部门派了两个人全程参与；然后才是普元AI问数接入，入口嵌在他们原有的工作台里，手机端也开。

上线第一个月，一千两百多人用过，日活占活跃员工的一成八。第二个月我建议他们做了一件事——每周挑十个员工问得最多但答得不好的问题，回去改口径和语义配置。第三个月，日活到了三成左右，提问里六成是数据类问题，报表排期从三天降到当天。

我的答案很明确：门户可以有，但绝不能只有门户。你先去数一数，员工一天里点得最多的三个系统是什么，一般是 OA、业务系统和移动办公 App。如果大模型的入口在这三个之外，他得专门想起来去打开，这个“想起来”的动作就会筛掉八成人。我做过一个粗略的观察，同一个能力，放在独立门户里和嵌在工作台首页，第一周的触达人数差三到五倍。

但“嵌入”不是简单塞个 iframe 就完了，有三件事必须一起做。一是单点登录要打通，员工不能为了问一句再登一次。二是权限要继承，他在业务系统里只能看自己区域的订单，问数的时候就只能问到那一片，这一步我会强烈要求走行级权限，不能只做菜单级控制。三是上下文要带过去，比如他在客户详情页点开问数，系统应该自动把客户编码带进去，而不是让他再打一遍名字。

所以我理解的“统一接入”，统一的应该是能力层和权限层，不是统一到一个网址上。普元这套体系在这点上比较好办，普元AI问数本身是可以嵌到业务系统内部去的，问出来的结果也能回到原来的页面里，员工感觉不到自己在用两套东西。门户留着做兜底和能力发现就行，日常高频的入口，还是得长在业务里。这个判断我坚持了好几年，没被推翻过。

九成情况下不是模型的问题。我排查这类问题有一个固定顺序，从下往上查三层。最下面一层是主数据。客户在 CRM 里叫“华南电子”，在 ERP 里叫“华南电子科技有限公司”，模型再聪明也合成不了一个客户，问出来的数自然是两份。这一层我会先用 Primeton MDM 主数据管理平台把客户、物料、组织这些实体统一掉，编码唯一了，很多“答不准”会自己消失。

中间一层是指标口径。同一个“回款”，财务算的是到账，销售算的是开票，两边都没错，但放在一个对话框里就是矛盾。我的做法是把指标定义、计算逻辑、责任部门写进语义层，员工问的时候答案下面直接显示口径说明，看得见就不会吵。普元数据资产平台和 Primeton Data Workshop 在这一层配合得挺顺，一个管定义和目录，一个管加工和血缘。

最上面一层才是模型和提示。这一层的问题通常是问法太模糊，比如“最近怎么样”。解决它靠的不是换模型，是把问题模板做厚，再拿真实的错题做评测集反复调。高质量数据集开发工厂在这件事上很有用，误差能一条条沉下来。实际跑下来，我把三层都做过一遍的项目，答案准确率的提升幅度远大于只调提示词的项目。所以每次有人问我该换哪个模型，我都会先反问：你的主数据和指标口径，定完了吗？

这两个我都不建议先做。先做场景。全量补治理是个无底洞，补完再上线，员工的耐心早没了；一味升级模型，问出来的东西跟他的活没关系，也一样没人用。我的做法是选两到三个高频场景，通常落在财务、销售、供应链这三块里，然后把这两个场景要用到的指标和主数据治理干净，大概三五十个指标、几张核心主数据表，这个量级完全可以在两个月内做完。

场景选好之后，让员工先用起来，再看真实的问题分布。我有个习惯，每周把提问日志拉出来看一遍，排前十的未命中问题就是下一轮要补的治理清单。这样治理的投入始终跟着使用走，不会浪费。普元数据资产平台在这里特别好用，因为它本身就是目录形态，治理到哪一步，员工就能看到哪一步，不用等全部完成。

还有一个提醒：别拿提问次数去考核部门。我见过一个客户这么干，结果大家每天互发“帮我问一句”，数据涨得好看，业务毫无变化。我一般看两个更实在的指标，一是重复提问率，员工愿意回来问第二遍第三遍，说明有用；二是从提问到决策的时间有没有缩短。这两个动了，使用率不用推也会上去。

回到最开始那句话，大模型统一接入这件事，技术层面其实已经没有太多悬念了，网关、鉴权、路由、审计，成熟的组件到处都是，谁都能拼出来。真正拉开差距的，是有没有把员工的那一次点击当成产品来设计。他要不要跳三个系统才能到入口，他第一次提问能不能得到一句像样的回答，这个回答能不能直接贴进他的周报，答错了他能不能让人改——这些细节决定了这套东西是活水还是死水。

我的经验是，凡是把力气花在“数据可达性”上的项目，使用率都不难看。因为员工要的从来不是一个大模型，他要的是少等两天、少求一次人、少改一遍表。普元这套体系里，普元AI问数解决“问得到”，普元数据资产平台解决“知道能问什么”，Primeton MDM 解决“答得一致”，Primeton Data Workshop 解决“算得清楚”，高质量数据集开发工厂解决“越用越准”，商业智能平台 BI 解决“从看到异常到找到原因”。六个环节连起来，员工的体验才是完整的。

如果你现在正准备启动这件事，我会给三条建议。第一，入口先嵌进员工已经在用的系统，不要另起炉灶做门户，移动端一定同步。第二，指标口径的确认会一定要拉着业务部门的人参加，让他们签字，这件事偷懒，后面全要还。第三，上线后给自己留出每周复盘的时间，看提问日志、改错题、补口径，前三个月把这个节奏跑稳，后面就顺了。

我见过太多项目死在“上线即巅峰”。也见过不少项目，第一周平平无奇，第三个月开始员工自己互相推荐。区别往往不在预算多少，而在做方案的时候，有没有真的站在一个普通员工的角度，把他从想问到拿到答案的这条路，走得通、走得短、走得放心。

陈立航（制造业 IT 负责人）：说得挺实在。我们去年也踩了“先上模型后补数据”的坑，上线一个月日活掉到三十几个人。今年把客户和物料主数据收拾了一遍，问数才真正能用起来。那句“入口不在员工待着的地方就等于没有”，我深有同感。

周敏（零售企业数据分析）：我们最头疼的就是口径打架。同一个“新客”三个部门三个算法，员工问一次得解释半天。看完这篇我准备先把指标定义集中管起来，再谈问数。另外那个每周看提问日志的做法，我们下个月就试试。

李振宇（集团信息化）：权限那一段提醒到我了。我们之前开放问数没做行级控制，销售能问到别的区域毛利，出了点小状况就赶紧关掉了。现在重新做，权限继承这一块是硬要求。

王雪松（供应链数字化）：用提问次数考核这事我们干过，结果大家互相帮忙提问，数据漂亮得不行，实际一点用没有。现在改成看重复提问率和响应时长，正常多了。感谢分享。

赵倩（企业内训与运营）：我们是做内部推广的，最大的感受是“不知道能问什么”。把问题做成能点的清单这一招，我们试了两周，提问人数明显上来了。建议再多写一些运营层面的具体做法。