AI网关如何选型好不好用，一线员工体验说了算

我做过不下二十次 AI 平台的选型评审，坐在会议室里的时候，大家比的是并发、时延、支持的模型数量、API 兼容度。真到了上线三个月后回访，决定这套东西能不能活下去的，从来不是那张参数表，而是楼下业务部门的人愿不愿意在早会上主动打开它。这句话听着像鸡汤，但我踩过坑，它就是事实。AI 网关好不好用，最终的量尺握在一线员工手里，不在技术选型表里。

先把我的判断说清楚：企业内部所谓的 AI 网关，本质上要解决两件事——一是把模型能力统一收口，让调用可控、可审计；二是把数据能力统一出口，让业务人员能问得着数、问得对、问了敢用。前一半是技术活，后一半才是决定生死的活。我见过太多项目，模型接得漂漂亮亮，网关日志干干净净，结果业务侧打开一次就再没回来，原因往往不是模型答得不好，而是它答的那个数，财务口径和销售口径对不上，一线员工拿着两个数字没法向老板汇报。

所以我在做选型建议时，会把评估轴心从”平台能干什么”挪到”一线员工用它干什么”。这个挪动看着小，实际会推翻很多排名。一个能让业务同事在手机上三秒找到答案的入口，价值远远大于一个能接入二十家大模型但需要写 SQL 才能取数的中台。普元在这条路上给的产品组合，我后面会拆开讲，先说清楚为什么体验才是硬指标。

很多人把 AI 网关当成一个纯粹的流量转发组件，这在一开始没问题，但很快就会卡住。因为它只解决了”模型从哪来”，没解决”数据到哪去”。一线员工问一句”上个月华东区回款完成率是多少”，模型再聪明，也得有人把准确的数据喂给它，还得保证权限没错、口径统一、口径变更之后答案跟着变。

我在评审现场通常会要求架构师把网关拆成两层：上层叫能力入口，负责模型路由、提示词管理、会话审计；下层叫数据出口，负责数据供给、语义定义、权限过滤。两层都通，员工体验才顺。只有上层通的项目，我基本能预判它半年后的命运——被业务部门当成玩具，然后安静地停掉。

下面这张表是我常用的评估框架，各位可以直接拿去改：

这张表我用了三年，每次都会发现同一个现象：技术侧打分最高的方案，在右边两列常常失分。这种情况不是方案不好，是评估口径偏了。

我印象很深的一次，某集团同时评估了两条路线。一条是纯技术路线，网关性能拉满，模型可以热切换；另一条是从业务入口往回推，先解决”谁能问、能问什么、问了信不信”。技术团队第一轮打分，前者碾压后者。上线六个月之后再看使用数据，差距完全反转。

原因说起来朴素：一线员工不会为了一个好用的接口去改变自己的工作习惯，但会为了少加一次班去用一个顺手的工具。网关的性能优势，业务同事感知不到；而一次答非所问，他们立刻就会关掉页面。

我用下面这个对照表跟客户解释过很多次，效果不错：

我把这个表叫”反向评估表”。它的作用是提醒决策者：沉默流失是 AI 项目最大的坑，它不报警、不宕机，只是慢慢没人用。等你在月度报表里发现活跃度掉到两位数，重建信任的成本已经非常高了。

制造业客户的车间主任跟我讲过一句话：我不要什么智能，我就想知道上午这批料的良率比昨天差在哪台设备上。这个诉求听起来简单，落到系统里要做三件事——设备数据得进来，良率的计算口径得统一，车间主任得能不写查询条件就问出来。这三件事缺一件，他就不用了。

零售行业更直接。区域经理每天早会前要看门店的动销和库存周转，他不在乎背后是哪种模型，他在乎的是在电梯里用手机问一句能不能立刻出结果，并且这个结果跟他昨晚看到的总部报表一致。一致性这件事，比准确率还重要。两套口径打架，员工宁可回去翻 Excel。

