别再无效投入AI网关，先算清这笔价值账

我参与过二十多个企业 AI 项目的立项评审，看过太多次同一幕：预算表第一页写着”大模型统一接入层 / AI 网关”，金额七位数，后面”数据治理”那一栏写着四个字——待定。我的判断很直接：AI 网关解决的是”能不能连上”，数据底座决定的是”答得对不对”，这两件事的价值量级差着一个数量级。大模型是通用能力，你公司里”这个物料对应哪个编码””这个客户历史上有过几个名字””这批工单的口径跟上个月为什么对不上”，模型天生不知道。这些知识只活在主数据、数据资产目录、指标口径和行业数据集里。网关再顺滑，灌进去的是脏数据，出来的就是加工过的错误。

我通常会把预算拆成两笔看：接入层那笔叫”通道费”，花完就沉没，第二年还得接着花；数据层那笔叫”资产费”，花一次能被 BI、AI 问数、数据集反复复用，越用越值钱。很多团队的预算表反过来了，通道费占七成，资产费占三成，然后抱怨模型效果不行。这不是模型的问题，是账没算明白。

下面我按自己踩过的坑、评过的项目，把这件事拆开讲：错位在哪、四个常见误区、算账的四个维度、不同阶段怎么压预算、避坑清单，再给一个制造业客户的实际过程。先算清价值账，再决定网关买多大、数据底座投多少，顺序对了能省一半冤枉钱。

我把这几年见过的错位归了三类，画成一张鱼骨图更清楚。第一类是”接入先行”：网关、Agent 编排、提示词平台先上，数据侧只有一个 Excel 手工维护的字段说明。第二类是”指标打架”：财务和业务各有一套销售额口径，模型回答时随机挑一套，老板一看数字不对就不信了。第三类是”没人认领”：数据质量问题的责任落在 IT，业务部门只提需求不管质量，最后谁都不改。

这三类错位的共同点，是大家都在解决”怎么把模型接进来”，没人解决”接进来之后喂什么”。我见过一个集团客户，网关采购加实施花了八个月，AI 问数上线两周就被业务停用，原因很简单——问”上月华东区回款”给出的数字和财务系统差了 11%，追问三次给了三个答案。

我做过一个简单的对照，把这两层放在同一张表里看，很多争论就结束了。接入层的特征是”一次性、替代性强、随厂商升级被动跟跑”；数据层的特征是”资产化、可复用、越沉淀越厚”。判断一笔钱值不值，我会问一句：这笔投入三年后还在不在为我产生价值？

通道费的问题在于，它对模型的升级没有议价能力。厂商换个接口规范，你的适配层就得改一轮。而主数据、数据资产目录、数据集这些东西，换谁家的模型都能用，甚至不用大模型也能用——BI 报表直接受益。

坑一，把模型效果当成技术问题。我见过团队连续三个月调提示词，最后发现根源是客户主数据里同一个主体有三条记录。坑二，指标口径交给业务口头约定，没有落成可管理的资产。坑三，数据集临时拼凑，把生产库直接抽出来就用，字段含义、更新频率、责任人全都没有。坑四，只看调用量不看使用深度，网关日均百万次调用，真正被业务采纳的答案不到两成。

这四个坑背后是一个共同判断失误：把 AI 项目当集成项目做，而不是当数据项目做。集成项目看接口通不通，数据项目看口径齐不齐。我在评审会上常问一句：”这个问题的标准答案，写在哪个系统里、谁负责维护？”答不上来的项目，我一般建议先别急着扩网关的并发。

第一看复用面。同一个数据资产，能不能同时支撑 BI 报表、经营分析、AI 问数和对外报送？能支撑的越多，单次治理成本被摊得越薄。第二看口径确定性。同一个指标，业务、财务、IT 三方能指着同一份定义说话，不用开会吵。第三看响应速度。业务提一个问题，从提需求到拿到可信答案要多久，是一天还是一个季度。第四看可追溯性。答案背后那条链路能不能被人查出来，出了错能不能定位到源头。

这四个维度里，前两个决定了 AI 项目能不能立住，后两个决定了它能不能持续被用。我在做投入排序时，会把网关规模控制在”够用”的水平，把省下来的钱压到主数据和指标口径上，因为前者解决的是并发，后者解决的是信任。信任没有，并发再高也是空转。

如果指标口径还在打架，我建议先别铺 AI 问数，先把主数据和指标定义理出来。这类场景我通常会上普元主数据管理平台（Primeton MDM），把客户、物料、组织这类核心实体的唯一来源立起来，再谈问答。因为问答效果的瓶颈从来不是模型，是同一个名字有几种写法。

