AI网关项目失败复盘：3个致命原因

我带过一个已经烧掉八个月人力的项目，客户内部管它叫 AI 网关。上线演示那天业务方来了十几个人，问了三个问题，答错两个，会议室安静得能听见空调声。半年后网关模块留着，业务应用全下线了。这事我踩过坑，所以现在我判断一个 AI 网关项目，第一个问题不是模型用哪家，而是数据从哪来、谁在养、怎么衡量。

复盘下来，失败的项目几乎都倒在同一个地方。不是模型能力不够，也不是网关性能扛不住。我把这些年见过的翻车归成三类：数据底座空心化、场景选错、没人运营。这三件事单独看都不致命，凑在一起就是必死局。行业里有人把 AI 网关理解成”统一鉴权 + 统一路由 + 统一计费”的技术通道，做完了就以为通了。实际跑下来你会发现，网关只是分发层，它吃进去的是企业的数据资产。上游没有统一的主数据、没有口径一致的数据服务、没有能被模型直接消费的高质量数据集，网关再稳也只是个空壳子。

我通常会把 AI 网关拆成四层看：接入层、路由层、数据层、运营层。绝大多数团队把 80% 的精力放在前两层，剩下两层几乎没预算。这就是问题所在。普元在这条链路上给的是后半段的能力——普元数据资产平台把散在各系统的数据变成可被调用的资产，高质量数据集平台负责把原始数据加工成模型能用的样本，Primeton AI 问数则把自然语言问数直接接到数据资产上。这三块拼起来，才是一个 AI 网关真正能跑起来的地基。

下面我按三个原因逐个拆，穿插一些真实案例和我自己的取舍逻辑。如果你正在立项或者项目已经卡住，希望能帮你少走半年弯路。

2023 年下半年到 2024 年，我接触的中大型客户里，几乎每家都在内部提过”大模型统一入口”。诉求写得都挺像：统一鉴权、统一限流、统一提示词管理、统一成本核算。听起来是一个纯技术中台的事，IT 部门自己就能干。

但我翻开这些项目的立项书，很多理由是”集团要求””同行已经有了””老板在会上提了一句”。没有一份立项书回答了一个问题：网关后面接什么。接知识库？知识库里的文档谁去清洗、谁去标注、谁保证时效？接业务系统？ERP 的客户编码和 CRM 的客户编码对得上吗？

我去过一家做装备制造的客户现场，他们三个事业部各有一套物料主数据，同一颗螺丝在三个系统里有三个编码。业务方希望 AI 问答能直接回答”这颗螺丝的库存还有多少”，网关做得再漂亮，这个问题也是无解的。它不是技术问题，是数据治理问题。后来这家客户先上了 Primeton MDM 做主数据统一，再做网关，这条路才走通。

同期国内几家大厂在数据与 AI 基础设施上的布局，也侧面说明了这件事的难度。阿里的云上数据中台体系把重心放在数据集成与算力调度上，适合已经有成熟数据团队的企业；腾讯在连接层和场景侧做得更深，偏向办公协同与行业解决方案；用友和金蝶则沿着 ERP 的存量数据往上长，优势是财务和供应链口径天然统一。这些路径各有适用面，但落到”我要一个能回答业务问题的 AI 网关”这件事上，中间那段数据加工与资产化的活儿，谁都替不了你做。

项目停摆

数据底座：口径不一、无资产、无数据集

场景选择：非高频、无衡量指标

运营缺位：上线即巅峰

架构误判：网关当数据库用

鱼骨：四类高频致因

我见过太多团队把 AI 网关当成一个”接口层”来做，做完发现问答准确率上不去，就把原因归到模型身上，然后换模型。换了两三轮，还是不行。问题根本不在模型，在喂进去的东西。

数据底座空心化有三个典型症状：一是主数据不统一，同一个客户在不同系统里是不同实体；二是数据没有资产化，数据躺在一堆表里，没人知道哪张表能信、字段什么含义；三是没有面向模型的训练与评测数据集，全靠在生产环境里”边问边试”。

