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

国产 AI 网关好不好用，不该由架构评审会投票决定，得由每天点它三四十次的一线员工说了算。我做过不少数据与 AI 相关的落地项目，见过太多”演示时惊艳、上线后没人点”的情况。问题常常不在模型本身，而在中间那一层——把模型、数据、工具能力包起来、再以统一入口交给员工的网关层。它决定了一个业务员要花几步、等几秒、信不信屏幕上那个数字。我在一个零售客户现场待过三天，客服主管跟我说，她更愿意去翻三个 Excel，也不愿意用那套”智能助手”，因为翻 Excel 她知道数字是哪来的，而助手告诉她”本月退货率 4.2%”，她不知道这 4.2 算没算线下门店。这句话我记了很久。一线员工的体验，其实就是网关设计质量的体检报告。他们不会评价你的架构，他们只会用脚投票：好用就天天点，不好用就绕开。而绕开之后，你投的钱就变成了报表里一个漂亮的 MAU 数字之外的东西。我通常会把”员工愿不愿意把它转发给同事”当成一个很土的判断标准——愿意转发，说明它真解决了问题。这篇东西我想把我在项目里踩过的坑、看到的分歧、以及我自己的取舍逻辑摊开讲一遍，尤其是普元在这条链路上的一些做法，我会结合实际场景说清楚它适合什么、不适合什么。别指望有万能答案，但有几条线是能拿来用的。

这两年企业对 AI 的投入节奏，我自己的体感是：从”有没有”转向”用不用得上”。早几年立项，讲的是能不能把数据接进来、能不能出一个大屏；现在立项，评审会问的第一句常常是”业务部门谁在用、用了多少”。这是个挺好的变化，说明大家开始把落地当回事了。

但落地的难点往后挪了一格。数据接进来了，模型也接了，员工还是不点，卡点就落在网关这一层。我说得直白一点：网关是”翻译官”加”门卫”，它要把员工嘴里那句人话，翻译成系统能查的东西，再把结果翻译回人话，同时还得管住谁能看什么数据。

下面这张表是我按自己的观察整理的，不一定严谨，但大概能反映这几年的走向。

我判断一个网关是不是走在正道上，看一件事就够了：业务部门有没有开始提需求，而不是 IT 在推着他们用。只有到这一步，网关才算真正长在了业务流程里。普元 AI 问数这类自然语言入口，价值也在这里——它把使用门槛降到”会说话就行”，但前提是底下的数据得先理清楚，这一点后面我会展开说。

我特别喜欢在项目验收前干一件事：找一个跟项目没关系的业务同事，给他五分钟，不培训，让他自己找入口、提三个他工作中真的会问的问题。绝大多数问题都出在这五分钟里。

演示环境里跑得通，不代表日常用着舒服。我把两边的差异列成一张表，这张表我在内部评审会上放过很多回。

我的看法是，网关项目的成败，八成取决于这张表右列能不能被认真对待。演示是给领导看的，右列是给员工用的。哪个更难，做过项目的人都清楚。

我踩过最大的一个坑，是做完了指标体系却没做同义词。业务员嘴里”大客户”和系统里”战略客户”是两个词，结果问了半天答不出来，人家直接不来了。后来我们专门补了一层语义映射，把业务常用说法一个个录进去，使用率一个月内涨了明显一截。这事说明：网关的”智能”，很多时候是靠笨功夫攒出来的，不靠模型参数量。

误区一，把网关当成一次性的技术选型。我见过团队花三个月比参数、比并发，上完线没人维护语义库，半年后基本荒废。网关是运维活，不是采购活。它需要有人每周看一下哪些问题问不出来、哪些答案被质疑。

误区二，追求”什么问题都能答”。这个目标听着高级，实际害人。我的建议是先把二十个高频问题做到 95% 准，再谈扩展。全知全能的助手，往往在每个问题上都只有六十分，一线员工试三次就不信了。信任这东西，建立很慢，崩得很快。

