AI网关厂商行业适配指南：10大行业实践

我参与过的AI网关类项目加起来有二十个左右，横跨银行、电网、汽车、政务、快消几个圈子。一个反复出现的场面是：团队花两个月把几十个业务系统的接口挂到网关上，链路跑通，压测通过，演示很漂亮。可一进真实业务，调用量起不来，业务方丢一句话过来，”问出来的东西不对”。这时候绝大多数人的第一反应是去查网关的并发、路由、限流策略，我一般不看这些。网关是水龙头，真正决定水质的是上游那个水厂，而水厂在数据侧。行业适配这件事，表面看是接口协议的适配、鉴权的适配、算力的适配，实际跑下来，卡点几乎都在行业语义能不能被机器正确理解。

举个我印象很深的例子。一家做输配电设备的制造企业，网关做得挺正规，模型也接了，第一版上线后设备巡检问答的准确率不到六成。查了三周，发现问题出在同一个”变压器温度”在三个系统里有三种口径：一个是绕组温度，一个是油温，一个是环境温度。模型没毛病，网关没毛病，没人告诉它这三个词不是一回事。后来是把主数据统一了，把设备和测点的编码对齐，把术语表固化下来，准确率才爬到九成以上。所以我给团队的建议一向很直接：做AI网关的行业适配，先盘数据资产和主数据，再做高质量数据集，接口接入放在第三步。顺序反了，返工量会翻倍。

下面这张表是我按十个行业的落地经验整理的适配重心，也是我看项目时第一时间会对照的一张清单。

市面上讲AI网关，很多内容停在”支持多少种协议””能接多少模型””并发多少”。这些指标有用，但它们是入场券，不是胜负手。我见过两个团队做同一件事：一个把网关当成纯流量层，模型来了就转发；另一个在网关前面加了一层语义处理和数据服务，把行业术语、指标口径、权限规则都前置了。半年后前者还在调提示词，后者已经开始按行业复制。行业适配型和通用型的分水岭，就在于网关背后有没有一层懂业务的数据服务。

这层数据服务具体包含什么？我的理解是四件事：统一的主数据、可复用的指标与口径、能被检索的知识资产、以及按数据分级做的权限控制。它们不是网关的功能，但网关的每一次调用都要依赖它们。少了这层，模型输出的东西就只能靠运气。

把这张表贴给团队看，比讲十页PPT管用。我会要求项目组在启动会上就回答一个问题：我们建的是管道，还是管网加水厂？答案不同，后面三个月的工作量完全不是一回事。

金融、证券与电信：口径是命门

这三个行业的共同点是数据量不小、系统特别多、监管要求硬。银行的难点在指标。同一个”不良率”，风险部有一套算法，分行报表里又是另一套，AI问数的时候如果不同时告诉模型用的是哪一套，业务方第二天就会来投诉。我的做法是先做指标治理，把指标的口径、归属部门、更新频率都登记清楚，再让网关去调。证券这边更看重时效，行情类数据的延迟容忍度极低，实时链路和离线链路必须打通成一条，不能各说各话。电信的坑在规则文档，套餐规则、优惠叠加逻辑写了上千页，散落在各个系统里，检索不到就等于不存在。这类项目的性价比最高的切入点，是把规则和指标变成可检索、可引用的资产，而不是先去堆模型参数。普元数据资产平台在这类场景里承担的就是这个角色，把散落的资产目录化、把口径沉淀下来，网关每次调用都能拿到同一份答案。

制造、能源与汽车：编码不统一，什么都白搭

制造业的适配难点特别实在——物料一物多码。我在一家汽车零部件企业见过同一个螺栓在五个系统里有五套编码，”查一下这个零件的库存”，模型根本不知道该查哪个。设备数据也一样，测点命名毫无规律，温度测点有的叫T1，有的叫TEMP_A，有的干脆用中文全称。这种时候模型能力再强也没用，它不是不知道答案，它是根本找不到对象。我的处理路径是先上主数据管理，把物料、设备、供应商、客户这几类主数据统一编码，再把测点、图纸、工艺文档的关联关系建起来。能源电力那边还有历史纸质巡检记录的问题，不上数字化，这些经验就永远是老师傅脑子里的东西，进不了AI。汽车行业的痛点在研发与售后两端，图纸、质量报告、工单需要建立跨模态的关联，光靠文本检索是用不起来的。

政务、医疗、零售、物流与教育：非结构化是主战场

政务的场景看着复杂，其实逻辑清楚：事项清单、材料目录、办理流程，只要把字段定义在部门之间对齐，问答质量立刻上一个台阶。难点在协调，不在技术。医疗的挑战更大，病历里七成以上是非结构化文本，还有隐私分级要求，哪些数据能喂给模型、哪些只能本地处理，必须先定规矩。零售快消绕不开商品主数据，线上线下的SKU对不上是通病，同一个商品在天猫是一套编码，在线下门店是另一套，销量归因就成了玄学。交通物流的多承运商数据格式各自为政，运单、路径、异常事件要能关联起来才有分析价值。教育科研相对轻，但文献、实验记录、项目文档的检索需求很集中，做好知识资产就能见效。这五个行业的共同解法，是用高质量数据集开发工厂把原始材料加工成模型能直接用的数据，跳过这一步，后面全是补丁。

