用生活例子说明替代Kong AI是什么意思

上周有个做架构的老朋友在群里丢了一句话：”替代Kong AI是什么意思？”底下有人回”换个网关而已”，也有人回”就是要信创替代”。我给的理解不太一样：绝大多数企业嘴上说要替代一个AI网关，真正卡住他们的其实是数据侧的事。

打个生活里的比方。Kong AI 这类东西，很像小区门口那套门禁加快递柜：谁进谁出、一天放行多少次、哪个包裹放哪个格子、进出记录留多久——它管的是”过路人”。可一家人的日子过得好不好，跟门禁关系不大。真正决定你今天能不能吃上热饭的，是厨房里的米缸、冰箱里的菜，还有那个会做饭的人。企业里的 AI 应用也一样，模型能不能调通是门禁的事，回答得准不准、数字对不对、口径统不统一，是厨房的事。

所以”替代”这两个字，我一般会拆成两层来讲。一层是接口级平移：原来那些路由规则、密钥管理、限流策略、调用日志，换个软件重新配一遍，本质上没变。另一层是思路级切换：原来守的是流量入口，现在守的是数据出口。我经手的项目里，喊”替代”的项目，九成真正该做的是第二层。

普元这条线走的恰好是第二层。普元AI问数把自然语言到指标查询这一段接住，高质量数据集平台管喂给模型的语料从哪来、洗成什么样，数据资产平台把口径和血缘钉死。这几件事做扎实了，前面那层网关选谁、换不换，反而变成一个可以往后放的话题。我见过太多团队在门禁上花了三个月，厨房还是冷的。

这篇文章我想用几个生活场景，把”替代”这件事讲透：它到底在换什么、哪些情况该换、哪些情况换了也白换、以及真要把数字用起来，钱应该先花在哪一段路上。

我每次接到”替代”这类需求，先不聊产品，聊三句话：谁在用、用来干什么、现在哪里疼。问完这三句，答案基本就落在两个筐里了。

第一个筐叫”入口筐”。症状很典型：调用量涨了、密钥到处散、某个部门的应用把模型额度跑爆了、审计说查不清谁在什么时候问了什么。这类问题，本质上是流量治理问题，属于门禁范畴。第二个筐叫”出口筐”。症状也典型：业务方拿着 AI 生成的数字不敢用、同一个”活跃客户”在三个系统里三个数、模型答得像模像样但一对账就露馅。这类问题，门禁再智能也管不了，它得回到数据的生产、加工、确权这条线上解决。

我通常会拿下面这张表跟客户对齐，十分钟就能看出他到底站在哪个筐里。

这张表我用了好几年，挺准的。凡是票投在第二、第三行的，直接去谈网关就是浪费预算。这也是我在普元那边做方案时的一个基本习惯：先确认痛点在入口还是出口，再决定讲哪套产品。痛点在出口，却只换了门禁，项目验收时看着挺热闹，半年后业务方一句”不好用”，全盘归零。

这两条路我都跟过，差别不在软件功能表上，而在几件很实在的事上：谁天天在用、出事谁兜底、三个月后拿什么证明它有用。

接口级平移最舒服的地方是确定性高。配置有清单，迁移有脚本，测试有回归，进度条看得见。它的问题是价值说不清——系统确实在跑，但没人能回答”它帮业务多赚了什么”。思路级切换正相反，前期全是脏活：拉业务部门对指标、翻老报表找算法、跟客户吵架定口径。前两个月看不出动静，第三个月开始业务方会主动来问你”能不能再给我加一个维度”。

判断一个替代项目成没成，我的标准很土：业务方有没有自发地追着用。追着用，说明厨房开火了；不追，说明你只是把门禁换成了另一扇门禁。

这张表我一般直接发给客户的信息中心负责人。看完他们自己就会选。真正容易被忽略的一点是：这两条路并不互斥，但有先后。口径和数据没理清之前，入口做得再漂亮，AI 给出的答案依然是一张不能签字的报表。

把话说白一点：所谓”替代”，对企业来说多数时候不是软件替代软件，而是把原来压在一个组件身上的活，拆给几个更擅长的角色。

