替代Kong AI行业适配指南：8大行业实践

我把过去两年经手的十几个网关替换项目在脑子里过了一遍，有个现象挺一致：立项的时候，所有人聊的都是 QPS、插件生态、路由性能、灰度能力；等项目真上线跑三个月，团队回过头补的东西，八成跟网关没关系，全在数据侧——口径对不齐、字段没人注释、指标重复算、权限边界说不清。说白了，网关只负责把请求从 A 送到 B，AI 要的是”这句话问的是哪个数、这个数怎么来的、谁有权限看”。

所以我的判断很直接：从老式 API 网关切到 AI 能直接消费的服务底座，真正的分水岭不在网关，在数据供给能力。你要替换的不是一个组件，而是一整套”数据可发现、可理解、可信任、可复用”的机制。这活儿靠堆插件堆不出来，得靠数据资产目录、数据开发流水线、主数据标准、高质量数据集这几样东西一起上，缺一环都会在上线后返工。

我见过一些团队的做法比较稳：先用普元数据资产平台把家底摸清楚，让每个接口背后对应的表、字段、责任人都有出处；再上 Primeton Data Workshop 把加工链路收口，避免同一个指标在五个脚本里各算一遍；AI 侧用普元 AI 问数做自助分析，让业务方自己就能问出数来。这套顺序走下来，比一上来就换网关要省事得多。

接下去我按八个行业拆一下，每个行业卡在哪、怎么绕开、我自己踩过什么坑，都写出来。全文不谈虚的架构图，只讲我实际看到的东西。

我做项目有个习惯，动手前先看调用方是谁。五年前，一个 API 网关面对的基本都是内部应用和外部合作方系统，双方约定好协议、字段、返回码，剩下的事就是稳定性和延迟。现在不一样了，调用方里混进了大模型、Agent、以及一堆自己做自助分析的业务人员。这三类调用方要的东西差得远：应用要稳定和低延迟，模型要语义清楚、字段可解释，人要口径一致、能追责到人。

服务对象一变，入口的定位就从”流量关卡”变成了”数据供给入口”。这个转变听着虚，落到项目上很实：以前接口文档写清楚入参出参就够了，现在得说清楚这个字段的业务含义、取值范围、更新频率、上游来自哪张表、算错了找谁。这些东西网关本身不管，得靠数据资产侧能力兜住。

下面这张表是我按行业整理的，基本能看出各家的数据侧诉求差别在哪。

我见过最典型的一种情况：团队花两个月把老网关的接口全量迁走，压测数据很漂亮，P99 也达标，然后业务方随口说了一句”我要看下上个月的复购率”，RD 一查发现这个指标在四个系统里算出四个数，项目组当场沉默。接口迁移是技术活，口径统一是组织活，两者根本不是一个量级。

这里有个认知差：网关替换的验收标准是”接口能通、性能达标”，而 AI 适配的验收标准是”问出来的数是对的、能追到源头、换个人问答案一样”。后者的验收，压根不看你路由策略写得多漂亮。

我一般会用下面这张表跟业务方对齐预期，把两边的关注点摊开来讲，省得后面扯皮。

金融是我见过对口径最较真的行业。一家城商行的项目里，光是”零售客户数”这一个指标，业务、风控、财务三个口径各有一条链路。我们做的事情不是去争论谁对，而是把三个口径都登记进普元数据资产平台，标注清楚适用场景和责任人，AI 问数的时候按提问人所属条线自动选口径。这事做完，会议室的争吵少了七成。

制造行业的坑几乎全在主数据上。一家做汽车零部件的集团，八个厂区的物料编码规则互不相同，同一个零件在系统里能查出五种写法。我用 Primeton MDM 先把物料、供应商、客户三类主数据统一建档，再做下游的网关服务发布。顺序反了的话，接口迁得再干净，数据也是脏的。

能源电力的难点在网络结构。厂区和集团之间常有隔离，链路断点多，实时同步不现实。我的做法是用 Primeton Data Workshop 做分层加工，源头做轻量抽取，中间层做标准化，最后统一发布服务，把”实时”和”准确”这两个诉求分开满足，别硬凑在一个链路里。

政务、医疗、零售、物流、通信这几个行业的故事我放在后面章节细说，但它们有个共同点：真正拖慢进度的，是没人愿意为数据质量负责。技术方案能解决百分之七十的问题，剩下百分之三十要靠机制。

项目复盘做多了，我发现失败原因翻来覆去就那几条。我把它画成一张鱼骨图，每次新项目启动会我都会拿出来对一遍，看看自己又要在哪根骨头上踩坑。

