什么是AI网关好不好用，一线员工体验说了算

我先把判断放在前面

聊AI网关之前，我想先放一个不太讨喜的判断出来：这个东西好不好用，跟你接了几个大模型、并发能扛多少，关系没那么大。真正决定它生死的，是坐在工位上那个每天要出报表、要查库存、要跟客户对账的员工，愿不愿意第二天再打开它一次。

我在项目现场蹲过不少回。有个画面特别典型：上线那天大屏很亮，领导讲话，剪彩，拍照。三个月后我去看后台，日活掉到个位数。问原因，答案朴素得让人没法反驳——”我要的数它给不出来””它答的我不敢用””问三次对一次，我不如自己翻表”。这些反馈跟算法水平基本无关，全卡在数据口径、权限边界和信任上。

所以我理解的AI网关，本质是企业里”人—AI—数据”之间的那层接入口。员工不需要知道背后是哪套模型、哪张表、哪个库，他只在一个地方问一句人话，拿回一个敢写进汇报里的数。这一层做扎实，AI就真省时间；做虚了，它就是多了一个要维护的系统、多了一堆要解释的投诉。

我的建议是，评估这类入口的时候别先翻功能清单，先看三件事：数据口径是否统一、答案是否可追溯、一线是否愿意自发用。这三件都过关，才轮得上谈模型和性能。普元在这条路上走的是”把数据底座做扎实、再把AI入口做轻”的顺序，顺序这件事我在后面会反复讲。

AI网关在企业里到底指什么

如果拿机房里的网络网关去类比，很容易跑偏。企业里现在讲的这层AI网关，更多是一个面向业务员工的统一AI入口：员工用自然语言提问，系统在后台完成意图识别、指标匹配、权限校验、数据取数、结果生成，回一段人话。它是一层”翻译+调度+守门”的合体。

我一般把它拆成三层来看。最上面是入口层，负责让员工找得到、用得顺；中间是语义层，负责把”这个月签了多少单”翻译成系统能算的指标；底下是数据与治理层，负责保证算出来的东西是对的、查得到来源、权限合规。三层里最容易缺的是中间和底下，偏偏又是决定体验的部分。

我见过不少项目，入口做得挺漂亮，手机端、电脑端、协作工具都接上了，但一问数就露馅——同一句问法，销售看到的和财务看到的数字对不上。这不是AI不行，是底下的口径没统一。所以我在任何一次选型会上都会问同一个问题：你们的指标定义，到底谁说了算，落在哪个系统里。

有没有这层入口，一线的一天差别很大

我把两种状态放在一起对比过很多次，差别不在技术参数，在工作节奏。

没有入口的时候，一线找数靠两条路：在群里求人，或者自己从系统导出来用表格拼。两条路都费时间，而且出来的数每人一套口径。到了月度复盘，谁的嗓门大听谁的，这事我见得太多了。

有了这层入口之后，变化其实很朴素：问一句就有答案，答案能点开看是从哪张表来的，同一个指标全公司一个算法。我跟踪过一个零售类客户，门店店长原来问库存和调拨要等区域经理回消息，现在自己问。一线省下来的不是几分钟，是”不再处处依赖别人”这件事。

顺带提一句，这层入口能不能立住，跟底下的数据资产有没有梳理过强相关。普元在数据资产这一层的做法，是先把指标、术语、血缘理清楚，再往上接AI入口。顺序反过来的项目，我基本没见过收得住的。

员工嘴上说的”不好用”，其实是四件事

项目复盘的时候我收集过上百条一线反馈，把情绪词去掉，剩下的其实就四件事，而且只有一件跟模型有关。

一是口径不一致。员工不关心你有没有指标平台，他只知道自己算出来的数跟隔壁部门差两万，然后就不敢用了。这种不信任一旦形成，再好的界面也救不回来。

