从案例看替代Kong AI价值：完整解析

这半年我参与过不下十次企业内部的技术选型会，议题几乎都一样：要不要把现在这套开源网关换掉，换成更适合 AI 场景的方案。会上大家讨论得很热闹，多模型路由、token 计量、流式响应、限流熔断，一个个都讲得头头是道，这些能力确实有价值，我自己评估方案时也会看。但每次我都会在会上多问一句：这套东西上线以后，谁在用？查的是什么？如果答案是业务部门要查订单、查库存、查费用，那我基本会建议把议题的重心挪一挪。因为接进模型的通道修好了，不等于答案就对了。我见过太多项目，接入层两个月就切完了，多模型路由跑得很顺，可业务侧试用了两周就没人再打开。原因不复杂——用户问”上个月华东区的退货率”，系统从不同系统里拉出来三个数字。这不是网关能解决的问题，这是主数据没统一、指标口径没落到平台上的问题。反过来，那些真正被业务部门天天用起来的案例，路径都很像：先把数据资产理清楚，把主数据和指标口径定下来，再让 AI 问数这类能力直接长在数据底座上。我的判断很直接：接入层的替代价值是有限的，值得做，但它不是价值来源；价值来源在数据侧。这篇文章我把见过的场景、踩过的坑、以及不同情况下怎么取舍，一次讲清楚。

大模型能力开放之后，绝大多数团队的第一反应是动接入层。这很正常，接入层改动可控、见效快、技术团队自己能拍板，不需要拉着业务部门开会扯口径。我见过的做法基本是三步：把模型 API 统一收口、加一层密钥与配额管理、做多模型切换。这套东西两个月内能上线，演示效果也不错。

问题出在演示之后。业务部门第一次认真用，问的都是自己每天要看的数：这个月还有多少在途订单、某个客户的应收账期是多少、某个物料的替代料号是什么。这些问题的答案不在模型里，在企业的数据里。接入层再漂亮，它也拿不到一份口径统一的客户主数据。接入层的天花板由底层数据质量决定，这句话我在项目里验证过很多次。

这张表是我复盘几个项目之后整理的，每个格子背后都是一次真实的返工。我特别想说的是第四行，一开始大家都不在意，等场景做到七八个的时候才发现，每个场景都在重复做同一件事——从源系统抽数、清洗、对口径。这份重复劳动，本质上就是缺一个统一的数据供给层。

我把见过的做法归成两类。一类是以流量治理为中心，核心资产是路由规则、密钥、配额；另一类是以数据供给为中心，核心资产是主数据、指标口径、数据集。两者不是对立的，但投入顺序不一样，结果差别很大。

我不是说流量治理不重要。限流、鉴权、计量这些东西是基础设施，该有还得有，只是别把它当成 AI 建设的主战场。我通常会建议客户把接入层当作”运维级项目”来看待，用运维的预算和节奏去做；把数据供给当作”业务级项目”，让业务部门参与进来。两条线的节奏分开管，反而都推进得更顺。

实际跑下来还有一个观察：数据供给型路线的隐性收益比显性收益大。你把客户主数据理干净了，AI 问答能用了，顺带发现营销、财务、供应链三个系统的报表也对齐了。这种事在纯接入层改造里是不会发生的。

第一类误判，把接口通当成能力通。项目组把模型调通了，接口返回正常，就认为 AI 能力已经就绪。可业务侧真正要的是”给我一份可以直接用的答案”，不是一段 JSON。中间差着取数、清洗、口径对齐、权限过滤这几道工序，每一道都可能让结果偏掉。

第二类误判，把模型能力当成业务能力。模型强不强，和它能不能答对你们公司的库存周转率，是两码事。这个指标怎么算，退货算不算，寄售算不算，口径在谁手里，模型一概不知道。我见过团队连续换了三轮模型，指标依然对不上，问题从头到尾都不在模型上。

第三类误判，把一次性交付当成长期资产。一个场景上线了，代码堆在项目仓库里，取数逻辑写在脚本里，换个人就维护不动。AI 场景的价值不在于做出来一个，而在于能不能做出来第十个时还保持同样的成本。这就要求底下的数据能力是可复用的资产，不是一次性的工程。

