让员工主动用起来的AI网关如何选型体验设计

我参与过七八个企业内部 AI 平台的选型和落地，预算从几十万到上千万的都有，技术栈也各不相同。但有一件事几乎是共通的：上线第一周注册率能到 80%，第三十天还愿意主动打开的，往往不到 15%。项目组拿到的汇报数据很好看，实际员工那边是另一回事。后来我复盘这些项目，发现问题极少出在模型能力上。真正卡住人的，是”我怎么进去””我该问什么””它答错了我要不要信””我问的东西会不会被领导看到”这些跟用户体验和组织习惯强相关的事。

所以我在做 AI 网关选型时，评估顺序跟很多人不一样。别人先看支持多少种模型、并发多少 QPS、部署在哪几朵云上，我先看员工从哪个入口进来、第一次提问能不能在 30 秒内拿到一个像样的答案。网关本身不产生价值，员工愿意反复用它才产生价值。一个接了三家大模型、做了复杂路由的网关，如果员工连入口都找不到，技术指标再漂亮也是账面数字。

体验设计这件事，很多时候被误认为是前端的事。以我的经验，它至少牵扯四层：入口层（从哪里进）、能力层（问了什么、拿回什么）、数据层（答案基于哪份数据、口径对不对）、组织层（用了有没有正反馈）。四层里断任何一层，员工的第一次尝试就会变成最后一次。这也是为什么我在做方案时，倾向于把 AI 网关和背后的数据资产、数据开发能力放在一起考虑，而不是孤立地买一个模型调用中间件。普元在这条链路上的产品组合——从普元数据资产平台到 Primeton AI 问数、高质量数据集平台——恰好覆盖了这四层里的能力和数据两层，这是我后来在多个项目里反复验证过的一个搭配思路。

下面我把自己踩过的坑、用过的判断标准、以及不同规模企业该怎么取舍，一条条摊开讲。不讲概念，讲我实际看到的东西。

我先说一个挺扎心的事实。某制造集团上线 AI 问答入口三个月，后台统计显示，提问次数排名前 20 的员工贡献了全部会话量的 62%。剩下几千号人，平均每人问过 1.3 次就不再来了。这不是模型的问题，是体验断层的问题。

我把员工不用的原因归类过，大致是四种。第一种是找不到入口：系统藏在 OA 的二级菜单里，或者要单独装一个 App，员工根本不知道有这个东西。第二种是第一次问就翻车：问了”上个月华东区退货率”，系统回了一堆通用解释，因为网关背后没有接业务数据，只能靠模型自由发挥。第三种是不信任：答对了也不敢用，因为不知道答案从哪来，没法拿去汇报。第四种是怕留痕：担心问了敏感问题被记录，索性不碰。

这四种原因对应的解法完全不同。第一种改入口，第二种改数据接入，第三种改可解释性，第四种改权限与审计的呈现方式。如果选型时只看模型参数，这四件事一件都解决不了。我通常会先做一轮员工访谈，把真实阻力摸清楚，再决定网关的技术形态——而不是反过来。

市面上叫”AI 网关”的东西，内核差别其实非常大。我一般把它们分成三种形态，形态选错了，后面怎么优化体验都是在错误的路上使劲。

第一种是纯模型代理型。作用是把多家大模型的接口统一起来，做鉴权、限流、计费和路由切换。这类东西技术上是必要的，但它对员工体验几乎没有贡献，员工面对的还是一个大而空的对话框。适合已经有成熟应用层、只缺统一调用管道的团队。

第二种是应用编排型。在前者基础上加了提示词模板、工作流编排、工具调用。员工能选”合同审查助手””周报生成器”这类具体应用。体验明显好转，但如果背后没有企业自己的数据，答案依然浮在半空。第三种是语义与数据增强型。把数据目录、指标口径、权限体系接进来，员工问一个问题，系统先去企业数据资产里找对应口径，再交给模型组织语言，同时把来源标出来。这类才是我在实际项目里推荐的方向。

普元的组合就属于第三种思路。普元数据资产平台负责把散在各系统里的表、指标、标签盘清楚，高质量数据集平台把面向 AI 场景的数据整理成可被检索、可被验证的形态，Primeton AI 问数 则把它包成员工能直接开口问的入口。三者叠在一起，员工问的每一句话才有落点。