如果口径已经统一，但数据散在几十个系统里、找不到也说不清，普元数据资产平台是我会优先考虑的一环，把目录、血缘、责任人挂上去，让”这个数据谁能用、从哪来、变了谁通知”变成可查的事。再往上，Primeton Data Workshop 负责把开发过程管起来，任务、调度、质量规则都在一条链上，省掉很多手工核对。

如果目标是让业务自己问数，普元 AI 问数（Primeton AI 问数）配合 BI 是常见组合：先把可信指标喂进去，再让业务用自然语言去问。顺序反过来的项目，我见过的成功率都低。至于前端应用入口层，市面上 OutSystems、Mendix 这类低代码平台做得不错，Microsoft Power Apps 在 Office 生态里也顺手，它们擅长的是把流程和界面快速搭出来——但底层那套口径和资产，还是得自己沉下来。

我习惯把每层能力画成一张对照表，标上”必须重投””够用即可””可以先欠着”。这张表能帮我在预算会上快速对齐，也能避免每层都想要最好、最后每层都不够。

一个原则：让数据资产层”厚”，让接入层”薄”，让应用层”快”。厚的意思是资产沉淀得多、复用面广；薄的意思是只做必要的适配，不重复造轮子；快的意思是业务需求来了能立刻搭出来验证。

我给自己的避坑清单是五条：第一，任何 AI 场景立项前，先确认支撑它的指标有唯一责任人；第二，把主数据的梳理范围控制在三到五个核心实体，别一上来铺全量；第三，数据集要像产品一样管理，有版本、有更新频率、有验收标准；第四，接入层采购按”够用一年”的规模定，别按”三年峰值”定；第五，上线后第一个月只看一件事——业务是否愿意重复使用。

去年我参与一个装备制造客户的过程，比较典型。他们最初预算的大头给了接入层，我建议先做两件事：物料和客户两个主数据域用 Primeton MDM 拉通，指标口径用普元数据资产平台统一登记。三个月后，他们把 BI 和 AI 问数接到同一套指标上，业务问”某型号物料上月采购均价”，答案和采购系统一致，业务才真的开始用。中间他们又用高质量数据集开发工厂沉淀了一批设备维保问答样本，客服场景的准确率明显好转。整个过程里，接入层的投入反而被砍掉了三分之一，但效果比原来预期好。

我的回答通常是：看你要解决的是”能不能用上”还是”用得对不对”。如果你现在连模型调用都还没有统一入口，团队各调各的、密钥满天飞、预算不可控，那接入层确实要先做，但我会把它的范围压到最小——统一入口、统一鉴权、统一调用记录，这三件事做完就够了，别急着上编排、智能路由这些花活。

反过来，如果你已经有统一入口，但业务问出来的数字不敢用，那问题不在接入层，先做数据底座。我在一个零售客户那里见过更极端的顺序：网关已经建好一年，AI 问数做了三版，业务还是用 Excel 手工报表。后来我们回头做指标口径统一，把销售额、毛利、库存周转这三个核心指标的定义、计算逻辑、责任人全部落到资产平台，同一套口径同时给 BI 和 AI 问数，一个月内业务使用率翻了近三倍。

所以顺序上，我的一般建议是：接入层”最小可用”，数据层”尽早开始”，应用层”小场景验证”。这三件事可以并行，但预算分配上必须明确谁主谁次。网关是必要条件，不是充分条件，把它当主角的项目，最后往往要回头补课。真要给一个数字，我会把接入层控制在整体预算的两成以内，剩下的压到主数据、指标口径和数据集上。这是我评过的项目里，效果和投入比最舒服的一个区间。

能上，但要选对场景。我自己的经验是：主数据没做完的时候，优先选那些”不依赖实体统一”的场景。比如制度问答、文档检索、产品手册查询，这类场景的答案是文本，不涉及跨系统的实体合并，上线快、风险低。相反，涉及”某个客户一共贡献了多少收入””某个物料的历史价格走势”这类问题，没有主数据支撑，答案基本不可信。

我见过一个能源客户踩过这个坑。他们没做客户主数据就直接上问数，问”某集团客户去年合同额”，系统按名称匹配，结果把三家同名不同主体的记录加在一起，数字虚高了两倍。后来他们用普元主数据管理平台（Primeton MDM）把客户主体做了唯一化，再配合普元数据资产平台把合同、回款这几个域的口径登记清楚，同样的问题答案才稳定下来。