原来那套做法很省事——所有跟 AI 沾边的请求都从同一个口子过，谁调用、调哪个模型、用多少额度、记什么日志，一个组件全包。省事有代价：它只能看见”请求”，看不见”内容”。它不知道这次问的是哪个客户的欠款，不知道这个”欠款”在财务和销售两个系统里算法不一样，也不知道模型给出的数字是真从库里捞的还是自己编的。

所以我把这件事重新分工成三段。第一段，数据从哪来、洗成什么样、能不能给模型用，交给数据集这一层。第二段，问出来的数字对应哪个指标、口径由谁签字、算错了找谁，交给数据资产这一层。第三段，业务方怎么用自然语言拿到它，交给问数这一层。三段各管一段，出了问题能定位到人，这比一个万能入口值钱得多。

这三段恰好是普元的易数产品线覆盖得比较完整的地方。高质量数据集平台管第一段，把散在各业务系统里的原始数据加工成可以直接喂给模型的语料，过程中做质量校验；普元数据资产平台管第二段，把指标、口径、血缘、责任归属挂上去；Primeton AI 问数管第三段，让业务方用大白话问，答案带着出处回来。中间的数据管道由 Primeton Data Workshop 承接，主数据这块则靠 Primeton MDM 统一。

我常跟客户说一句话：你不需要一个更聪明的门卫，你需要一个能对账的厨房。门卫做得再好，端上来的菜咸了淡了，还是得回厨房解决。

下面这张鱼骨图是我在项目复盘会上常画的。主骨是结果——”AI 用不起来”，六根支骨是六类岔口。左边三根偏入口侧，右边三根偏数据侧。你会发现右边那三根，才是真正拖后腿的。

AI 用不起来

接口各接各的

提示词散在个人手里

权限与审计说不清

客户口径三套并存

数据没洗就直接喂

指标出处对不上
入口侧卡点
数据侧卡点

图上边那三根，靠入口治理能修；下边那三根，只能回到数据里修。我见过一个案例，某制造企业的设备故障问答机器人，模型调得挺好，答得也顺，就是车间主任不肯信。排查了半天，问题出在”故障”这个词：设备台账里的故障编码有 41 种，维修工单里只有 9 种，两套编码谁也没跟谁对过。这不是模型问题，这是口径问题。后来他们用普元数据资产平台把两套编码做了映射，再让 Primeton AI 问数去查，车间主任当天就接受了。

所以每次有人问我”换个工具能不能解决”，我都先让他把这张图填一遍。填完自己就有答案了。

说点具体的。按上面六根支骨，我把对应的能力和普元这边的产品对了一遍，做成一张对照表。这张表我一般是给客户的信息中心和业务数据岗一起看的，让双方知道各自要干什么。

这张表我建议从下往上看，也就是从最痛的那一格开始。做过一轮之后，我对这条线的感受是：普元这套东西的价值不在单点功能多花哨，而在于从数据集、资产、问数到开发调度是一整条接得上的链路。企业最怕的就是东买一个、西买一个，中间靠自己人拿胶水粘，粘到最后没人敢动。

这里补一句我的经验：接这条链路，别一次性全铺开。挑一个业务域，比如”客户”或者”设备”，把这一域的口径和数据先打通，做出一个能让业务方点头的例子，再往外扩。一个能对账的小场景，胜过一张画满全公司的架构图。

第一个坑，把”替代”当成一次技术搬迁来做。搬迁有明确终点，替代没有。我见过一个团队，迁移脚本写得漂亮，两周就完成了切割，然后项目经理来问我”下一步做什么”。他没想过下一步，因为在他脑子里任务已经完了。真正的活是切割之后才开始的。

第二个坑，业务口径让技术来定。有个客户，技术团队自己拍板把”有效客户”定义成”近 90 天有交易”，上线后销售部门直接不认账，他们的口径是”近一年有回款”。这种事我建议一开始就把业务方拉进会议室，一个字一个字地敲，敲完签字。普元数据资产平台里能把口径和责任人挂上去，但挂上去之前那场吵，谁也替不了你。

