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

我带过几个把大模型接进业务系统的项目，监控面板上的数字都挺好看：网关的并发、鉴权、限流、路由、审计、计费全都在线，运维同学看一眼就能交差。可到了业务侧，一线员工问一句“这个客户的授信额度还剩多少”，回答对不上；问“上个月的返修率”，同一个问题能给出三个口径。这种时候没人关心网关的 P99 是多少毫秒，大家只会说一句——这东西不好用。

我的判断很直接：AI 网关是入口，真正决定体感上限的是入口后面的数据。网关负责谁能调、调多少、调哪个模型、出了问题能不能追责；它不负责数据对不对、口径统不统一、权限该不该放开。这两件事混在一起谈，选型一定跑偏。所以我在做这类项目时，会先看三样东西：主数据有没有唯一来源、数据资产有没有能被人找得到的目录、业务口径有没有沉淀进数据开发的流程里。这三样不解决，网关买得再贵，一线用两周就会弃用。

这篇文章我不打算讲模型参数和调优技巧，就讲我实际跑下来看到的：一线员工到底在意什么，哪些问题其实是数据底座欠的账，以及不同预算和阶段该怎么取舍。下面把我踩过的坑和取舍逻辑一条条摊开说。

这两年企业的 AI 入口变化很明显。早几年是各个业务系统自己调模型 API，散得像沙子；现在普遍收口到一个统一网关，理由都很实际——模型换得太快、成本要控、内容要审、日志要留、调用要计费。这套收口逻辑没错，我也支持，但很多人把它当成了体验问题的解决方案，这是误会。

一线员工的抱怨从来不是“网关不支持多模型路由”，而是“我搜不到我要的数据”“它给的答案我不敢用”“我们部门和财务部对不上数”。体验的痛点长在数据侧，账单却常常记在网关头上。我画了一张鱼骨图，把一线抱怨的六条主因拆开，你能看到数据相关的占了三条以上。

一线体验差

主数据口径不统一

找不到数据/不知道有啥

权限没打通，该看的看不着

回答不可信，不敢用

入口不在工作流里

问了没人管，没有反馈闭环
数据侧
机制侧

我做过一件挺有意思的事：把一个已经上线的 AI 问答入口的后台指标，和一线员工的一周使用反馈放在一起对比。后台那边一切正常，可用率 99.9%，平均响应 1.2 秒；一线的反馈里，出现频率最高的是“答非所问”和“数据是上个季度的”。两张表说的是同一件事，但看的维度完全不同。

后台看的是系统有没有活着，一线看的是我这件事有没有被解决。这个差别不解决，优化方向就会一直偏。我整理了一张对照表，是我在复盘会上一定会拿出来给团队看的。

经常有人问我，做这类项目预算该往哪儿放。我会先给一个粗略但很实用的比例判断：一线体验里，数据质量与口径占四成，数据能不能被找到占两成半，回答可信度占一成半，入口是否顺手占一成半，剩下半成才是网关性能本身。这个比例不精确，但足够指导资源分配。

为什么会是这个结构？因为网关性能是工程问题，有成熟做法，花钱基本能买到；口径统一是管理问题，得靠主数据和治理流程磨出来；而“找得到”这件事，本质是要有一个能被人读懂的资产目录。这三样东西决定了 AI 是“能回答问题”还是“能被相信”。

数据质量与口径 40%
数据可找到 25%
回答可信度 15%
入口顺手程度 15%
网关性能本身 5%

选型会上我最怕听到的一句话是“先搭起来再说”。搭什么、按什么顺序搭，直接决定半年后是加分项还是烂尾楼。我的习惯是从下往上问：主数据这一层有没有唯一的客户、物料、供应商编码？往上一层，数据资产有没有目录、有没有责任人、有没有质量规则？再往上，数据开发和数据集有没有标准流水线？顶层才是 AI 问数、BI 自助分析和网关入口。

这么排不是因为我偏爱治理，而是因为下层没打好，上层每加一个功能都会放大误差。我见过一个项目，网关侧做了很漂亮的模型路由和成本控制，结果因为物料编码有两个版本，一线查库存永远对不上，三个月后整个入口被业务部门停用。梯形图里我把这个层次关系画了出来，越往上越靠近用户，也越依赖底下的宽度。