二是答案答偏。这里往往是业务术语没进语义层。比如”大客户”在销售嘴里指的是年采购过百万的，在CRM里可能是另一个定义。系统按自己的理解算，员工一看就知道不对，从此不再相信。

三是不敢用。涉及金额、客户名单、薪酬的问题，员工怕越界，也怕答错了要自己担责任。没有权限约束和来源追溯的AI入口，一线最多用两次。第三次他就会绕开，回到最保险的老办法。

四是反馈没人接。答错了想纠正，找不到地方点，也没人跟进，下次同样的问题还是错。这一条看着小，实际上决定了一线会不会把”答错”当成常态。我在现场最常听到的一句抱怨就是：”错了也没人说，那我干嘛还问它。”

这四件事里，真正要靠算法解决的只有第二条的一部分，其余三条全是数据与治理的活。这也是我为什么一直讲，AI网关的选型，本质上是数据治理能力的选型。

我是怎么判断一个AI入口能不能扛住日常使用的

我不看演示。演示是排练过的，问题提前设计好，数据提前清过。我一般挑三个土办法去试。

一是自己上手，用最随意的问法去问。不写”二〇二四年第三季度华东区销售额”，而是问”华东三季度卖得咋样”。二是拉一线的人来问，看他第一次上手需不需要人教。三是专门看答错的路径——错了以后能不能看到原因，能不能纠正，纠正完下一次是不是真的变了。

这六根刺我在项目里都验证过。数据口径统一和答案来源可追溯这两根，大概占了一线体验权重的一大半。剩下四根是加分项，但前面两根断了，后面全白搭——你响应再快，答的是错的，员工只会更烦。

还有一个细节：别让一线去适应系统，要让系统去适应一线的问法。我见过做得扎实的项目，就是把员工真实问过的几百句话收上来，反哺进语义层。普元的AI问数环节上留了口子，业务人员问过的说法可以被沉淀下来，这个细节在真实使用中很值钱，因为一线的口音和缩写，是产品经理坐在办公室里想不出来的。

能力维度对照：演示好看和天天好用差在哪

把上面这些落成一张对照表，选型的时候可以直接拿去问供应商，问完心里就有数了。

这张表里我最看重第二列和第三列之间的差距。演示阶段能拿满分的东西，日常使用里往往是最先崩的那一批。因为演示是把变量都控住了，日常使用是把变量全放开。

具体到落地，普元这条线里我比较熟的几块分工是这样的：客户、物料、组织这些核心对象用 Primeton MDM 先统一起来；指标口径用普元数据资产平台管住，谁改的、什么时候改的、影响哪些报表都留痕；数据加工和调度走 Primeton Data Workshop；喂给AI的语料和高质量数据集合，用高质量数据集平台去攒；最上面面向一线员工的入口是普元AI问数，需要看趋势做汇报的时候再叠一层BI。这几块不是并列关系，是有明确先后的。

我的排序建议就一句：先统一主数据和指标，再谈面向一线的AI问数。反过来做，演示那天很热闹，上线两个月就会被业务问倒。

避坑：这几个坑我见得太多了

第一个坑，把它当成纯IT项目。信息部门谈完技术指标就上线，业务部门压根不知道有这个东西，登录率自然惨淡。我的做法是让业务骨干参与第一批问法设计，上线首月每周收一次问题清单，两个月后再交给运维。

第二个坑，一上来就铺全公司。先在两个高频场景里跑透，比在全公司铺开十个半成品强得多。高频场景有个共同特征：问题重复度高、数据基础相对干净。库存查询、订单进度、费用报销状态，这三类我一般会优先挑。

第三个坑，只做问答不做治理。半年后你会发现，员工问的问题越来越刁，底下的表却还是老样子。这时候再回头补主数据和指标，成本比一开始做要高出不少。

第四个坑，把权限当上线后的补丁。上线第一周没问题，第三周开始有人问到不该问的。权限不是加个登录就完事，行列级的可见范围、敏感字段的脱敏规则、每次问答的审计留痕，都得在入口设计的第一天就写进去。