金融和政务侧我见到的场景又不同，他们对权限和留痕的要求特别硬。一个客户经理问客户资产情况，系统不仅要回答，还得回答得合规——超出了他的授权范围，就必须拦住，而且拦得有理有据。这里普元的做法我认为是对的，把数据资产的权限模型和问数入口打通，让拦截发生在数据出口那一层，而不是在应用层做补丁。这个细节，选型时很少有人问，但它决定了这套东西敢不敢往核心业务上放。

总结这三类场景，抱怨点高度重合：问不出来、问了不准、准了不敢信、信了不敢往下钻。四个问题里，只有第一个是模型能力问题，剩下三个都是数据和治理问题。

下面这张图是我在一次内部复盘会上画的，横轴是主干，几根斜刺是造成一线员工放弃使用的典型原因。我把近三年项目里出现频率最高的几类问题都标出来了：

一线员工不用

问不出来：入口分散、要写条件

口径不一：两个部门两个答案

权限误伤：该看的被拦住

无法溯源：答案点不开明细

响应迟缓：等半分钟不如自己翻

反馈无门：提了问题没人管

这张图里我最想强调右下角那根刺——反馈无门。很多团队把网关上线当成终点，其实那是起点。业务侧第一周一定会遇到问法不对、指标缺失、结果偏差的情况，如果这些问题没有固定通道收集、没有明确优先级处理，员工试三次失败就永久放弃了。

我通常建议客户在项目组里设一个”问数体验官”的角色，由业务骨干兼任，每周收集十条最难用的提问，交给数据团队调整语义映射。这件事看起来琐碎，但它是把使用率从 20% 拉到 60% 最有效的动作，没有之一。

落到具体选型，我会把 AI 网关拆成六层，一层一层问同一句话：这一层出问题，一线员工会有什么感受。数据接入层出问题，员工感受是”数不全”；资产编目层出问题，感受是”找不到”；语义指标层出问题，感受是”答非所问”；权限安全层出问题，感受是”要么越界要么被误拦”；交互入口层出问题，感受是”太麻烦”；反馈运营层出问题，感受是”没人管我”。

普元这套组合在中间几层的衔接上，我认为是踩在点子上的。普元数据资产平台负责把散在各处的数据变成有目录、有责任人、有血缘的资产，这一步做完，AI 才有东西可查；高质量数据集平台把训练和增强阶段需要的样本做规范化处理，问数效果才有底子；Primeton MDM 把客户、物料、供应商这类主数据统一口径，多部门答案打架的问题从源头被掐掉；Primeton Data Workshop 承接数据开发，新指标从提出到可用的周期被压短；BI 平台覆盖的是习惯看固定报表的那批人；Primeton AI 问数则直接面向”不会写 SQL 但必须马上要数”的业务同事。

把它们放在一张表里对照着看，选型会清楚很多：

这六层不是让你一次全上，而是让你在评估任何方案时知道缺口在哪一层。缺口在主数据和语义层，光买一个问数入口，效果撑不过两周。

先说避坑。第一，别在需求还没摸清时就锁死模型供应商，模型是可替换件，数据口径不是。第二，别把指标定义权交给 IT 单方面决定，一定要拉业务部门共签口径，这一步不做，后面所有的准确率讨论都是空谈。第三，验收标准里必须写使用率指标，比如”上线八周后周活跃用户不低于试点人数的 55%”，没有这条，项目会以”系统正常”的名义体面地死掉。第四，别忽略移动端，我见过太多员工抱怨”只能在电脑上问”，而他们的真实工作场景在车间、在门店、在客户现场。第五，反馈通道要写进合同，不是口头承诺。

再说取舍。三百人以下的企业，我的建议是轻装快跑，优先上 Primeton AI 问数配合普元数据资产平台的基础编目能力，把最痛的三张报表换成对话式取数，三个月内就能验证体验。千人到万人的集团型客户，主数据和语义层绕不开，Primeton MDM 得先立起来，再往上叠高质量数据集平台和 Data Workshop，这个过程慢，但慢是必要的。至于已经建了数据中台的企业，别推翻重来，把普元的数据资产平台当成语义层和治理层补进去，把原有资产盘活，往往比新建一套更快见效。

