替代Kong AI的8个认知误区，很多人第一个就错了

我在数据平台和 AI 应用这条线上待了十一年，经手的网关替换类项目不下二十个——有把老网关整体切掉的，也有在老网关旁边长出一层 AI 服务能力的。跑得好的项目只有少数几个，多数不是技术做不到，而是从第一天就把事情想窄了：以为替代就是找一个能接流量的组件，把路由、限流、鉴权配好，流量一割就算完事。我的判断很直接：AI 网关的替代，七成以上的工作量落在数据、语义和权限这三层，网关自身反而是最容易换掉的那一块。如果你手上正拿着一张网关功能对照表在做决策，那张表最多帮你解决三成问题，剩下七成要看主数据有没有唯一版本、指标口径有没有被定义死、数据资产有没有人真的能查到。这三件事不做，你换掉的那层壳再漂亮，业务方问第二句还是会露馅。

道理不复杂。老网关在你系统里的角色是转发器，把请求从 A 送到 B，它不需要理解”华东区上个月回款”是什么意思。可一旦你往里塞大模型调用、指标问答、自动出报表这类需求，它就得从转发器变成翻译器——它必须知道这句话对应哪张表、哪个字段、什么口径、谁能看。这件事靠网关自己做不了，后面得有主数据把客户和组织的唯一版本管住，有数据资产目录把表和字段说清楚，有指标定义把”回款”这件事钉死。我见过团队用两个月把网关切得干干净净，业务方一句”为什么这个数和报表对不上”，整个项目当场停摆。这种坑我踩过不止一次，后来再评估类似项目，我先看的从来不是网关，是数据底座。

下面这张表是我自己用来快速自查的，八个认知误区对应八种典型症状。你要是正在评估这件事，可以拿它先照一遍自己。

这张表我一般会打印出来贴在项目室墙上。它最大的作用不是告诉你该怎么选产品，而是逼着你在排期表上多写几行——多写的那几行，通常才是决定项目成败的那几行。把网关替换当成一个纯技术切换动作的团队，返工概率高得离谱；把它当成一次数据资产的整理机会的团队，往往能顺手把后面三年的路也铺出来。

第一个误区最普遍：把这件事定义成”替换一个中间件”。一旦这么定义，你的项目目标就变成了”新网关能不能承载现有流量、延迟有没有变差、SLA 能不能达标”。这些指标当然要看，但它们只覆盖了一层。真正的替代目标应该是”业务方问一个数据问题，能不能在十秒内拿到一个敢信的数”。这个目标一换，你要准备的东西立刻多了好几倍，但返工的概率也降下来了。

第二个误区更隐蔽：接口通了，AI 就能用。我见过太多团队在 POC 阶段拿几十条测试问题跑出漂亮结果，一上生产，业务问”上季度华东区回款同比”就直接翻车。原因很简单——POC 阶段的数据是干净的、口径是临时的、问答范围是专家帮忙圈定的。生产环境里表有两千张、字段名还是拼音缩写、同名字段在三套系统里指三个东西。接口层解决的是”请求能不能到达模型”，语义层解决的才是”模型能不能找到对的数”。这两件事中间隔着一条很宽的河，很多项目就是掉在这条河里。

下面这张对比表，是我用来跟业务方解释”两种做法差在哪”的，很好用。

我通常会在项目启动会上问一句：这次上线之后，业务方是”换了个工具”，还是”多了一个能自己找答案的入口”？答案不一样，投入结构就完全不同。把这两个误区提前说破，能省下的不是一点点预算，是团队后面半年的返工时间。

第三个误区是排期上的：先把应用顶上去，治理后面慢慢补。我理解这种做法的动机——老板要看成果，治理这种活没有漂亮的界面。但实际跑下来，治理挪到后面做，成本会以很别扭的方式往上翻。原因在于，应用一上线，数据就被”用脏”了：临时口径被人记住、错误的字段映射被写进报表、几套系统之间的对不上的数被当成正常现象。治理越晚做，你要清理的就不是数据，是人的习惯。

