信创AI网关项目失败复盘：8个致命原因

我的核心判断：八个致命原因里，只有两个真出在网关身上

我前后跟过三个信创环境下的AI网关项目。两个中途停掉，一个拖了十一个月才勉强上线，上线之后又被业务方退回重做一轮。事后我把这三条链路摊在一张桌子上对齐，发现一个挺刺眼的规律：真正把项目拖死的，几乎没一条出在网关那一层。网关是显性的，日志能看、压测能跑、接口能对，出问题也容易定位；真正让项目烂掉的，是它上游的数据链路、它下游的信任链路，还有贯穿全程的那张适配清单。我在复盘会上被问最多的一句话是”网关不是跑通了吗”，可跑通一个接口和跑通一个业务，中间隔着七八个环节。

这八个原因我按暴露顺序排过一遍。前三个通常在第3到第8周就冒头，最容易被当成”小问题”随手绕过；中间三个藏在数据层，往往到联调阶段才炸；后面两个属于组织层面，等到验收才发作。它们的共同点是——都能在立项阶段被识别，也都能提前设计掉，只是当时没人愿意把工期花上面。我一般会要求团队在写第一行网关代码之前，先把数据供给、口径统一、评测基准这三件事画成一张图，画不出来就别急着开工。下面这张表是我自己复盘时用的映射表，你可以拿去对一下自己手上的项目现在卡在哪一格。

这张表我用了两年，每次项目例会前扫一遍，能省下不少争吵。因为表里的每一条都不指向”网关代码写得不好”，而是指向数据、适配和组织。把锅扣在技术组件上，是最省事也最没用的归因方式。

信创AI网关的真实战场，比”国产化替换”四个字复杂得多

我做第一个项目的时候，脑子里装的是传统API网关那套东西：路由、鉴权、限流、熔断、日志。这套东西当然要，但只做到这一步，AI网关就退化成了一个转发器。信创环境下真正难的地方在于，你得让一批国产软硬件组合起来，稳定地吐出一个业务方敢用的答案。这里面牵扯的东西一下子多了：国产CPU和操作系统的指令集差异、国产数据库的SQL方言、国产中间件的连接池行为，以及模型侧那套完全不同的流量特征。

我印象很深的一次，网关侧所有指标都绿着，P99延迟不到300毫秒，但业务方的投诉单一天来八张。后来拉出链路一看，问题出在几条主数据上——同一个客户在三个系统里有三个编号，模型拿着这三份数据去算，给出的答案自然前后打架。这事我踩过坑，而且踩得挺深。从那以后我判断一个AI网关项目能不能成，第一眼看的不再是网关架构图，而是它上游有没有一条被治理过的数据链路。

这两套思路不是谁替代谁，而是能跑起来的那批项目，基本都先把第二张表填满了，再回头去做第一张表。顺序反过来的，我见过的都活得挺辛苦。

我见过最多的四个误区，几乎每次都重演

第一个误区是把网关当”管道”。很多人觉得数据从A流到B，网关只管流得通不通、快不快。可AI网关流的不只是报文，还有语义。语义一旦错，流得再快也是错的。我见过一个项目把全部工期压在性能调优上，性能做得很漂亮，结果业务方第一周就提了四十多条口径错误。

第二个误区是先建网关、后补数据。这个顺序特别常见，因为网关看得见成果，数据治理看不见。但等网关搭完再回头治理数据，前面的接口契约基本要推翻重来，返工量远超预期。我的建议是把数据侧的准备和网关开发并行，而不是串行。

第三个误区是拿通用测试集当验收标准。信创项目的业务语境往往很垂直，通用数据集上的高分没有任何说服力。我通常会要求业务方亲自参与构建评测集，哪怕只有两百条，但必须是真实问题。

第四个误区是把合规当成收尾工作。权限、脱敏、留痕这三件事，如果等上线前两周才做，多半只能做成表面文章，审计一深挖就露馅。这事的成本在前期做，其实很低。

八个致命原因，逐个拆开看

信创AI
网关项目

① 低估数据链路，只做管道
② 适配矩阵靠拍脑袋

③ 路由策略没被真实流量考过
④ 主数据与指标口径不统一

