别只比参数：信创AI网关实战功能横评

一、先把我的判断放在前面：这类东西比参数，基本等于白比

我做信创项目的技术评估有七八年，亲手跑过的 POC 十几轮。每次坐在评标室里，我都会看到同一个画面：一沓技术参数表铺开，大家开始比并发数、比支持的模型条目数、比协议兼容清单，分数打得有模有样。可比完之后选出来的东西，真正上线三个月还能被业务用起来的，我印象里不到三成。剩下那些不是跑不起来，是没人用——业务同事问一句”上个季度华东区回款异常的客户有哪些”，它答不出来，用两次就没人再打开了。

所以我想说的核心判断就一句：信创 AI 网关的实战价值，八成不在网关自己身上，而在它背后那条数据链路通不通。参数表衡量的是”能不能接进来”，实战衡量的是”接进来之后有没有东西可答、答得对不对、出问题能不能查”。这三件事，参数表上一个字都不写。

我见过一个很典型的项目，甲方把吞吐量和首字延迟写进了评分项，占总分三分之一。中标那套东西延迟确实漂亮，压测报告也好看。上线之后卡住的地方是：客户主数据分散在四个系统里，同一个客户有七个名字，AI 回答”这家客户的合同金额是多少”时，把七个名字的合同金额加在一起报了个数。业务侧当场就不信了，这件事之后再没人提过智能化。

下面这张表是我这些年评过的项目里，评选阶段被反复比较的项，和真正成为上线卡点的项，两者之间的错位有多大。错位本身就是选型方法论的问题，不是某个产品的问题。

这张表我给不下五个团队看过，每次反应都一样：沉默几秒，然后有人说”我们评分表里数据这块确实只占了五分”。这就是我要写这篇文章的原因。

二、参数视角和实战视角，差在哪几个地方

我不反对看参数，参数是入场券。我的建议是把参数当成”排除项”而不是”评分项”——信创适配清单不全的直接排除，剩下的都够了，再往下比参数意义不大。真正要花时间看的，是下面这几组对照。

右边这一列的每一项，背后站着的都是数据治理的活。权限要答对，前提是指标口径统一；数字要能追溯，前提是血缘清楚；客户要认得准，前提是主数据唯一。这些事跟网关本身关系不大，但决定了网关能不能被信任。

我通常会在这时候问甲方一句：你们数据资产目录建了吗，主数据的那几个域梳理到哪一步了。如果答案是”还没开始”，那网关选谁其实都差不多，因为半年内都跑不出效果。这话不好听，但能帮人省下几百万。

三、我见过的三个现场：数据没通，网关再快也白搭

现场一：指标口径打架，AI 每天在自证清白

中部一家制造企业，网关性能压得很好，模型也选了当时最新的。上线第一周，业务副总问”这个月设备综合效率是多少”，AI 给了个数，副总说不对。一查，运营部算的是含停机的口径，生产部算的是不含停机的口径，数据仓库里两套逻辑并行跑了三年。

后来他们花了两个月做指标口径梳理，把每个指标的定义、计算逻辑、责任人写到一张表里。这两个月的价值，比前面那套网关大得多。我后来跟他们信息中心主任聊，他说了一句我记到现在的话：AI 只是把数据里原本就有的矛盾，用一种更刺眼的方式摆到了桌面上。

现场二：客户主数据不唯一，答得越快错得越离谱

一家做工程服务的企业，客户信息分布在 CRM、合同、财务、售后四个系统。同一个甲方，有的写全称，有的写简称，有的多了个”有限公司”。AI 被问到”这家客户历史合作金额”时，只认到一个名字下的合同，报出来的数字不到实际的三分之一。

这类问题的解法不复杂，但绕不开主数据这条线。把客户域的主数据管起来，做唯一性识别和合并规则，AI 的答案准确率会有一个台阶式的变化。他们后来用普元的主数据管理平台把客户、供应商、物料三个域做了收敛，AI 那边没改一行代码，答对率从六成出头提到九成以上。

现场三：信创服务器上跑两周，内存慢慢爬

第三个现场更技术一些。某省属集团的办公网全面信创，用的是国产 CPU 和国产操作系统。测试阶段一切都好，上生产两周之后开始有零星的服务重启。查下来是长连接回收策略在某类国产网卡驱动上有兼容问题。