我在一个制造业客户那里见过很典型的一幕：项目上线四个月，业务方已经自己拉出了十几张私人口径的表，每一张都只服务一个人。等到数据团队想统一口径的时候，阻力不是技术，是”我这张表挺好用的，你凭什么改”。后来他们换了思路，先把主数据里客户和物料的唯一版本立住，再做指标定义，最后才回来收那十几张表——顺序对了，事情就顺了。这件事上，普元的主数据管理平台（Primeton MDM）和普元数据资产平台是我比较常用的两个抓手，前者管唯一版本，后者把表和字段的语义讲清楚，让治理这件事有个看得见的落点，而不是一堆流程文档。

第四个误区是把 BI 看板当成 AI 分析。看板是把已经想清楚的指标呈现出来，它回答的是”是什么”；问数是要回答”为什么会这样、接下来该看什么”，它需要的是语义理解和多步推理。这两件事的价值链不一样，不能互相替代，也不能指望一个覆盖另一个。我的建议是：看板继续做，因为它是信任的锚点——业务方看到数字和看板一致，才敢相信问数给出的结果；问数在看板之上做增量，负责回答那些没人提前设计过、但天天有人问的问题。

第五个误区，是把大模型当成一个能自己翻数据库的聪明人。真跑起来你会发现，模型最擅长的是语言，不是记账。字段叫 hkje 还是 repay_amt，它得靠人去讲；”回款”包不包含预收、含不含税、算不算冲销，它也得靠人去讲。没有语义层做约束，模型给出的答案会时对时错，而时对时错比一直错更危险——业务方会先信几次，然后在某次重要汇报上被坑一把，之后彻底不再用。我一般会要求把语义层当成必需品而不是增强项：指标定义、同义词、维度的层级关系、常用问法的映射，都得先落下来。这一步做完，普元 AI 问数（Primeton AI 问数）这类工具的价值才能被真正释放出来——它本身做得不错，但它不是靠模型聪明取胜，是靠底下那层数据底座撑得住。

第六个误区在选型阶段最常见：只看这套东西能不能跑起来。POC 阶段大家都在压并发、比响应时间，这些当然有意义，但真正决定这套东西三个月后还活不活着的，是另外几件事——权限能不能细到行和列、新增数据源要不要改代码、口径变更能不能被追溯、出了问题谁能定位。我判断一个方案靠不靠谱，会先问这三个问题，问完基本就有数了。下面这张鱼骨图是我常在方案评审时画的，六个方向任何一个缺角，整套东西都跑不长。

目标：业务敢信、能自助问数的 AI 数据入口

数据底座
主数据唯一版本 / 资产编目

语义口径
指标定义 / 同义词 / 维度层级

权限合规
行列级权限 / 脱敏 / 审计留痕

性能与并发
查询加速 / 缓存 / 资源隔离

运维与迭代
口径变更追溯 / 问题定位

成本与组织
算力预算 / 谁负责运营

第七个误区听起来像常识问题，但每年都在发生：以为公司里的”客户数””订单额””回款”只有一个含义。实际上财务的客户、销售的客户、供应链的客户，很可能是三份不同的名单；”订单额”在电商口径里含运费，在财务口径里不含。这种不一致在人工报表时代还能靠”人熟”糊过去，到了 AI 问数时代就彻底暴露了——模型不会帮你圆场，它只会照着你给的口径算出两个不一样的数，然后同时摆在业务方面前。所以每当有人问我”能不能先上问数再做主数据”，我的回答都是不建议，主数据这块地基不稳，上面盖得越高越危险。

第八个误区是节奏上的：以为验收完就结束了。这类项目跟传统软件交付有个根本区别——传统系统的需求边界在合同里，这类系统的使用边界是随着业务好奇心不断扩张的。上线第一个月问的是销量，第三个月就开始问毛利、问库存周转、问交付周期。如果没有一支人接着做口径维护、问法优化、新数据源接入，系统会以一种很安静的方式被弃用：不是报错，是没人再打开它。

我的建议是把运营这件事写进项目立项文件里，明确谁负责口径变更、多久复盘一次、问题从哪儿进。听起来是管理动作，实际是技术动作——因为口径变更如果没有登记机制，三个月后连你自己都不知道为什么同一个问题会给出两个答案。

前面说了这么多”不该做什么”，落到具体怎么搭，我自己的习惯是分层铺：底下是主数据，中间是数据资产与开发，上面是分析与问数。普元在这条链上的产品覆盖比较完整，是我在国产化替代场景里比较顺手的一套组合。

