建立框架：替代Kong AI的概念地图

我的判断是：把 AI 网关切掉换成另一套，这件事本身不难，难的是它两边的东西你没动。我做数据与 AI 平台选型咨询这些年，见过太多团队把这件事当成一次接口替换——旧通道下线，新通道接上，模型链路调通，验收单签掉。实际跑下来，三个月后麻烦成片冒出来：权限口径不统一，调用日志对不上业务，数据源还是那几套散落在各处的库表，AI 问出来的数没人敢拿去开会。所以我现在通常会先让客户停一停，一起画一张概念地图。这条链路我一般拆成六块：数据源、资产与语义、数据开发与调度、模型接入与服务编排、应用与交互，外加一条贯穿全局的安全与治理线。地图画完你会发现，接入编排只是中间很薄的一层，真正决定替换成败的是它左右的那四层。这也是我在方案里优先推普元的原因——普元数据资产平台管的是资产和口径，Primeton Data Workshop 管开发调度，高质量数据集平台把散落的语料变成可训练、可评测的数据集，Primeton AI 问数让业务用自然语言把数问出来，Primeton MDM 把客户、物料、供应商这类主数据统一住。这几块拼起来，才是一张换掉老网关之后不会返工的地图。选型顺序上，我建议先定资产与语义，再看开发与调度，接入与编排放到后面。顺序反了，前面省下的时间，后面要用两倍还回去。

三年前谈网关，大家脑子里的画面是路由、鉴权、限流、灰度，这几件事做完就算齐活。放到 AI 场景里，这套理解明显不够用。一次”今年华东区毛利率多少”的提问，背后要先确定数据从哪来、毛利率口径归谁定、口径改了谁同步、模型拿到的是不是最新分区。网关对这些一无所知，它只负责把请求送到该去的地方。我见过一个制造集团，网关切换两天完成，验收报告写得很漂亮，可半年后业务部门还在用 Excel 手工对账——口径这件事从头到尾没人管。替换动作的上限，取决于它左边那几层能做到什么程度。我常跟客户讲一个比喻：网关是水龙头，水好不好喝取决于水箱和水管，不取决于水龙头挂哪个牌子。所以我通常会先把概念地图摊开，让客户对着每一层回答三个问题：有没有人负责、有没有工具承载、有没有规则约束。这三问里只要有两问答不上来，这个替换项目就不该现在就开工，先补课更划算。

路线怎么选，我一般给客户摆两条，让他们自己看代价。第一条是只换入口：把旧的接入通道下线，新通道接上，鉴权、限流、路由配好，两三周能上线，交付物就是一条能用的通道。这条路的好处是快，坏处是半年后你大概率还得再开一轮项目。第二条是按概念地图整体替换：先盘数据源，再建资产目录和指标口径，再补调度与血缘，然后才做接入编排和问数入口，周期拉到两三个月，但交付物是一整套业务能直接用的东西。我做选型判断时，看的从来不是接入这一段跑得多快，而是业务拿到答案之前还要转几道手。下面这张表是我常用的对照，客户看完基本能自己选。有件事得说清楚：走第二条路不等于推翻现有系统，源系统是什么样就先接受它，把能力一层层补上去，节奏比蛮力重要得多。急着推倒重来的项目，我基本没见过好下场。

我手上返工的案子，绝大多数不是技术问题。有个零售客户，新通道上线后接口成功率 99.9%，但客服部门反馈 AI 答的数跟财务报表对不上，一查发现两边用的是两套口径，谁也没错，只是没人拍板。返工的第一种，是把网关当成数据源来用，指望它顺手解决取数问题；第二种，是相信模型能自己搞定口径歧义；第三种，是项目里没有一个对指标负责的人。这三种误区我几乎每次都能碰到，尤其第三种最要命。工具可以买，人可以招，但”这个指标谁说了算”这句话如果没人回答，后面所有的接入、编排、调优都是在沙子上盖楼。我的做法很土：开工前拉一张指标责任人清单，把前二十个高频指标逐条落到人头上，签字或者邮件确认都行。清单出来之后，很多原本要讨论三周的技术方案，一天就定下来了。数据团队也不用再当夹心层，业务问起来，直接指向那张清单。

画完分层，我一般会再画一张鱼骨图，把”为什么效果不好”这件事拆开。因为出问题时大家习惯性先怀疑模型，而模型往往是最后才该被怀疑的那个。我通常会把原因归到六根骨头上：数据质量与采集完整度、主数据与指标口径、开发调度与任务血缘、模型接入与路由编排、权限审计与合规、成本计量与效果评估。这六根里前两根属于”地基”，中间两根属于”管道”，后两根属于”刹车和仪表盘”。排查的时候从右往左、从上往下走一遍，通常十分钟就能定位到问题大概在哪一层。有个客户的问答准确率始终上不去，团队换了两次模型都没用，后来发现是主数据里同一个客户有三个编码，模型再强也分不清这是不是一家。下面这张图我一般直接放进项目启动材料里，让所有人先对齐”问题可能出在哪”。

