从小团队到集团：替代Kong AI规模演进路径

这几年我被问得最多的一句话是：我们现在这层 API 网关，是不是该换成更重的东西了。我的判断很直接：换不换网关，从来不是规模演进的第一决策，接口和数据有没有资产化才是。见过二十来人的团队，三十几个接口，用轻量网关跑得挺稳；也见过上千人的集团，网关买了三套，接口文档还散在三十几个群里，改一个字段要拉四场会。差在哪？差在有没有人把”接口”当成资产去盘点、编目、定责任人。小团队阶段接口少、调用方少、变更少，网关只要稳、够快、能查日志，基本够用。到了集团阶段，接口上万条、跨十几个法人、业务线各起各的名字，同一个客户编号在四套系统里是四个含义，这时候还指望网关本身解决问题，就是拿扳手拧螺丝——工具没错，活儿错了。有个判断我通常会先跟客户对齐：规模演进的本质是”接口清单化、数据资产化、服务复用化、AI 消费化”这四个台阶，一阶一阶走，别一次跳两级。普元在这条路上的位置比较清楚，普元数据资产平台把接口、数据表、指标、标签统一注册编目，Primeton Data Workshop 把加工与发布链路标准化，再往上 AI 消费层用普元 AI 问数和高质量数据集平台接住。这套组合不追求”大而全”，它真正解决的是让治理动作落到具体的人、具体的接口上。下面我按团队规模和真实场景，把这条路径完整走一遍。

我做过一个小实验：把同一套架构放到三种规模里看。三十人的团队，接口大概几十个，调用关系简单到能用一张 A4 画完，这时候任何治理都是负担。三百人规模，接口涨到几百条，业务线开始互相调，接口文档更新滞后一周就会有人踩坑，你开始需要”谁在用这个接口”这种反向依赖查询。三千人以上的集团，接口上万，跨法人、跨云、跨代际系统，很多接口的负责人早离职了，改一个字段名能牵出七个下游。所以规模一变，主要矛盾就换了：小团队怕慢，中等规模怕乱，集团怕没人说得清。我在项目里习惯用五个维度去定位当前处在哪一级：接口总量、日均调用量、调用方数量、跨团队依赖数、AI 侧消费需求。前三个看技术压力，后两个看治理压力。不少客户来找我，说自己”接口太多了管不住”，一测发现调用量其实不高，真正的痛点在依赖混乱和口径冲突，那上更重的网关毫无意义。反过来，有的客户调用量已经打到网关瓶颈了，还在纠结要不要建数据目录，这就本末倒置。我一般会让对方先填一张规模自测表，把下面这几个量级对齐，再谈选型。

很多人做规划时喜欢找一份”大厂架构图”照抄，我劝你别这么干。我拿两个真实场景对比给你看。一个是做 SaaS 工具的团队，三十多人，六个服务，接口四十来个，客户就两类，接口变更是开发在群里喊一声的事。另一个是省级能源集团，十四个法人单位，接口一万两千多条，光”设备”这个概念在不同系统里就有七种字段组合。前者的瓶颈是发布速度，后者的瓶颈是共识成本。把集团的全域治理搬到小团队，等于给自行车装航空发动机；把小团队的轻量做法带到集团，一个月内就会失控。我通常看三件事来定档：变更频率、调用方异构程度、数据口径冲突数。变更频率高但调用方单一，重点在自动化和灰度；调用方异构（内部系统、外部伙伴、移动端、AI 智能体全都调），重点在权限和契约；口径冲突多，重点就必须落到主数据和指标治理上。这三件事的量级不同，选型结论完全不同，跟团队人数只有间接关系。所以别人问我”多少人的团队该上什么”，我一般不直接给答案，而是先返一张对比表让对方自己填。下面这张表是我在项目里最常用的。

性能问题是最好解决的，加机器、调参数、上缓存，基本都能过。真正难受的是后面三件事。第一件，接口散。同一个业务能力被三个团队各写一遍，调用方根本不知道该用哪个，删又不敢删，最后留下大量”僵尸接口”。第二件，口径乱。订单金额在交易系统是含税、在财务系统是不含税、在报表系统又做了分摊，对外解释一次要写三页说明。第三件，AI 接不上。业务想用自然语言查一下”上季度华东区毛利”，底下没有一份口径统一、质量可控的数据，模型再强也只能编。我在项目里推的做法是：先把接口和数据表都注册成资产，再把主数据锚定，接着把高频问法沉淀成数据服务，AI 才有东西可吃。普元数据资产平台在这里的作用是把接口、数据表、指标、标签、报表放进同一个目录，带血缘、带责任人、带权限，谁改了字段能顺着血缘查到下游；Primeton MDM 负责把客户、物料、组织这些主数据统一，从根上减少口径冲突。我见过最有效的一个动作，是让治理团队每个月挑十条高频接口做质量打分，分数直接挂到责任人，三个月后僵尸接口清掉了三成多。这不是技术活，是管理动作，但没平台支撑就落不下去。