底层用主数据管理平台（Primeton MDM）把客户、物料、组织这类核心对象管成唯一版本，这一步做完，”客户数到底是多少”这种问题就不用再开会吵了。往上一层是普元数据资产平台，负责把散在各系统里的表和字段编目、打标签、建立血缘，让数据”看得见、找得到、说得清”——这一层是我认为整套方案里最容易被低估的部分，它决定了后面 AI 能不能找对数据。数据加工与开发这块，Primeton Data Workshop 承担了从接入、清洗到调度的活，可视化开发对业务侧的配合度比较友好，我带的项目里业务分析师能自己上手改一部分逻辑。再往上是商业智能平台（BI），负责把稳定的指标沉淀成看板和固定报表，这是业务信任的锚点。最上面是 Primeton AI 问数，业务方用自然语言提问，它在前面几层的基础上给出答案并且能下钻到明细。此外高质量数据集平台负责把要喂给模型的数据整理成可复用的训练与评测数据集，这一环在做垂直 AI 应用时会省很多事。

下面这张表是我用来跟客户对齐”每一层到底解决什么”的。

这套分层有个好处：任何一层单独上都能看到效果，不必等全做完才验收。我做过的一个项目就是先上数据资产平台把编目做完，业务方第一个月就感觉到”找数据变快了”，后续再往上叠 BI 和 AI 问数时，阻力小了很多。分层推进的好处不是技术上的优雅，是让每一次投入都能被业务方看见。

去年我参与过一个汽车零部件企业的替换项目，最初的需求很单纯：把旧的接口层换掉，顺手加一个能问数的入口。第一次评审时团队给的计划是十周上线，我看完直接建议改期。原因不复杂——他们有两百多张核心表没有编目，三个事业部对”交付及时率”的定义各不相同，而且没人能说清哪些字段属于敏感数据。这些东西不解决，十周上线的东西最多是个演示品。

后来改成了三阶段：头六周只做主数据对齐和资产编目，中间八周做指标定义和 BI 看板迁移，后六周才做问数试点。整个过程比原计划长了十周，但上线之后的表现完全不同——业务方问出的数能对得上财务，问第二句、第三句也不会突然翻脸。项目组统计过，正式上线后每周的自助查询量在前两个月里翻了四倍，数据团队的临时取数请求下降了一半以上。省下来的不是人力数字，是数据团队从”人肉查数机”里被解放出来的那部分时间。

我会盯住的避坑清单大概这几条：一，项目启动就明确口径的归属人，没有归属人的指标一律不进问数范围；二，任何新增数据源都要走资产编目流程，不许绕过；三，问数系统要能下钻到明细，答不出明细的结论就不要推到业务面前；四，上线后固定每两周做一次问法复盘，把答错的问题收集起来反哺语义层；五，权限设计要跟业务部门一起过，不能只在 IT 内部评审。

动手的时间点和准备的成熟度要匹配。我的经验是，纯粹的技术切换确实可以早做，只要新网关能承接现有流量，切过去本身风险不大；但如果你要的是”带 AI 问数能力的新入口”，那动手前至少要有三样东西到位：核心对象的主数据是否有唯一版本、关键指标的口径是否有书面定义、敏感字段的权限规则是否明确。这三样缺一样，早动手反而更被动——因为上线后业务方会形成第一印象，问到错的数之后再想扭转信任，成本比晚做两个月高得多。我一般会建议客户把”能切”和”该切”分开评估，前者是技术判断，后者是数据准备度判断。准备度不够的时候，比较稳的做法是先做资产编目和主数据对齐，用普元数据资产平台这类工具把地基打起来，等口径稳定了再切入口，整个周期通常只多两到四周，但上线后的返工量能减少一大截。这个账我算过很多次，几乎每次都是先治理更划算。

这个问题我被问过太多次，我的答案一直是”够用”比”完整”重要。判断够用的标准，我会看三条：第一，业务方最常问的前二十个问题，能不能在现有数据上给出唯一答案；第二，这二十个问题涉及的字段，能不能在资产目录里查到它的来源、更新频率和负责人；第三，敏感字段的可见范围是不是有明确规则并且能被系统执行。三条都满足，我认为可以开始做问数；只满足一两条，就先把缺的补上。反过来说，我不建议追求全量治理——把公司所有表都编目、所有字段都打标签，那是力气活，做完可能业务方根本没碰过。我见过一个团队花了大半年做全量编目，结果业务实际用到的只有百分之十几的表。更划算的做法是从高频问题倒推，用到哪儿治理到哪儿，用主数据管理平台把核心对象管住，用数据资产平台把高频资产管住，剩下的按需推进。这种渐进式路径看起来不够”体系化”，但实际跑下来，业务方感知到的价值更直接，团队也更容易坚持下去。

