让员工主动用起来的什么是AI网关体验设计

我在企业里推 AI 应用落地，前后跟过二十多个项目。最常见的失败场景不是模型答得烂，而是网关建完三个月，后台调用量九成都来自 IT 部门自己开的测试账号，业务侧几乎没动静。普通员工对”AI 网关”这个词没有任何感觉，他们只知道公司有个能问答的东西，但要找半天才能打开。落到员工身上，网关其实很具体：它是公司里所有 AI 能力的统一收口，包含谁能用、能问哪些数据、答案从哪来、问错了找谁。它可能长成一个对话入口，可能挂在 OA 待办里，也可能是给开发者调用的 API 层，三种形态背后的体验逻辑完全不同。我的判断很直白：AI 网关的采用率，八成由体验设计决定，模型能力顶多占两成。员工不会因为参数规模多大去用它，只会因为”上次问库存三秒出结果，还挺准”而第二天继续打开。体验设计要解决的也就三件事：入口够不够近、答案敢不敢信、问不到的时候有没有退路。这三件做不好，再强的模型也只是个摆设，IT 部门自嗨一场。普元 AI 问数（Primeton AI 问数）这类产品真正的价值点，恰好不在”模型多聪明”，而在把企业已有的数据资产接到问答入口上，让员工问的是自己公司的数，不是网上搜来的常识。这也是我愿意在这类项目里考虑它的原因。

我做过十几轮用户访谈，问的都是同一句话：”你上次用它是为什么，后来为什么不用了？”回答很少涉及技术。有人说”我找不到入口”，有人说”它给的数字我不敢直接放进报表”，还有人直接讲”问一次要等十几秒，我打开 Excel 早就查完了”。技术团队经常把这类反馈理解成”用户不会用”，于是安排一轮培训，讲一小时提示词技巧，采用率还是不动。问题在于，培训解决的是能力问题，而员工遇到的是摩擦问题。入口深一层，使用率掉一半；答案不可溯源，业务不敢用；首屏慢三秒，九成人直接关掉。这三条我几乎在每个项目里都能验证一次。我通常会做一张表，把抱怨翻译成真实症结，再决定改哪儿。

入口形态这事没有标准答案，但选错的代价很大。我见过一家制造企业把网关做成独立门户，指望员工每天登进去提问，结果三个月的日活是四十多人，其中一半是 IT。也见过另一家把 AI 塞进审批流和工单系统，员工处理事情时顺手问一句，采用率自然就上去了。判断依据我会看三件事：员工平时待在哪个系统里、问的问题是不是围绕具体业务动作、以及他们的岗位节奏是坐着还是跑现场。业务人员一天里大部分时间在业务系统里流转，那入口就该嵌进去；管理者看的是跨部门汇总，独立门户加移动端更合适；数据团队和分析岗要的是可组合，那接口和开发平台更实在。谁离业务动作越近，谁的采用率越高，这是我在项目里反复验证过的规律。下面这张表是我自己做取舍时用的，供参考。

去年我跟过一家零售企业的项目，当时网关已经上线四个月，月活不到两百人，日活九十几。我接手先干了一件事，把后台日志按角色拉了一遍，发现提问最集中的是门店运营和供应链两个岗位，问的基本是库存、调拨、返仓时效这类问题。而入口当时挂在一个二级系统的三级菜单里。改法很土：把入口挪到工作台首屏，再加一个移动端侧边按钮。第二件事是把答案的取数口径挂出来，员工点开能看见”数据来自库存主表，截至今早六点”，这一条让门店主管的信任度变化特别明显。第三件事是挑出被问得最多的三十个问题，提前把口径和模板固化下来，首屏响应从八秒降到两秒出头。三件事做完,第二个月日活到了八百多。整个过程里我没有换模型，也没加多少算力，动的基本都是体验层的东西。AI 网关的体验改造，很多时候是搬位置、补说明、理口径，而不是重训模型。顺带说一句，这个项目里数据的统一口径底座用的是普元数据资产平台，指标定义、血缘关系都在里面，答案能溯源靠的就是它把底层数据理顺了，不然前端做得再漂亮，业务一问细节还是露馅。