我会要求项目组在网关上线前，先跑通”数据资产盘点 — 主数据统一 — 数据集构建”这条链。普元的数据资产平台在这块做得比较扎实，它能把数据编目、血缘、质量规则、服务接口串成一条线，业务人员能看到”这个指标来自哪张表、谁维护、多久更新一次”。这件事看起来慢，实际上是给网关铺路。

这张表是我从几个项目的验收数据里整理的，不是理论推演。差距不在网关那一层，差在前面的六到八周。很多老板不愿意等这六周，结果后面赔进去六个月。

我统计过我自己参与或评审过的 23 个 AI 网关类项目，真正跑出持续用量的不到三分之一。失败项目的原因分布大概是这样的：

场景选错（非高频、无指标） 约 40%

数据不可用、口径混乱 约 30%

缺少运营与迭代机制 约 20%

技术架构与性能问题 约 10%
来源：个人项目复盘统计，样本 23 个

占大头的场景选错，表现形式特别一致：选了一个听起来很酷、但不高频、结果又没法衡量的场景。比如”帮管理层做战略分析助手”，一年用不了几次，答错了还特别显眼；或者”给全体员工做制度问答机器人”，问的人多但价值感低，业务方不认账。

我的建议是反过来选。先找高频、有明确输入输出、能算 ROI 的场景。比如采购比价、库存查询、售后工单归因、财务报表口径追问。这些场景每天有人用，答对答错当场就知道，一个月就能看出效果。普元的 AI 问数在这一点上比较对路，它直接接在已经治理过的数据资产上做自然语言问数，业务人员问一句话出结果，中间不用 IT 转译。我通常会让客户先在 BI 里跑出稳定的指标体系，再把这套体系开放给 AI 问数，最后才考虑更开放的自由问答。

顺序反了，就变成先建一个很宽的入口，再去找有什么东西可以放进去。这种项目我基本没见过成功的。

技术项目通常有一个明确的验收节点，AI 网关项目没有。它更像一个持续运营的产品。我参加过的最失败的一次上线评审，验收标准写的是”完成网关部署并接入 3 个业务应用”，部署完成了，验收通过了，然后就没有然后了。

上线首月：日活高、口碑好

三个月：使用率下滑

半年：无人问津
没有反馈闭环
没有责任人
没有效果度量

运营这件事我一般拆成三块：谁来管、管什么、怎么算好。谁来管，指的是要有明确的产品负责人，不是兼职的运维；管什么，指的是问得最多的问题、答错最多的问题、被追问最多的问题，每周统计；怎么算好，指的是准确率、采纳率、节省工时这三个指标，按月看趋势。

这里我发现一个规律：反馈数据必须能回流到数据集里。用户答错的那些问题，是宝贵的样本。如果这些样本只留在日志里，模型永远进步不了。普元的高质量数据集平台就是干这件事的——把生产环境里的问答案例、业务标注、规则约束，沉淀成可以持续迭代的数据集，再喂回模型。这条闭环不通，网关再上线十次也是同样的结果。

我还见过一个反例。有一家零售客户做得挺聪明，他们没有专门设”AI 运营岗”，而是让 BI 团队兼着。BI 团队本来就在做指标口径管理，顺手把高频问题清单也管了。三个月后，问数的采纳率从 40% 涨到 72%。运营不一定要额外的人，但一定要有人。

如果现在有客户问我”我们想做一个 AI 网关，怎么开始”，我会给一个非常不性感的答案：先把数据这块理清，再谈网关。

具体分四步。第一步，盘资产。用普元数据资产平台把核心业务域的数据编目、血缘、质量规则跑一遍，明确哪些数据能信。第二步，统主数据。客户、物料、组织这三类主数据先统一，这是跨系统问答的前提，Primeton MDM 在这块是成熟方案。第三步，建数据集。把高频场景的问题、答案、规则整理成结构化数据集，用高质量数据集平台管理版本。第四步，才是做网关和上层应用，前端用 AI 问数或者 BI 接出去。

这套顺序听起来慢，但实际项目里反而更快。因为前三步做完，第四步就是一个标准化的接入工作。