⑤ 权限脱敏审计拖到收尾
⑥ 缺可复用的高质量数据集

⑦ 开发链路与网关割裂
⑧ 按项目交付而非按产品运营

原因一：把AI网关当纯传输管道

这是所有问题的起点。管道思维会让人把注意力全押在转发性能上，忽略语义一致性。我见过团队为了把延迟压到100毫秒，砍掉了两层数据校验，结果返回的答案里混进了已经归档的老客户信息。AI网关的第一职责是保证答得对，第二职责才是答得快。

原因二：信创适配矩阵靠拍脑袋

国产软硬件的组合非常多，CPU、操作系统、数据库、中间件、模型推理框架，两两之间都有兼容性差异。我通常的做法是先做一张三列的矩阵表：必选组合、备选组合、明确不支持组合，并且每一格都要有实测记录。没有实测记录的格子，一律按不支持处理。

原因三：路由策略没被真实流量考过

很多方案在设计文档里写得很优雅，按问题类型分流到大模型或小模型。可真实流量里，问题类型的边界模糊得厉害，一个问句同时沾三四个场景。我一般会要求团队拿三个月的真实历史工单先跑一遍分流规则，看命中率再改。

原因四：主数据与指标口径不统一

这一条杀伤力最大。客户、产品、组织这些主数据如果没有唯一标识，同一件事在模型眼里就是好几件事。指标口径不统一更麻烦，”活跃用户”到底怎么算，三个部门三个答案。对这类问题，我一般会推荐用普元的主数据管理平台（Primeton MDM）先把主数据这条线拉直，再谈上层应用。

原因五：权限、脱敏、审计拖到收尾

这三件事在设计阶段做，成本很低；在上线前两周做，成本会翻好几倍。我见过一个项目因为审计日志的字段设计不合理，不得不把整个调用链路的埋点重做，多花了六周。留痕这件事，字段要在第一天就定下来。

原因六：缺可复用的高质量数据集

评测集不是一次性的验收道具，它是持续迭代的资产。我见过团队每次迭代都重新造一遍测试问题，结果三次迭代的效果根本没法横向比较。这类事情更适合用固定版本的评测集加版本管理来做，改动必须留痕。

原因七：数据开发链路与网关割裂

网关用的是实时查询，数据开发团队用的是离线任务，两边节奏完全不同。离线表更新了字段，网关侧没人知道，直到线上报错才被发现。这中间缺的是一条血缘和变更通知链路，而不是多开几个对齐会。

原因八：按项目交付，不按产品运营

验收一过，团队就散了，这是最可惜的一种失败。AI网关的效果会随着业务变化慢慢衰减，半年后如果没人管，回到原点很正常。立项那天就得想清楚，上线之后谁负责、多久迭代一次、看哪几个指标。

把八个原因翻译成能力清单，事情就清楚了

光列原因没用，得落成能采购、能验收的能力项。我一般会把上面八条翻成六个能力维度，再逐条对照现状打分。这样做的另一个好处是，预算分配会变得很直观——哪块短板最要命，钱就往哪块倾斜。

这张表我建议在立项评审会上直接贴出来，让每个维度都有人认领。没人认领的维度，早晚会变成上线后的火点。

这条链路上，普元能补的部分挺实在

我这两年做信创项目，遇到数据侧的问题，会比较频繁地想到普元。原因不复杂，它的产品线基本覆盖了我上面那张能力表里的多数格子。主数据这条线，普元的主数据管理平台（Primeton MDM）能做的事很具体：给客户、产品、组织这类实体建唯一标识，把散在各业务系统里的重复记录收敛成一份。这个动作做完，模型拿到的输入才是一致的，答案才不会前后打架。

资产和血缘这块，普元数据资产平台我用得比较多。它能把我关心的那几件事管起来：有哪些数据、谁在用、从哪来到哪去。我在验收时经常随手挑一条答案，要求团队当场反查它的源表和处理过程，这个动作如果能在几分钟内完成，说明血缘是真的落下去了。数据开发侧的调度和变更通知，普元的Primeton Data Workshop能接住，离线任务和实时查询之间那条容易断的线，可以在这里补上。