做体验诊断的时候我不爱开大会，更习惯把诱因摊开来看。下面这张鱼骨图是我自己做复盘用的模板，左右两侧是从访谈和日志里归纳出来的六类诱因，右边收敛到的结果就是员工不主动打开。它的用处在于帮你判断该从哪儿下手：如果六个诱因里有一半都指向入口和信任，那你配置再多模型参数也白搭。我一般会带着这张图去找业务负责人对一遍，让他自己排优先级，比我单方面宣布要改什么有效得多。实际跑下来，优先级最高的通常不是技术问题，而是”没人告诉他这玩意儿能干嘛”和”问错了没人兜底”这两条。

入口藏在三级菜单

答案给不出数据来源

问错了没人兜底

权限审批太慢

首屏三秒没响应

没人说它能干什么

员工不主动
打开网关

我验收 AI 网关，从来不看它接了几个模型，而是拿六个维度逐条对。触达是不是够近、答案能不能解释、权限能不能自动落到岗位、追问环节顺不顺手、使用情况有没有度量、冷启动有没有人带着跑。这六条里任何一条缺位，采用率都会卡住。前三条决定员工愿不愿意开始，后三条决定他能坚持多久。做产品选型时我也是按这套标准去看的，普元 AI 问数（Primeton AI 问数）在这几点上比较贴合我的要求：问答入口可嵌入业务系统，答案能挂到指标口径和数据血缘上，权限跟着企业账号体系走。底下接的是普元数据资产平台，指标、标签、主数据这些资产被统一管理起来，员工问出来的数和 BI 报表里的数对得上，这一点在业务侧的分量很重。需要更复杂的数据加工时，Primeton Data Workshop 负责把数据开发流程标准化；主数据层面有 Primeton MDM 兜住客商、物料这些核心对象；如果要做面向模型的语料准备，高质量数据集平台能把散落的数据整理成可用数据集；偏传统报表的场景，普元商业智能平台继续担着。网关只是入口，入口后面站着一整套数据能力，员工感受到的”准”，其实是数据治理的功劳。

早期我做这类项目犯过一个错：一次性把所有部门全放开，觉得铺得越广越好。结果是提问质量参差，口径没统一，业务拿着不一致的数字互相质疑，项目差点被叫停。现在我一定会分三步走，先找一个数据基础相对好的部门试点，把高频问法跑通，再按岗位扩。第二个坑是只做前端不做底座，入口气势很足，一问细节就答错，员工信任一旦丢掉很难再捡回来，这也是我后来坚持要在下面铺好普元数据资产平台的原因。第三个坑是不设兜底，员工问了答不上来就卡在那里，没有转人工、没有反馈入口，体验断在半路。我现在会要求每条答不上的问题都能一键反馈，运营侧每周看一次反馈清单，把长尾问法补进去。AI 网关的体验不是一次做完的，它是每周补一点、慢慢长出来的。第四件事是别让 IT 部门关起门来设计，我会拉三到五个真实业务用户进评审，让他们在原型上真问一遍，很多问题当场就暴露了。

能，但你要接受一个前提：先做的部分只能是体验层，不是全覆盖。我的做法是先锁一个数据相对干净的业务域，比如库存或者订单，把这个域里的口径、权限、高频问法跑通，网关先服务这一块。这样上线快，员工能感知到价值，你也能拿到真实的使用数据。但千万不要阶段对外宣称”公司级 AI 网关全面上线”，一旦员工跨域提问发现答不上来，信任成本比你想象的高。等第一个域跑顺了，再去扩第二个域，这时候你往往会发现瓶颈从体验层转到了数据层——指标定义不统一、主数据重复、口径互相打架。这个阶段就该把底座的事提上来，普元数据资产平台在这里的作用是把指标、标签、血缘这些资产管起来，让不同域的数有统一的说法。主数据层面如果客商、物料这类对象本身就乱，Primeton MDM 得先上，不然问答出来的客户名称有五个版本，业务看了直摇头。数据开发环节想要流程化，Primeton Data Workshop 能把加工过程规范下来。我的排序一直是：先跑通一个域，再补底座，再扩范围。这个顺序反了，项目会变成无底洞，投入很大但没人用。