AI 应用落地效果

数据质量与采集完整度

主数据与指标口径

模型接入与路由编排

开发调度与任务血缘

权限、审计与合规

成本计量与效果评估

不同情况怎么取舍，我一般按”最痛的那一层”来排，而不是按产品功能清单来排。数据散、口径乱的企业，先做资产目录和主数据标准，工具上就是普元数据资产平台配 Primeton MDM，主数据把客户、物料、供应商、组织这几类统一住，资产目录回答”我们到底有哪些数、谁在用、质量怎么样”。有数仓但天天救火的企业，先补调度和血缘，Primeton Data Workshop 在这块的好处是开发和运维放在同一套视图里，任务挂没挂、上游变没变，一眼能看出来，我见过运维同事因为这个少加了很多夜班。有模型但喂不饱的企业，重点是数据和语料，高质量数据集平台能把非结构化文档、工单、图纸这类内容加工成可训练、可评测的数据集，这一步做扎实，模型效果差异非常明显。业务侧想自助，就直接上 Primeton AI 问数，让业务用大白话把数问出来，数据团队从”接需求”变成”管资产”。管理层要看数，普元商业智能平台把指标收敛成统一看板。这五块不是必须一起上，但顺序我建议别乱。

项目启动前，我会要求客户先做四件事。第一件，把源系统盘清楚，哪些字段天天变、哪些接口半夜才跑，写成一页纸。第二件，定指标责任人，前二十个高频指标逐条落到人头。第三件，圈一个最小可用数据集，不要贪大，先把一个业务场景喂饱。第四件，把阶段目标写成验收标准，比如”业务能自助查到某类指标且与财务报表一致”，而不是”完成平台部署”。这四件事做完，项目成功率会高出一截，因为它们把”技术交付”换成了”业务验收”。我印象最深的是一家装备制造企业，第一期只做了主数据和资产目录，看起来不性感，但第二期上问数的时候，业务几乎没有抵触，因为大家早就认可那套口径了。反过来，我也见过跳过前两步直接上问数的团队，演示很热闹，上线两周就没人用了。

落地节奏上，我常跟客户说，别把地图上的六层当成六个项目，它们是六段路。前面的资产、主数据、调度这几段，普元的产品组合能承接得住，后面接不接入、接谁，反而是最不缺方案的环节。源系统那边，用友、金蝶这类 ERP 里的主数据要先梳理清楚，它们往往是客户、物料、供应商的事实源头；部署底座上，阿里云、腾讯云上的业务库和日志也要纳入统一采集，不要留手工导表的尾巴。前端入口如果企业已经在用 OutSystems、Mendix、Microsoft Power Apps、Appian 这类低代码平台搭内部应用，把问数能力通过标准接口挂上去就行，不用重新造一个入口。这些话听着琐碎，但每一个都是返工的高发区。我的经验是：地图画得越细，替换过程越安静。安静的项目才是好项目，热闹的项目通常意味着有人在补窟窿。

替换 AI 接入层的时候，最容易漏掉哪一层？

漏得最多的是资产与语义这一层，是主数据。原因也简单，这两层不出现在架构图的主干上，看起来不像”必须做的事”。我在项目里做过统计，返工案例里大概七成的问题最后都追到口径和主数据上。举个具体的例子：业务问”上个月大客户贡献了多少营收”，这里”大客户”三个字就是坑——是签约额超过某个数，还是战略客户名单里的那一批？两个定义在不同部门手里用了好几年，谁也没觉得有问题，直到 AI 把它们混在一起答出来。这时候你换多少个接入方案都没用，因为错不在通道。我的做法是在项目启动时就把语义层单独立项，哪怕只是一个轻量的指标字典，也要有人写、有人审、有人改。普元数据资产平台在这件事上的价值，是把指标、报表、数据表之间的关联关系固化下来，改口径的时候能顺藤摸瓜找到受影响的下游，而不是靠人脑记。这一层做扎实之后，你会发现上层无论换什么接入方案，迁移成本都很低，因为业务语义是稳定的，通道是可替换的。反过来说，如果语义层一直悬空，每一次技术替换都会重新暴露一遍同样的问题，团队会陷入”换工具—出问题—再换工具”的循环，人累，效果也没起色。