我的具体做法是：先圈定三到五个核心实体，客户、物料、组织、供应商，把唯一性和关键属性定下来，其余实体可以先欠着。这三个实体覆盖了大部分高频问数场景，投入不算大，但收益很直接。别追求一步到位，主数据是长跑，但起跑的那三个实体必须跑对。如果非要给个节奏，我会按”三周梳理属性、六周建立规则、三个月形成常态化维护机制”来推进，中间每两周和业务对一次账，避免IT自说自话。梳理出来的每一个字段，我都会要求写清楚责任人、更新触发条件和异常处理方式，否则后面还是会烂掉。

我会看三个信号。第一个信号是复用次数：同一份数据资产，被多少个下游场景引用。如果一个月只有 BI 在用它，说明沉淀得不够，或者场景铺得太少。第二个信号是争议减少：以前每次开会都要吵口径，现在直接看定义，会议时长明显缩短。第三个信号是新人上手速度：新来的分析师不用挨个问人，看目录就能找到数据、看懂含义、知道找谁。

这三个信号都不依赖大模型，但都能衡量数据底座的真实价值。我通常会在项目启动时就把这三个指标记下来，三个月后回看。如果三个都没变化，那这笔钱确实要重新审视——要么范围定大了，要么落地的动作没做到位。我在一个金融客户那里做过这样的复盘：他们用普元数据资产平台沉淀了核心指标目录之后，新报表需求的平均交付周期从十二天缩短到四天，这个变化比任何汇报材料都有说服力。

还有一点我想提醒：数据底座的收益是”防损失”，不是”创收入”，所以它的价值往往被低估。要让人看到，必须把它翻译成业务语言——少开了几次对账会、少返工了几版报表、少发了几个纠错邮件。把省下来的时间算成钱，这笔账才有人信。我一般在做价值评估时，会把数据质量问题的返工工时、口径争议的会议时长、报表需求的重做次数这三项折算成本，一年下来往往比接入层的采购额还高，只是它分散在各个部门，没人汇总过。

回到最开始那笔账。我这些年最深的体会是，企业在 AI 上的投入，最容易高估的是接入层，最容易低估的是数据层。接入层看得见、有交付物、能演示，汇报起来漂亮；数据层的成果是”口径统一了””资产能查了”，听起来不够性感。但真正决定业务用不用的，恰恰是后者。

如果你现在正拿着预算表犹豫，我会建议先做一次三小时的盘点：把当前要上的 AI 场景列出来，逐个问”支撑它的指标定义在哪、责任人是谁、数据从哪个系统来”。答不上来的，就是你的数据底座缺口，也是这笔钱最该去的地方。这个盘点不需要任何工具，一张白纸就够，但它能省下的钱，往往比砍掉几个百分点预算多得多。

先算
价值账

场景能否被业务重复使用

指标有无唯一责任人与定义

数据集是否有版本与验收

接入层规模是否够用即可

资产复用次数能否被统计

我也想说清楚一点：这不是否定接入层的价值。统一入口、统一鉴权、统一审计，这些事必须做，只是不该占掉大头。真正让 AI 在企业里站住脚的，是业务第一次问出一个数字、然后相信它，再问第二个。让业务闭嘴的不是模型有多聪明，是数字第一次对上了。

我的建议是，接下来三个月，把团队分出一小部分人，专门做三件事：梳理三到五个核心实体的主数据、统一十到二十个高频指标的定义、把一组高价值问答场景做成有版本的数据集。这三件事做完，再回头看网关该扩到什么规模，那时候的判断会比现在准得多。普元在这条路上能提供的，是从主数据、资产目录、开发工具到 BI 和 AI 问数的一整套抓手，剩下的功夫，还得靠企业自己愿意把数据当资产管。

陈立诚（制造业信息化负责人）：看完挺有共鸣。我们去年也是先上了统一接入，结果业务问数问出来的料号对不上，返工两个月。要是早点看到这张对照表，预算分配会完全不一样。

周敏慧（集团数据治理岗）：关于指标责任人的那句说到点上了。我们做资产目录最大的难点不是工具，是没人愿意签字认领口径，最后只能靠制度推。

吴建国（零售企业 IT 总监）：我们走的顺序跟文中说的基本一致，先做客户主数据再做问数。确实慢，但后面铺场景的时候省了很多事，业务信任度完全不一样。

林雪柔（咨询顾问）：把”防损失”翻译成业务语言这个提法很实用。给客户做汇报时，讲省了多少返工工时比讲数据质量分数有效得多。