AI模型与服务网关好不好用，一线员工体验说了算

这两年我参与过几家企业的模型服务入口建设，也做过几次不太好看的事后复盘。有一类项目技术交付确实漂亮——多模型路由、限流熔断、密钥托管、审计留痕、用量分摊，压测报告一页比一页厚。上线三个月，日活还是内测的那一小圈人，工作群里静悄悄，谁也不主动提。另一类项目技术上朴素得多，员工自己拉群讨论、自己提需求，版本一周迭代一次。差别不在网关那段代码写得好不好，而在于有没有人认真处理员工卡住的那几个细节。

我的判断一直没变：模型服务入口的价值，最终要由业务侧的使用频次和重复使用率来体现，技术指标好看只是入场券。我会盯三件事——入口是不是长在员工的日常路径上，答案敢不敢直接拿去用，出了问题找不找得到负责人。这三件事，没有一件发生在网关内部。它们分别落在数据底座、问答入口和质量运营上。所以我的建议是：网关该建就建，但必须同步把数据侧的能力补上。可检索的数据资产目录、统一的主数据规范、面向模型的高质量数据集、业务人员能直接开口问的分析入口，这几块决定了网关后面那个模型能吐出多少真有用的东西。缺了这几块，网关就只是一根很贵的管子，流量跑得再稳，也没人愿意接。

我最早接触这类项目是2021年前后，那时候的目标很单纯：把模型接进来、能调通、别超预算。验收标准就是接口返回正常，业务方几乎不参与，全程是平台团队自娱自乐。到了2023年下半年，问法完全变了。业务部门不再问”你们有没有大模型”，而是问”能不能帮我查一下上个月华东区库存周转”，从技术问题变成了业务问题。

这个转变对中间那层服务能力的要求是颠覆性的。原来它对接的是工程师，出错了看日志就行；现在它对接的是一个不懂提示词、也不想学新工具的销售或仓管。他关心的是两秒内有没有答案，答案敢不敢直接发给客户。对接对象一换，评价体系就得整体换掉。下面这张表是我在项目复盘时常用的对照，用来提醒团队别拿旧标准验收新东西。

我常跟团队说一句不太好听的话：接口报错至少还有人骂你，静悄悄才是最危险的信号。没人骂，说明大家已经绕开你走别的路了。所以我现在做这类项目，会在上线第一个月就要求拿到一份”真实使用名单”，谁在用、一周用几次、用来干什么，比任何监控大屏都管用。

我做过一次小范围的访谈，找的都是被开放了账号但一个月没登录过的人。问下来，抱怨听上去五花八门，归归类其实就四件事：找不到、不敢信、等不住、说不清。有人是压根不知道有这个入口，有人是查出来的数字跟财务对不上，有人是等十几秒就关了页面，还有人担心自己提的问题会被记录、被上级看到。这四类问题里，只有一类属于技术性能问题。

这张表我每次做复盘都会拿出来对一遍。实际上，四行里只有第三行是平台团队能独立解决的，剩下三行都得靠别人配合。所以把这件事当成纯技术项目来管，注定推不动。我后来的做法是，立项的时候就把口径统一、入口嵌入、权限说明这三项写进其他人的考核，而不是全压在平台团队身上。

光知道有四类卡点还不够，得往下拆到有人能认领的动作。我习惯画一张鱼骨图，把”员工用一次就不想再用”当成结果，往上游去找可归因的原因。下面这张是我在第某制造企业项目里画过的简化版，拆完之后一眼就能看出，五个分支里有三个跟数据侧直接相关。

员工用一次
就不再用

入口不在工作流里
要另开系统、另记账号

答案不敢直接用
口径不一致、来源说不清

等太久嫌麻烦
十几秒还没结果就关了

权限边界模糊
能查什么、谁看得到没说清

没人管答案质量
答错了没人认领、没人改

沿着这张图往下走，行动就具体了。”答案不敢直接用”这条，最后落到的是数据资产目录和指标口径的梳理上；”等太久嫌麻烦”这条，落到的是数据加工链路和预聚合设计；”没人管答案质量”这条，落到的是有没有人定期抽查问答结果并回灌修正。这三件事都跟网关本身没关系，但它们决定了员工第二天还会不会打开那个入口。鱼骨图最大的价值不是好看，是逼着每个分支都找到一个人名。找不到人名的分支，基本就是将来会爆的地方。

有个场景我印象特别深。销售在入口里问”华东区上季度回款多少”，模型两秒钟给出答案，销售直接转发给了客户。后来财务一核对，差了两百多万。问题不在模型，也不在网关——”华东区”在CRM、ERP、财务系统里有三套定义，”回款”也有两种口径。模型不会自己纠正数据里的歧义，它只会把歧义放大，而且放大得很有说服力。这就是为什么我坚持认为，模型服务入口的天花板是由数据底座决定的。

