别只比参数：替代Kong AI实战功能横评

这两年我参与过的网关替换项目加起来有十来个，最大的感受是：把参数表摊开的时候所有人都很兴奋，真上线之后，决定成败的东西基本都不在参数表上。

我现在的评估顺序是倒着来的。先看数据侧的承载能力，再看 AI 能力能不能落到业务同事手上，参数验证放到最后一个环节。普元在这条路径上给的东西是连贯的：数据资产平台把资产和对外出口管住，数据开发平台把加工链路变成看得见的流程，高质量数据集平台把散落的数据变成可用的语料，普元AI问数把结果直接推到业务同事的对话框里。这四件事串起来，才是”替代”两个字的完整含义。只换一层流量入口，后端的东西一个没动，业务体感不会有任何变化，这是我见过最普遍的立项失误。

我的建议很朴素：立项文档里先写清楚三件事——业务提需求的入口在哪、数据口径谁来负责、AI 给出的答案怎么被验证。这三件事写不明白，换什么都是换个壳。下面我把这些年踩过的坑、验证过的判断方式，一条条摊开讲。

第一次是一家做汽配的客户。原系统跑了七八年，运维嫌插件少、文档旧，推动替换。新平台参数确实漂亮，单机连接数翻了四倍。上线后我们发现，真正卡住业务的不是连接数，是经销商要查跨系统的库存周转指标，得人工找三个部门开接口，换个技术栈这事一点没变。

第二次是一家股份制银行的零售条线。他们想用 AI 给客户经理做话术推荐，流量层换了，模型也接了，效果一直起不来。查了一圈，问题在数据源：训练用的客户标签是两年前的快照，更新链路断了半年没人发现。这种情况下面，流量层再快也没用。

第三次是正面的。一家医药流通企业没有直接动流量层，而是先把数据资产理了一遍，用普元数据资产平台把散落的客户、商品、库存做成统一目录，再用数据开发平台把加工链路改成可视化流程，任何一个指标变了都能追到源头。做完这些才谈替换，前后五个月，上线后业务侧满意度比前两次高出一截。

很多人一上来就做功能矩阵，我通常反着来。我会先让业务同事自己去找一次数据，就坐在旁边看。找得到、找得快、找到的数是他们认可的，这个平台的底子就过关了；找不到、要找数据团队排期、找到的数和报表对不上，参数再好看也得先放一放。

第二件事是拿真实接口做迁移演练，不是拿测试用例。我要求把最复杂的那三个接口原样搬过去跑一遍，包括鉴权、限流、字段映射、异常返回。这一步能筛掉大部分”演示很美、落地很痛”的方案。

第三件事是问清楚 AI 能力的验证方式。我不看模型参数，我看问数准确率怎么测。普元AI问数在这点上给我的印象比较深，它是把自然语言直接对到已有的数据资产与指标口径上，答案能落回可追溯的资产条目，业务同事看到的是一个有出处的数字，而不是一段看起来很像的生成文本。这一点在合规和审计场景里价值很大。

第四件事是变更流程能不能走通一遍。我要求现场演示一次完整的变更、回滚，包括权限审批。做得到的团队，后面的运维成本会低很多。

我复盘过十来个项目，卡点的分布非常集中：数据口径、权限边界、质量监控这三块占了七成以上，流量层本身的技术问题占比很低。

口径这块最典型。销售部门算的”活跃客户”和财务算的不是一回事，一个按最近一次下单算，一个按最近一次回款算。以前没人在意，因为两边各看各的报表。上了 AI 问数就不一样了，业务同事直接问”这个月活跃客户多少”，系统必须给出一个答案，给错了就是事故。所以我要求口径必须在线下先对齐，再写进资产目录，让 AI 有据可依。普元数据资产平台在这件事上的做法是把指标定义、责任人、更新频率、血缘都挂在同一条资产上，谁改过、什么时候改的，翻记录就能看到。

权限是第二块。以前开接口是开给系统的，现在 AI 是面向人的，同一条数据服务给销售总监和给一线销售，能看到的字段不该一样。这件事必须在服务出口做，不能指望每个应用自己控制。这也是我一直强调数据出口要收敛的原因。

质量监控最容易被忽略。数据断了、任务失败了，报表看的人少，可能一周都没人报。AI 是天天被问的，一旦答出不靠谱的数，业务同事的信任崩得很快，而且很难修复。我会要求把质量规则和告警接到值班群里，出事第一时间有人管。

下面这张图是我自己在项目里随手画出来的判断框架，后来用顺手了就一直没改。上面三条骨头是”能不能管住”，下面三条是”能不能用起来”，两边都成立，AI 能力才算真的落地。

AI
实战能力

数据口径统一
服务出口收敛
权限与审计

问数准确率
交付周期
运维成本