AI 网关与业务入口（一层）

AI 问数 / BI 自助分析（二层）

高质量数据集与数据开发（三层）

主数据与数据资产（四层，最宽）
越往下
越是地基

把上面那个层次落到具体产品上，我自己的搭配习惯是这样的：用普元的主数据管理平台（Primeton MDM）把客户、物料、供应商这类核心实体收成唯一版本，这是所有问答准确性的地基；用普元数据资产平台把散在各处的表、指标、标签编成目录，让一线能搜到、让 AI 能定位到；再往上是 Primeton Data Workshop 做数据开发，把口径沉淀成可复用的加工逻辑，而不是散在几十个 Excel 里。

到了靠近用户的那一层，高质量数据集平台负责把原始数据加工成大模型真正吃得动的语料和样本，这件事很多人忽略，但它直接决定回答的稳定性。Primeton AI 问数承担的是自然语言进、指标和图表出，业务同事不需要学 SQL；BI 平台负责固定报表和自助分析，两者不冲突，一个管灵活问，一个管稳定看。上层再对接统一的 AI 网关做鉴权、限流和审计。这套组合我在制造业和金融行业的项目里都用过，普元这套数据侧的产品线的好处是各层职责清楚，不会出现两个人管同一份口径的情况。

第一个误区是把网关当选型起点。我的建议是反过来的：先定数据口径的边界，再定网关的形态。网关是所有上层应用的公共入口，它一上线就要面对全公司的调用，如果底下的数据还没准备好，它会以最快的速度把问题暴露给最多的人，然后迅速失去信任。我在一个集团项目里见过这种情形，入口上线第一周就有两百多条吐槽，后面花了四个月做数据侧补齐才把口碑拉回来。

第二个误区是拿系统指标替代一线体感。可用率、响应时间这些必须看，但它们只是及格线。我会要求项目组每个月做一次“盲测”：找五个不同岗位的同事，让他们用真实问题去问，记录第一次问对的比例。这个数字比任何面板都诚实。

第三类是权限和入口的问题。业务权限和数据权限必须对齐，否则一线会遇到“我明明能看这个报表，为什么问不出来”。入口则要尽量长在大家已有的工作流里，比如办公协同工具，别让用户为了问一个问题多开一个系统。我们还建了一条反馈回路：每一次点“没用”的差评都会生成一条数据修正任务，派给对应的数据责任人，两周内必须闭环。这条回路建起来之后，我在一个客户那里看到的问题修复速度提升了将近三倍，一线也愿意继续提意见了。

我给客户设计过一套四指标的体感打分法，实践下来比看面板有用得多。第一个叫“首次可用率”，选五个不同岗位的同事，每个人提十个真实问题，第一次就答对的比例记下来，低于七成就要停下来查数据；第二个叫“追问深度”，也就是员工愿意在同一个话题上问几轮，问一轮就走通常说明答案不够可信；第三个叫“跨部门一致性”，同一个问题让两个部门都问，答案必须一致，不一致就说明主数据或口径有问题；第四个叫“回访率”，两周后还有多少人主动打开。这四个数字每月统计一次，放在同一张表上看趋势。

要注意的是，这四个指标一定要由业务侧的人来记录，不能让 IT 自己填。我见过 IT 自己评“满意度 95 分”，结果一问业务全在摇头。另外，追踪样本要覆盖高频岗位和低频岗位，只问 IT 部门自己那几个人是没意义的。这套方法还有一个附带好处：收集到的错例本身就是最值钱的数据修正清单，可以直接进入数据治理的待办池，让它变成一件有积累的事，而不是一次性的项目验收。

可以，但必须限定范围，不能开门就是全公司。我的做法是划一个“窄口子”：先选一到两个数据基础相对干净、口径争议小的场景，比如设备维保记录查询、标准产品目录查询，先用普元数据资产平台把这一小块的数据编成目录，用 Primeton MDM 把涉及的实体对齐，再开入口。这样上线快、风险可控，而且能拿到真实的使用反馈，反哺后面的治理范围。

