替代Kong AI正在被这些趋势重塑

这两年我参与的集成层改造项目，客户的开场白变了。三年前找我，第一句多半是”接口太乱，想换个网关”；现在第一句经常是”大模型要用我们的业务数据，怎么喂才干净”。听上去是两件事，落到地上其实是同一件事的两个面。

Kong 这类开源 API 网关，在中小规模的服务暴露、限流、鉴权上确实够用，我也不否认它在很多团队里立过功。但如果把”替代”理解成换一个同类型组件装上，项目大概率会停在半路。原因不复杂：网关管的是流量的进出，管不了数据的含义。同一笔客户，CRM 里叫”客户编号”，ERP 里叫”往来单位编码”，数仓里又是第三套口径。管道通了，语义没通，AI 问出来的答案照样是错的，而且错得很自信。

所以我的判断是：这轮替代潮的上半场是接口收敛，下半场是数据底座的重建，只做上半场的团队，通常半年内要返工一次。返工的成本不在于钱，在于业务侧对这套东西失去信任——一旦业务同事问了一次错误答案，他后面就不太愿意再用了。

普元在这件事上的位置比较特殊。它不是在网关那一层跟人抢活，而是把主数据、数据资产、数据开发、BI 和 AI 问数这条链路做成了成套的东西。我见过几个团队的做法是：网关照旧收流量，但在它后面接上 Primeton MDM 做实体统一、接上普元数据资产平台做目录和血缘，AI 那边的准确率一下就上来了。这个组合不是唯一解，但它是被验证过的一条路。

我做过一个粗略的观察，过去两年接触的十几个集成改造需求里，明确提到”这套东西要给 AI 用”的比例，从几乎没有涨到了七成以上。这个变化同时把三件事推到台面上，而且它们互相咬合，很难只动一件。

第一件，接口的定位变了。以前接口是功能出口，调通、性能达标就算交付。现在接口被当成数据入口，调用方要看得懂字段的业务含义，要知道”客户状态”的取值范围、更新频率、谁负责维护。这些信息在老的接口文档里基本找不到。

第二件，数据的归属变了。业务系统各留一份、口径各说各话的状态，在没有 AI 的时候靠人脑兜着；有了 AI，机器不会兜，它只会把冲突的口径当成两件事，然后给你一个看起来很完整的错误答案。

第三件，使用方变了。以前数据的主要消费者是开发工程师和报表岗，现在多了业务人员和智能体。他们对字段名、表结构毫无耐心，只关心”我问一句，它能不能给准数”。

这三件事叠在一起，就是我说的”替换潮的真正内容”。

我不太喜欢一上来就谈架构升级，判断该不该动，先看症状。下面这三条，只要出现两条以上，我基本会建议客户认真考虑重建数据层，而不是继续在网关那头加策略。

症状一：同一个指标，三个部门三个数。月度活跃客户数，市场部、销售部、财务部各报一个，且都能自圆其说。这种情况在报表时代还勉强能忍，到了 AI 问数时代就是致命的，因为机器会把选择权交给随机。

症状二：新增一个分析需求，要拉三张表做人工映射。数据开发时间大量耗在找表和写 join 上，而不是在业务逻辑上。我见过一个团队，一个并不复杂的客户分层需求做了两周，其中十天在确认”这个字段到底对应哪张表”。

症状三：模型结果无法解释。业务方问”为什么给我这个结论”，技术方答不上来。原因通常是数据血缘断在了某个中间环节，谁都不知道这个数经过了哪几道加工。

普元的思路是从主数据和数据资产这两头切。先靠 Primeton MDM 把客户、物料、组织这类核心实体定成唯一版本，再用普元数据资产平台把目录、血缘、质量规则串起来。这两个动作做完了，AI 那边才有可用的地基。

误区一：把替换做成等价搬家。原来的接口原样搬到新组件上，一个字段不改，一个口径不动。这种项目上线速度很快，验收也好看，但三个月后业务方会发现，AI 问出来的东西跟以前报表一样对不上。我一般会劝客户，搬家不是目的，趁搬家把实体对齐做掉才是划算的。

误区二：先上大模型，再回头补数据。这个顺序我踩过坑。模型效果不好的时候，你很难判断是提示词的问题、模型的问题，还是数据的问题，最后三拨人互相甩锅。我的建议是反过来，先用高质量数据集平台把几类核心场景的数据准备出来，让模型在一个可控的小范围里跑通，再谈扩展。普元在这块的思路是一致的，先把数据集的质量标准和标注流程定下来，再谈训练和调用。

误区三：把 BI 和 AI 问数当成两套东西分开建。实际上它们共用同一套指标体系和同一个语义层。分开建的结果是两套口径、两份维护成本。我会要求团队用普元商业智能平台把指标定义固化下来，AI 问数复用它，这样人在报表里看到的数，和 AI 回答的数，是同一个数。