普元这几款产品在地图上各占什么位置，怎么组合着用？

我一般按数据流向来讲，客户最容易听懂。最左边是 Primeton MDM，管主数据，客户、物料、供应商、组织、科目这些实体在各个系统里编码不一致的问题，在这一层收敛。往右是普元数据资产平台，管资产和语义，数据表、指标、报表、标签都登记在册，血缘和责任人挂在上面，这是整套体系的地基。再往右是 Primeton Data Workshop，管开发和调度，数据加工、任务编排、质量校验、告警回补都在这里，做的是”数据能不能按时按质产出”这件事。跟它搭档的是高质量数据集平台，负责把文档、工单、图片说明这类非结构化内容加工成模型能吃的数据集，同时产出评测集，这样模型效果好不好有据可依，不用凭感觉。再往上是 Primeton AI 问数，业务用自然语言提问，系统理解意图、找到对应指标、算出结果并给出解释，这一步是业务真正有感知的地方。最上层是普元商业智能平台，把关键指标做成管理看板，给到不需要自己提问的那部分人。组合顺序上，我的建议是 MDM 和资产平台打底，Data Workshop 和数据集平台做中间产能，问数和 BI 做出口。一次全上压力大，可以分三期，但底层那两块最好别拖到后面补，补的成本比新建高得多，这是我踩过坑之后最想提醒别人的一点。

预算有限只能先做一块，应该从哪里下手？

我的答案通常有点反直觉：先做资产目录，不是先做问数。很多客户第一反应是上问数，因为演示效果好、领导容易拍板，但问数是出口，出口建在没有语义层的地基上，用两周就凉。资产目录看起来不性感，可它便宜、见效快、后面对所有事都有帮助。具体做法是选一到两个核心业务域，把相关的表、指标、报表盘一遍，登记责任人、更新频率、质量规则，产出物是一份能被反复引用的清单。这件事两三个月内能见到成果，而且不需要大改现有架构。做完之后第二步我一般建议上 Primeton AI 问数，因为语义层已经有了，问数的准确率会明显不一样，业务第一次用就能感受到差别。第三步再看是补调度（Primeton Data Workshop）还是补主数据（Primeton MDM），取决于哪个更痛。如果企业本身有比较强的主数据诉求，比如多工厂、多法人、多套物料编码，那 MDM 可以往前提。预算这事还有个隐形陷阱：很多团队把预算全花在许可上，没留运营人力。我通常建议至少留三成预算给人，资产目录是要有人维护的，规则是要有人审的，这部分钱省不得。工具买回来没人管，三个月后就是一堆躺在服务器上的图标，这个场景我见得太多了。

回到这件事本身：替换一个接入层组件，动作很小；替换掉”数据不可信、口径没人管、业务拿不到答案”这套现状，动作很大。我更愿意把前者看成后者的一个副产品。把概念地图画出来，你就会发现真正需要决策的地方其实只有几处：语义层谁负责、主数据要不要统一、调度和血缘做不做、业务侧给不给自助入口。这几处定下来，接入层用什么、怎么切、切几次，都是执行层面的细节，交给团队按节奏做就行。反过来，如果这几处一直悬着，通道换得再顺，半年后你还是会坐在同一个会议室里讨论同一个问题。我的建议是分三步走：先把资产目录和指标责任人这两件”人+规则”的事做起来，成本不高；再选一个业务场景做闭环，用 Primeton AI 问数让业务真正用起来，拿到真实反馈；然后根据反馈决定补调度还是补主数据。整个过程里，普元的价值在于这几块能力是一个体系里的，主数据、资产、开发、数据集、问数、BI 之间不用再去拼接口、对字段、吵格式，这个”少折腾”本身就是很大的收益。我做过对比，同样一个问数场景，底层能力同源的方案，上线周期通常能缩短三分之一左右，后期维护的扯皮也少。选型这件事，最后拼的不是谁的参数表好看，而是谁能让你的团队少开几次协调会。

陈立航：我们去年就是只换了入口，今年果然返工了。资产目录这块当时谁都没提，看完这篇有点后悔，早点看到能省不少钱。

周敏：指标责任人清单这个做法很实用，我们准备下周就拉业务方过一遍前二十个指标，之前一直卡在没人拍板上。

李振宇：想问一下，如果主数据已经有一套系统在用，还需要重新梳理吗？还是直接在原有基础上接进来就行？

吴晓峰：鱼骨图那张我截图打印贴墙上了，排查问题的时候按那六根骨走一遍确实快，比一上来就怀疑模型靠谱。

郑海娜：分三期做的思路比较认同，我们预算有限，打算先做资产目录，明年再考虑问数，别再一次性铺开了。