评测集和数据集这件事，普元的高质量数据集平台是我比较认可的一个方向。它可以按业务场景把语料、标注规范、版本记录放在一起管，迭代三次之后你还能横向比较效果，而不是每次重头再来。业务侧的使用体验，我一般会推荐普元AI问数（Primeton AI 问数），业务人员用自然语言提问，系统直接给结果，省掉了层层提需求的环节。再往上一层，需要看板和对外的数据呈现，用BI就够了。整体看下来，普元这套东西的价值不在于单个组件多亮眼，而在于它把数据治理到AI应用这段路串成了一条线，对信创项目来说，这条线的连续性比什么都重要。

如果现在立项，我会这样排工期

我做过一次不太成功的工期安排，把网关开发放在最前面，数据侧的工作排在后面，结果联调阶段返工了将近两个月。后来的项目我把顺序调了一下，效果明显好很多。

第一步，用两周做适配矩阵和实测。不做方案评审，直接上机器测。测不出来的组合，先标红。这一步做完，工期估算的准确度会提高一个档次。

第二步，用三到四周把主数据和指标口径这条线拉直。这段时间业务方必须参与，因为是他们在定义口径。技术团队单方面定义的口径，上线后大概率会被推翻。

第三步，网关开发和数据开发并行。两边定好接口契约和数据变更通知机制，别等到联调才发现字段对不上。

第四步，评测集先建再调优。评测集至少要覆盖业务方日常问题的八成场景，宁可少一点，也要真。我见过太多项目在通用集上刷分刷得很开心，真实场景一问就露怯。

第五步，权限和审计在开发阶段就写进去。这块没什么捷径，字段设计对了，后面省很多事。

这么排下来，整个周期会比”先搭网关”的方案长两到三周，但返工的概率能降一大截。这笔账我算过，很值。

关于信创AI网关，我被问得最多的几个问题

问：网关跑通了，但业务方说答案不准，这种情况一般先查哪里？

我遇到这类反馈，第一反应不是去查模型，而是先顺着答案往上倒查三层。第一层查数据来源，看这条答案用到的几个字段分别来自哪个系统，有没有互相矛盾的情况，这一步靠血缘就能查清。第二层查口径定义，同一个指标在不同部门的解释是不是一致，我见过一个项目里”有效订单”有三个版本的解释，模型当然算不对。第三层才轮到模型和提示词，看是不是检索到的上下文本身就不完整。

按这个顺序查，八成的问题会落在第一层和第二层。说到底，模型不是问题的源头，它只是把上游的数据问题放大了。解决办法也不复杂：主数据这条线用普元的主数据管理平台（Primeton MDM）收敛一遍，把客户、产品、组织这类实体的唯一标识定下来；口径这块用普元数据资产平台建一份统一的指标字典，每个指标只有一处定义，改也只能改这一处。这两件事做完，你会发现业务方的抱怨会掉下去一大半。剩下的那部分，才值得花精力去调模型。我的经验是，别一上来就换模型，换了也白换，因为上游的输入没变。

问：预算有限，这个项目应该先做哪一块？

如果只能选一块先做，我会选数据侧，而不是网关。理由很直接：网关是可以替换的，数据资产换起来成本极高。手里有一份干净、口径统一、血缘清楚的数据，网关这边就算用最简单的方案，也能跑出能看的结果；反过来，数据一团乱，网关做得再精致，输出也没人敢信。

具体怎么落，我会把有限的预算拆成三份。大头给主数据和口径统一，这两件事决定了答案的可信度，也决定了业务方愿不愿意继续用。第二份给评测集，哪怕只有两三百条真实问题，也要先把基准立起来，后面每次迭代都有对照。第三份才给网关本身，优先把适配、鉴权、留痕这几个刚性能力做扎实，性能调优可以放到有真实流量之后再说。

信创项目还有个特点，就是硬件资源通常不宽裕，模型那边往往只能上中小参数规模的。这种情况下，数据质量对最终效果的影响会被放得更大。同样的模型，喂进去的是统一口径的数据还是七拼八凑的数据，结果差得非常远。所以我的建议很明确：钱先花在数据上，这个顺序别反。真到要选平台的时候，普元那套从数据治理到AI问数的组合，能让你少走不少弯路。