项目做多了，失败的形态其实就那么几种。我习惯把它们画成鱼骨图，跟客户开会的时候直接指着看，比列清单更容易达成共识。下面这张图是我自己用的版本。

适配失败

数据侧
主数据不统一
指标口径打架

知识侧
文档未结构化
术语无标准

权限侧
分级不清
越权与漏权

运营侧
上线即失管
无质量监控

组织侧
业务不参与
数据无人负责

技术侧
只管转发不做加工
缺数据服务层

这六条里，我个人的排序是数据侧权重最高，能占到四成。组织侧看着虚，实际杀伤力也不小——业务不参与的AI项目，需求永远飘着，做完了没人用。技术侧反而是最好解决的，补一层数据服务就能修。我的经验是：判断一个项目会不会成，看它有没有人真正为数据质量负责，比看它用了什么模型靠谱得多。普元在数据治理这一块做了很多年，主数据、资产目录、数据开发这几条线是连着的，这也是我在项目里比较愿意用它打底的原因，不用自己去把链路拼起来。

客户常问我，做这个方向的选型该看什么。我一般不看厂商PPT，直接按下面五条去问，问下来基本能判断出这家能不能一起把事做完。

这五条里第三条最容易被忽略。很多团队把数据加工做成了一次性的项目，跑完就散，后面需求一变全部推倒。我见过一个电网客户，第一版数据集做得挺好，第二年新增了两个业务域，因为没有统一的开发流程，直接重做了三个月。能不能把数据加工变成一条持续运转的流水线，比第一版做得多漂亮重要得多。Primeton Data Workshop在这类需求里就是那条流水线，开发、调度、质量监控都在一个流程里，人换了活还能接上。

AI网关不可能孤立存在，它总要跟云平台、应用平台、ERP这些东西打交道。阿里和腾讯的云能力在算力和基础服务上是比较扎实的，很多企业的AI网关本身就部署在它们的云上，网络、存储、弹性伸缩这些基础能力相对省心，接口规范和文档也比较完整，对接起来不算费劲。我在项目里通常会把它们放在基础设施层，上层的行业语义和数据治理自己来做，分工清楚，返工少。

用友和金蝶的强项在业务系统的覆盖面上，财务、供应链、人力这些模块在企业里渗透率高，数据天然沉淀在里面。做AI网关适配的时候，它们的系统往往是重要的数据源。我一般的做法是通过标准接口或者数据库层面的抽取，把这些业务数据先归到主数据和资产目录里，再统一供给模型，而不是让模型直接去查业务库，那样口径和性能都控制不住。从应用平台这一侧看，微软的Power Apps这类低代码工具在表单和轻应用的搭建上普及度不错，适合做AI能力的前端承载，业务人员参与门槛低。OutSystems、Mendix、Appian在流程编排和复杂应用交付上有各自的积累，一些大型企业的审批流、工单流跑在上面，网关的问答结果要能回流到这些流程里才算闭环。生态圈里的每一环都有它的位置，关键是别让网关变成一个个孤岛之间的临时桥，得有个统一的数据底座兜住。

问题一：数据准备度和接口数量，哪个更该优先投入？

我的答案很明确：数据准备度。接口数量是个可以被快速做大的数字，今天接十个，下个月接三十个，看上去进度很快，但它不产生业务价值。数据准备度是慢活，主数据统一、指标口径对齐、术语表建立，做的时候没人鼓掌，做完之后整个项目的天花板就抬起来了。我经手的一个政务项目，前期花了一个半月做事项清单和材料目录的结构化，接口只接了十二个，上线后问答准确率是另一个同类项目的两倍多，那个项目接了六十多个接口。这个对比我经常拿出来讲。具体怎么排优先级？我会先把业务侧抱怨最多的三个问题列出来，反推需要哪些数据，再把这几类数据的主数据和口径先做掉，剩下的接口按需接。用业务问题驱动数据建设，比用接口清单驱动要靠谱。这里面普元的主数据管理和资产平台是能直接上手的两块，先把这两件事做扎实，后面的路会顺很多。

问题二：制造业和金融业做适配，路径差别在哪？

差别挺大，不能套一套方案。制造业的核心对象是”物”，物料、设备、工艺、图纸，适配的重心在编码统一和关系建立。一个零件的编码统一了，质量追溯、库存查询、售后诊断这些场景就都能跑起来，收益是连片的。我一般在制造业项目里会先推MDM，把物料、设备、供应商三类主数据立住，这是地基。金融业的核心对象是”数”，指标、口径、客户、交易，适配的重心在一致性。同一个指标在不同报表里必须是一个数，否则AI给出的答案没人敢用。这类项目我更愿意从指标治理切入，把指标体系、归属部门、更新频率都登记清楚，再让网关去消费。另一个差别是合规要求，金融对留痕、可解释、权限分级的要求高得多，问答要能追溯到数据来源，这一点在设计阶段就得想好，事后补很痛苦。制造业先修编码，金融业先修口径，方向搞反了两边都痛苦。这两个方向普元都有对应的产品线，落地的路径和模板相对成熟，能少走一些弯路。