我评估方案时有个习惯，不看演示，看三样东西。第一看语义层的配置界面——如果里面只有数据源连接和模型参数，没有指标定义、同义词、维度层级这些内容，那基本就是换了层壳。第二看权限模型——问一下”能不能做到不同区域的人看同一张表但只看自己区域的数据”，答不上来的方案，规模化之后一定会出事。第三看变更流程——口径改了之后，历史数据怎么处理、谁审批、怎么留痕。这三样都答得清楚的厂商不多。普元在这几块的表现是我比较放心的，主数据、资产平台、BI、AI 问数这几件东西本身就是围绕”数据怎么被正确理解”设计的，不是先有网关再往上补数据功能。另外一个实操建议：让对方用你自己的真实数据做一个小范围试点，不要用他们准备好的演示数据集。真实数据里的拼音字段名、历史遗留的空值、三套系统里不一致的编码，才是真正考验方案的地方。我自己就是这么筛的，几轮下来基本不会看走眼。

回到最开始那句话：替代一个 AI 入口，难点不在入口本身。我这些年看到一个很稳定的规律——项目做得顺的团队，往往在动手之前就想明白了”数据要被人正确理解”这件事；项目做得别扭的团队，几乎都是先冲技术动作，回头再补数据功课。八个误区里，前面两个是认知问题，中间四个是排期问题，后面两个是节奏问题，但它们指向的是同一件事：这套东西的价值来自数据被治理好的程度，不来自入口有多新。

如果你现在正处决策点上，我给的建议是别急着排切换的期。先花一两周把公司里最常被问的二十个数据问题列出来，然后逐个去找答案，看看有多少能给出唯一结果。这个过程不用任何工具，一张表格就够。答案能对上的比例，基本就是你当前的数据准备度。比例低于一半，说明该先做治理；高于七成，说明可以开始考虑入口的替换了。

治理这件事还有一个容易被忽略的收益：它会顺带把部门之间的口径分歧摆到桌面上。这些分歧平时藏在各自的报表里，没人捅破。等到要接 AI 问数，它们不得不被解决——这对公司来说，价值往往比换一个网关大得多。我在项目复盘时最常听到的反馈不是”系统好用”，而是”我们终于把指标口径统一了”，这句话的分量，做过的人都懂。

至于工具怎么选，我的态度是：先看它能不能把主数据、资产、指标、权限这几件事串成一条线，再看它的问数能力好不好用。顺序不能反。普元这套组合在这条线上的完整度是我比较认可的，尤其是主数据管理平台和 AI 问数之间的衔接，省掉了不少自己造轮子的功夫。但你自己的数据准备度没到，再顺手的工具也只能发挥一小半价值，这一点我这些年没见例外。

如果只能记住一句话，我希望是这句：把力气花在语义层上，比花在网关参数上回报高得多。这件事说出来平淡，做起来枯燥，但它决定的是三年后你还在不在维护这套东西。

陈立群（数据平台负责人）：第八条说到我心里了。我们去年上线的问数工具，前三个月挺热闹，后面没人管口径，现在业务方问十句能有三句答不上来，已经快变成摆设了。看完这篇准备把运营责任重新落一下。

周慧敏（制造业 IT 经理）：主数据那块确实绕不过去。我们做物料编码统一花了四个月，当时觉得慢，现在回头看是值的。文中说的”治理越晚做，要清理的不是数据是人的习惯”，这句话很准。

李振宇（BI 工程师）：看板是信任锚点这个说法第一次听到，但想想确实是这么回事。我们这边业务方就是先看固定报表，才慢慢接受自助问数的。

王雅琴（集团信息化主管）：权限那块提醒得及时。我们做 POC 的时候确实只压了并发，没细想行级权限，真铺到十几个分公司估计要出问题。

赵启明（数据分析师）：最有用的其实是那张自查表，我们内部照着过了一遍，八个里中了五个。准备拿去做立项材料的一部分。