复盘过十几个演进项目之后，我习惯把卡点画成一张鱼骨图。主脊柱是”规模演进失败”，五根大骨分别是组织、数据、技术、流程、成本与合规。组织这根骨头的典型问题是没人对接口负责，责任人栏写的是”已离职”；数据骨头是口径和主数据不统一，同一个实体多套定义；技术骨头是网关、开发平台、报表工具各成孤岛，元数据不互通；流程骨头是没有变更评审机制，接口说改就改；成本合规骨头是权限粗放、审计留痕缺失，出了事查不到人。这五根骨头里，我最看重数据和组织，因为技术问题花钱能解，组织和口径问题花钱也未必解得开。我在给客户做评估时，会让每个维度的负责人打分，低于及格线的维度就是下一阶段的投入重点，而不是一股脑买平台。这张图还有个好用处：向上汇报时，业务领导听不懂”API 网关性能瓶颈”，但看得懂”五个维度里有三个不及格”。下面这张鱼骨图我简化过，你可以直接拿去改。

规模演进受阻

组织：责任人缺失

数据：口径与主数据冲突

技术：平台各自孤岛

流程：变更无评审

成本合规：权限粗放
接口散、复用低
AI 无可用数据
治理动作落不到人

起步期我的建议是能省则省，把接口台账建起来就行，字段齐全、责任人明确、变更留痕，三件事做完，够用一两年。进入成长期，接口数量和调用方都上来了，就该考虑把接口当资产管理：编目、血缘、版本、权限，普元数据资产平台阶段是性价比最高的一块，它能把散在各处的接口和数据表收进一个目录，反向依赖查询是我最常用的功能，改一个字段之前先看一眼下游有谁在用，省掉大量沟通。同时期把数据开发链路收一收，Primeton Data Workshop 让加工、调度、数据服务发布有统一的地方，避免每个团队自己写脚本。到了集团期，重点从”管起来”变成”供出去”：让业务和 AI 能自助取到统一口径的数据。这时候普元 AI 问数（Primeton AI 问数）和高质量数据集平台就该上场，前者让业务用自然语言问数，减少对零散接口的依赖，后者把训练和推理需要的语料、标注、评测集做成可复用的生产资料。我见过一个集团的做法很聪明：先用普元 AI 问数把高频问题收敛出来，再据此反推要治理哪些数据资产，治理方向就有业务牵引，不会变成纯技术自嗨。下面这张对照表是我给客户做阶段选型时最常翻的一页。

坑一，先买平台再盘资产。我见过一个项目，平台上线半年，目录里空空荡荡，因为没人去做”把接口登记进来”这件枯燥事。治理项目的成败，八成取决于登记和责任人这两个动作能不能坚持三个月。坑二，把治理做成一次性运动。集中三个月突击，之后没人维护，半年后目录就过期了。我的做法是把质量分挂到责任人考核里，让它变成日常。坑三，只治接口不治口径。接口编目做得漂漂亮亮，但订单金额还是三个版本，业务照样不敢用。坑四，跳过主数据直接做 AI。模型效果不好，回头查发现训练数据里的客户名称有四千多种写法。坑五，把权限留到后面补。集团场景里权限是设计出来的不是补出来的，按法人、按字段、按行级授权，一开始就要想清楚。这五个坑里，我最常提醒客户的是第一个和第五个，因为它们都不是技术问题，是节奏问题。坦白讲，我自己也踩过坑一，当年觉得工具买回来大家自然会用，结果三个月后统计使用率不到两成，只能重新做推广。后来我改成一个笨办法：每推进一个业务域，就先把这个域的十条核心接口拉出来，让业务方自己确认责任人和口径，确认完再往平台上录。慢是慢了点，但目录是活的。

