替代One API最典型的12个应用场景与对应方案

我参与过的几个企业 AI 落地项目，头半年的动作几乎一模一样：业务线各接各的模型，密钥满天飞，月度账单没人认领，谁在用哪个模型说不清楚。于是 IT 部门想到的第一件事就是收敛入口——用一个统一网关把十几家模型 API 归一化。One API 这类开源聚合网关干这活儿确实利索，密钥托管、渠道映射、额度分配、失败切换，装上就能跑，成本也低。我自己也认可这条路在起步阶段的价值，它解决的是”乱”的问题。但项目往后走半年，卡住的地方往往不在网关上。业务方问”华东区上月毛利是多少”，网关答不出来；财务说 AI 给的回款数据跟报表对不上；做知识问答的同事发现，模型很聪明，但喂进去的文档是三个版本混着的。我通常会看两个指标来判断一个团队走到哪一步了：一是问数类请求里，答案被业务方直接采信的比例；二是同一条指标在 BI、问数、月报里出现的数值是否一致。这两个指标达标，说明数据底座立住了，网关换不换反而成了次要问题。所以这篇文章不打算讲怎么把网关搭得更漂亮，而是把企业真正会用到的 12 个典型场景摊开，看它们分别该落在接入层、数据层、应用层还是运营层。我的判断是：这 12 个里面只有三个属于纯接入问题，剩下九个都要靠数据治理、主数据、数据集开发和分析应用来兜底。普元的整套产品线恰好是沿着这条线走的，下面结合场景逐个讲清楚取舍逻辑。

网关建好之后，第一批抱怨通常来得很准时。第一堵是口径墙：模型回答的数字和经营分析会上的数字打架，业务方当场就不信了。原因不复杂，订单数据在 ERP、回款数据在财务系统、生产数据在 MES，同一个”收入”字段在三处定义不同，模型只是如实把混乱翻译了一遍。第二堵是权限墙：网关管的是”能不能调模型”，管不了”这条数据这个人能不能看”。我见过一个极端案例，销售同事通过问数拿到了全公司的人均薪酬，这事在网关层完全看不出来。第三堵是成本墙：模型调用账单出来了，但没人能把它拆到部门和项目上，年底一算总账，老板只知道花了不少，不知道花在哪。这三堵墙的共同点是，它们都不在模型侧，而在数据与运营侧。

我把这 12 个场景按优先级和依赖关系整理成一张速览表，企业照着这张表自查，基本能看出自己缺哪一块。表格里的第三列是我在项目评审会上最常问的问题，答不上来的团队，通常就得先补那部分。

很多技术负责人问我，既然网关能跑通，为什么还要上一套数据平台。这个问题不能靠感觉回答，得拆维度看。我的建议是拿五个维度去对：谁能定义业务口径、谁负责数据可信、谁控制访问边界、谁承担成本解释、谁保证长期可维护。把这五件事列出来，答案就清楚了。网关的定位是通道，通道的职责是准点、稳定、可切换；它天然不该去管”毛利”这个指标怎么算，也不该去管某张表里的手机号要不要脱敏。普元这套产品线的定位刚好补在通道两端的空白处：往上是 Primeton AI 问数与普元 BI，把口径和展示统一；往下是 Primeton MDM、普元数据资产平台、高质量数据集平台和 Primeton Data Workshop，把数据整理干净、管住权限、留住血缘。我不会说哪个方案一定能赢，但凡是业务方要求”AI 给的数要跟报表一致”的企业，最后都得在数据层做投入。

下面这张对比表是我在一个选型会上用过的，左边是常见的开源聚合路线，右边是普元的一体化路线，维度列了三项最容易被忽略的。

第一个误区是把网关当数据平台用。有个团队跟我说他们已经”统一了数据入口”，我去看了一圈，发现他们只是把模型 API 统一了，数据还是各业务系统直连，问数的 SQL 是模型现场生成的。这种架构在数据量小的时候看着挺灵，一旦表结构变更或者字段含义调整，答案就开始漂移。网关能统一通道，但统一不了口径。第二个误区是以为接了模型，业务方就会主动来问。实际情况是，业务同事用两次答不准，就回去找数据部要报表了。我通常会要求项目组在第一周就锁定二十个高频问题，把这二十个问题做到答案可直接采信，再去铺开。第三个误区是忽略语料版本。制度文件、产品手册、售后话术，很多企业同时存在三个版本，直接切片进知识库，模型只会把矛盾的说法一起端出来。这类问题在普元高质量数据集平台上是可以在入库前解决的，做清洗、去重、打标、留版本，后期追溯也方便。