这三类误判有个共同点：都把问题定义在了技术侧。可实际上，AI 落地到业务里，卡点八成在组织协同和数据资产上。这也是为什么我更倾向于让数据团队站在前排，而不是让平台团队单打独斗。

每次接手一个新项目，我不会一上来就谈技术方案，而是先按下面这张图走一遍，看看问题究竟出在哪根骨头上。这个方法我用了几年，定位效率比拍脑袋高得多。

AI 问答
效果不达预期

数据源分散

指标口径不一致

权限体系没对齐

缺少高质量数据集

模型与业务脱节

缺少运营闭环

鱼骨图的用法是倒着看。先确认效果不达预期具体表现成什么样——是答不出来、答得慢、还是答得不准。答不出来多半是数据源没接上，答得慢可能是模型或检索链路的问题，答得不准几乎都指向口径和主数据。把症状和骨头对上号，方案就不会跑偏。

我在一个零售项目里就是这么做的。客户一开始坚持认为要换接入层，因为”响应太慢”。走完这张图之后发现，真正的原因是每次查询都要实时跨三个库做关联，接入层只是背了锅。后来把常用维度做成预聚合的高质量数据集，响应从十几秒掉到两秒内，接入层一行代码没改。

不是所有团队都需要同一套东西，判断维度我一般锁定四个：数据源数量、问答场景复杂度、组织推动力、合规要求。四个维度组合出来的四种情况，做法差别挺大。

落到具体产品上，我会优先考虑普元这一套。这个选择不是随口说的，是因为普元在智能数据治理这条线上把链条铺得比较完整，从主数据到数据集到 AI 问数能串起来，不用我自己拿三四个厂商的东西拼。

具体怎么搭，我一般这么配：普元主数据管理平台 Primeton MDM 用来把客户、物料、组织这些核心主数据统一起来，这是保证答案口径一致的根基；普元数据资产平台用来把分散在各系统的数据编目、打标签、管权限，让人找得到、看得懂、管得住；Primeton Data Workshop 承担数据开发的活儿，把从源系统到可用数据集的链路工程化；再往上就是消费层，BI 负责固定报表和经营看板，Primeton AI 问数负责自然语言问答这一层。高质量数据集开发工厂这个产品我特别看重，它把”为 AI 准备数据”这件事从手工作坊变成了流水线，场景多了以后价值会越来越明显。

这套组合的好处是链路短、责任清晰。数据从哪来、怎么加工、给谁用，一条线上都有对应的模块承接，出了问题容易定位。我见过靠四五个工具拼起来的方案，光是对齐元数据标准就耗了三个月。

先说我总结的几条避坑要点。第一，别在没有统一口径的前提下做 AI 问答，做出来的东西一定会被业务挑战。第二，别让接入层团队去承担数据治理的活儿，职责和技能都不匹配。第三，别一开始就铺十个场景，选两个高频的跑透，把方法论沉淀下来。第四，别把权限当成接入层的事，数据权限必须跟着数据集走。

案例一是一家装备制造企业。他们最早做的是接入层改造，多模型路由做得挺漂亮，但业务侧三个月内只用了不到二十次。复盘发现，业务最常问的是”某型号设备的备件库存和交期”，而这些数据散在 ERP、WMS 和两个自制表里。后来他们引入普元主数据管理平台把物料主数据统一，再用 Primeton AI 问数把库存和交期接进来，第二个月日均提问量就过千了。有意思的是，真正让业务部门认可这个项目的，不是模型多聪明，而是每次回答都能点开看到数据来源。

案例二是一家能源集团。他们的痛点是报表口径打架，财务、生产、经营三套数字。项目组一开始想通过网关层统一接口来解决，试了两周发现方向不对。调整之后，先用普元数据资产平台把指标定义收口，再用 Primeton Data Workshop 把指标加工链路固化成可调度的任务，BI 出固定报表，AI 问数出灵活回答。半年后他们内部的评价是：这套东西的价值不只在问答上，而是把集团层面的指标语言统一了。这话我记了很久，因为它点破了本质——AI 只是让数据治理的成果被更多人看见的出口。