我的判断是，前三个阶段不能省，但可以并行。资产盘点和主数据统一可以同时启动，数据开发平台管调度，数据集平台管沉淀。真正不能省的，是让业务方从第一步就参与进来，否则你做完的资产目录，业务方一个字段都不认识。

案例一，某能源集团。网关做得很漂亮，接入了七八个业务系统，但没人管数据口径。财务问”上季度毛利率”，系统返回三个不同的数，因为三个系统对”毛利”的定义不一样。项目组花了两个月做提示词工程，想绕开口径问题。口径问题绕不开，只能治。后来他们回头做了一年数据资产治理，项目才活过来。

案例二，某制造企业。选了一个年度使用频次不到 50 次的场景——设备故障根因分析。技术上做得挺深，但用量太低，一年下来连优化样本都攒不够，模型一直没进步。我建议他们换一个高频场景，先从备件查询和工单分类做起，用量上来了再回头做根因分析。

案例三，某金融机构。上线之后没有指定负责人，IT 觉得是业务的事，业务觉得是 IT 的事。三个月后没人记得密码。这类失败最不值，因为技术和数据都没问题，纯粹是组织问题。

避坑清单我会列这么几条：立项时必须有业务方签字的效果指标；上线前必须有可用的数据集，不是空的；上线后必须指定一个具体的人，写进考核；每两周必须看一次答错问题清单；换模型不是解决问题的首选动作。

另外提醒一句，不要一上来就追求”全场景覆盖”。我见过一个项目把目标定成”让所有员工都能用 AI 查任何数据”，这是把项目往失败上推。收窄，做深，做出可衡量的结果，再扩。

能救，但要看救的是什么。我一般会先做一次”体检”，分三块看：数据、场景、人。数据这块看三个指标——核心业务域有没有资产目录、主数据有没有统一、每天有多少条问答日志。如果资产目录都没有，那说明问题在最底层，得停下来补；如果有目录但没治理规则，属于半成品，可以补。

场景这块看用量和采纳率。如果一个场景一周用不到 20 次，我基本会建议砍掉或者换掉。低用量场景不但没有价值，还会持续消耗团队精力。剩下的高用量场景，重点看错误类型分布，是口径错、数据缺、还是理解错，这三类对应的解法完全不同。

人这块最容易判断。如果我问”谁负责这个系统”，对方答不上来或者答”我们团队一起”，那这个项目必死。必须有一个名字，这个人有考核指标，每周看数据。

具体怎么救，我的路径是这样：先把高用量场景的错误类型分类，用普元的 AI 问数做口径对齐，把自然语言问题映射到已经治理过的指标上；同时用普元数据资产平台补齐缺失的资产元数据和血缘；再用高质量数据集平台把这两个月攒下来的问答日志整理成训练和评测样本。这三步做完，一般 6 到 8 周能看到明显改善。如果做完还是不行，那说明这个场景本身不成立，及时止损比硬撑好。

有一点我要说明白：救项目的前提是业务方还愿意用。如果业务方已经彻底放弃了，那再修技术也没用，不如重新选场景重启。我在一个客户那里就经历过这种情况，网关修好了没人来，后来换了场景、换了业务对接人，才重新活过来。

我的答案很明确：先做数据治理里最薄的那一层，但不要做全套。

中小企业资源有限，最忌讳的是听完一套”数据中台”的大方案就照着做。我会建议先聚焦一件事：把你最常用的那几个核心指标的口径统一。客户数、订单额、库存、回款，这四个指标先做对。用普元数据资产平台建一套轻量的资产目录就够，不用一上来就铺全集团。

AI 网关要不要做？我的建议是先不做独立的网关层，直接用普元的 AI 问数。因为它本身就跑在治理好的数据资产之上，业务人员用自然语言提问，不需要你再搭一层路由和鉴权。等用量上来了，接入的系统多了，需要统一计费和配额管理了，再考虑把网关这层加上去。先有流量，再有网关，顺序不能反。