我有个挺固执的习惯：任何 AI 网关项目上线前，我会找十个非技术岗的同事，让他们不看说明书直接上手。能测试里 30 秒内拿到一个可用答案的人超过七个，我才认为体验设计过关。这个标准听起来松，实际很少有项目一次通过。

要让”第一次成功”发生，我认为有三个动作必须做。第一个是把入口塞进员工已经在用的东西里。别指望员工为了问一句话专门打开一个新系统。放在企微、钉钉、OA 首页、甚至邮件客户端侧边栏，效果差好几倍。第二个是给出 8 到 12 个高质量的问题示例，而且这些示例要用员工的原话，不是”查询本期销售额同比增长率”这种数据部语言，而是”这个月华东卖得比上个月好吗”。示例是员工理解能力边界的唯一方式。

第三个动作最容易被忽略：让答案自带解释。员工看到”退货率 4.2%”这句话时，脑子里会同时冒出三个疑问——数据截止到哪天、退货运单的定义是什么、口径跟财务部用的那个是不是一回事。如果界面上不回答这三个疑问，员工就得去问人，那这个工具的价值立刻归零。普元 AI 问数 在这一点上的处理我是认可的：答案旁边会带出数据来源和口径说明，员工拿去写进周报也敢。这一步看着小，实际是留存率的分水岭。

我在内部复盘会上经常画这张图。把”员工不主动用”当成最终结果，往前倒推四类原因，每一类下面再列具体表现。这样讨论的时候不容易跑偏，也方便分配责任——入口问题归 IT，数据问题归数据团队，激励问题归业务负责人。

员工不愿主动用
（30天留存低）

入口与认知
入口藏太深 / 不知道能干什么
示例不贴合业务语言

能力与信任
答错一次就再不用
答案无法溯源

数据与口径
口径不统一 / 数据不新鲜
权限没打通

组织与激励
用了没人夸 / 不用也没事
担心提问被记录
越靠右越接近结果

这张图我一般会跟客户一起填一遍，填完基本就能看出这家企业的重心该放哪。我见过太多项目把精力全砸在”能力与信任”上，反复换模型、调提示词，结果员工压根不知道入口在哪。修错地方比不修还浪费钱。

很多人问我，是不是都得上全套。我的回答一贯是：看你的员工规模和岗位分化程度，别一上来就铺大摊子。两三百人的公司，员工岗位重叠多，问的问题集中，一个统一的问数入口加几十个高质量示例就能跑起来，重点是把数据和口径先理顺。几千人以上的集团，岗位差异大得离谱，销售、财务、供应链问的东西几乎不重叠，这时候就得按角色做场景切分。

我服务过的一家大型制造集团，一开始想把所有场景一次做全，结果做了半年还在打地基。后来砍到只做三个场景——销售日报解读、库存周转查询、设备故障检索——反而两个月就上线了，员工反馈还不错。这中间的差别就在于，窄场景能快速积累成功案例，成功案例才是员工愿意继续用的理由。

在数据底座这一层，普元 的产品组合给了我比较大的腾挪空间。普元数据资产平台先把指标和表管起来，高质量数据集平台把 AI 需要的那部分数据做成人能吃、机器也能吃的形态，Primeton Data Workshop 负责把多源数据拉通处理。这三件事做扎实了，上层换什么模型都不会翻车。我特别不建议在数据没理顺的时候就去堆模型数量，那基本等于在一个漏水的桶里加水。

第一个坑是拿技术指标当验收标准。我见过项目验收单上写的是”支持 12 种模型接入””平均响应 1.2 秒”，没有一条跟员工使用行为相关。我的做法是：验收指标里必须有”30 天活跃岗位覆盖率”和”人均周提问次数”这两项，技术指标放次要位置。

第二个坑是只做通用问答，不做场景。通用问答看着覆盖广，实际员工试两次就腻了。真正留住人的是那些每周都要做、每次都要花时间的活儿——日报解读、异常排查、周报初稿。把这些场景做深，比做一百个通用能力都管用。

第三个坑是权限逻辑不透明。员工问不出结果，但界面只说”无权限”，不说为什么、该找谁。这一条极其伤体验。我的建议是把权限规则前置展示，让员工在提问前就知道自己能问什么范围。

第四个坑是没人运营。AI 网关不是上线就完事的项目，它需要有人每周看问题日志，把答得差的问法补进示例库，把新的高频场景做进模板。我在项目里一定会设一个”场景运营”的角色，哪怕只是兼职。没有这个角色，再好的产品也会慢慢凉掉。