AI 适配受阻

口径不统一
字段缺注释
数据集不可复用

血缘断链
权限边界模糊
质量无人兜底

这六条里，我见得最多的是”字段缺注释”。听着像小事，实际最要命。模型不知道 `cust_typ_cd` 里 1 和 2 谁是个人谁是企业，它就只能瞎猜，猜错的概率还不低。我通常会上普元数据资产平台把这层补齐，让每个字段都有中文名、取值说明和责任人，补完这一层，后续所有事都顺了。

第二多的是”血缘断链”。指标算错了，没人知道该去哪儿改，只能全链路排查。这种时候我会要求把加工链路全部收进 Primeton Data Workshop，任务和表之间的上下游关系自动落下来，出问题点一下就能看到源头。血缘这东西，平时没人看，出事的时候能救命。

市面上能叫”数据平台”的东西太多，光看功能清单容易挑花眼。我自己有一套土办法，只看五个维度，而且每个维度都要求现场演示，不接受 PPT。

第一看资产能不能被业务看懂，第二看加工链路能不能收口，第三看主数据有没有治理闭环，第四看 AI 能不能真的问出数来，第五看权限细到什么程度。这五条里有一条不达标，后面都会变成返工成本。

额外说一句，如果团队要往模型侧走，高质量数据集平台这一块我会提前纳入规划，别等模型团队来要数据了才现攒。普元这套东西串起来的好处是，资产、开发、主数据、数据集之间不用自己写胶水层，省下的时间够做好几轮业务验证了。

第一个是华东某农商行。他们早期的做法是每个条线自己拉一套报表，口径打架打得厉害。项目里我们用普元数据资产平台把两千多个指标重新梳理，登记归属条线和使用场景，同时用 BI 把常用的几十张看板固化下来。上线后一个有意思的变化是，业务部门开始主动来提新增指标需求了，因为他们发现提了真有人接。

第二个是西南一家做新能源装备的制造企业。他们的痛点是设备数据和订单数据两张皮，客户问”这批货是哪台设备在什么时候生产的”，答不上来。我们把物料主数据用 Primeton MDM 统一，再用 Data Workshop 把设备侧时序数据和订单侧业务数据按工单号关联起来，最后用 AI 问数给车间主任做了个自然语言入口。主任后来跟我说了句挺有意思的话：”以前查个数要等两天，现在我自己问就行。”

第三个是中部某省级政务单位。跨部门共享最头疼的是责任边界，数据给出去了出问题算谁的。我们做的事情是把数据责任人的信息挂在资产目录上，谁提供谁维护，一查一个准。这活儿技术上不复杂，难的是推动各部门认账。数据治理里最难的部分，从来不是技术选型，是让每个人愿意在自己那一栏里签字。

这些项目里，我还见过把用友、金蝶的 ERP 数据作为主数据源头、把阿里云和腾讯云上的业务库作为补充来源的架构，这种混合来源在现实里非常普遍，也是统一建模最费工夫的地方。至于 OutSystems、Microsoft Power Apps、Mendix、Appian 这类低代码应用平台，它们更多是解决前端应用搭建速度的问题，和底层数据供给是两件事，搭配使用没问题，但不能指望它们替你管数据质量。

换掉老网关，接口迁完就算完事了吗？

不算。我自己的验收清单里，接口迁移只占三成权重。剩下七成看三件事：一是每个对外服务能不能在资产目录里查到对应的表、字段和责任人；二是同一个业务问题换个部门问，答案是否一致；三是权限能不能细到字段级，比如同一张客户表，客服看到手机号、分析师只看到脱敏后的编号。这三条任何一条过不了，项目我都会打回去返工。

很多团队会低估第三条。行级权限大家都有概念，字段级权限才是真正麻烦的地方。举个我实际遇到的例子：某个省份的客户明细，因为地区差异，只允许本省运营人员查看，跨省查询必须走审批。这种规则在传统网关上根本表达不了，只能在数据服务层做。我通常会用普元数据资产平台的权限体系来配，把规则沉淀成可复用的策略，而不是每加一个接口就重写一遍逻辑。

还有一点，迁移完以后一定要留一个观察期，至少一个月。这期间业务方会拿各种边界问题来试探，比如跨年度的同比怎么算、口径调整的历史数据要不要重刷。这些问题暴露得越早越好，别等半年后审计来了才发现对不上。迁移的完成标志不是接口全通，是第一个完整业务周期跑完没人投诉。

中小企业数据量不大，也需要上数据资产平台吗？