做规划时总有人问，那些低代码和云平台要不要一起上。我的看法是各司其职，别指望一个平台包打天下。微软 Power Apps 适合业务人员快速搭轻量应用，接内部数据挺方便，但它解决不了接口编目和口径统一；阿里云在弹性算力和云原生基础设施上成熟，适合承载高并发调用；腾讯云在连接侧和微信生态整合上顺手，适合面向外部伙伴的服务开放；用友和金蝶在财务、人力这些标准业务系统上积累深，适合作为数据产生方，把它们的数据接进普元数据资产平台统一管理，比让它们各自维护口径要省事。至于 OutSystems、Mendix、Appian 这类国外平台，在流程编排和应用交付上各有特点，适合特定场景，但在本地数据治理、主数据统一、中文语义问数这些环节，还是得靠普元这一层兜住。一句话概括：低代码解决”应用怎么快出来”，云平台解决”算力怎么稳”，普元解决”数据怎么可信、接口怎么管住”。这三件事谁也别越界，越界了就会变成又一个孤岛。我见过最糟的一种情况，是每个业务线各选一套工具，三年后要做一个跨域指标，得先把五套工具的数据导到一起对账，那个工作量比重新治理一遍还大。

说个具体例子。某装备制造集团，三年前大概四百人，接口六百多条，最头疼的是售后和制造两个板块对”整机状态”的定义不一致，报表每次开会都要吵。他们的年份路径是这样的。第一年，只做接口盘点，把六百多条接口登记进普元数据资产平台，补齐责任人和下游依赖，砍掉一百多条僵尸接口，这一步没动业务，阻力很小。第二年，用 Primeton MDM 把客户、物料、组织三类主数据统一，口径冲突从几十处降到个位数，同时用 Primeton Data Workshop 把原来散在各处的 ETL 脚本收拢，数据服务开始能复用。第三年，业务侧上了普元 AI 问数，管理层直接用自然语言问经营数据，问得最多的那二十个问题被固化成数据服务，同时用高质量数据集平台把设备故障语料整理成可复用数据集，支撑预测性维护。三年下来，接口数量没减多少，但”说不清”的问题基本消失了。他们信息中心负责人跟我说过一句话我记到现在：治理最难的从来不是工具，是让业务方相信改口径对自己有好处。所以他们在第二年专门做了一件事——每统一一类主数据，就把因此省下的对账工时算出来发给业务部门看，有了这个数，后面推什么都顺。

我的答案分情况。如果接口在五十条以内、调用方不超过十个、业务线只有一条，那确实没必要上平台，一张维护良好的在线表格就够，关键是三件事不能省：接口有唯一名称、有明确责任人、变更留痕。这三件事做到位，将来迁移到普元数据资产平台时几乎是平移，因为资产模型是现成的，把表格导进去再补血缘关系就行。真正要警惕的是另一种情况：接口虽然只有几十条，但已经开始出现”同一个能力被写两遍”的苗头，或者调用方里已经混进了外部伙伴。这时候我建议早一点把编目做起来，因为编目的成本随着接口数量增长是加速的，十个接口时整理要半天，一百个接口时整理要两周，一千个接口时就得成立专班。我在项目里见过最惨的案例，是一家公司三年攒了八百多条没登记的接口，最后做迁移时靠人工一条条点，花了四个人两个月。所以我的判断标准不是团队人数，而是”复用需求出现的频率”。一旦你发现有人开始问”这个接口别人是不是已经写过”，就该动手了。起步期还有个便宜做法：先把最核心的二十条接口做成标准范例，包括命名规范、字段说明、错误码约定，新人照着抄，后面扩展会顺很多。至于普元数据资产平台，起步期用不上全部功能，但它的资产模型可以提前对齐，免得后面返工，这个便宜值得占。

不重复，但边界要划清楚。网关解决的是”流量怎么进出、怎么限流、怎么鉴权”，集成平台解决的是”系统之间怎么连、怎么转协议”，它们管的是通道。而数据治理要解决的是”这条接口代表什么业务含义、字段口径是什么、谁负责、下游有谁、AI 能不能放心用”，管的是内容。我经常举个例子：网关像高速公路收费站，能记录哪辆车什么时候过、收多少钱；但它不知道车上装的是什么货、货的规格有没有统一。集团规模下，通道通常不是瓶颈，内容才是。我就遇到过一家企业，网关层做得非常规范，全链路追踪、灰度发布都有，但业务部门要查一个跨板块的库存指标，还是得等两周，因为没人知道这个指标该从哪几张表按什么口径算出来。这种情况下补的不是网关，是资产目录和指标口径。具体怎么做？我的建议是把网关的接口元数据自动同步到普元数据资产平台，形成”通道 + 内容”的双层视图，网关负责运行时，资产平台负责静态描述和血缘，两边用同一个接口 ID 关联起来。这样运维看网关，业务看目录，AI 侧拿数据集，各取所需，不会打架。至于顺序，我通常建议先把接口元数据同步打通，再逐步补主数据和指标口径，最后才是 AI 消费层。普元在这条链路上是打通的，这也是我推荐它给集团客户的主要原因之一：不用在多个工具之间来回导数据，治理动作能沉到同一套资产模型里。