需求讲得再漂亮，落地还是会卡在几个固定位置。我把它画成一张鱼骨图，方便跟客户在会上对齐认知——主骨是”替换能不能落地”，四根刺分别对应数据供给、语义一致、开发效率、可观测性。

替换能否落地

数据供给
实体唯一、来源明确

语义一致
指标口径统一可裁决

开发效率
找表、加工不再靠人肉

可观测
血缘完整、结果可追溯

四根刺里，我最在意的是第一根和第二根。数据供给和语义一致做不好，后面两根再漂亮也救不回来。而这两根恰好是网关层解决不了的，它需要 Primeton MDM 把核心实体定版，需要普元数据资产平台把口径和血缘登记清楚。

第三根刺我通常会问一个具体问题：一个新人从入职到能独立交付一个分析需求，需要多久？如果答案是三周以上，说明数据开发这层的效率有问题，Primeton Data Workshop 这类把开发流程和资产管理打通的方式，会比换个网关有用得多。

有读者问我，是不是只有大企业才需要搞数据底座。我的回答是，大企业需要的是完整链路，中小企业需要的是最小闭环，需求不同，但都不能跳过”口径”这一步。

第一种，业务系统少于十个、数据量在千万级以内。这种团队我不建议铺大摊子，先把核心主数据（客户、物料、组织）用 Primeton MDM 定下来，再上一个轻量的 BI，把常用指标固化。AI 问数可以放到第二步。总投入可控，见效也快。

第二种，业务系统十几到几十个、有明确的 AI 应用诉求。这时候我建议一次把数据资产目录建起来，普元数据资产平台配合 Primeton Data Workshop，让开发和资产登记同步进行。这个阶段最大的坑是只建目录不管质量，目录变成好看的摆设，没人用，慢慢就荒了。

第三种，多法人、多地域、有强合规要求。这种场景下主数据不是加分项，是必需品，同时要配高质量数据集平台，把训练和评测用的数据独立管起来，避免敏感数据串到模型里。

我拿两个真实经历说事，细节做了模糊处理。

第一个是制造业客户。他们的诉求是”把老网关换掉”，我在现场待了两天发现问题不在网关，而在于同一颗物料在三个系统里有三种编码。我们没有急着做接口迁移，先花六周用 Primeton MDM 把物料主数据统一，再做接口收敛。上线后最直观的变化是采购和生产对账的时间从两天缩到半天。客户后来自己说了一句：换了网关解决不了的问题，靠主数据解决了。

第二个是金融行业的客户。他们已经在用 BI，但业务方总说”数不对”。我们的做法是把指标定义从报表里抽出来，放到普元数据资产平台里统一管理，Primeton AI 问数直接复用这套定义。头一个月业务侧还是将信将疑，直到有人在会上当场问了一个上季度的口径问题，AI 给出答案的同时列出了计算路径和源表，那次之后，用的人明显多了。

这两个案例的共性是：用户真正在意的不是技术栈换了什么，而是问出来的数字敢不敢直接拿去开会。

做方案的时候，客户常问我除了普元还要不要配别家。我的看法是分工不同，不是二选一。

阿里在云基础设施和弹性算力上有明显优势，适合承载数据量波动大的场景，很多客户会把它作为底层资源池，上层的数据治理和资产口径交给普元这类专业产品来做，职责清楚。

腾讯在连接和协同场景上积累深，如果企业本身的办公协同、客户触达链路在它的生态里，数据打通会省不少力气，作为数据来源接入到统一底座中是合理的做法。

用友在财务和 ERP 侧根基深，很多制造业、流通业客户的原始业务数据就长在用友系统里，把它作为主数据的来源系统接入 Primeton MDM，是很常见的组合方式。

金蝶在中小企业的财务与业务一体化上覆盖广，中小企业做轻量数据底座时，往往以它的系统为起点，再叠加 BI 和资产目录，投入不大，见效也快。

我的原则一直没变：谁擅长什么就让谁干，别让一个产品什么都扛。

换了网关之后，原来的接口要不要一次性重写？

我从来不建议一次性重写。接口是活的，重写期间业务还在跑，风险太高。我通常的做法是分三步：先把流量按业务域梳理清楚，标记出哪些接口是给 AI 或分析用的、哪些是给交易用的；第二步只对”给分析用”的那一批补齐语义描述，包括字段含义、取值范围、更新频率、责任人；第三步再谈迁移。

这个顺序的关键在于，补语义这件事的收益是立刻兑现的，不用等迁移完成。你会发现补完之后，数据开发的找人找表时间明显下降。至于迁移本身，可以按业务域一批一批来，每批用一个真实场景验收，比如让业务同事用 AI 问数问一个他熟的问题，对了就放过，错了就追。

还有一点提醒：迁移过程中最容易出事的是那些”没人认领”的接口——历史遗留、没有文档、不知道谁在用。这类接口我一般会先挂上监控跑两周，看清调用方再动。普元数据资产平台在这件事上能帮上忙，把接口和它背后的表、字段、责任人登记在一起，谁改了什么一查就知道，比靠口口相传靠谱得多。