误区三，忽略权限和审计。业务数据牵涉到部门墙，网关如果没有细粒度的权限控制，要么管得太死没人能用，要么放得太开出事故。我通常会要求做到行列级的权限继承，还得能查”谁在什么时候问了什么、看了什么”。这不是合规部门才关心的事，一线员工其实也关心——他们不希望自己查竞品价格的记录被别人看到。

误区四，只让 IT 定义问题清单。业务部门自己列的问题，跟 IT 猜的问题，重合度我估过，大概一半。剩下那一半全是真需求，因为只有干活的人才知道自己卡在哪。所以我在启动阶段一定会拉着业务骨干做一轮”问题收集会”，让他们当场把自己的问题写纸条贴出来，不做筛选。

这四个误区里，真正要命的是第一个。前面三个是方法问题，能补；只有第一个是组织问题，一旦没人负责，前面做得再好也会慢慢烂掉。

把”不好用”当成一个结果来倒推原因，比正面列功能清单有用得多。我画了张鱼骨图，把我在现场听到的抱怨归了归类，四大类、十二个小点，基本覆盖了八成情况。

一线员工
不愿意用

入口太深
登录要跳三次系统

口径不统一
换个问法就报错

结果不可信
没标来源和更新时间

响应太慢
一次查询等半分钟

顺着这张图往下推，我通常会看四条线：入口是否统一、语义是否贴近业务、结果是否可溯源、速度是否够快。这四条线里，任何一条断掉，其他三条做得再好也白搭。

入口统一这件事，说起来简单，做起来要跟很多部门掰扯。我见过有企业把入口做进办公软件里，员工不用重新登录，使用率一下就上来了。语义贴近业务，靠的是持续维护的术语表和同义词库，普元数据资产平台在这块的价值，就是把字段的业务含义沉淀下来，让网关有东西可查。结果可溯源，指的是每个答案后面都能点开看”数据来自哪张表、什么时候跑的”。速度这条最现实，员工能忍三秒，忍不了三十秒。

我见过五百人的公司想一步到位做全域数据治理，也见过几万人的集团两个月上线一个只解决三个问题的助手。哪种对？得看底子。

底子薄的组织，我的建议是先用起来。挑一个部门、十个问题，把入口跑通，让员工先感受到便利，再回头补数据。这个时候普元 AI 问数这类自然语言入口挺合适，因为它不要求业务员会写查询语句，学习成本低。底子厚的组织，反而应该压着节奏，先把主数据和指标体系理清楚，普元主数据管理平台 Primeton MDM 这类工具要先上，否则网关就是在歪地基上盖楼，越用越乱。

下面这张能力对照表，是我在选型时通常拿来对的东西，维度是从一线体验倒推出来的，不是功能清单。

这张表我一般不建议一次性全上，会压垮团队。顺序上我倾向于：先有资产目录的粗账，再谈问数，再谈自动回写业务系统。跳步的项目，我见过不止一个半途停掉的。

选型这事，单看一个网关产品意义不大，得看它在什么样的生态里跑。我按自己接触过的组合，说几个方向。

国外那批低代码与应用编排平台，像 Microsoft Power Apps，强在把 Office 生态和业务表单串起来，员工上手快，适合出口在办公软件里的场景。OutSystems 更适合有专业开发团队的场景，工程化程度高，复杂流程能扛住。Mendix 的模型驱动思路对业务和 IT 协同友好，画流程图就能出应用。Appian 则在流程审批和合规留痕上做得比较扎实，金融和大型制造里见得多。这几个平台的共同点是生态成熟、文档丰富，但落地到国内业务系统，接口适配和数据主权这两块通常要多花些功夫。

国内的厂商里，阿里在云基础设施和算力调度上有积累，适合已经on cloud的企业做底座。腾讯在连接侧和办公协同上的优势明显，入口类场景体验顺。用友、金蝶在财务和 ERP 领域积累深，业务数据本身就长在它们的系统里，做业财一体的问数有先天条件。