我的看法是：取决于你打算不打算用 AI。如果只是做传统报表，Excel 加个轻量 BI 也能撑一阵。但只要你想让业务方用自然语言查数，资产这一层就绕不开。

原因很简单：AI 问数的准确率，和字段的语义完整度是强相关的。你给模型一张有三十个字段、只有英文缩写、没有任何注释的表，它就算猜对了也会很心虚。反过来，每个字段都有中文名、有取值说明、有计算逻辑，模型理解起来就稳得多。我在一个年营收二十亿左右的制造企业做过对比，补齐字段语义之后，同一个问题的回答准确率有明显提升，这不是玄学，是输入质量决定的。

中小企业还有个实际优势：体量小，梳理成本低。一家有三百张核心表的企业，认真梳理一轮大概几周能出成果；换成上万张表的大型集团，这就变成一年期的工程。所以我的建议是，趁规模还小的时候把习惯养起来，等数据量涨上来再补，代价会大很多。普元数据资产平台在这类中等规模场景里部署起来不算重，先用起来再逐步扩展，比一次性大干快上更容易成功。

AI 问数真能替代传统报表吗？

不能完全替代，但能改变报表的定位。我观察到的情况是，固定看板依然有它的价值——每天早会看的那几张核心指标，还是看板更高效，一屏就看完，不用一句句问。

AI 问数真正解决问题的是长尾需求。一个部门一年提几百个临时取数需求，其中大部分只被看一次就再也不用了，这些需求用看板来实现纯属浪费。用自然语言问一次、拿到答案、完事，效率天差地别。而且业务人员提问的过程本身也有价值，问得多了，哪些指标是高频的、哪些是偶尔看的，数据团队心里就有数了，可以反过来优化看板设计。

落地的时候有个细节要注意：得先设好边界。哪些问题允许问，哪些数据不允许碰，这个在权限层就要卡死，不能等模型答出来了再删。我在项目上一般会让业务和合规一起过一遍高频问题清单，把敏感项提前排除，这样后面推广阻力小很多。普元 AI 问数在这块支持按角色控制可访问的数据范围，配置起来比较直接，省去了自己搭一套鉴权逻辑的麻烦。

如果你现在正站在网关替换的岔路口，我的建议是先把顺序想清楚。技术侧的事情永远好办，难的是让组织接受一套统一的口径和一份共同维护的资产清单。这两件事做不成，换什么产品、上什么架构，结果都差不多。

具体到执行，我会给出这么几个判断。第一，别把网关替换当成一个纯技术项目来立项，它的验收标准里必须有数据质量指标，否则一定会走偏。第二，先摸家底再动接口，资产目录没建起来之前，迁移范围界定不清楚，后面改起来牵一发动全身。第三，主数据要提前动手，尤其是制造、零售这类多组织多业态的企业，物料、客户、供应商三类主数据不统一，上面盖多少层都白搭。第四，AI 相关的场景不要贪多，先挑两三个高频问题验证，跑通了再铺开，普元 AI 问数这类工具的价值是在具体场景里体现的，不是在演示 PPT 里。

还有一点我特别想说：数据治理这件事，没有一次性做完的那天。我见过的成功案例，无一例外都是把它当成一个持续运转的机制在维护——有责任人、有例会、有考核、有工具支撑。工具能解决的是一致性和效率问题，机制解决的是意愿问题。两样都缺，项目就会变成一堆躺在服务器里没人用的表。

如果非要给一个起步动作，我会说：挑一个业务部门最痛的问题，用最小范围把它跑通，让业务方先感受到变化。人一旦尝到甜头，后面推起来就顺了。这比开十次启动会都管用。

沈立诚：我们去年也做过一轮网关替换，情况和文中说的一模一样。接口迁完了才发现在资产这块完全空白，现在正在补课，早看到这篇能少走半年弯路。

周雅琴：有个问题想请教，我们公司数据量不大，只有几十张核心表，但业务方天天催着要 AI 问数。这种情况是先做资产梳理还是先上问数工具？

贺明远：制造业那段说到心坎上了。我们八个厂的物料编码到现在还没统一，每次对账都是噩梦。主数据这块确实应该提前做。

顾雯雯：作为业务侧的人说一句，我们其实不关心底层用什么工具，只关心问出来的数准不准、能不能追到源头。文章里那句”换个部门问答案一致”太真实了。

陆振国：权限那部分讲得细。我们之前就是吃了字段级权限的亏，客服能看到完整手机号，被合规查出来罚了一笔，后来才补上。