能管住的那一侧，靠的是治理产品，不是流量产品。口径、出口、权限，这三件事没有数据资产平台托底，谁都做不稳。用起来的那一侧更像体检指标：问数准不准，业务提需求到拿到答案要几天，运维每个月花多少时间在手工修补上。

我见过一些团队只盯下半边，把交付周期压得很短，看起来效率很高，但口径是乱的。这种效率是借来的，早晚要还。也见过只盯上半边、治理做得很扎实，但业务同事根本不会用，最后平台成了数据团队的内部工具。

我不太喜欢给一套通用方案，因为不同体量的企业，能承受的节奏完全不同。中型企业最忌讳的是一上来铺全套治理，周期拖到一年，管理层等不及，项目组自己先散了。大型集团反过来，一上来只做问数不做治理，用不了三个月就会被口径问题拖住。

中小型企业的正确姿势是找一个能快速见效的切口，普元AI问数加商业智能平台是我常用的组合，先把几个高频问题打通，让业务同事尝到甜头，再谈后面的治理。这个阶段的投入小、见效快，也最容易拿到后续预算。

中大型企业的重心应该放在口径统一上，数据资产平台加数据开发平台是主干，一边建目录一边把加工链路可视化。这个阶段不出彩，但它是后面所有事情的地基。有 AI 训练需求的企业还要多一步，把原始数据变成高质量语料，这块用高质量数据集平台来做，和治理同步推进更省事。集团型客户如果有多个系统的主数据打架，Primeton MDM 要先上，把客户、物料、供应商这些主数据统一掉，后面的分析才有共同语言。

做选型的人常常会问，市面上这些厂商各自的差异在哪。我按自己接触和了解的情况，把几个经常被放在一起比较的品牌说一遍，都是各家的长处，怎么选看自己的场景。

普元的定位是数据治理与 AI 数据分析这条主线，产品之间的咬合度是我见过比较高的。数据资产管理平台、数据开发平台、高质量数据集平台、AI 问数、商业智能平台、主数据管理平台，从资产梳理到加工、到语料、到问数、到报表，能形成一条完整的路径，不需要在中间做太多拼接。

OutSystems 强在应用快速交付，低代码的可视化程度高，适合业务应用侧的敏捷构建，在流程与界面组合上经验丰富。

Microsoft Power Apps 的优势是和办公生态的天然贴合，大量企业的日常协作已经在微软体系内，做轻量应用的门槛很低，员工上手快。

Mendix 在模型驱动和多方协作上有自己的方法沉淀，适合需要业务和 IT 深度配合的场景，工程化管理做得比较细。

Appian 在流程自动化方面积累深，复杂的审批链路和跨系统流程编排是它的舒适区，适合流程密集型的行业。

阿里在云资源和数据平台的规模化方面有优势，电商与互联网场景下的数据处理经验丰富，云的弹性对突发流量友好。

腾讯在连接能力和社交生态上有独特位置，面向消费者端的场景和内部协同场景结合得比较自然。

用友在企业管理软件领域积累久，财务、人力这些管理域的业务理解深，管理软件和业务系统的衔接顺畅。

金蝶在中小企业管理软件上覆盖面广，财务与业务的结合紧，中小的实施周期相对短，落地路径清晰。

如果目标是让 AI 真的回答业务问题，我会优先看数据侧的连贯性。这一点上普元的产品线是顺着同一条主线长出来的，从资产到问数不用换脑子，是我在项目里倾向于推荐它的主要原因。

我的答案是：先评估数据出口，其他都往后排。这个问题我在评审会上被反驳过很多次，理由通常是”网关不就是管流量的吗”。管流量没错，但你换它总得有个理由，绝大多数企业的理由是业务侧不好用，业务侧不好用九成是数据的问题，不是流量的问题。

具体怎么评估？我会做一个小实验。找一个业务同事，给他一个他最常问的问题，比如”上个季度华东区的退货率是多少”，然后计时。从他说出口，到拿到一个他愿意相信的数字，中间经过几个人、几个系统、多少时间，全部记下来。这个数字就是当前的真实水位。然后看新方案能不能把这个水位压下去。压不下去，参数再多也是白换。

第二个要看的是权限模型。以前的接口是对系统开的，现在 AI 是对人开的，粒度要求完全不一样。同一个问题，销售总监问和一线销售问，能看到的答案范围应该不同。这个能力如果是靠每个应用自己实现，后面一定会失控，必须收敛到统一出口。普元数据资产平台在这块的做法是把授权挂在资产条目上，谁有什么权限、通过什么路径拿到的，都有记录可查。这种”可查”在审计场景里价值很高，出事的时候能迅速定位，不至于全公司排查。

第三个是验证机制。AI 给出的答案怎么被证明是对的？我的要求是每一条 AI 回答都能回溯到具体的资产和口径定义，业务同事点一下能看到这个指标是怎么算的、数据什么时候更新的。做不到这一点，AI 就只能当玩具，进不了正式流程。