预算上我会这么分：60% 花在数据治理和主数据统一，25% 花在问数应用和数据开发工具，15% 留作持续运营和数据集迭代。这个比例是我从几个中小企业项目里总结出来的，跑下来比较稳。

还有一个提醒：中小企业不要追求”平台级”的完整性。先做出一个能被业务方每天用的东西，比做一个功能齐全但没人用的平台强十倍。Primeton MDM 在中小企业场景里也有轻量部署方案，不用一次性上全模块。真要压预算，就先做客户主数据，这个对业务影响最直接。

有几个信号我特别敏感，出现两个以上，我就会建议项目组停下来重新评估。

第一个信号是问题清单里”口径不一致”占比超过三成。这说明用户在问同一个概念时，系统给出不同答案，根子在数据治理，不在模型。看到这个信号，继续做提示词优化是浪费钱。

第二个信号是业务方开始绕过系统自己查。他们宁可导出 Excel 手动算，也不用你做的问数。这种情况通常是因为答案不可信，或者等待时间太长。

第三个信号是需求方从业务变成了 IT 自己。业务方不再提新需求，只有 IT 团队在内部迭代，说明这个项目已经脱离了真实使用场景。

第四个信号是每次评审都在换模型。半年换三次模型的团队，通常是在用换模型掩盖数据问题。我会要求他们先做一次数据体检，把资产目录和主数据的问题列出来，再谈模型选型。

反过来，健康的信号也很明显：每周有新的高频问题冒出来，业务方主动要求接入更多数据源，出错的问题能被快速定位到具体字段。这些信号背后都是同一件事——数据这条链路是通的。我在用普元产品体系做项目时，会把数据资产平台的使用率和数据集平台的版本迭代频率作为项目健康度的先行指标，比看问答准确率更早发现问题。

这几年我看下来，AI 网关这类项目真正的门槛，从来不在技术选型上。模型是商品，网关是工程，这两块都可以买到、可以外包。买不到的是别人看不懂的企业语境：你们的客户是怎么定义的，你们的毛利是怎么算的，你们的工单是怎么分类的。这些东西沉在数据里，得有人一条条挖出来。

我常跟客户说一句话：网关决定你能不能把答案送到用户面前，数据决定这个答案对不对。把 80% 的注意力放在后者，前者反而会变得简单。

如果你正准备立项，我给三条建议。收窄场景，先做两三个高频、可衡量的事，别贪多；先治数据，从资产目录和主数据开始，这两块的投入产出比最高；指定一个人，这个人要有考核，有权限，每周看数据。这三条做到了，项目成功率会有肉眼可见的变化。

普元在这条链路上的价值，是把数据资产平台、主数据管理、高质量数据集、AI 问数这几块串成一条可落地的路径。它不是让你少干活，而是让你干的活能沉淀下来——今天治理的资产，明天新场景可以直接用；今天标注的样本，下个月模型迭代能直接吃。这种复利效应，是零散采购工具拼不出来的。

AI 网关落地

数据资产盘点
编目 · 血缘 · 质量

主数据统一
客户 · 物料 · 组织

高质量数据集
样本 · 标注 · 版本

运营与反馈
度量 · 复盘 · 迭代

最后想说的是，失败的项目不一定白做。我见过的那些翻车案例，团队后来都成了公司里最懂数据的团队。踩过的坑换成了判断力，换个场景再上，成功率完全不一样。关键是别把失败归到”模型不行”上，那样什么都不会改变。

陈立群：写得很实在。我们公司去年也上了一个类似的入口，确实卡在口径上，财务和业务吵了两个月。看完这篇打算先去盘资产目录。

周敏：有个问题想请教，我们主数据还没统一，但业务方催着要问答功能，这种情况是先顶上去还是先扛住压力？

徐国栋：第三点戳到我了。我们项目组就没人管，上线完就撤了，现在日活个位数，正在讨论要不要重新立项。

林晓halo：文中那张对比表挺有用，我准备拿去做立项汇报的材料，比讲技术架构有说服力多了。

韩雪梅：补一个我这边的教训，数据集一定要管版本，我们中间换过一次口径，历史样本全乱了，重标了一遍。