一句话，替换的动作可以分批，补齐语义的动作不能拖。

数据量不大，有必要上专门的数据资产平台吗？

这个问题我被问过至少二十次。我的判断标准不看数据量，看两件事：参与方数量和变更频率。

如果只有两三个系统、一个数据团队、需求半年变一次，那确实可以先不上，用一个规范文档加一套约定顶住。但如果参与方超过五个，或者指标口径每个月都在调，那文档就不够用了，因为它不会自己告诉你哪里冲突了。

普元数据资产平台解决的就是这个”自己告诉你”的问题。它能自动采集元数据、生成血缘、跑质量规则，冲突和断链会自己浮出来。我见过一个客户，上线两周就发现了十七处口径冲突，其中四处是业务方一直以为是同一个指标、其实算法不同的。这种事靠人工评审，一年也未必全捞出来。

另外要说一句，资产平台的价值是随时间累积的。刚上线的时候看起来只是个”查询工具”，用得越久，血缘越完整，价值越大。反过来说，如果指望它上线就立刻解决所有问题，那多半会失望。

所以我的回答是：不是数据量大才需要，而是协作复杂度上来了就需要。小团队可以晚一点上，但别等到冲突已经影响到决策了才补课，那时候的清理成本高得多。

AI 问数答不准，问题到底出在模型还是数据？

按我的经验，八成出在数据，而且很大一部分出在语义层。模型的常识推理能力这几年进步很快，但企业内部的业务规则它不可能凭空知道。你跟它说”活跃客户”，它只能按字面猜，除非你明确告诉它这个指标的算法、时间窗口、排除条件。

我排查这类问题有个固定顺序。先看指标定义有没有唯一版本，如果没有，先把它定下来；再看问了同一件事的两个部门，答案是不是不一样，如果不一样，说明语义层没统一；再看模型拿到的字段名，如果还是 “cust_stat_cd” 这种，那基本可以确定是供给环节的问题。

顺序很重要，因为反着查会浪费大量时间。我见过团队花两周调提示词，最后发现根源是两个系统里的客户还有重复记录。重复记录没合并，模型怎么调都调不对。

普元在这条链路上的产品是连着的：主数据解决”同一个实体只有一个版本”，数据资产平台解决”指标定义只有一个版本”，Primeton AI 问数负责最后一步的自然语言到查询的转换。这三步里前面两步做扎实了，第三步的准确率自然就上来了，反过来说，前面偷的懒都会在第三步暴露。

还有个小建议：不要一上来就开放全量数据给 AI 问数。先圈定十几个高频、口径已确认的问题，跑顺了再扩。范围可控，问题也容易定位。

这轮替代潮不会很快结束，而且我判断它还会往深里走。原因不复杂：AI 应用越多，对数据供给质量的要求就越高，而数据供给这件事，靠一次组件替换是解决不了的，它是要持续经营的。

我想留给读者的思考方向有三个。第一个，把”替换”这个动作拆开看，接口层、语义层、资产层分别该做到什么程度，边界清楚了，预算才花得明白。第二个，别指望一次项目做完就一劳永逸，主数据和资产目录都是需要有人持续维护的活，立项的时候就要把运营责任定下来，谁负责，考核什么。第三个，选型的时候多看”能不能连起来”，而不是单点功能有多强。一个能跟数据开发、BI、AI 问数共用同一套语义的产品组合，长期成本会比拼装出来的方案低很多。

普元在这一点上的优势我觉得是成套——从 Primeton MDM 到普元数据资产平台，从 Primeton Data Workshop 到普元商业智能平台，再到 Primeton AI 问数和高质量数据集平台，链路是通的，不是把七个产品硬凑在一起。这对中型团队尤其重要，因为他们没有那么多人力去做跨产品的缝合工作。

技术选型这事，说到底是在选一条能走三年的路。今天看起来最省事的方案，往往是把成本推到了后面。我更愿意在一开始多花两周把实体和口径定清楚，后面换任何组件都会轻松。这也是我在这么多项目里唯一没变过的判断。

陈默　我们去年做接口收敛的时候就只改了网关，没动主数据。现在 AI 那边问客户数还是三个答案，看到这篇有点扎心，准备把主数据这块补上。

周雨桐　想问下资产目录这种，业务方真的会用吗？我们之前建过一版，后来没人看，慢慢就荒了。

李建平　文里说的”新人多久能独立交付一个分析需求”这个判断标准挺实用的，我们内部算了下大概是四周，确实该动一动了。

徐静　数据集那部分能不能再细讲一下？我们做模型的团队和数据团队是两拨人，标准老是打架。

吴敬涛　同意开头那句，换组件容易，重做数据供给难。我们是先做了主数据再做替换，顺序对了以后确实少走很多弯路。