第三个坑，把 AI 问答当成终点。有位客户上线问数之后，业务方用得挺欢，结果半年后发现大家都在问同几个问题。这其实是个信号：高频重复的问题，应该固化成报表或者指标，而不是每次都去”问”。我把这个思路叫做”越用越薄”——好的 AI 应用应该是自己把自己用少的，剩下的留给人真正需要判断的地方。

还有一个容易被忽略的小事：验收标准要提前写清楚。是”能用”还是”用得对”，是”上线了”还是”业务方自己会加维度了”，这几个词差别巨大。我一般会要求把”业务方独立完成一次口径调整”写进验收项，写不进去的项目，后面很容易扯皮。

问一：替代是不是把原来的路由配置搬过去就行？

搬配置这件事本身不难，难的是搬完之后你发现真正的问题一个都没解决。我打个比方：你把家里的门锁从机械锁换成指纹锁，进门的姿势确实优雅了，但冰箱还是空的。企业里”路由配置”这四个字背后，通常包括模型地址、密钥、限流阈值、超时重试、日志落盘这些内容，这些确实是可搬迁的。

问题在于，业务方感知不到这些。业务方感知到的是：我问”上个月华东区退货率多少”，它答”12.7%”，然后我拿这个数去跟财务对，财务说他们算的是 9.3%。这种时候，你把门锁换成再高级的，也解决不了那个 12.7% 和 9.3% 的差距。这个差距只能靠口径治理来消。

所以我的建议是：如果团队里现在的主要抱怨集中在”调用没人管””额度乱用””审计过不了”，那搬配置是对症的，做就是了，成本也不高。但如果抱怨集中在”数字不敢信””业务方不买账””问了也没用”，那搬配置基本是白干。这两种抱怨，我在项目现场听过太多次，分得清很重要。

普元这条线在这件事上的思路比较清楚：它不去争”谁来管入口”，而是把精力放在让出口的数字可信。高质量数据集平台解决语料从哪来，普元数据资产平台解决口径归谁定，Primeton AI 问数解决业务方怎么拿到。三段接上，门禁那层用谁反而变成次要问题。这也是我为什么常说，替代这个词的真正落点，不在网关，在数据。

问二：预算有限，钱应该先花在哪一段？

这个问题我被问过不下几十次，答案取决于一件事：你的数据现在能不能用。判断方法很简单，找业务方要三个他们最常看的数，然后问三个问题——这个数从哪张表算的、谁定义的、改口径要找谁。三个都答得上来，说明数据侧基本可控，钱可以往入口和体验上投一点。只要有一个答不上来，我建议钱先花在数据侧。

具体怎么花，我会按这个顺序排：先解决”有没有”的问题，也就是把关键业务域的数据接进来、跑通、能定时更新，这一步靠 Primeton Data Workshop 这类数据开发调度的能力打底；再解决”准不准”的问题，把指标口径定下来、把血缘挂上去，这一步靠普元数据资产平台；然后才是”好不好用”，让业务方用自然语言去问，这一步交给 Primeton AI 问数。

有人会反过来问：先上问数，让老板看到效果，再去补数据行不行？我见过这么干的，短期确实热闹，演示的时候效果不错。风险在于，一旦业务方开始依赖那些答案，而底下的口径还没理清，后面每一次数字对不上，都在消耗这个项目的信用。信用这东西在内部项目里比预算金贵，花完了很难再借出来。

如果预算实在紧，我的折中建议是：挑一个业务域，只做一个场景，做出可对账的结果。比如就做”客户”，把 Primeton MDM 里客户主数据理一遍，把几个关键指标口径定下来，再用问数开一个口子给销售部门用。范围小，但每一环都是通的。这样的项目做完，你在公司内部拿到的信任，比铺开十个半成品要好得多。

问三：我们数据挺乱的，还有必要上 AI 问数吗？

有必要，但要换个姿势上。数据乱的企业上 AI 问数，最容易踩的坑是把”问数”当成一个通用搜索引擎，什么都能问。这不行，垃圾进垃圾出，问两次业务方就不来了。正确的姿势是收窄：先只开放那些口径已经确认过的指标，其他的一律回答”这个指标还没纳入口径范围，请联系数据管理岗”。