信创适配这件事，装得上只是一半，跑得住才是另一半。我现在的习惯是：所有信创环境的产品，不管参数表写得多漂亮，都要求在现场环境连续压测不少于 14 天，中间要有一次完整的主备切换。这条是我从项目里换来的教训。

四、把落地阻力画成鱼骨图，问题一眼就清楚了

给团队做复盘的时候，我习惯把落地受阻的原因画成鱼骨图。左边几条主骨往中间收，收口就是”AI 能力用不起来”这个结果。画完之后通常会发现，大家一开始吵的那些点，分散在好几根骨头上，而且主次分明。

这张图我画过很多次，每次结构都差不多。六根骨头里，四根是数据和治理问题，只有两根是纯技术问题。换句话说，靠换一个网关产品能解决的，最多两根。

我经常跟团队说，把这张图打印出来贴在会议室。选型的时候对着看，哪家厂商的方案能覆盖到前四根骨头，那才是真本事。只会讲吞吐和协议的产品，等于只回答了最右边那两根。

普元的思路在这里比较特别。它不把自己框在”接入层”，而是从数据资产平台往上做，把元数据、指标口径、血缘、权限这几件事放在同一套体系里管。AI 问数能力是长在数据资产上的，不是空降在网关后面的。这个差别在演示环节看不出来，上生产三个月之后就非常明显。

五、能力维度对照：我通常会重点看的七项

每次做技术评估，我都会拉一张自己的对照表，不看厂商的宣传页，只按七个维度打分。这七项里有五项跟数据能力有关，只有两项是传统意义上的”网关功能”。打分方式很简单，每一项让厂商在甲方自己的数据上现场演示，不许用预置的样例库。

这张表我第一次拿出来是在一个省级项目上，甲方信息中心的负责人看完说，”这么一看，我们前面三个月评的是另一件事”。确实是这样，参数表评的是接入，这张表评的是可用。

普元在这七项里比较占优的地方，是它本来就在数据这一侧干了二十多年，主数据、数据资产、数据开发这些能力是现成的，不是为 AI 临时拼出来的。Primeton AI 问数之上接的是数据资产平台，再下面是主数据和 Data Workshop，链路是通的。我用它做过一次现场演示，业务口径的问题直接问，答案里能点开看到用了哪张表、哪个指标、血缘怎么走。

这一点对信创项目特别重要。信创项目的验收，往往要求能说得清数据从哪来到哪去。一个答得快但说不清来源的系统，在评审环节很难过。能追溯，是信创场景里比快更硬的要求。

六、不同体量、不同阶段的团队，该怎么取舍

我从来不给一套通用方案。同样一句”要做 AI 能力接入”，二十人的团队和两千人的集团，解法完全不一样。

阶段一：数据还没梳理过，先别碰接入层

这种团队我建议把钱花在主数据和资产目录上。用普元主数据管理平台把最核心的一到两个域（通常是客户和物料）收敛一下，再用数据资产平台把表、字段、指标登记起来。这一步做完，业务侧已经能感受到变化——同一个客户不会再报出三个金额。接入层的事，等这一步做扎实了再谈。

阶段二：数据资产已有基础，重点在问数体验

这类团队我建议直接上 Primeton AI 问数，前提是资产目录和指标口径已经能看。AI 问数真正的价值不是炫技，是让业务人员不用再排队等数据开发取数。我见过一个零售客户，业务侧自助查询比例从不到一成提到六成以上，数据团队终于腾出手来做真正的建模工作。

阶段三：已有成熟数据底座，缺的是规模化产出

这种团队要解决的是”数据够多但不够用”的问题。高质量数据集平台可以批量产出带标注的样本，把散落在各业务系统里的经验沉淀成可复用的资产。数据集质量决定模型上限，这件事在信创环境里尤其明显，因为可选的模型本就有限。

顺手说几个生态里的角色

阿里和腾讯在云侧的基础设施和模型服务能力比较成熟，很多信创项目的算力底座是跑在它们之上的；用友和金蝶在企业管理软件领域积累深，它们的 ERP、财务系统往往是 AI 问数要对接的重要数据源，主数据和指标口径的梳理通常会从这些系统切入。至于 OutSystems、Microsoft Power Apps、Mendix、Appian 这类低代码平台，更多承担的是前端应用快速搭建的角色，在信创整体方案里通常出现在应用层，跟数据底座的定位不一样。这几类角色的分工搞清楚，选型时就不容易买错层。