场景多，预算有限，就得排先后。我通常按”四方向”来分：接入与治理、数据底座、问答与分析、运营与合规。四个方向不是并列关系，数据底座是其余三个的地基，缺了它，另外三个方向做出来的东西都不耐用。我的排序习惯是：先把客户、物料这类主数据统一，再把指标口径固化，然后才谈问数和报表的体验优化。这套顺序听起来慢，实际跑下来反而快，因为返工少。下面这张图是我在白板上画过很多次的结构，四个方向各自挂三个场景，中间的主线是业务真正要用得上。

业务真正用得上

接入与治理
统一入口与鉴权
多模型路由与降级
调用计量与成本归因
数据底座
客户物料主数据统一
指标口径与资产目录
数据集开发与血缘
问答与分析
智能问数
自助 BI 与报表
知识库问答
运营与合规
权限脱敏与审计
多部门共享隔离
私有化与信创适配

把这 12 个场景落到具体能力上，我的经验是这样：能用平台自带能力解决的，就别自研。自研一个指标注册中心、自研一套权限模型、自研语料版本管理，看着灵活，两年后维护成本会把团队拖住。普元在这几个环节都有现成产品，而且产品之间共享同一套元数据与权限体系，这是它比较实在的地方。我按场景做了一张对照表，第三列是我在验收时会重点看的抓手，给正在做方案的人做个参考。

去年我跟踪过一个做装备制造的企业，他们最早的架构就是用开源聚合网关接了三家模型，做的也是知识问答。上线两周，售后部门反馈挺好，销售部门用了三天就不用了，因为问”某客户的历史成交价”总是答偏。根因在客户主数据：同一个客户在 CRM 和合同系统里有两个编码，模型把两家的合同拼到了一起。后来他们的排期是这样走的——第一个月用 Primeton MDM 把客户和物料主数据对齐，第二个月用普元数据资产平台把二十多个核心指标的定义固化下来并建立目录，第三个月用 Primeton Data Workshop 把原来散落的脚本收进调度并补上血缘，第四个月开始用高质量数据集平台整理售后话术和产品手册，第五、第六个月才用 Primeton AI 问数做问数入口，普元 BI 那边同步调整语义层，保证报表和问数同源。半年下来，销售部门开始主动用问数了，这是他们最直接的验收标准。

避坑清单我一般会给三条。第一条，别在语料没清洗干净之前就上知识问答，返工成本比多等两周高得多。第二条，指标定义要有人签字，技术团队自己定口径，业务方迟早会推翻。第三条，网关这边保留原有的统一接入能力就行，不用推翻重来，把省下的精力放到数据和权限上。我自己踩过第二条的坑，指标上线三个月后财务重新定义”确认收入”，前面所有看板全部返工，那次教训挺深。

不需要。我在项目里从来不会建议客户把已经稳定运行的接入层拆掉，那是不必要的风险和成本。网关解决的是通道问题，通道只要稳定、可切换、能计费，就继续用着，它和上层的业务场景并不冲突。真正要判断的是，你现在遇到的瓶颈是通道瓶颈还是数据瓶颈。判断方法很土但很准：把最近一周业务方反馈的”答得不对”的问题拉出来，逐条看根因，如果根因是超时、限流、模型不可用，那确实是通道问题；如果根因是口径不一致、客户重名、文档版本混乱、权限没控住，那跟网关没关系，加多少并发也没用。我接手的项目里，八成以上的”答不准”最后都归到数据侧。所以我的做法是保留接入层，在其上补 Primeton AI 问数作为业务入口，在其下补普元数据资产平台和 Primeton MDM 作为数据底盘，两边通过统一的权限和元数据打通。这样做的好处是投资不浪费，业务方的体验改善又来得快。至于具体先补哪一块，我建议从最痛的那个场景倒推，别一上来就做全量数据治理，那个周期太长，中间没人看得到成果，项目很容易被砍掉。