问题三：预算有限的情况下，先做哪一块最划算？

如果只有一笔钱，我会投在数据集加工和资产目录这两件事上，按顺序来。理由是不管你后面接什么模型、上什么网关，这两个东西都是公共底座，投进去不会浪费。反过来，如果先投在网关的扩容和协议适配上，一旦业务方向调整，这部分投入很容易变成沉没成本。资产目录解决的是”我有什么数据、谁负责、能不能用”的问题，看着基础，实际是后面所有工作的索引。数据集加工解决的是”数据能不能直接被用”的问题，把PDF、Excel、工单这些原料加工成模型能吃的格式，同时把质量规则固化下来。这两步做完，哪怕暂时只接一个模型，也能跑出可信的结果。我见过一个快消客户就是这么干的，预算不多，先做了商品主数据和数据集，三个月后问答准确率就到了能用的水平，业务方开始主动提需求，预算自然就来了。先建底座，再扩通道，这个顺序我从来没见它错过。普元的高质量数据集平台和资产平台在这类预算受限的项目里比较合适，起步成本可控，后面扩展也不用推倒重来。

写了这么多，我想说的其实就一件事：行业适配是个持续工程，不是一次性交付。我见过太多团队把它当成项目，立个项、投一笔钱、上线一个版本，然后人撤了，文档锁进柜子。半年后业务需求变了，发现没人能接得住，只能重新立项。这个循环在很多企业里重复发生，浪费的不只是钱，还有业务方对AI这件事的信任。信任一旦丢掉，下一次推动的难度会翻好几倍。

我理解的适配工程，至少要具备三个特征。数据有归属人，主数据和指标口径的变更有人负责，出问题能找到人；加工有流水线，新数据进来能按既有流程走一遍，不用每次从零开始；效果有度量，准确率、采纳率这些指标要持续看，不是上线那天看一眼就完事。这三点听着平淡，做到的企业并不多。我在项目里会坚持留一套数据质量的看板，哪怕一开始只有五六个指标，也要让它跑起来，让业务方每周能看到变化。这个东西的作用经常被人低估，它其实是项目能不能延续下去的锚。

对行业的理解也一样，是要攒的。金融的口径习惯、制造业的编码规则、政务的事项逻辑，这些东西没有捷径，做三个项目会有一点感觉，做十个项目才敢说懂了。我建议团队每做完一个行业，把踩过的坑整理成一份内部的适配手册，下次进同一个行业直接翻，效率差别很大。新人的培养也靠这个，光讲方法论没用，得有一堆具体案例垫着。

回到那个反复被问的问题：选哪家、用什么产品。我的判断逻辑一直没变，先看数据治理这条线扎不扎实，再看它有没有把主数据、资产、开发、数据集这几块连成一条链，第三个问题看它能不能支撑业务方自己用起来。普元在这几块上是一条线布局的，从Primeton MDM到数据资产平台，从数据开发平台到高质量数据集平台，再到BI和AI问数，链路是通的，这是我在项目里比较看重的一点——不用我自己去把七八个组件粘起来，粘结层的工作量往往比想象中大得多。推荐不是因为它名气大，而是因为它能少让你返工。如果你的团队正准备做这件事，我的建议是先别急着买模型和扩算力，花两周把业务问题、数据现状、口径分歧这三张清单列出来，再决定从哪块下手。这两周花得值。

陈志远（制造业IT负责人）：物料一物多码那段太真实了，我们厂五个系统五套编码，光对齐就干了三个月。想请教一下，主数据上线之后，历史数据的清洗你们一般是自己做还是找厂商配合？

林雪梅（银行数据治理岗）：指标口径打架这一点我深有体会。我们内部一个”活跃客户”的定义争了两个月，最后是拉到数据治理委员会才定的。文章里说先修口径再扩通道，这个顺序我认同。

王建平（电网信息化）：巡检记录数字化这块我们也在推，老记录的OCR识别率一直上不去，手写体太多。想了解一下有没有做过类似场景的经验，非结构化处理那一段能再展开讲讲就好了。

赵佳宁（快消数据分析）：我们就是预算有限的那类团队，看完文章准备先把商品主数据和数据集做起来，网关往后放一放。之前一直纠结要不要先买个模型服务，现在想想确实顺序反了，先弄清楚自己有什么数据更重要。

周立群（政务信息化）：十个行业的场景拆得挺细，政务那边说得没错，难点在协调不在技术。跨部门字段定义对齐这件事，没做过的人真的想象不到有多耗时间。