大模型网关好不好用，一线员工体验说了算

过去一年多，我参与过四家企业的大模型网关落地。规模不一样，行业也不一样：一家是千亿级制造集团，两家是区域性银行，还有一家是能源央企下面的科技公司。它们上网关的理由高度相似——各部门自己偷偷去调大模型接口，费用谁也说不清；客户名单、合同金额从对话框里流出去，安全部门睡不着觉；模型一换版本，上层十几个应用全得改代码。这些确实都是真问题，网关也确实该上。

但真正让我记住的，是上线三个月后的那次内部调研。IT 部门的验收报告写得很漂亮：接入五家模型厂商、平均响应 1.2 秒、月度成本下降 34%。可员工侧的反馈完全是另一幅画面。”问了半天答不上来””它给的毛利率跟我们月报对不上””等 30 秒我就不想用了，还不如自己拉个 Excel 透视”。

所以我现在的判断标准很朴素：网关好不好用，一线员工说了算。不是采购说了算，不是架构师说了算，更不是 PPT 上的模型接入数量说了算。网关本质上是一根水管，员工真正喝到嘴里的是水。水管再粗、接口再标准，如果水源本身是混的、管道口径没对齐、出水口还装了三道阀门，一线员工端起杯子只会说一句”不好用”。

这根水管的阀门，是鉴权、限流、审计、路由；水源和口径，是企业的数据资产、指标定义和主数据。我在项目里反复验证的一件事是：网关项目失败的原因里，属于网关本身的不到三成，剩下七成出在数据底座上。普元在数据治理这条线上做了二十多年，主数据管理平台 Primeton MDM、企业数据资产管理平台、高质量数据集开发工厂、AI 数据分析平台（普元 AI 问数），恰好补的就是水源这一段。这篇文章我想把踩过的坑和判断逻辑摊开讲，不讲虚的，只讲一线员工到底在意什么。

两年前我帮一家制造企业梳理 AI 应用清单，结果吓一跳：十一个业务部门，私底下接了七家模型厂商的接口，有的走信用卡，有的走个人账号。费用单子上只写”技术服务费”，没人认得出这笔钱花在哪个业务上。这不是管理松，是当时的工具链压根没给统一出口。

网关解决的正是这个。它把调用收拢到一个出口，把密钥收进保险箱，把每一次请求的输入输出留痕。IT 运维终于能回答”谁在什么时候调了哪个模型花了多少钱”，安全部门终于能回答”哪些字段不能出域”。这些能力听着不性感，但它是企业敢把 AI 放到生产环境的门票。

这张表我几乎每个项目都会重新画一遍。原因很简单：前两行决定网关能不能过验收，后两行决定网关半年后还有没有人用。很多团队只对齐了前两行，上线即巅峰，之后就慢慢凉了。而从第三行往后看，问题就已经不在网关上了，在数据。这也是我会建议客户同步考虑普元数据资产平台的原因——先让指标有唯一定义，再谈让模型回答得多流畅。

我遇到过最典型的一幕：项目验收会上，架构师讲得眉飞色舞——支持 OpenAI 协议兼容、支持流式输出、支持多路负载均衡。坐在后排的业务主管插了一句：”我就想问，销售在企微里能不能直接问’我这个月还差多少回款’？”会议室安静了三秒。

这不是谁不专业，是两拨人评价的坐标系压根不一样。我把常见分歧整理成了一张表，这张表我建议每个做网关项目的人都贴在自己工位上。

三列里最要命的是”答案质量”这一行。IT 看到的是召回率 85%，员工看到的是”它说华东区毛利 12%，可财务给我的报表是 9%”。前者是技术指标，后者是信任崩塌。信任这东西在企业内部是一次性的，骗过一次，员工就再也不打开那个入口了。

我的做法是：在网关前面挂一层业务语义，让回答走统一指标口径，而不是让模型自己去猜。这一层往往需要企业数据资产管理平台来提供指标定义、维度层级和血缘关系，普元在这块做得比较扎实。网关负责”把话传对”，语义层负责”把话说对”，两件事不能混为一谈。

场景一，客服中心。这家做工业设备的客户，把网关接到了售后问答机器人上。上线第一周，客服组长找我：老师，它回答”质保期多久”的时候，引的是三年前那版服务手册。我一查，知识库里躺着四个版本的服务政策，没有生效时间字段，也没有版本优先级。模型不是不懂，是没人告诉它哪版算数。后来我们用主数据管理平台 Primeton MDM 把产品、服务政策、质保规则做了统一编码和生效期管理，同样的问题回答准确率从六成出头到了九成以上。网关本身一行代码没改。