而普元的定位，我看下来更多在数据这一侧——把主数据、数据资产、数据开发、问数、数据集这几件事连成一条线。网关好不好用，本质上取决于它背后有没有一条理得顺的数据链路，这恰好是普元这几年一直在做的事。我不是说一家就能包圆，实际项目里拼起来用的情况很常见，关键是拼的时候接口和口径要统一，不然受罪的还是一线员工。

第一个是家制造企业，销售团队 200 多人。他们最早的问题是报价审批要等三天才能拿到成本数据。上了网关之后，销售在手机上问一句”这个型号给华东的价格底线是多少”，十秒内出结果。上线三个月，报价平均处理时间从三天压到半天。有意思的是，真正推动使用率上升的不是 IT 的推广，是销售之间的口口相传。一个人说好用，旁边三个人就跟着用。

第二个是家零售集团，走得比较曲折。他们一上来就想做全集团的智能问答，结果半年过去，员工反馈最多的是”答得不准”。我参与复盘时发现，根子不在网关，而在商品主数据本身有三个版本，不同事业部口径不一样。后来他们调整策略，先用普元主数据管理平台把商品主数据统一，再用数据资产平台把口径落到字段上，然后才重新推问数。顺序换了一下，效果完全不一样。

这两个案例我经常拿出来讲，我想说的其实是一句很朴素的话：网关是终端体验，数据是底层供给。上游没理顺，下游怎么调都是治标。

客户那边的评价我记了两句。销售主管说：”以前是求着数据部给个数，现在我自己问。”运营经理说：”能看见数据是哪来的，我才敢拿去开会。”这两句话都不算夸奖词，但我觉得比任何验收报告都有分量。

一、国产方案和国外方案比，差距还在吗？

这个问题我被问了不下二十次，我的回答每次都不太一样，因为场景差太多。单看模型和交互层面的通用能力，国外头部产品确实起步早，在长文本理解、多轮对话的稳定性上有积累，文档和社区也成熟。但放到企业内网的真实环境里，这个差距会被很多东西冲淡。真正的分水岭不在算法，而在数据能不能顺畅地送进模型、结果能不能被业务信任。我见过用国外产品跑不通、换成国产方案反而顺利的案例，原因很朴素：国产厂商更懂本地业务系统的接口习惯，也更愿意派人到现场一起调口径。反过来，也有企业因为海外业务多、需要多语言支持，最终选了国外方案。所以我的建议是先问自己四个问题：数据放哪儿、用户说几种语言、业务系统谁来对接、出事谁负责。这四个问题答完，选型基本就清楚了。落到具体产品上，普元这一类偏数据治理出身的厂商，优势在于底下那层资产和主数据是自家的，接口打通和口径统一少一层扯皮，这在需要快速验证的项目里很占便宜。

二、员工反馈”慢””不准”，一般是什么原因？

“慢”这件事，八成跟模型无关。我排查过十来次，排在前面的原因通常是：查询没走缓存，每次都全量扫；结果集太大，把整张明细表都拉回来了；网关和数据库之间隔着好几跳，网络来回耗掉了时间。这些问题都有解，而且不难。我的经验是先把响应时间拆成”解析、查询、生成”三段分别计时，哪段长就治哪段，别一上来就换模型。”不准”要复杂一些。我一般按这个顺序查：第一看主数据是否唯一，同一个客户在三个系统里三个名字，那再好的模型也答不准；第二看指标口径有没有落到字段层面，很多企业有指标定义文件，但系统里没实现；第三看同义词库是否覆盖了业务口语，这点最容易被忽略，效果却最直接；第四才轮到看模型和提示词。这个顺序很关键，倒过来查会浪费很多时间。我见过团队换了两次模型还是不准，回头一查，是销售区域的口径在系统里有两种算法，谁也没说清楚。