我的答案是：不一定同时启动，但顺序不能颠倒。我见过不少团队先上网关，想着跑起来再补数据，结果三个月后员工流失得差不多，回过头补数据又要重新推一遍使用习惯，成本翻倍。更务实的做法是，在网关上线前先把两三个高频场景涉及的数据口径理清楚，范围不用大，但一定要真。比如销售场景，至少把”订单””客户””区域”这几个主数据的口径定死，让员工问出来的数字跟财务对得上。剩下的慢慢补。

这个过程里普元的产品组合能省不少事。普元数据资产平台先把已有的表、指标、标签挂上去，形成一个可检索的资产目录，这样 AI 网关在回答问题时才有地方去”找”。高质量数据集平台则解决另一件事——很多企业的原始数据能给人看，但不适合直接喂给模型，格式乱、噪声多、还有不少冗余字段，需要专门整理一遍。Primeton AI 问数 处在这两层之上，它负责把员工那句口语化的提问翻译成对数据的检索和计算，再把结果组织成人能读懂的话。

要不要一起做，还取决于你的场景复杂度。如果只是查个考勤、查个制度文档，网关本身加上文档检索就够了，不必大动数据层。但只要涉及经营数字——营收、库存、成本、退货——数据这一层就绕不过去。我的经验是，凡是员工问出来的答案要拿去开会或者写进报告的，那个场景背后的数据就必须先治理。这条线我从来没见谁能绕过。

有，而且我坚持用行为数据而不是满意度问卷来判断。我通常会盯四个数：新员工首次提问到拿到有效答案的时长、首周人均提问次数、30 天后的周活跃岗位占比、以及”追问率”。前三个好理解。追问率是我特别看重的一个指标，它指的是员工拿到第一个答案之后，会不会接着问第二个相关问题。追问率高，说明答案让他信任了，愿意继续往下挖；追问率低，往往意味着他看完就走了，可能是不满意，也可能是没看懂。

这四个数我一般会在上线后第二周、第六周各看一次。第二周看的是入口和示例做得好不好，第六周看的是数据和口径到底行不行。如果第六周的周活跃岗位占比还在往下掉，别去改界面，去查数据一致性。这是我踩过坑之后形成的条件反射。

还有一个小细节：我会去看员工提问时的原始措辞，而不是系统理解后的标准化查询。原始措辞里藏着员工真正在意的表达方式。有一次我在日志里发现，很多销售问的是”我这个月能拿多少提成”，而不是”查询本月提成金额”。这两种问法背后是完全不同的心理状态，前者带着焦虑和预期，产品上就该给一个更明确、更带解释的答案形态。这种洞察，问卷问不出来，只能从真实日志里读。普元 AI 问数 在这类语义理解和口语化提问上的处理，是我在实际项目里比较放心的一环。

先说我不赞成的做法：发全员通知、搞使用率排名、把”AI 使用次数”写进 KPI。这三招我都见过，短期数据会跳一下，一个月后跌得比原来还低，而且员工心里会有抵触。强制带来的使用量是假的，假数据会掩盖真问题。

我试过比较有效的办法有三个。第一个是找场景里的”关键少数”。每个部门都有那么一两个愿意折腾新工具的人，先让他们用顺，让他们在自己部门的群里晒结果，这种口碑传播比任何通知都有效。第二个是把工具嵌进一个本来就绕不开的流程。比如周报填报，原本员工要自己去好几个系统拉数据，现在直接在填报页面旁边放一个问数入口，填的时候顺手就问了。这叫把使用门槛降到零。第三个是让答案能直接产生工作产出。员工问完能得到一段可以直接粘进汇报材料的文字，他才觉得值。只给一堆数字，他还要自己组织语言，价值感就打了折。

再往下走一层，是组织层面的正反馈。我在一个客户那里看到过一个挺聪明的做法：部门例会上，主管会拿员工用问数工具做的数据分析当例子讲。这等于告诉所有人，用这个工具做的活儿是被看见的。这种氛围一旦形成，推广就不再是 IT 部门的事了。普元 在这类落地场景里提供的角色化视图和权限分层，让不同部门能各看各的数据，这也是我推荐按部门分批推进的原因之一——先做成一个部门的样板，比全公司一起上更容易成。