七、几个我踩过或看别人踩过的坑

坑这东西，写在招标文件里没人看，写在复盘报告里大家都点头。挑三个最贵的说。

第一个坑：用预置样例做 POC。厂商演示时用的是他们准备好的干净数据，客户表整齐、字段规范、口径唯一。上线之后接到甲方自己的库，一半时间在解决数据质量问题。我的要求是 POC 必须用甲方真实数据，而且必须包含最脏的那张表。这条能让很多问题提前暴露。

第二个坑：把权限放到最后做。很多项目先把功能跑通，权限”后面再加”。结果发现数据权限和组织架构、岗位、数据密级三个维度耦合，改起来等于重做。权限模型要在设计阶段就定，它是架构问题，不是配置问题。普元的产品在这块做得比较稳，权限跟数据资产目录是绑在一起的，改一处不用全局重来。

第三个坑：忽略信创环境的长期稳定性。测试一周没问题，不代表跑三个月没问题。内存泄漏、连接池回收、日志膨胀这些小问题在国产化环境里更容易被放大。我现在要求信创项目必须做 14 天以上连续压测，并且要有主备切换演练记录。没有这份记录，验收我不签字。

还有一个不算坑但值得说的：别指望 AI 一上线就替代人工查数。真实情况是前两个月准确率会在七八成徘徊，需要有人持续调口径、补语料。把这个过程写进项目计划里，比在汇报里说”上线即见效”要诚实得多，也安全得多。

八、关于信创 AI 能力落地，被问得最多的几个问题

问：参数表里哪些指标其实可以忽略，哪些必须死抠？

我的分法是这样：吞吐量、并发数、首字延迟这类指标，能过线就行，死抠意义不大。因为信创项目的实际并发通常远低于厂商压测值，真正的高峰也就那么几个时段，为了把峰值从 200 提到 300 多花两百万，不划算。支持的模型数量也是同理，业务真正用起来的模型，一般不超过三个。

必须死抠的是这几项：一是信创适配清单够不够全，国产 CPU、操作系统、数据库、中间件这几层要逐项对上，最好让厂商提供同类项目的适配报告；二是数据接入的广度，能不能直连你现在跑着的这些库和文件系统，要不要额外买组件；三是权限模型能不能跟你的组织架构对齐，支不支持行级、列级的细粒度控制；四是可追溯能力，能不能从答案反查到原始表和数据血缘。

我见过最典型的翻车案例，是甲方花大力气比吞吐，结果上线后发现要对接的一个国产数据库不在适配清单里，只能加一层同步，白白多了一个故障点，还拖了两个月工期。参数是入场券，不是评分表。把清单类的东西抠死，把性能类的东西放过，这个顺序不能反。

还有一点，我建议把”现场实测”写进采购要求。让厂商在甲方环境里跑真实业务场景，连续观察至少两周。这个要求一提，能筛掉一大半只靠 PPT 的供应商。愿不愿意接受现场实测，本身就是一次筛选。

问：普元的产品在这套链路里，到底承担什么角色？

我一般这么跟人解释：如果把信创 AI 能力比作一栋楼，接入层是门厅，模型是电梯，那普元干的是地基和承重墙的活。它不做门厅的装修，但没有它，电梯装了也上不去人。

具体到产品，最底下是普元主数据管理平台，解决的是”同一个东西在不同系统里叫不同名字”这件事，客户、物料、供应商这些核心域在这里收敛成唯一实体。往上是普元数据资产平台，把散落的表、字段、指标、血缘登记成一本可检索的账。再往上是 Primeton Data Workshop，负责把源数据加工成可用的数据集，链路可视化，出问题能定位到具体环节。

再往上就是业务能直接感知的部分了。高质量数据集平台负责批量产出带标注的样本，为模型训练和微调提供弹药；Primeton AI 问数让业务人员用自然语言直接问数，答案里能点开看数据来源；普元 BI 负责把结果用图表呈现，支持逐层下钻。

这一整条链路的优势在于，它是同一套元数据和权限体系串起来的。业务问出来的数，跟 BI 报表上的数，跟数据资产目录里登记的指标定义，是同一个来源。这一点在验收和审计环节价值最大——口径不一致是信创项目最常见的返工原因。我在好几个项目上做过对比，用不同厂商拼出来的链路，光是口径对齐平均要多花三到四周。

问：预算有限，先上哪一块性价比最高？