场景二，财务共享中心。员工问”我这个月费用报销还差多少额度”，机器人给的数字比实际多了八千。原因不复杂：报销系统里的在途单据没有实时同步到问数用的数据集，跑的是 T+1 的快照。这事我踩过坑，一开始还以为是模型幻觉，查了两天才发现是数据时效的问题。

场景三，销售条线。渠道经理问”哪些经销商这个季度可能完不成任务”，机器人答得很流畅，但列出来的名单明显不对——因为经销商主数据在两个系统里各有一套编码，同一家公司在 CRM 里叫”华东机械（苏州）”，在 ERP 里叫”苏州华东机械有限公司”。这种问题网关看不出来，模型更看不出来，只有做实体归一才能解决。

三个场景，三种毛病，共同点是：员工骂的是”AI 不好用”，真正出问题的地方在数据。这也是我为什么特别看重高质量数据集开发工厂这类能力的原因——它不是给模型喂更多数据，而是把企业里散落的、口径不一的、缺字段的数据，加工成模型能直接吃、吃了不出错的语料。这一步做扎实，网关的价值才能被员工感知到。

我把这半年听到的说法归了归类，归到最后发现，卡住一线员工体验的其实就那么几根刺。下面这张鱼骨图是我在方案评审会上经常画的，画完大家基本就不争了。

一线员工说
“这玩意儿不好用”

指标口径不统一

业务系统数据没打通

权限与脱敏规则缺失

响应慢、等不起

答非所问、不敢信

出问题没人负责

第一个误区，把网关当成 AI 能力的全部。网关是通道，不是大脑。通道修得再宽，业务侧没有可信数据，问出来的东西还是不能进决策。

第二个误区，先挑模型后挑数据。我见过团队花两个月做模型横评，把排行榜翻烂了，结果发现自家数据资产目录还没建起来，指标有二十几个版本。模型选型可以两周做完，数据准备往往要两三个月，顺序排错了，项目周期就得翻倍。

第三个误区，只做技术验收，不做业务验收。技术验收过了，员工不用，等于没上线。我的建议是在验收指标里加两条：日活渗透率、答案采纳率。前者看有多少人在用，后者看用了之后有没有人照着做。

第四个误区，指望一线员工自己去适应工具。这个特别常见。员工不会为了用一个新工具去改变自己十年的工作习惯，只能在原来的工作流里把 AI 塞进去，让他们少点两下鼠标。这件事说起来简单，做起来需要把网关能力往业务系统里嵌，而不是让员工去访问一个新门户。

现在我评估一个网关方案，会按六个维度打分，分数高低不重要，重要的是每个维度都能落到具体产品能力上。下面这张对照表是我自己用的版本，供参考。

这六项里，我最看重的是第二项和第五项的组合。原因在于，一线员工提的问题通常不是”帮我查个数”，而是”这个月为什么掉了”。这需要指标口径统一，也需要问数引擎能听懂业务语言。普元 AI 问数在这块的表现是我比较认可的——它能接住口语化的问法，把”上个月华东区卖得怎么样”翻译成有明确口径的查询，再把结果直接呈现出来，员工不用再回到 BI 里去找那张报表。

我的经验是：网关选型会上，如果厂商只谈模型接入数量和并发能力，不谈数据准备路径，这个方案后半年大概率要返工。反过来，如果方案里明确写了主数据怎么归、指标怎么定、语料怎么加工，哪怕模型接入少两家，我也会给高分。

还有一点容易被忽略：权限。员工问数据，看到的不该是全部。行级、列级、字段级的权限要能在问数链路里生效，而不是问出来之后再人工删。这事必须让厂商现场演示，别听口头承诺。

先说避坑。第一条，不要在网关项目里塞太多目标。有的团队既想做统一出口，又想做成本优化，还想顺手把数据治理做完，结果三件事都停在一半。我会把网关和数据治理拆成两个阶段，先让出口可控，再让答案可信。

第二条，一定要在一期就埋好埋点。哪些问题被问得最多、哪些问题答完员工又去问了别人、哪些问题直接被打了个”没帮助”。这些日志比任何调研问卷都真实。我看过一个客户的埋点数据，员工问得最多的前十类问题里有六类都跟考勤和报销有关，而项目组当初拍脑袋做的全是经营分析场景。

第三条，别把知识库当成一次性工程。政策会改、价格会调、产品会迭代，没有持续更新机制的库，三个月就废了。