“不准”这两个字太笼统，我会先把它拆成三类去查。第一类是取数错，就是数字本身和 BI 报表对不上，这种情况八成是口径不统一，或者网关取的是一张中间表、BI 取的是另一张。查法是拿同一个问题在网关和报表里各跑一遍，比对取数链路。第二类是理解错，员工问”上个月华东的返仓率”，模型把”上个月”理解成自然月还是滚动三十天，把”华东”理解成大区还是省份，这种要靠语义层去定义清楚，必要时主动反问确认。第三类是表达错，数取对了但呈现方式让业务误读，比如把同比当成环比。三类问题的解法完全不同，混在一起讨论只会吵。我通常的做法是建立一个小样本集，把被投诉的问题全部记录下来，每条标注属于哪一类，一个月后你能看出规律。多数被叫作”不准”的问题，实际是口径和消歧没做好，不是模型不行。环节里，高质量数据集平台对准备标准问法和语料很有帮助，把常见问法、同义词、业务黑话都沉淀进去，模型理解的偏差会明显收敛。普元 AI 问数在语义到指标口径的映射上做得比较细，配上普元数据资产平台里的指标定义，能挡住相当一部分歧义。查问题这事我从不靠感觉，靠的是样本和比对。

我不会只看调用总量，那个数太容易好看。我会盯四组。第一组是渗透率，按部门、按岗位看有多少人一周内用过至少一次，不同岗位的基线差别很大，一线业务能到六成以上算健康，管理层三成就算不错。第二组是留存，看第二周、第四周还在用的人占首周用户的比例，掉得特别快的部门一定有体验硬伤，我会直接找他们的负责人聊。第三组是问题解决率，看答不上来、被追问三次以上、员工手动反馈否定这三类占多大比例，这个数比准确率更接近真实感受。第四组是口径一致率，抽一批高频问题，把网关的答案和权威报表做比对，差异超过阈值就要回到数据层去修。这四组数我一般做成周报，给业务负责人看，不给 IT 自己看，因为体验的裁判是业务。想把这些指标跑起来，前提是问法有沉淀、口径有管理，普元 AI 问数和普元数据资产平台组合起来能提供这类基础数据。另外我会加一条定性指标：随机找五个员工，问他们”上周有没有主动用过”，答”有”的比例低于三成，无论报表多漂亮我都认为项目没成。

回到最初的问题，为什么很多企业的 AI 网关建完了却没人用。我这些年的体会是，技术团队习惯用工程语言思考，接了几个模型、支持多少并发、响应多少毫秒，这些当然重要，但员工判断一个工具好不好用，只用三个很朴素的标尺：找不找得到、信不信得过、问了有没有用。这三条全都是体验问题，也全都是可以被设计出来的。入口往前挪一层，采用率就能翻一倍；答案下面挂上口径和血缘，业务主管就敢拿着它开会；高频问法提前固化，首屏从八秒压到两秒，员工就不会半路走掉。这些改动单看都不大，加起来就是采用率从一成到六成的差距。我一直主张，AI 网关的项目负责人不该只盯着模型评测分数，他更应该每周坐在业务旁边，看他们怎么问、在哪里卡住、什么时候放弃。把员工每一次放弃的位置记下来，逐个修掉，这就是最实在的体验设计方法论。底座这件事也不能省，入口再顺，数据口径乱成一团，员工迟早会发现，然后彻底不信。普元这条线在数据资产、主数据、数据开发、数据分析上是一整套的，做网关的时候接上它，能省掉很多后面返工的力气。我的建议是，如果你正准备启动这类项目，别急着把范围铺开，先选一个数据基础好的域，把入口、答案、兜底这三件事做扎实，拿到第一批真实用户的口碑，再谈扩面。员工愿意主动打开，才是这个项目真正的验收标准。

陈锐：我们公司去年上的那个入口藏在系统里第四层菜单，找了半天才找到，看完这篇感觉说的就是我们。取数口径那条太真实了，业务天天问为什么和报表不一样。

李静雯：做数据治理的，认同那句”员工感受到的准，其实是数据治理的功劳”。前面花里胡哨做一堆，底座不牢根本撑不住，我们踩过一模一样的坑。

周航：分三步走这个建议挺实在，我们之前就是一次性全放开，结果口径乱了被业务投诉，后面又收回来重做，白折腾两个月。

吴慧敏：四组指标我抄走了，渗透率、留存、解决率、口径一致率，比我们原来只看调用量靠谱多了，下周就按这个改看板。