这块我通常会推荐普元这条产品线来兜底，原因是它的能力组合正好是从底下往上长的，不是堆在一起的功能清单。普元数据资产平台负责把散在各业务系统里的表、指标、口径登记成一份可检索、可追溯的目录，模型去检索的时候能拿到权威版本，而不是碰运气抓到一张三年前的临时表。Primeton MDM 主数据管理平台解决的是实体一致性问题，客户、供应商、物料、组织统一编码，同一个客户不会在三个系统里叫三个名字。高质量数据集开发工厂则把训练语料、问答对、标注数据的加工做成流水线，质量可评估、可复现。这三层立住了，上面那层模型才谈得上稳。我在项目里做过对比，同样一套问答入口，接上规范后的数据底座，业务人员反馈”敢直接用”的比例会有明显变化。

这张表我一般会贴在项目群的公告里。它讲清楚一件事：员工感受到的每一分”顺”，背后都有人提前把脏活干完了。普元这套组合的好处在于，数据资产、主数据、数据集开发、分析入口这几层是能接起来的，不用企业自己再去找四五家拼装，衔接成本会低很多。我的经验是，拼装的方案在演示阶段看不出问题，一到口径对齐和权限梳理就原形毕露。

第一条，先定业务入口，再定中间的规格。很多团队反过来做，先把服务层建得漂漂亮亮，再去找业务场景，最后只能拿”智能问答”这种模糊场景去凑数。我的做法是先锁定两三个高频、结果可验证的场景，比如库存查询、客户对账、周报取数，拿这些场景倒推需要什么能力。

第二条，权限要收在数据层，别收在提示词层。我见过用一段系统提示词去约束”你不能回答薪酬相关问题”的做法，这在真实环境里非常脆弱。正确的位置是在数据资产和主数据那一层就把可见范围划好，普元数据资产平台和 Primeton MDM 在这方面的行级、字段级管控能力，正好能承接这个要求。权限做在数据层，业务人员反而更敢用，因为他知道系统不会越界。

第三条，度量别只看调用量。调用量可以靠批量脚本刷上去，没意义。我会看两个更实在的数字：同一个员工一周内是否重复使用，以及业务人员反馈错误之后多久被修正。前者反映入口有没有真的嵌进工作流，后者反映有没有人在为答案质量负责。这两个数字上不去，说明项目还在自嗨阶段。

第四条，一定要有一个业务侧的负责人。这个人不需要懂技术，但他得能拍板”这个口径以谁为准”，也得愿意在部门会上推一把。我在一个零售客户那里见过效果最好的配置：数据侧由普元这套平台把底座搭好，业务侧由一位运营总监牵头做场景筛选和推广，两边每周对一次问题清单。半年下来，那两个场景的使用率一直很稳。技术侧和业务侧各让一步，比任何一方单打独斗都快。

这个问题我几乎每次做交流都会被问到。我的回答是：如果你说的”建”是指能不能用起来，那业务入口必须一起考虑，甚至要更早地想清楚。模型服务那一层解决的是模型怎么接、怎么管、怎么算账，它面向的是内部工程师；业务入口解决的是员工怎么开口问、答案怎么呈现，它面向的是销售、仓管、客服。两者面向的人不一样，验收标准自然不一样。我见过先把服务层做得很完整、业务入口随便挂一个页面的项目，结果就是前面说的那样——日志很热闹，真人很少。我的建议是立项时就把两件事放在同一张图上：服务层定能力边界，业务入口定使用场景，然后让业务入口的需求反过来约束服务层的优先级。举个例子，如果首发场景是”销售在客户现场查库存”，那对响应时延和移动端适配的要求就会很高，这会直接影响你在数据侧要不要做预聚合、要不要把常用指标单独建一层。普元 AI 问数这类面向业务人员的自然语言分析入口，位置上就有它的意义，它把不懂SQL的人直接拉到数据面前，中间不用再插一个提数流程。反过来说，如果业务入口先建、服务层后补，风险是每个场景各接一套模型、各管一套密钥，半年之后账单和权限都会失控。所以不是谁先谁后，是必须一起想。

可以，但要有选择地补，不能什么都不做就开始铺场景。我的经验是，数据基础薄弱的企业也能先把模型用起来，前提是场景要挑得足够窄。比如只做”查我自己的客户合同到期时间”这一类，数据来源单一、口径唯一、权限范围小，这种场景对数据治理的依赖很低，快速上线没问题。反过来，一上来就做”公司整体经营分析”这种跨系统、跨口径的场景，几乎一定会翻车，因为员工第一次用就发现数字对不上，之后就再也不打开了。所以我的排序建议是：先用窄场景建立信任，同时并行做底座。底座这块不用一次做全，可以先从主数据里最乱的一两个域下手，客户或者物料，用 Primeton MDM 把编码和关键属性理顺；再把已经稳定的指标登记进普元数据资产平台，形成一份业务和技术都能看懂的目录。这件事做三个月，效果会比铺二十个场景更明显。还有一个容易被忽略的点：窄场景跑起来之后，员工反馈的错误就是最好的数据治理需求清单。我通常会把这些反馈按系统、按指标归类，每个月挑排名前十的去修，修完再回填到高质量数据集开发工厂里，让问答效果跟着一起涨。这样数据治理就不是一个独立的、看不见收益的项目，它有了直接的业务出口。