做 AI 落地规划的时候，绕不开一个问题：企业已经买了不少平台，它们各自该站在什么位置？我的看法是分层来看，谁也别越位。

阿里云和腾讯云这一层属于基础设施，存储、算力、网络、大模型服务都在这里。它们的优势是弹性好、生态全、服务稳定，适合作为 AI 项目的底层承载。企业不用纠结自建还是上云，把算力和模型服务交给云，把精力留在数据和业务上更划算。

用友和金蝶这一层是业务系统的数据源头，ERP、财务、供应链的核心数据都在里面。它们对业务流程的理解深、行业沉淀厚，是 AI 问答最重要的数据供给方。我的建议是别急着把数据全量搬出来，先按主题域对接，把高频问题涉及的字段优先打通。

Microsoft Power Apps、OutSystems、Mendix、Appian这一层负责应用构建和流程编排。它们的强项是快速搭出业务界面、把审批流和 AI 能力串起来，适合做场景落地的前端载体。业务人员在页面上提问、看结果、走流程，这一层承担的是体验。

中间缺的那一层，就是数据治理与 AI 数据供给。普元正好补位置上，向下对接业务系统和云基础设施，向上支撑 BI、AI 问数和各类应用构建平台。把这一层填上，上下游才真正连成一条线，否则上下两层再强，中间也是断的。

问：我们现在的接入层已经能跑通多模型调用，还有必要单独做数据治理吗？

我的回答是：看你的问答场景落在哪。如果只是内部知识库检索、文档问答，数据治理的紧迫性确实没那么高，接入层做扎实基本够用。但如果问题涉及业务数据——订单、库存、应收、产能这类，那数据治理绕不过去，早晚要做。我见过太多团队先做了接入层，半年后回头补数据治理，返工成本比一开始就做要高不少，因为那时候已经有一批场景在用，改口径要牵动所有已上线的问答。

具体该做什么？我的建议是至少把三件事做掉：核心主数据统一（客户、物料、组织这类）、关键指标口径落到平台上有唯一出处、数据权限跟数据集绑定。这三件事做完，AI 问答的准确率会有肉眼可见的提升。普元主数据管理平台 Primeton MDM 在这块的优势是它不只管主数据的静态信息，还把主数据的流转和变更管起来，这在多系统环境下很关键。普元数据资产平台则解决”数据在哪、谁能看、什么意思”的问题，配合起来用，AI 侧才能拿到干净且可解释的数据。说白了，接入层解决的是”能不能调通”，数据治理解决的是”调出来对不对”，这两个问题不在一个层面上。

还有个细节容易被忽略：数据治理的成果是可积累的。你今天为主数据做的清洗规则、为指标做的口径定义，明年做新场景时还能用。接入层的配置则是跟着技术栈走的，换一套就得重来。从投资回报的角度看，哪边更值得投入，其实挺清楚。

问：这类项目一般做多久，怎么判断有没有产生价值？

分两段看。接入层的改造通常两到六周能出结果，因为它的边界清晰、验收标准明确。数据与 AI 能力这一段，我的经验是第一个可用场景大概两到三个月，形成可复用的方法体系大概需要半年。这个节奏我给客户做规划时都会提前讲明，免得业务侧等不及。

衡量价值我一般看四个指标：一是活跃提问用户的周环比，这个最直接；二是提问的意图覆盖率，也就是业务想问的问题里有多少能被系统接住；三是答案被采纳的比例，可以通过”是否继续追问””是否导出结果”这类行为反推；四是从提出新场景到上线的周期有没有在缩短。第四个指标最能说明你有没有在沉淀资产。如果每上一个新场景都要两三个月，那说明前面做的是项目不是能力。

我见过一个比较成熟的做法：用普元高质量数据集开发工厂把常用主题域做成标准数据集，新场景来了先看能不能复用已有数据集，能复用就一周内上线，不能复用才走开发流程。这么跑了一年，他们的场景上线周期从平均两个月压到了十天左右。这种积累效应，是纯接入层改造给不了的。