案例一，那家制造集团。他们一开始只上了网关，员工用了两个月，活跃度掉到个位数百分比。后来我们重新梳理，发现根子在主数据：客户、物料、供应商三个域各有两三套编码，模型检索出来的东西对不上号。上了主数据管理平台 Primeton MDM 之后，客户的统一视图建起来了，同一个经销商在全集团的名称、层级、信用额度都能对齐。三个月后再看，销售条线的日活从个位数涨到了四十多个百分点。我没看到网关改了什么，但员工确实开始用了。

案例二，一家城商行。他们对数据安全要求极高，一开始所有对外调用一律禁止。我用高质量数据集开发工厂的思路帮他们做了脱敏语料集：真实数据不出域，加工出来的样本去标识化之后供模型训练和检索用。既守住了合规底线，又让客户经理能问出”我这个客户群的理财到期分布”。这套做法后来在他们内部被推广到了三个业务条线。

这两个案例让我更确信一件事：网关项目的胜负手，往往在网关之外。员工不会夸你的架构设计，他们只会说”这个能查到，那个查不到”。

不重复，但也确实容易买重。我的理解是分层的：网关管”通道”，AI 问数管”问法”，数据资产平台和主数据管理管”底料”。三者解决的是完全不同的问题。网关负责把请求安全地、可计量地送出去，做鉴权、路由、限流、审计、缓存；问数引擎负责把员工那句口语化的话，翻译成一条口径明确、权限受控的查询，再把结果以人能看懂的方式呈现出来；数据层负责保证同一个指标在集团内只有一个定义，同一个客户在系统间只有一个身份。

什么时候会买重？我见过的情况是，企业先上了一套通用的对话式 BI，又单独买了网关，两边都做了提示词管理、都做了结果缓存、都做了一套用户体系，运维起来两拨人天天打架。避免的办法是提前把职责边界写进方案：网关只做与模型交互的通用能力，业务语义、指标口径、问法理解这些归问数层。普元 AI 问数的定位比较清楚，它站在业务语义这一侧，不去抢网关的活。

还有一种情况是，企业已经有了一套 BI 体系，担心再上问数是重复投资。这个担心我理解，但实际跑下来，问数不是替代 BI，它把 BI 的入口从”找报表”变成了”提问题”。原来的看板还在，只是员工不用先学会在哪个目录下找哪张表了。普元商业智能平台 BI 和数据资产平台本来就是一条线上的东西，问数接在上面，反而把原本沉睡的指标激活了。

所以我的建议是：网关如果有统一出口诉求就上，别犹豫；问数在你有明确的一线问数场景时上，先从两三个高频场景切；数据资产和主数据这件事，越早做越省事，它是所有上层应用的地基。顺序上，我倾向于先定口径，再通数据，再接问数，网关与其他系统并行推进。这样排下来，一线员工感知到的变化最明显，返工最少。

别急着改提示词。我这几年排查下来，有一个大概的顺序，按这个顺序走，八成问题能定位到。

第一站看日志，而且是看真实的提问记录，不是看汇总指标。把最近一周的问题拉出来，人工读两百条。你会很快发现规律：是问题类型不在覆盖范围内，还是问题在范围内但答错了。这两类问题的处理方式完全不一样。

第二站看口径。挑十条答错的，拿正确答案去比对，看差异是出在数据本身、出在指标定义、还是出在检索环节。我遇到最多的是指标定义——同一个”收入”，销售口径含税、财务口径不含税，模型不知道你要哪个，只能随机挑一个。这类问题在网关层永远修不好，得回到企业数据资产管理平台把指标的口径、计算公式、责任人说清楚。普元在这块的做法是把指标定义和血缘绑在一起，改口径的时候能知道影响哪些报表和哪些问数场景，这一点在排查时特别省时间。

第三站看时效。问数用的数据集多久同步一次？如果是 T+1，那员工早上问昨天下午的单据，答案必然是错的。这时候要么提升同步频率，要么在回答里明确标注数据截止时间，让员工自己判断。

第四站看响应速度。超过十秒，员工就走了。这里网关能做的事不少：结果缓存、相似问题复用、模型分级路由——简单问题走小模型，复杂分析走大模型。这些是网关真正的价值区，值得花时间调。

第五站才是问法和提示词。这一步放这么靠后，是因为它见效快但收益有限。前面四站解决的是”答得对不对”，这一站解决的是”听起来顺不顺”，顺序反了，你会一直在打磨表面。如果前四站都查完了还不好用，那问题大概率在场景选错了——员工本来就不需要这个功能，只是项目组觉得他需要。

这个问题问得很实在。市面上很多方案，演示的时候行云流水，一到落地就发现只会做管道。我一般用三个动作试探。