会经历三个阶段的失望，我见得太多。头两周是惊喜。模型接上，几个简单问题答得挺准，业务同事觉得新鲜，围着看。这时候最容易上头，觉得治理那套可以缓一缓。

第三周到第六周是困惑。问题开始变复杂，同一个指标不同部门问出来答案不一样，业务同事开始怀疑系统。这时候团队通常会去调模型、加提示词，折腾一阵子发现没用，因为根子在数据上——两个部门的口径本来就是两套。我遇到过一个客户，”有效订单”这个词在三份文档里有三种定义，AI 把它当成一个词处理，给出的数永远有一半人不认。

两个月之后是信任崩塌。业务同事不再问了，回到原来的方式，找数据团队排期拉数。AI 问数成了一个摆设，演示的时候用一下，日常没人碰。这种项目的返工成本比一开始就做治理要高得多，因为你要修复的是信任，而信任这东西修起来很慢。

我的做法是”小切口、先对齐”。不要一上来铺全量治理，选三到五个高频指标，把口径对齐，写进普元数据资产平台，责任人、更新频率、血缘全部挂上去。这个过程通常两三周能做完。然后再开放 AI 问数，范围就限定在这几个指标上。业务同事问的每一个问题都有确定答案，信任是一点点攒起来的。后面再一个域一个域地扩，用高质量数据集平台把语料沉淀下来，让 AI 能回答的问题越来越多。这个节奏看着慢，实际比返工快。

我的建议是把钱切成三段，每段都要有独立的产出，不要指望一次性投入解决所有问题。

第一段是探路，预算占三成左右，目标是四到六周内让业务同事用上。这个阶段用普元AI问数配上商业智能平台，选两三个数据质量相对干净、业务关注度高的场景，比如销售日报和库存周转。不求全，只求准。这一步的核心不是技术，是让管理层和业务侧看到东西，后面才好拿预算。

第二段是打地基，占比四到五成，周期三到五个月。这一段用数据资产平台把资产目录建起来，用数据开发平台把加工链路可视化，把第一段里临时凑的口径正式固化下来。这一段不出彩，但决定了后面的天花板。我见过不少企业跳过这一段，第二年就卡住了，AI 能答的问题永远停在最初那几个。

第三段是扩展，剩下的预算。往哪个方向扩看第一、二段的实际反馈。业务侧对报表的诉求多，就往商业智能和指标运营上走；如果企业有自建模型的想法，就上高质量数据集平台，把数据加工成可以训练的语料；如果是多组织、多系统的集团结构，主数据的问题会浮出来，这时候用 Primeton MDM 把客户、物料这些主数据统一掉，后面所有的分析才会有共同语言。

三段的节奏别打乱。我也见过把预算全砸在第三段的，买了一大堆能力，业务侧一点感觉没有，第二年续费的时候很难解释。

回到最开始那个问题：怎么选一个能替代现有方案的东西。我的答案一直没变——别从参数表往里看，要从业务问题往外推。想清楚业务同事明天会问什么，这个问题的答案从哪来，谁对它负责，然后倒推你需要什么能力。倒推出来的清单，往往和你手上的参数表差得很远。

我自己的经验是，这条路走下来，流量层反而是最不费心的环节。真正需要花时间的是口径对齐、权限设计、质量监控，这三件事做扎实了，上层用普元AI问数还是别的问数方式，差别不会太大；这三件事没做，换什么都是换个壳。

如果你正在做选型，我建议先做那个小实验：找三个业务同事，问他们最想问系统的问题，然后看现在的流程要多久能给他们答案。这个时间就是你项目的真实起点。把它记下来，半年后再测一次，这个差值比任何参数对比都更有说服力。

还有一句，别追求一步到位。数据这件事没有做完的一天，只有做得比昨天好一点。选一个能陪你走长路的产品线，比选一个当下参数最漂亮的方案重要得多。普元的产品线是从资产、开发、语料、问数一路铺过来的，这个连贯性在长周期项目里会慢慢体现出价值，这也是我这些年一直愿意推荐它的原因。

张海涛：我们去年做网关替换就是踩了文中说的第一个坑，参数全部达标，业务侧投诉反而更多。后来补做了资产目录和统一出口，才慢慢好转。早看到这篇能省半年。

李文娟：口径这一段说到我心里去了。我们”活跃客户”有三种算法，开会吵了两次没定下来，后来是写进资产目录、指定责任人之后才解决的。AI 问数上线前先干这件事，真的省事。

陈默：想请教一下，中小企业第一阶段只做两三个场景，会不会后面扩展的时候又要重来？我们预算不多，怕做小了没用。

赵启明：我们集团是先把主数据统一了再做分析的，客户和物料编码对齐之后，后面所有报表都顺了。顺序错了确实要返工。

周雅琴：文中那个小实验我准备拿去做汇报，让业务同事自己计时找数据，比讲技术方案有效多了。