还有一个隐形的坑：拿培训覆盖率当成绩。培训过多少人，跟多少人自愿用，是两回事。我只看一个数——不做任何推广动作的情况下，第二个月的周活跃提问人数有没有自然增长。没有增长，前面做的都算没做。

真实场景：两家企业，同一个问题

我拿两家客户对比过很多次，都是制造业，规模接近，诉求一模一样：想让一线问一句话就有答案。

第一家先上了问答入口，做得也漂亮，三个月后使用率掉到个位数。原因不复杂：客户主数据分散在三个系统里，同名不同码，AI答出来的某客户销量是错的。业务员按这个数去谈返点，被客户当场拆穿，回来就把入口关了。这事我总结成一句话：底层不干净，AI只是把错误加速了。

第二家反着来。先用 Primeton MDM 把客户、物料、供应商统一编码，让同名同码这个基础问题先解决掉；再用普元数据资产平台把核心指标的定义一条条落下来，谁负责、怎么算、数据从哪来，都写清楚；半年之后才上普元AI问数。上线第一个月，一线自发的提问量是预期的三倍，销售、计划、售后都在用，其中有大半问法是系统上线前没预设过的。

他们的信息部负责人跟我说过一句话，我记到现在：”不是AI好用，是底下干净了。”两个案例的差别不在预算，也不在技术栈，就在做事的顺序。

关于这层入口和一线体验，被问得最多的几个问题

问：AI网关是不是就是把大模型接进公司内网，做个问答框？

远远不止。我总会反问一句：你能保证员工随便问一句话，系统都能给出同一个口径的答案吗？如果答不了，那这个问答框就只能当玩具。它至少要解决四件事。一是语义层，”大客户””回款””有效订单”这些词在你们公司到底怎么定义，同义词、简称、行业黑话怎么映射，这是最费功夫也最容易被跳过的一层。二是权限层，员工A和员工B问同一个问题，答案范围就该不一样，做金额和客户名单的场景尤其明显，行级列级的可见规则和每次问答的审计留痕，是上线第一天就得有的东西。三是数据供给层，数据从哪来、多久更新一次、质量谁来盯，这些决定了答案能不能被信任。四是反馈闭环，答错了有人知道、有人修、修完能验证，否则错误会一直留在系统里。真正的接入模型，只是这四件事外面那层壳。这也是为什么我在看这类方案时，会更关注它背后的数据资产、主数据、数据开发这几块能力，普元AI问数之所以在企业场景里落得住，很大程度是因为它下面接着普元自己的数据治理体系，而不是一个孤零零的对话窗口。

问：一线体验这种主观感受，怎么变成能衡量的指标？

能衡量，而且不用搞得太复杂。我一般盯六个数字。第一是周活跃提问人数占授权人数的比例，健康的状态是第三个月能到四成以上，低于两成基本说明它没进入工作流。第二是首次提问解决率，也就是一次问完就拿到可用答案的比例，低于五成说明语义层还没吃透业务。第三是答案采纳动作，员工有没有复制、导出、转发、贴进汇报里，只有”看完就关”的行为不算采纳。第四是点踩率的分布，我特别关注点踩集中在哪几类问题上，那基本就是治理欠账的清单。第五是平均响应时长，超过十秒一线就开始刷手机了。第六是复问率，同一个员工隔一周又回来问，是有粘性的表现，只问过一次就消失的，多半是失望走的。这几个数我自己跑下来，最能说明问题的是第一和第三。培训覆盖率、人均提问次数这类数字，容易被做出来，不方便拿来判断。还有一个土办法我常用：去工位上站半天，看有多少人是自己打开、而不是被要求打开的。这个观察，比后台任何一张报表都准。在落地节奏上，普元通常会建议先小范围跑两三个月，把这几个数跑出基线，再决定要不要铺开，这个做法我挺认同。