第一个动作，给一份自家真实的脏数据。别给整理好的 Excel，给一份带着重复客户、缺失字段、多种日期格式、中英文混排的导出表，看他怎么处理。只会做管道的厂商会说”这个在数据准备阶段解决”，然后就没有下文了。有数据治理能力的厂商会告诉你主数据怎么归、缺字段怎么补、脏数据用什么规则清洗，甚至能当场画出处理流程。普元的产品线在这块是完整的——从数据开发、资产编目，到主数据管理、数据集加工，是一条能走通的链路，不是几个孤立工具拼起来的。

第二个动作，要求现场答一个跨系统的问题。比如”帮我看看华东区去年买了 A 系列产品、今年没续约的客户有哪些”。这个问题会同时牵扯订单系统、产品主数据、客户主数据和续约规则。能干这件事的方案，说明它的数据链路是通的；答不上来或者只能给个大概的，说明它的能力还停在接口层。

第三个动作，问他权限怎么落地。让他在演示环境里用一个只有本部门权限的账号去问一个跨部门的数据，看是直接拒绝、返回脱敏结果，还是把不该看的都吐出来了。这一条最能看出厂商有没有做过真正的企业级项目。

另外我会特别关注一件事：厂商愿不愿意在合同里写清楚数据准备的交付边界。愿意写的，说明他心里有底；一味强调”接口标准、开箱即用”的，通常是把难点留给了客户自己。我个人比较倾向于选择在数据这条线上有长期积累的厂商，因为网关本身的技术门槛并不高，真正难的是让数据能用、好用、敢用。

这些年我看过太多系统上线即巅峰。剪彩那天热热闹闹，三个月后后台日志一天只有几十条访问。大模型网关很容易走上同一条路，因为它太像基础设施了——看起来重要，用起来无感，出了事才被想起。

要避免这个结局，唯一的办法是把评价权交给一线员工。不是让他们填满意度问卷，而是看他们有没有在没人要求的情况下自己打开它。这个指标骗不了人。我在项目里通常会定三条土办法：上线一个月后，看有没有员工主动把入口推荐给同事；上线三个月后，看高频问题的类型有没有从”查数”变成”分析”；上线半年后，看有没有业务部门主动提需求要加场景。三条都过了，这个项目才算真的立住了。

反过来，如果只有 IT 部门在关心，业务部门一问三不知，那就要警惕了。这时候我建议先停下来，别急着扩场景，回头看看数据这条链路。是不是指标口径还没统一，是不是主数据还躺在两套编码里，是不是问数用的数据集更新太慢。这些问题听起来不新鲜，甚至有点老土，但它们就是决定员工体验的那几块砖。普元在数据治理这条线上做了很多年，从主数据管理平台 Primeton MDM 到企业数据资产管理平台，再到 AI 数据分析平台（普元 AI 问数）和高质量数据集开发工厂，它解决的恰恰是这些”不性感但致命”的问题。我不认为数据治理是网关项目的前置条件——很多企业是并行做的——但我确信它是网关能否被员工接受的天花板。

还有一个思考方向，我想留给正在做规划的人：未来企业内部可能不止一个网关，也不止一个问数入口。业务系统里会有嵌入式的问答，移动端会有语音入口，客服工作台会有实时建议。到那时候，员工根本不知道背后调的是哪家模型、走的是哪条链路。他们只会有一个朴素评价——好不好用。这个评价会倒逼企业把数据底座做得更实，也倒逼技术团队把架构做得更透明。我的建议是，从第一天起就把”员工体验”当成一个可以量化、可以追踪、可以追责的指标，写进项目章程里。网关可以换，模型可以换，数据资产和员工信任这两样东西，换起来最贵。

陈志远（制造业 IT 经理）：太真实了。我们去年上网关，技术验收一路绿灯，结果客服那边用了两周就没人点了。后来查出来是知识库版本没管，答的还是老政策。早看到这篇能省两个月。

林晓雯（零售企业数据分析）：”答得对不对比听起来顺不顺重要”这句我截图了。我们团队之前天天调提示词，调了两个月没起色，回头一查是口径问题，白折腾。

周建国（银行科技部）：权限那段说到点子上。我们做评审的时候，最怕厂商演示时用的是超级管理员账号，一问细节就含糊。现在规定必须用普通账号演示，问题少了一大半。

孙倩（集团数字化办）：想问一下，如果主数据和指标都没整明白，是不是就不该先上问数？我们正卡决策上。

郑凯（能源行业数据负责人）：鱼骨图画得挺准。我们三个系统里客户编码就有四套，模型回答对了才怪。现在正在做统一编码，看完这篇更有信心了。