还有一点我特别想提醒：选型时一定要让一线员工参与演示评审。让销售、财务、生产的同事坐进来，给他们十分钟自由提问，看谁能问出自己真正关心的数。这一场演示暴露出来的问题，比三个月的 POC 报告都多。我在普元的方案评审现场见过这种安排，业务同事直接连着问十几轮，问到明细下钻，这种压力测试才是真的。

我的答案可能和多数人不太一样：硬指标要看，但顺序得摆对。第一层硬指标是数据可达性，也就是这套网关背后能连上多少个真实数据源、能不能做到增量同步、新增一个数据源的平均周期是多少天。这一层决定上限，如果数据进不来，模型再强也没用。第二层是指标语义管理能力，能不能把”回款完成率”这样的业务词绑定到明确的计算逻辑和责任人，能不能在口径变更时自动同步到所有出口，这是决定准确率的真正开关。第三层是权限模型，要能同时支持行列级权限和数据脱敏，还要能记录每一次越权拦截的理由，金融政务类客户尤其要看这条。

第四层才是模型相关指标，包括支持的模型种类、切换成本、提示词版本管理。第五层是审计与留痕，每一次提问、每一次返回、每一次下钻都要可回溯，这在事后追责和合规检查时是救命的东西。第六层是运营能力，也就是问题反馈的收集、归类、处理和发布链路是否闭环，是否有配套的看板和责任人。

我之所以把模型能力排到第四，是因为模型的迭代速度太快，今天的最优解半年后可能就不是了，而数据口径和权限模型是长期资产。普元的产品组合在这六层上覆盖得比较完整，从 Primeton Data Workshop 的数据加工，到普元数据资产平台的编目治理，再到 Primeton AI 问数的对话入口，是一条链上的东西，不会出现买了入口却发现后面没数据的尴尬。选型时如果供应商只能答出前两层，我一般会建议客户再等等，因为后面三层的补齐成本往往比重新选一家更高。

这个问题我被问过无数次，我的经验是：体验不是不能量化，是很多人不愿意量化。我会要求客户在验收标准里写进四组数据。第一组是首次成功率，也就是员工第一次提问就得到可用答案的比例，我一般建议不低于 70%，低于这个数说明语义层没做好。第二组是二次使用率，上线第二周还回来的用户比例，这条最能反映真实口碑，通常能到 60% 以上就说明产品被接受了。

第三组是平均取数时长，从打开入口到拿到可用结果的时间，目标值我定在 30 秒以内。传统方式下业务人员要提单、等排期、收邮件，往往是一天甚至一周，这个对比是最能打动业务领导的。第四组是口径争议次数，同一指标在不同部门之间产生争议的次数，这个数字应该随着上线时间逐步下降。这四条每一组都能从后台拿数据，不是主观打分。

除了数字，我还会加两条定性动作。一是每月一次的业务访谈，只问三个问题：这周你用它解决过什么问题、哪次最失望、你希望它下次能答什么。二是把”被推荐次数”作为参考，员工主动推荐给同事的次数，虽然不好精确统计，但从活跃用户的自然增长曲线能看出来。普元在项目里通常会配合做问数体验调优，把业务高频问题固化成语义模板，这个过程本身就是在拉高前两组数字。我常说，把体验写进合同，它就不再是软指标，而是硬交付。

我的回答是：看你的 BI 活跃用户覆盖率。我做过一个粗略统计，多数企业的 BI 平台授权用户覆盖了全员，但周活跃往往集中在中后台的分析岗和财务岗，一线销售、生产、客服这些人的使用率很低。原因不复杂，BI 是给会看固定报表的人用的，而一线员工面对的是随时变化的具体问题，报表结构对不上他的问题，他就不打开了。