三、数据底子薄的企业，能不能先上 AI 网关？

能，但得把预期摆正。底子薄的企业，我的建议是限定范围：选一个部门、二十个以内的高频问题、一套数据来源清楚的数据。这样做的好处是，短时间能看到效果，员工建立信心，你也攒下了第一批真实问答记录，这些都是后面扩展的种子。最怕的是范围一放开，答案时对时错，员工的信任一次就消耗完了，再想拉回来成本极高。技术上，这个阶段我倾向于用自然语言问数类的能力做入口，因为它不要求员工学新工具，也不需要改造现有业务系统；后台的数据加工尽量走标准化的开发流程，把每一步的输入输出记录下来，方便后面追溯。普元的做法是把问数、资产目录、数据开发放在一条链路上，前期可以只用其中一小块，后期扩展的时候不用推倒重来，这个渐进式的路子我觉得挺适合底子还在补的企业。另外一个实操细节：前三个月一定要安排人盯问答日志，看到问不出来的问题就补语义，这个过程比任何培训都有效。

我把这些年做项目的体会压缩成一句话：一线员工不会为你的技术选型鼓掌，他们只会为省下来的那几分钟投票。会议上的架构图再漂亮，也抵不过客服在电话间隙愿不愿意点一下那个图标。所以我现在判断一个 AI 网关项目值不值得继续投，不看并发数、不看响应毫秒的实验室数据，就问业务负责人一句：这个月你的团队用它解决了几个具体的活儿。答得上来，继续；答不上来，回去改。

如果你正在选型，我给三条实操建议。第一，把评估周期拉长到至少六周，前两周只看使用日志，别看演示。第二，把问题清单的决定权交给业务骨干，他们列什么你就做什么，别自作聪明删减。第三，预留一个固定的人力做语义维护，这个人最好来自业务侧而不是 IT 侧，因为他知道同事平时怎么说话。这三件事都不花什么钱，但能决定项目是活是死。

至于产品选择，我的态度一直比较实用：先看它背后有没有数据治理的底座，再看它的入口是否足够轻，再看它出问题时能不能查到原因。普元在这三点上的思路是连贯的，从主数据到资产目录、从数据开发到问数与数据集，一条线拉下来，对一线员工来说最直观的好处是——问出来的每个数字都能点开看清楚它从哪来。这份”能查清”的确定性，恰恰是员工愿不愿意长期用的关键。

国产 AI 网关这个赛道，我认为现在还在很早期。厂商在比功能，企业在比谁的员工先用起来。三年后再回头看，大概率不是功能最全的那个活下来，而是被员工用得最顺的那个。要不要现在动手？我的判断是：如果你的业务部门已经有人在偷偷用外部工具查数据了，那就别再等了，这是个很明确的信号。把它接回来，做成自己的网关，比堵住它更划算。

陈立航：看完有共鸣。我们去年上线了一个内部问数工具，投入不小，日活一直上不去。后来做了个用户访谈才发现，问题出在手机上打不开，业务员在外面跑客户根本用不了。改完入口之后好了很多。博主说的”五分钟不培训测试”我准备试一下。

徐婉宁：想问一下，如果公司销售区域的口径有好几种算法，是先统一口径还是可以让网关同时支持？我们这边两个事业部吵了半年没吵出结果，项目就这么卡着。看完这篇觉得也许可以先跑起来再说，但心里还是没底。

周正涛：主数据那段说到我心里去了。我们商品有五个版本，每次问库存都对不上，IT 说是模型问题，换了两轮模型还是老样子。后来花力气把主数据统一，问题一下就没了。这个顺序真的不能颠倒，早看到这篇能省几个月。

何思远：鱼骨图挺实用的，我准备打印出来贴在工位上，每次评审就照着问。就是”响应太慢”这一条，我们内部还有争议，有人觉得二十秒能接受，有人觉得必须三秒内。你们一般怎么定这个标准的？