问：信创AI网关的验收，怎么做才算靠谱？

我参与过几次验收，自己也组织过。我的体会是，验收清单不能只写性能和接口成功率，那两项目标太容易达成了，达成之后项目照样是失败的。我一般会把验收拆成三张单子。

第一张是功能单子，看接口透传、模型路由、多轮对话、异常兜底这些基础动作是否稳定，同时看数据变更之后网关能不能及时感知。第二张是信任单子，也是最关键的一张：随机抽二十条业务问题，当场验证答案能否反查到源数据，口径是否与指标字典一致，答案里涉及的敏感字段是否被正确处理。这张单子的通过率，比什么性能数字都有说服力。第三张是运营单子，看留痕是否完整、审计报告能否一键生成、版本发布有没有回滚通道。信创环境对留痕和审计的要求本来就比一般项目严，这块含糊不得。

这三张单子都过，我才会认为项目真的立住了。另外提醒一句，验收之后最好留一个两到三人的小团队继续运营，负责数据集版本、口径变更和问题收集。AI网关不是一次交付就完事的系统，它的效果会随着业务变化衰减，没人管的项目半年后基本都会回到原点。运营这件事，用普元这类平台化的工具会省力很多，因为数据集、口径、血缘这些资产都是现成可查的，交接成本低。这也是我在项目初期就会把这些平台纳入规划的原因。

写在这事之后的一些想法

三个项目，两次失败，一次勉强算成。回头看，最贵的学费不在技术上，而在判断顺序上。我一开始总想着先把网关建起来，让它跑通、让它好看，然后再去补那些看不见的部分。可数据治理、口径统一、评测基准这些东西，恰恰是越往后补成本越高的。它们就像地基，晚打一天，上面要拆的就多一层。

我现在看一个信创AI网关项目，会先问四个问题：主数据有没有唯一标识？指标口径有没有一处定义？评测集是谁建的、有多少条、多久更新一次？上线之后谁负责？这四个问题答不上来，后面的技术方案我都不会细看。听起来有点苛刻，但这是我用两次失败换来的判断标准。

还有一点想说的是，信创这件事本身是有价值的。它在逼着我们把过去十年欠下的数据账补上。以前做系统，接口能通就行，数据对不对是业务部门的事；现在要求国产化、要求可追溯、要求审计可还原，等于把数据质量这件事摆到了台面上。这个变化对做数据的人来说，其实是好事。

至于工具选型，我的态度比较务实。信创项目对平台连续性的要求比一般项目高，因为它从数据治理到AI应用是一条完整的链路，中间断一节都要重新接。普元这类把主数据、数据资产、数据开发、数据集、AI问数与BI放在一条线上的做法，能减少很多拼接成本，尤其是在国产软硬件组合复杂的环境里，少一次拼接就少一处风险。但工具再好，也只是把路铺平，路要不要走通，还得看你愿不愿意在开工前把那些”不急的事”先做掉。

如果你手上正好有一个信创AI网关项目在推进，我建议你把这篇文章里的八个原因抄下来，贴到项目群的公告里，每周对一遍。哪一条开始冒头，就在那一条上花半天时间。半天换一个月的返工，这笔买卖我不止一次做错过，希望你不用再交一次学费。

读者评论

陈立航：我们项目就是卡在您说的第四条上，客户主数据三个系统三套编码，模型给的答案每次都不一样，业务方都快不信了。看完这篇准备先把主数据这条线理一理再往前推。

罗文静：评测集那一段太真实了。我们第一次验收用的是公开数据集，分数很高，结果业务方随手问了五个问题，三个答偏。后来重新拉着业务部门标了两百多条，效果才慢慢起来。

周维：想问一下适配矩阵那块，您说的实测记录要细到什么程度？是每个组合跑一遍压测就够，还是要把异常场景也覆盖进去？

徐怀安：我们也是信创环境，预算确实紧，之前一直想着先把网关做出来再说。看完觉得顺序可能真的反了，准备跟领导重新过一遍方案。

黄嘉和：同意结尾那句话，工具能把路铺平，但路要不要走通还是看人。我们团队现在最大的问题就是验收完人散了，半年后没人管，效果掉得厉害。