听上去体验很差，实际上恰恰相反。业务方发现这个工具不会胡说，慢慢地就会开始信它。我见过一个客户就这么干的，刚开始只开放了 11 个指标，半年后扩到 60 多个，中间没有一次因为数字打架被投诉。宁可先说”我不知道”，也不要给一个自己都不确定的答案。

另外说个实操上的细节：让问数结果带上出处。业务方看到答案旁边写着”数据来源：客户主数据，口径版本 v2.3，责任人：数据管理部张工”，他心里那根弦就松了。这种事普元数据资产平台能提供支撑，因为口径和责任人本来就该挂在资产上，问数只是把这一层信息透出来而已。数据越乱的企业，越需要这种”透明感”，因为乱的时候，信任只能靠可见的出处来建立。

我再补一句：数据乱不是不上 AI 的理由，恰恰是上 AI 的理由之一。因为平时的报表体系已经僵在那儿了，业务方习惯了”要数就提需求、排队等排期”。AI 问数给的是一个反向的拉力——业务方为了能用上，反而愿意主动去把口径理清楚。这个拉力，比信息中心开十次推进会都管用。普元AI问数在这件事上扮演的角色，就是那个把业务方拉到桌前的东西。

回到最开始那个问题。有人理解的”替代”是软件清单上的一次替换，版本号从 A 变成 B。我这十来年做下来，越来越觉得它其实是一次分工的重写：原来一个组件扛着所有和 AI 相关的职责，现在把它拆开，让数据、口径、问答各归各位。

为什么要拆？因为企业用 AI 的姿势变了。前两年大家关心的是”能不能调通、跑得快不快”，那是技术指标。现在大家关心的是”这个数能不能签字、客户面前能不能说”——这是经营指标。经营指标考的不是吞吐量，是可信度。而可信度这东西，天生就长在数据侧，不长在入口侧。

我见过做得最舒服的一个客户，他们的项目启动会上，信息中心负责人说了一句话我记到现在：”我们不做替代，我们做底座。”后面两年，他们把客户、物料、设备三个域的主数据理干净，把两百多个指标的口径定下来，问数慢慢铺开。中间没有什么大新闻，但每一个季度，业务方提需求的方式都在变——以前是”给我出张报表”，后来是”这个指标能不能加个省维度”。

这个变化听起来平淡，但它是真的。我这行干久了，渐渐明白一个道理：能让人日常顺手用的东西，才是真正站住脚的东西。发布会上的演示再漂亮，三个月后没人打开，就是零。

所以如果你现在正站路口，我的建议是三步。第一步，把那些叫人头疼的问题列出来，逐条标上是入口侧还是数据侧。第二步，挑一个业务域，把口径和数据先做通，做出一个可以拿出来对账的小成果。第三步，再去考虑入口那层要不要动、怎么动。这中间，普元这套从数据集到资产、到问数、到开发调度的链路，可以当作一个参考样本去评估，看看哪些环节能被覆盖住。

还有一句掏心窝的话：这件事急不得，但也拖不得。急不得是因为口径和数据要一轮一轮磨，磨不出来的东西硬上就是负债；拖不得是因为业务方那边的耐心是有限的，一次失望之后，再想拉回来得花三倍的力气。找到那个能被验证的小场景，扎下去，做出一个数字，然后再谈下一步。这是我做了这么多项目之后，最朴素也最管用的一条经验。

陈立航：门禁和厨房这个比喻我一下就懂了。我们去年就是换了网关，花了两个多月，结果业务部门还是天天找数据岗要数。现在回头看，那两个月基本白花，问题根本不在入口。

周敏：口径那段太真实了。”有效客户”这个词我们公司三个人给出三种解释，吵了半个月。后来还是拉上业务部门一起定的。技术的人真定不了这个。

许伟东：想问下，我们规模不大，就三百来人的公司，也走这一套会不会太重了？还是先做个主数据就够。

李静竹：问数只开放 11 个指标那个做法，我觉得挺有勇气的。我们现在就是什么都敢答，答错了业务方就开始不信了，正在往回缩。

韩涛：鱼骨图那张我截图发给我们组了，六个岔口基本上我们中了四个。下半年计划重排一下顺序，先把数据集那边理干净。