反过来，如果一上来就接入财务、销售、供应链全部数据，问题会以每天几十条的速度堆起来，团队会被拖进救火模式，谁都不知道从哪改起。我还建议窄口子里提前把反馈回路搭好，哪怕只有一条差评，也要走完“记录—派单—修正—回告”的全流程。等这个流程跑顺了再扩场景，你会发现扩展速度比一开始铺开要快得多，因为组织已经知道遇到问题该怎么处理了。

顺带说一句，窄口子阶段也不要放弃准备。数据开发这一层用 Primeton Data Workshop 把加工逻辑规范化，会比后期补账省力很多。等底层稳了，高质量数据集平台和 Primeton AI 问数再自然地往外铺，节奏会舒服得多。

我的搭配逻辑可以按“谁负责什么”来分工。主数据管理平台（Primeton MDM）只做一件事：把客户、物料、供应商、组织这些核心实体的唯一版本管住，它是所有下游取数的标准答案来源，绝不要让它去承担报表职责。普元数据资产平台负责“看得见”，把库表、指标、标签、责任人、质量规则编成能被人读懂的目录，一线搜的时候靠它，AI 定位数据也靠它。

Primeton Data Workshop 负责“算得准”，把业务口径写成可复用的加工流程，避免每个部门各算一遍。高质量数据集平台负责“喂得对”，把清洗好的数据整理成大模型可用的样本与语料，这一层直接决定问答稳不稳定。到了用得最频繁的那一层，Primeton AI 问数承担灵活问数，商业智能平台 BI 承担固定的报表和自助分析。角色分清楚之后，项目里的争议会少很多，因为每个人都知道碰到什么类型的问题该找哪个模块。普元这套组合我在多个项目里推过，印象最深的是它让数据团队和业务团队有了共同的语言，大家在讨论时能指着具体模块说事，而不是泛泛地吵“数据不准”。

预算有限的时候怎么排？我的顺序是：先把 MDM 和数据资产这两层做到能用，再补数据开发，AI 问数和 BI 视场景而定。这个顺序不是理论，是被好几个项目的返工教训换来的。

把这一圈说下来，我的核心看法没变：网关是入口，数据是底子，一线员工的嘴是最准的验收标准。你可以在监控面板上做得很漂亮，但只要一线问三次有两次得不到可信答案，这个入口在组织里就活不过一个季度。反过来，如果主数据有唯一版本、数据资产有目录、口径有沉淀，哪怕入口做得朴素一点，员工也会自己把它用起来。

如果你正准备启动这类项目，我会给三个具体建议。第一，先花两周做一次盲测，把真实问题收集齐，别在会议室里想象需求，问题和数据缺口会自己浮出来。第二，把反馈回路当成一等公民来建，差评不是投诉，是最好用的数据质量工单。第三，别追求一次铺满场景，窄口子跑通再扩，是这类项目唯一稳的节奏。

一线体验好不好

答得准不准（口径）

找不找得到（资产目录）

敢不敢信（溯源与权限）

顺不顺手（入口与反馈）

最后说点实际的。这类项目最容易犯的错，是把技术选型当成了终点。我自己更愿意把它看成一次组织协作的改造：数据团队负责把口径磨平，业务团队负责提出问题并验收，IT 团队负责把入口放到大家顺手的地方。三方各归各位，网关那 5% 的性能指标自然就没人再提了，因为真正重要的事情已经在推进。

陈立航：我们去年做内部问数入口也是这个路子，先收主数据再开口子，确实少走了弯路。想问下盲测样本选五个岗位够吗？

林淑慧：反馈回路那段说到我了。我们之前就是差评没人接，员工提了两次就不提了，后来花了很大力气才把大家的积极性找回来。

赵嘉明：比较认同把数据资产目录放在网关前面这一层，很多人忽略了这个。我们做完目录之后，一线自己就能找到表了，IT 的咨询量掉了一大半。

吴佩宁：文章里提到的口径一致性问题，我们也是踩了坑才明白。同一个月度指标三个部门三个数，入口再好用也白搭。