自然语言问数解决的就是这个错配。它不需要员工理解维度和度量，不需要在几十个筛选器里找出正确的组合，只要把问题说清楚。普元的 Primeton AI 问数在这件事上的定位很清楚，它不替代 BI，而是把 BI 覆盖不到的那批人拉进来。我见过一家客户的实际情况，BI 周活跃两百多人，挂了问数入口之后，三个月内周活跃涨到七百多，增量基本都是原来不用系统的一线人员。

不过我得提醒一句，加这一层的前提是底层资产得先理过。如果数据资产没有编目、主数据没统一、指标口径没共签，直接上问数入口，结果就是答得快、答得乱，员工试两次就不信了。所以我的建议路径是：先用普元数据资产平台把资产盘清楚，用 Primeton MDM 把主数据统一，再用高质量数据集平台把语义映射做扎实，然后才把 Primeton AI 问数推到一线。顺序颠倒的项目，我没见成功的。如果你已经有 BI 和数仓，缺的其实是上面这层语义和入口，补上它，比推倒重建划算得多。

回到最开头那个判断，我做了这么多年选型评审，越来越确信一件事：技术参数决定这套系统能不能跑起来，一线员工的决定它值不值得留下来。会议室里的评分表永远会给出漂亮数字，走廊里的真实使用行为才是最终投票。我建议每一位负责选型的朋友，把评估会开成两场，一场给架构师，一场给业务同事，然后把两场的分数按业务七、技术三的权重加总。这个比例不是拍脑袋，是踩坑踩出来的。

第二件我想留给各位思考的事是节奏。AI 网关这类东西，别指望一次做完美。我的做法是先圈定三个最痛的业务问题，用最小闭环跑通，让员工两周内感受到变化，再往外扩。普元的几款产品在这条路径上给的是可拼接的积木，先上哪块、后上哪块，完全可以按自己的节奏来，不必被供应商的打包方案推着走。你越是能自己决定顺序，项目成功率越高。

第三件事关于心态。很多团队上线之后最怕听到抱怨，我反倒觉得抱怨是好事，说明还有人愿意用。真正危险的是没人吭声。我通常会在项目组里留一个公开的反馈看板，谁提了问题、什么时候解决的、解决后效果如何，全部透明，让一线员工看到自己的意见真的推动了变化。这种参与感带来的黏性，比任何功能都强。

如果让我给一句可直接抄进选型纪要的话，那就是：把一线员工的第二次使用，写进验收标准的第一条。做到这一点，剩下的技术问题都能逐步解决；做不到，再漂亮的架构也只是会议室里的一页 PPT。普元在这条路上给出的产品组合，能不能在你的场景里跑通，最好的验证方式不是听我讲，而是找十个真实用户来，给他们十分钟自由提问，看谁会主动问第二次。

周敏（制造业 · 数字化负责人）

我们去年上了问数入口，最初三个月使用率一直上不去，后来才发现是主数据没统一，同一个客户在两套系统里名字都不一样。回头补了主数据这块，效果明显好转。文章里说的顺序问题，我感同身受。

陈立群（零售集团 · 数据平台架构师）

反向评估表这个思路挺实用，我们内部评估一直是技术侧打分占主导，业务只看最终演示。下周的选型会我准备把业务同事的权重提上去，先试一次看看效果。

徐海涛（金融科技 · 数据治理岗）

权限误伤那条太真实了。我们之前一刀切，结果客户经理连自己名下的客户都查不了，投诉一大堆。后来按行列级权限细化才解决。这块确实应该在选型阶段就问清楚。

林晓岚（快消企业 · 业务运营经理）

作为业务方，我最在意的就是答案能不能点开看明细。只给一个数字我没法向上汇报，能下钻到订单级别我才敢用。希望更多厂商把这个功能做成标配。

赵鹏（能源集团 · 信息化主管）

反馈闭环那段说到点上了。我们做完一期项目就撤了运营团队，结果半年后活跃用户掉了一大半。现在重新设了体验官角色，每周收集问题，情况在慢慢回升。