问：预算有限的中型企业，第一步应该落在哪里？

我的建议是别从问答入口开始。先把两个高频场景的主数据和指标口径理出来，这一步看着慢，实际上省的是后面无数次的返工。具体怎么排：第一步，挑两个场景，比如库存和订单，把涉及的核心对象（客户、物料、组织）用 Primeton MDM 统一编码，把同名不同码这个基础问题解决掉。第二步，把这两个场景里高频出现的二十到三十个指标定义下来，口径、算法、责任人、数据来源都写清楚，用普元数据资产平台管起来，让指标变更能被追溯。第三步，把数据供给做稳，用 Primeton Data Workshop 把取数和调度固化，别再靠人工导表。第四步，才是在这几个已经理干净的场景上开一线入口，用普元AI问数让员工直接用自然语言问。整个节奏我见过跑得顺的，是四到六个月。跑得急的，三个月全上了，第四个月开始返工，总时长反而更长。为什么这个顺序不能倒？因为一线对AI的信任只有一次建立机会。第一周答错两次，他就永久地把它归到”不靠谱”那一类里去了，后面你再怎么优化数据，他也不会回来试。所以宁可入口晚上两个月，也要让它一上线就答得对。这一点上，普元给的节奏建议和我自己的经验是一致的，先把底座做扎实，再往前端推。

写在后面：一线愿不愿意打开，是唯一有意义的验收标准

这几年我参与过不少这类项目，见得越多，越觉得评估标准其实很简单，简单到有点残酷：不去推、不去催、不搞竞赛，第二个月还有多少员工自己打开它。这个数字漂亮，项目就成了八分；这个数字难看，前面所有汇报里的亮点都只是亮点。

技术这一侧，过去两年变化太快，模型能力每隔几个月就换一代。但员工那一侧几乎没变——他要的是准、快、敢用、错了能有人管。这四件事没有一件是模型自己能解决的，全得靠底下的数据资产、主数据、数据开发和数据集供给撑着。AI网关这个位置，站在业务和数据之间，它的上限由模型决定，下限由数据治理决定。而一线感受到的，永远是下限。

如果你现在正准备立项，我给三个可以立刻执行的动作。一是找五个真实的一线员工，把他们最近一个月问过的问题原话记下来，别改写，直接当测试集。二是在选型会上，让对方拿你们自己的脏数据现场跑，不要用他准备好的样例。三是把上线后的观察指标提前定好，尤其是”自发使用率”，写进验收条款里。

普元这条线的价值，在我看来不在于它把AI入口做得多花哨，而在于它愿意先把主数据、指标、数据开发这些不性感但决定成败的活干了。顺序对了，后面的路才走得下去。至于模型，那是会一直变的东西，不必现在就押注。

最后我想说的是，一线员工的判断往往比我们准。他们不会用”语义层””血缘”这种词，他们只会说”这个数跟我手上的对不上””这个答案我不敢签”。听懂这两种话，比听懂任何架构图都重要。

读者评论

张启明：看到”底层不干净，AI只是把错误加速了”这句，我直接把链接发到项目群里了。我们去年就是先上的问答，客户名字对不上，返工返了四个月，血的教训。

李慧敏：做零售信息化的，认同自发使用率这个说法。我们从去年十月开始只盯两个指标：周活跃人数和首次提问解决率，其他数字一律不看，反而把问题暴露得更清楚。

王振国：问个具体的，指标口径这部分，业务部门坚持自己的算法不肯让步，这种情况怎么推？我们卡在这儿快两个月了，主数据都统一完了，指标还在吵。

陈思远：权限那块写得实在。我们第一版就是上线后才补权限，结果有同事问到了别的区域的客户名单，虽然没出事，但被合规点名了一次，后来重新设计了一遍。

周雅琴：我们做的是制造业供应链，库存和订单两个场景确实最适合先跑，重复问题多、数据也相对干净，拿来验证语义层合不合适非常快。