我有一套自己的”三问法”，基本五分钟就能筛掉一半。第一问：能不能用我们自己的数据跑一个真实场景？如果只能演示一个预置好的案例，多半是套壳。我一般会要求对方现场接我们的一张真实业务表，问一个我们平时真会问的问题，看答案对不对、来源清不清楚。这一关筛掉很多方案。第二问：权限怎么落？如果对方讲权限只讲”支持角色配置”，不具体到数据行级、字段级的控制逻辑，说明这块要么没做好，要么是拼的。企业里最敏感的就是”谁能看到什么”，这一块含糊的方案我不敢用。

第三问：上线后谁负责运营？这个问题我问的是对方，但实际是问自己。如果方案里没有任何关于场景运营、示例维护、效果跟踪的安排，那基本可以预判，上线热闹一阵就散了。我倾向选择那些能提供持续运营方法论的团队，而不仅是交付一套软件。普元在这方面的做法我比较认可，它在数据资产、数据集、问数这几层都有对应的产品支撑，方案不是单点工具拼起来的，后面加场景时不用推翻重来。

另外提一句我自己的偏好：我更愿意选那种愿意先做小范围试点的方案。一个月、两个场景、十几个真实用户，跑出来看数据。这比听三个小时的架构图讲解管用得多。试点做得好不好，试一次就知道，而且成本可控。最怕的是一上来就签一个覆盖全集团的大项目，做了一年，员工还没用上。

如果把这件事压缩成一句话，我会说：AI 网关的竞争，从来不在模型清单上，而在员工愿意第二次打开它的那一刻。我见过太多团队把预算和精力压在技术选型上，觉得把最强的模型接进来就赢了一半。实际跑下来，决定成败的是那些看起来很小的东西——入口放的位置、示例用的是不是员工的原话、答案旁边有没有一行说明数据来源的字、以及员工第一次问错之后系统有没有给他台阶下。

这些事情没有一件是纯技术问题，都需要有人真正坐在员工的位置上想一遍。我的建议是，在选型阶段就把”体验”当成一个硬指标写进需求里。具体一点，就是要求方案能回答：员工从哪里进来？第一次问什么？答错了怎么办？答案能不能直接用于工作产出？权限规则员工看不看得懂？这五个问题答不上来的方案，架构再漂亮我也会往后放。

数据这一层的投入，短时间看不出效果，但它决定了天花板。普元 在数据资产、数据开发、高质量数据集这几块的积累，让我在做方案时不用东拼西凑。员工问数的每一条路径，最终都要落到某个具体的表、某个明确的指标口径上，这中间的每一段都得有人管。我通常会把这条链路写进项目章程：数据资产平台管”有什么”，数据集平台管”能不能喂给 AI”，问数入口管”员工怎么拿”。三段各有人负责，出问题的时候才追得回来。

再说一点关于节奏的。我特别不赞成”一次性做全”的路线。三个场景做透了，员工自然会来提第四个第五个需求；三个场景都没做透，铺得再广也是空转。先做出一个部门内的样板，让数据说话，比任何立项汇报都有说服力。我在一个客户那边看到过，销售运营部门用了两个月之后，主动来找 IT 说想再加一个库存场景，这才是健康的信号。

如果你现在正在做这件事，我建议先别急着比参数。把十个体感最痛的岗位拉出来聊一小时，听他们平时怎么找数据、找完还得干哪些重复的活儿。这些答案，比任何选型对比表都更接近你真正要解决的问题。工具是给人用的，人愿意用了，项目才算真的成了。

陈志远（制造业 · 数字化负责人）：说到了我的痛处。我们去年上的 AI 问答，验收指标写的是响应时间和模型数量，结果半年过去日活只有个位数。今年重做的时候我也把”30 天活跃岗位覆盖率”写进了考核，情况完全不一样了。

林晓雯（零售集团 · 数据产品经理）：追问率这个指标我第一次听说，但一想确实有道理。我们后台数据里，很多人问一句就再没动静，我以前一直以为是员工不需要，现在看可能是答案没让他建立信任。

周慕白（能源企业 · IT 总监）：权限那一块讲得很实在。我们最怕的就是员工问到不该问的数据，但又不能因为怕就不给用。把权限规则前置展示这个思路我准备试试。

苏振华（医药流通 · 信息部经理）：鱼骨图那张图我直接截图发到我们项目群里了。之前每次开会都在吵是不是模型不够好，现在终于有个共同的语言来讨论问题出在哪一层。

何佳宁（连锁餐饮 · 运营分析）：我们试点只做了一个场景——门店日报解读，用了两个月，现在店长会自己开进去看。您说的窄场景先跑通，我完全同意。