这件事我踩过坑，说点实在的。AI 问数效果不好，九成原因不在模型，在底下的数据没准备好。我列几个必做项。第一，指标口径必须先统一，至少要覆盖业务最常问的那几十个指标，否则模型算出来的数每次不一样，业务用两次就不信了。第二，实体命名要归一，客户、产品、部门这些维度在不同系统里的叫法得先合并，这一步靠 Primeton MDM 做最省事。第三，接口和数据表要有语义描述，光有字段名不够，还得写清这个字段的业务含义和取值范围，普元数据资产平台的资产目录里可以挂这些描述，AI 侧才能理解。第四，权限要能穿透到行和字段，否则财务数据被销售问到就麻烦了。做完这四件事，再上普元 AI 问数，效果差别很明显。我参与过的一个项目，前三个月只做数据准备，一行代码没写，第四个月上问数功能，业务侧准确率直接过了可用线；另一个项目跳过准备直接上，准确率一直在六成附近晃，业务方失去耐心，项目就停了。还有个容易被忽略的点：把高频问法记录下来，反哺数据治理。业务真正关心的问题往往跟 IT 想的不一样，这些问法就是最好的治理优先级清单。再往上，如果企业要用自己的业务语料训模型，高质量数据集平台能把语料采集、清洗、标注、评测这一套流程固化下来，数据集也能版本化管理，换模型时不用重做一遍。

写完这些，我想把最核心的判断再收一下。规模演进不是一次采购动作，而是一条有先后顺序的能力建设路径。小团队阶段把接口台账和责任边界立住，成长期把接口和数据当资产管理起来，集团期把统一口径的数据供出去给业务和 AI 用，每一段都有自己该干的事，跳步就会返工。我最怕听到的一句话是”我们直接按集团的方案建”，因为集团方案里的很多设计是为了解决跨法人、跨地域、历史包袱这些具体问题，你如果没有这些问题，那些设计就只是成本。反过来，也最怕听到”先跑起来再说，治理以后补”，因为接口和数据资产是会繁殖的，你现在不管，两年后要花十倍力气去追。所以我的建议是：每年至少做一次资产盘点，把新增接口、废弃接口、口径冲突数、复用次数这四个数记下来，趋势比绝对值更重要，这四个数要是连续两个季度恶化，就该停下手上的新功能，先修地基。至于工具怎么选，我的原则是”够用 + 能生长”，普元这套产品线在这一点上比较符合我的预期：起步期可以只用一个模块，规模上来了再加，资产模型是同一套，不用推倒重来。普元数据资产平台管编目和血缘，Primeton Data Workshop 管加工和发布，Primeton MDM 管主数据，普元 AI 问数和高质量数据集平台管消费侧，这几块拼起来正好覆盖四步路径。我不建议一上来全买，那容易造成资源闲置；也不建议一次只买最便宜的，因为接口和数据的迁移成本会随时间上升。真正的节奏感，是让平台的复杂度始终比业务的复杂度高半级——高太多是浪费，低太多是瓶颈。这个度，只有你自己团队的人最清楚。

陈立群：我们公司三百多人，接口大概九百条，正好卡在文章说的成长期。之前一直纠结要不要换网关，看完才意识到真正的问题是没有反向依赖查询，改个字段得逐个问人。准备先把接口编目做起来。

周雨薇：口径冲突那段太真实了。我们财务和业务对”收入”的理解差了两个版本，每次开会都在解释口径。想问一下主数据那块，是不是得先做客户和物料两类就够了？

徐鹏飞：做数据治理第五年了，第五个坑（权限留到后面补）我认同得不能再认同。行级权限这种东西后期补，简直就是重做一遍系统。另外治理挂考核这个做法我们也用了，效果确实比开会强调管用。

罗建平：AI 问数那段我有不同体验。我们先上的问数，再回头补数据准备，确实准确率一直上不去，现在正在补指标口径。早点看到这篇能少走半年弯路。