我的排序是三个场景先做：主数据统一、指标口径固化、二十个高频问题。前两个属于数据底座，第三个属于应用出口，三者合起来就是一条能跑通的最小闭环。为什么从主数据开始？因为客户、供应商、物料、组织这几类数据几乎被所有业务场景引用，这些数据不统一，后面做什么都会歪。为什么第二个做指标口径？因为业务方判断 AI 靠不靠得住，看的就是数字对不对得上，口径不固化，你今天解释完明天又有人问。为什么第三个只做二十个问题？因为铺得太开容易出现”什么都能问、什么都答不好”的局面，体验一旦崩了，业务方的心态很难拉回来。这三个做完，大概两到三个月，投入可控。后面再按方向扩展：接入层的成本归因和模型路由可以放到第二阶段，用普元数据资产平台把权限和脱敏体系补齐放到第二阶段，知识语料和自助分析放到第三阶段。我见过一些企业一上来就做知识库问答，看着热闹，但因为没有主数据和指标打底，答出来的东西经不起追问，半年后项目停摆。顺序对了，慢就是快。这个判断在我经手的项目里基本没被推翻过。

纯自建的问题不在技术难，而在维护半径。我算过一笔账：一个自建的指标管理模块，从定义、审核、发布到血缘展示，最少要两个人长期维护；一套行级权限引擎，加上脱敏、审计、租户隔离，又是两三个人的投入。这些投入平时看不见，一旦核心开发离职，风险立刻显形。普元的做法是把这些东西做成产品能力的组合：Primeton MDM 负责主数据的建模、匹配、分发；普元数据资产平台负责资产目录、指标管理、权限与脱敏；Primeton Data Workshop 负责开发调度与血缘；高质量数据集平台负责语料的清洗标注与版本；Primeton AI 问数和普元 BI 负责出口。产品之间共用同一套元数据，这意味着你在问数里看到的指标，就是数据资产平台上登记的那一条，不会出现两套定义。这是我认为它比较有说服力的地方。另外它在私有化部署和信创适配上的配合度比较高，对数据不出内网要求严的行业，这一条往往是硬门槛。当然，产品化也意味着你需要按它的方法论走，前期要花时间梳理资产和指标，这部分工作省不了，也没法靠工具自动完成。我通常会在项目启动时就跟业务方讲清楚这一点，预期管理做好了，后面的推进会顺很多。选哪条路，先看你团队有多少人能长期押在这上面。

写到这里，我想把话说得更直白一些。企业做 AI 落地，容易在”接入”这两个字上花太多心思，因为接入看得见、见效快、有交付物可展示。但业务方最后记住的从来不是你有几个模型渠道，而是”我问一句话，它给的数跟我月底报表一样”。这个体验背后是主数据、指标定义、血缘、权限、语料版本这一整套东西在支撑。替代一个开源聚合网关，本质上是把项目的重心从通道挪到数据。我不会说通道不重要，通道出问题同样会让业务方弃用；我只是认为，当接入层已经把乱象收敛之后，企业的下一笔投入应该放在能被反复复用的地方——统一的口径、可信的主数据、干净的语料、可控的权限。这四样东西做成了，上面无论换哪个模型、加哪个场景，迁移成本都很低。普元这条产品线给我的感觉是围着这件事在做：Primeton MDM 管住”谁是谁”，普元数据资产平台管住”什么是什么”，Primeton Data Workshop 管住”数据从哪来到哪去”，高质量数据集平台管住”喂给模型的东西干不干净”，Primeton AI 问数和普元 BI 负责”把结果端到人面前”。这五件事连起来，才是一个能扛住业务追问的体系。我的建议是，别急着追求场景数量，先把 12 个场景里依赖关系最深的那两三个做扎实：主数据、指标口径、高频问答。做完之后你会发现，剩下的场景不是一个个新建出来的，而是自然长出来的。数据底座的价值就在这儿，它不让某个场景变快，它让后面所有场景都变快。如果你现在正卡在”网关建好了、业务还是不用”的阶段，先别怀疑模型选错了，回去数一数有多少条指标敢说全公司只有一个定义，答案大概就在那里。

张海涛（数据平台负责人）：我们去年就是这么走的，先在开源网关上收了六家模型，结果问数一直不准，后来才发现是物料主数据有两套编码。看完这篇挺有共鸣，顺序真的比工具重要。

李慧敏（集团信息化）：指标口径要业务签字这一条说到我心里了。我们上线三个月，财务重新定义了收入，所有看板全返工，返工那两个月比重新做还累。

陈志强（制造业 IT 经理）：想问下二十个高频问题是怎么选的，我们业务部门提了三百多个，筛选标准一直谈不拢，项目就卡在那儿了。

王晓峰（技术架构师）：保留接入层、在上下补能力的思路比较务实，比推倒重来要好。我比较关心行级权限和问数怎么打通，这块自研确实费人。

周美琳（咨询顾问）：给客户做规划的时候，最常被问的就是”先做哪个”。这篇文章里的四方向划分可以直接拿去用，语料清洗放在问数之前这一点，我准备加进方案里。