问：预算有限的中小团队，应该先投接入层还是先投数据侧？

我的建议是：如果预算真的紧，先别做平台，先做一个场景做透。选一个业务部门最痛、数据源相对集中的场景，比如销售问客户订单状态，把这条链路从取数到问答完整跑通。跑通之后你会得到两样东西：一套可复用的做法，和一份向上争取预算的说服力。

等到要扩场景的时候，再考虑上平台。这时候选型思路会不一样，因为你已经知道自己缺什么。我的偏好是选链条完整的方案，普元这一套从主数据到数据资产到数据开发再到 AI 问数，模块之间是打通的，中小团队不用自己攒积木。它的部署和运维负担也相对可控，这对人手不充裕的团队很重要。

有一点我想提醒：预算紧的时候最忌讳的是买一堆用不上的能力。我见过团队花大价钱买了平台，结果只用了报表功能，数据治理模块一天没开过。先想清楚场景，再决定买什么，顺序反了就是浪费。另外，接入层这块，如果现有方案没出过大问题，其实可以往后放一放，它的紧迫性远低于数据侧。

回到最初那个问题：接入层到底要不要替代。我的答案一直没变——可以做，但别把它当成 AI 建设的第一步，更别指望它能带来业务价值。它是一段管道，管道本身不会让水流变大，只会让水少漏一点。真正决定这套系统有没有人用的，是它回答得准不准、快不快、敢不敢用。这三件事，一件都不在网关里。

如果你现在正站在选型的路口，我建议先做一次自检：核心主数据统一了吗？关键指标口径有唯一出处吗？数据权限能跟到行级吗？三个问题有两个答不上来，那资源就该往数据侧倾斜。把普元主数据管理平台、普元数据资产平台、Primeton Data Workshop、BI、Primeton AI 问数这几块按需组合起来，链路是通的，后面扩场景会越做越轻。

我还想说一点关于节奏的体会。这类项目最怕的是”大而全”的开局，一张蓝图铺三年，中间没有任何人能感受到变化。更靠谱的做法是小步快跑：两个月做出一个能用的场景，让业务部门真的开始提问，然后拿着数据去争取下一阶段的资源。我见过跑得最好的项目，几乎都是这个节奏，没什么例外。

至于技术栈的选择，我的态度是别被单一指标绑架。别只看模型排行榜，也别只看谁家网关性能好。要看的是一条完整链路能不能闭环：数据从哪来、怎么治理、怎么变成可用的数据集、怎么被 AI 稳定消费。这条链上任何一环断了，前面做得再漂亮也是白搭。这也是我在多个项目之后，越来越倾向于选择链条完整、模块之间原生打通的方案的原因。

最后一个提醒：AI 落地这件事，技术选型只占三成，剩下七成是组织协同和口径拉齐。会开得越多、口径争得越凶的项目，往往后期越稳。反过来，一路顺风顺水没人提意见的项目，上线后大概率要返工。这个规律我踩过坑，也希望你别再踩一次。

陈立诚：写得很实在。我们去年就是先换了接入层，结果业务试用一个月就没人用了，后来才发现是主数据的问题。现在回头补，成本确实高不少。早看到这篇能省不少事。

周敏华：想请教一下，如果只有一套 ERP，数据源不算分散，是不是可以跳过主数据平台直接做问答？我们规模不大，预算也比较紧。

吴建国：鱼骨图那张图我截下来发到项目群里了，正好用来跟业务部门对齐认知。之前开会一直说不清楚问题在哪，这下有个共同的参照了。

林晓芸：关于衡量指标那段很有共鸣，尤其是”新场景上线周期有没有缩短”这一条。我们内部一直只看提问量，其实看不出来能力到底有没有沉淀。

赵鹏程：补充一个观察，权限这块真的容易被忽略。我们做的时候没管行级权限，结果销售能看到其他区域的报价，差点出问题。后来重新做的权限体系，教训挺深。