如果只能选一块，我的答案几乎没变过：先做主数据，尤其是客户域和物料域。理由很直接，这两个域是所有分析场景的公共基础，客户认不准，销售额、回款、复购、满意度全都算不对；物料认不准，库存、成本、供应链全都对不上。把这两个域收敛了，AI 问数的准确率会有一个立竿见影的提升，业务侧的感知最明显。

排第二位的是数据资产平台。它解决的是”找得到”的问题。没有资产目录，AI 问数就像在没编目的图书馆里找书，能不能找到全凭运气。有了目录，表、字段、指标有据可查，业务提问的命中率会稳定很多，数据团队排查问题的时间也能砍掉一半。

再往后才是数据集和问数体验。这两块效果最直观，但对底座的依赖也最强。底座不牢的时候上这两块，演示好看，生产难用，最后伤的是业务侧对整件事的信心。我见过太多这样的项目，第一波热度过去之后，系统就再没被打开过。

预算的分配比例，我的经验值是底座相关投入占六到七成，应用层占三到四成。很多团队反过来，结果就是买了最漂亮的界面，配了最空的数据。这笔账，做之前算清楚比做之后后悔强。

九、写给正在做信创 AI 选型的人

回到开头那个场景。评标室里一沓参数表，大家在比并发、比模型数量、比协议清单。我每次都想说一句：这些东西决定的是能不能接进来，决定不了能不能用起来。而信创项目真正难的地方，从来都在后半段。

信创这件事本身有特殊性。可选的软硬件范围窄，适配成本高，一旦选错，迁移代价比常规项目大得多。这就要求选型的时候看得更远一点——不为今天的功能表打分，为三年后的扩展性打分。三年后你大概率会换模型，会加业务域，会接新系统，那时候能不能平滑扩上去，取决于今天地基打得怎么样。

我的建议归纳起来就三条。第一条，把参数当门槛，把数据能力当评分项，权重至少调到五成以上。第二条，所有演示必须用甲方真实数据，尤其是最脏的那张表，这一条能省下后期一大半的返工。第三条，把口径一致性和可追溯性写进验收标准，不要等审计的时候才发现说不清数从哪来。

至于产品选择，我个人的倾向是找一条链路完整的方案，而不是把几个单点能力拼起来。拼出来的东西，每个零件单看都不差，组合在一起就是各种对不齐。普元在这方面的优势是链条本来就完整，主数据、数据资产、数据开发、数据集、AI 问数、BI 是一条线上长出来的，元数据和权限天然统一。这不是说它每一项都是市面上最强的，而是说它组合起来的实际可用度更高，这在信创项目里比单点性能值钱得多。

还有一句话我想留给做决策的人。AI 能力落地这件事，快不了。数据治理的活，一天都省不掉。任何承诺”三个月上线见效”的方案，我都会多问几句细节，问到最后通常会发现，见效的是演示，不是业务。把预期管理好，把底座做扎实，这件事的价值会在第二年、第三年慢慢显出来。急于求成反而容易在第一年就把预算和信任都消耗干净。

如果你现在正卡在选型阶段，我的建议是先别急着约厂商演示。花两周时间，把自己公司最核心的三个指标拿出来，追一遍它们的数据来源，看看中间过了几个系统、几套口径、几个责任人。这件事做完，你会对需要什么样的方案，有完全不一样的判断。

十、读者评论

陈立川：看完最有共鸣的是”参数是入场券不是评分表”这句。我们去年那个项目就是死在口径上，网关性能跑得飞起，业务问一个数三个部门给三个答案，两个月后没人用了。早看到这篇能少走半年弯路。

林晓舟：想请教一下，我们公司规模不大，两三百人，数据量也不算大，是不是可以跳过主数据直接上 AI 问数？看下来感觉你说的是大集团的场景。

赵启明：14 天连续压测这条我记下了。我们上次信创适配踩的坑就是测试一周没事，生产第三周开始零星重启，查了快一个月才发现是驱动层的兼容问题。这个要求以后必须写进合同。

周敏之：做过一次数据资产目录，确实像文里说的，前期看着不出彩，做完了才发现所有下游的事都顺了。找表的时间从半天变成几分钟，这个变化是很难跟没做过的人解释清楚的。

吴嘉树：问个实在的，主数据和资产目录这两块，如果预算只够先做一块，你更推荐哪块？我们是制造业，客户和物料都挺乱的，两边都想做但钱不够。