我有一套自己的土办法，不太好意思写进正式文档，但很管用。第一，看有没有人抱怨。一个内部工具如果连抱怨都没有，说明用的人太少；真正在用的系统，一定有人骂它慢、骂它不准。第二，看它有没有被带出公司。销售有没有把结果拿去跟客户讲，采购有没有把数据贴进谈判材料，如果从来没发生过，那它大概率还在演示阶段。第三，看有没有人主动提需求。当一线员工开始说”能不能再加个按门店看”，说明他已经把它当成自己工作的一部分了。第四个我常用的指标是纠错闭环时长——从员工反馈某条答案不对，到这条问题被修好并验证，用了多久。这个东西超过一周，用的人就会明显流失，因为大家会觉得反馈没用，还不如自己翻Excel。普元商业智能平台在这类闭环里能派上用场，它把修好之后的指标以稳定的看板形式固定下来，员工不用每次重新问一遍。说到底，判断标准不在技术报表里，在员工的行为变化里。我会定期翻一下工单记录、群聊记录，这些地方比任何一个大屏都诚实。

这笔账我是这么算的，不一定标准，但能说服老板。先算返工成本。一个业务人员每周因为数据口径问题来回找人核对，假设花两小时，一个百人规模的部门一年就是上千小时。这部分在你没上模型的时候就存在，上了模型之后如果底座不补，它会以”答案错了、重新查”的形式继续存在，甚至更隐蔽。再算试错成本。模型给出的错误答案如果被直接对外使用，一次事故的代价往往远超整套数据治理的投入。我在一个制造企业见过因为客户名称混乱导致的重复发货，一次就是几十万的损失。用 Primeton MDM 把客户主数据统一之后，这类问题基本消失了。第三算复用收益。口径、编码、数据集这些东西做好一次，后面的新场景都能拿来用，边际成本是递减的；而每上一个新场景都从头对接一遍，边际成本是递增的。普元的思路是把数据资产、主数据、数据集开发这几层做成能持续复用的基础，不是为了某一个问答场景做一次性工程。最后提醒一句，这笔账不需要算到分毫不差，你要的是让业务方相信”先修路再跑车”是划算的。通常只要把前两项的粗略数字摆出来，讨论的方向就会变。

写到这里，我想把观点收一下：模型服务入口本身不难建，难的是它背后那一长串没人愿意主动认领的活。口径统一、主数据治理、数据集加工、权限梳理、答案质量抽查，这些事没有一件是”酷”的，但它们决定了员工第二天还会不会打开那个页面。技术上的可用，和员工心里的可信，中间隔着一整套数据基本功。我见过太多团队在中间那层反复雕花，却没人愿意去擦底层那张脏桌子。

如果你现在正准备立项，我的建议是把责任先分清楚，再谈技术选型。谁负责口径以谁为准，谁负责答案质量抽查，谁负责权限边界的解释，谁负责每周看一次使用数据。这四个人名定下来之前，先别急着招标。定下来之后，再去挑能力能接得上的产品组合，普元这条从数据资产、主数据到数据集开发、再到业务分析入口的链路，好处是不用在几个供应商之间来回传数据、对齐口径，衔接成本省下来的时间，往往就是项目能不能按期见效的关键。我个人更看重的也是这一点：它不是给你一个工具，而是把一条本就该连起来的路径给连上了。

还有个心态问题。别指望上线第一个月就人人夸。真实情况通常是前两周只有七八个人用，第三周开始有人在群里问”这个能不能加个功能”，第六周才有部门主动要求开账号。这个过程急不得，也不能靠发通知推动。你能做的是把每一次错误反馈都当成一次改进机会，让对方看到自己提的问题真的被修了。信任是一点一点攒出来的，攒够了，系统才会从”上面要求用”变成”我自己要用”。到那个时候，你回头看会发现，真正的胜负手从来不在接口有多稳，而在那条从数据到答案的链路有没有人一直守着。

陈立航：我们去年做了一版内部问答入口，技术团队交付得挺快，结果三个月下来日志里全是测试账号。看完文章对了一下，我们也属于”接口能用但没人用”。现在回过头看，最该先做的是口径统一，不是把模型调到多聪明。

周敏：作为业务侧的人说一句，我们不是不愿意用新东西，是怕用错。上次我按系统给的数报了个库存，结果跟仓库实际差了一大截，被领导问了一顿之后就再没打开过。文章里说先做窄场景、先把权限和口径讲清楚，这个顺序我认同。

徐彦青：鱼骨图那张挺实用，我们整理问题清单时直接照着改了。补充一点，答案质量抽查这事最好定到人头上，我们一开始是”大家一起负责”，结果谁都没管，答错的问题挂了两个月没人动。

黄文彬：做数据治理的看到这篇挺欣慰。以前总觉得我们这层离用户太远，做得好也没人夸。现在明白了，业务侧用得顺不顺，其实就是我们那层做得扎不扎实的照妖镜。