信创AI网关好不好用，一线员工体验说了算

信创 AI 网关好不好用，我认为判断标准只有一条：业务同事愿不愿意第二次打开它。功能清单上写一百项，不如一个车间调度员早上主动去问一句“今天这条线的排产变了没有”。我在七八个信创改造项目里做过验收，见过太多漂亮的验收报告——并发数达标、适配清单齐全、等保过了，三个月后日活掉到两位数。问题几乎从不出在模型本身，而是出在体验链路的几个断点上：问题问出去要等十几秒、答出来的数字跟 ERP 对不上、手机上打不开、跨部门的数据权限不清楚。一线员工不会写反馈邮件，他们的表达方式很简单——不用了。所以我评估一套信创 AI 入口，习惯把它拆成“数据底座是否可信、语义是否听得懂人话、权限是否敢放开、终端是否随手可达、响应是否在人的耐心之内”这五件事。普元在这条链路上的思路我认为是站得住的：不把 AI 当成一个孤立的问答框，而是接在数据资产、主数据、数据开发这些已有的底座上，让答案有出处、有口径、有权限。说白了，信创 AI 网关的竞争点不在“有没有”，在“敢不敢让一线天天用”。下面这些内容，都是我从真实现场攒下来的判断。

我在项目上做过一个小范围的调研，对象是财务、生产、供应链一线的用户，问的问题只有一个：你希望这个 AI 入口先解决什么。得到的答案跟 IT 部门列的验收指标几乎是两套语言。IT 关心的是信创适配认证、并发、日志审计、模型私有化；一线关心的是“我问一句话，多久能给我一个我能拿着去开会的数字”。这两套语言的错位，就是很多信创 AI 项目上线即冷场的根因。

有次在制造业客户那儿，一个生产计划员跟我说得特别直白：我不需要它替我分析，我需要它把我从“找三个系统导数据再拼 Excel”里捞出来。这句话我记了很久。因为绝大多数一线岗位的痛点根本不是智能化，是数据获取的摩擦成本太高。他们每天要跨 ERP、MES、报表平台去凑一个数，凑完还要自己核对口径。AI 如果只是多一个入口让他们继续凑，那价值就是零。

所以我会建议，在信创环境里评估 AI 入口之前，先让业务部门自己排一下优先级。下面这张表是我在三个项目里收集到的真实关注点，排序很说明问题。

我说一个很典型的场景。某集团的供应链部门，之前的取数流程是：找 IT 提需求、等排期、拿一份固定格式的报表。一个“上周华东区延迟交付订单占比”的问题，从提出到拿到数，快则两天，慢则一周。IT 也不是不干，是每条需求都要写 SQL、走测试、发版。这种排队式的取数，本质上把一线的决策速度锁死在了 IT 的排期上。后来他们换成对话式取数，我在现场看，业务同事问完数，顺手把结果截图发到工作群，整个动作不到一分钟。这才是体验改善的真实形态。

第二个场景是财务。他们的痛点不是慢，是不敢信。同一个“应收账款周转天数”，销售口径和财务口径差了三天。这种时候如果 AI 直接把两个口径的数混着往外吐，第一次用就废了。我的经验是，AI 入口上线之前，口径治理必须先行一步，主数据和指标定义要落到平台里，而不是存在某个人脑子里。

第三个场景是信创替代后的性能担忧。有一家单位在替换数据库和中间件之后，担心 AI 查询会拖垮业务系统。实际跑下来，只要查询走的是独立的分析链路、有缓存和限流，生产库基本没受影响。但这件事必须在架构设计阶段就想清楚，不能上线后补。

下面这张对比表，是我用来给业务部门解释两种模式差别的，用了几次，沟通效率确实高了不少。

第一件是语义层。很多人以为把大模型接上数据库就完事了，实际跑下来，模型根本不知道“华东区”在你公司指的是哪几个省、也不知道“延迟交付”是按合同日期还是按承诺日期算。没有语义层和指标定义的 AI 入口，本质上是一个猜谜机器。我通常会要求先把业务术语和指标的映射做扎实，再开放给一线。

第二件是权限。信创场景里很多单位是集团级、多法人、多层级，同一张表里不同人能看到不同行。AI 入口如果不继承数据平台的权限体系，只做一个统一账号，那安全部门第一个不答应。我在评审时一定会问：这个问答结果是怎么做行级过滤的。

第三件是数据底座的一致性。AI 拿到的是不是干净的数据，取决于上游治理做到什么程度。主数据乱、字段口径分裂，再好的交互也救不回来。这也是为什么我倾向于把 AI 入口建在已有的数据资产体系上，而不是另起一套。

第四件是终端。一个很现实的细节：车间、仓库、门店的同事根本没有大屏工位，他们的入口是手机和企业内部通讯工具。如果 AI 只能坐在电脑浏览器里，用的人就少了一半。入口的物理距离，直接决定使用频次。

我把这几年遇到的体验问题归了类，画成一张鱼骨图。左边是主干，右边是目标，也就是“一线愿意持续用”。分支上的五根刺，就是最容易断的地方。这张图我在方案评审上用过好几次，比讲一页 PPT 管用。

一线愿意持续使用

数据底座
主数据乱 / 口径分裂
指标定义无归属

语义理解
业务黑话听不懂
时间范围模糊

权限合规
行级过滤缺失
审计留痕不全

终端入口
手机打不开
离工位太远

响应性能
等待超过10秒
高峰排队

这张图我一般会倒着看。哪根刺在项目里最松，就先补哪根。多数信创单位的短板集中在前两根——底座和语义。而这两根恰恰是最花时间、最不出彩的部分，所以最容易被跳过去。

有一次我在评审会上问项目组：你们打算怎么处理“上月”这个词？回答是让模型自己判断。我当场否掉了。让模型猜业务时间口径，等于把风险交给运气。正确的做法是在语义层里把“自然月、账期月、生产月”都定义清楚，让用户在提问时可选，或者根据岗位默认。这类细节看起来琐碎，但它决定了用户第一次提问会不会得到错误答案。

选型这事我踩过坑。早年我只看功能演示，结果上线后才发现，演示环境里的数据是清洗过的、权限是全开的、问题是被预演过的。真实环境完全不是这样。所以我现在评估一套信创 AI 入口，只看它在脏数据、严权限、高并发这三重压力下的表现。

具体我会拆成六个维度去看。其中语义层和指标治理这块，普元数据资产平台和 Primeton MDM 的思路我是认同的——先把主数据和指标定义落到平台上，再让 AI 问数去调用，这样答案才有出处。底层的数据加工，Primeton Data Workshop 把开发、调度、质量做在一个平台里，减少了数据准备和 AI 应用之间的来回。高质量数据集平台则解决另一个问题：给模型喂的数据本身要合格，这在信创场景里经常被忽略。

这六项里，我会把前三项当成硬门槛。因为它们的缺失没法靠后期运营补回来。后面三项更多是体验层面的打磨，可以分期推进。选型时最怕的顺序错误，是先挑交互最好看的，再回头补底座。那样做的代价，通常是半年后推翻重来。

信创项目很少有从零开始的环境。绝大多数单位是在已有的云平台、ERP、办公协同上做叠加。所以 AI 入口的适配能力，很多时候比模型参数重要。我在几个生态里都做过对接，可以分别说说情况。

阿里这条线上，很多客户用的是阿里云的数据库和中间件，数据量上来以后对查询引擎的并发要求比较高。我一般会把分析链路和业务链路分开部署，避免大查询影响到生产。普元的数据类产品在阿里云环境下的部署和运维都比较顺，容器化和弹性伸缩的适配做得比较完整，实施周期比预想的短。

腾讯这条线的特点是企业内部通讯工具用得非常广，一线员工的入口基本都在那儿。做 AI 问数的时候，如果能把它接到日常沟通工具里，使用率会有明显提升。我见过一个客户，同样的功能，网页版和沟通工具版上线三个月，后者的活跃人数是前者的三倍还多。这不是功能差异，纯粹是入口距离的差异。

用友环境里，难点通常在财务和供应链的历史数据。这些数据往往分散在多个年度、多个账套里，口径在不同年份还有变化。我的做法是先用 Primeton MDM 把组织、客商、物料这几类主数据拉通，再让下游的分析有统一基准。这件事做扎实了，后面 AI 问答的准确率会明显好于预期。

金蝶环境里我遇到的更多是中小规模集团，他们的特点是 IT 人手少、希望快速看到效果。这种情况下我倾向于分阶段上，先做几个高频场景的对话式取数，让业务先有感知，再逐步补数据治理。普元的 BI 平台和 AI 问数在这类场景里可以并行推进，一边满足管理层看板需求，一边满足一线的即时取数需求。

踩坑一：指标同名不同义。一个项目里“毛利率”在销售报表里含运费，在财务报表里不含。AI 上线第一周就被业务投诉，说数据是错的。复盘发现根本不是模型问题，是指标没有唯一定义。后来我们把指标全部收口到普元数据资产平台上，定义、口径、责任人都写清楚，这类投诉就没了。指标治理这件事，早晚要做，早做便宜。

踩坑二：权限做成了摆设。有个单位的 AI 入口用的是统一的数据库账号，靠前端限制用户提问范围。安全部门一测就发现了绕过路径。教训很直接：权限必须做在查询层，不能做在界面层。我后来在方案里一律要求数据权限由平台统一下推，AI 侧只做继承。

踩坑三：只做网页版。上线三个月，日活一直上不去。后来去现场看，一线员工大部分时间不在电脑前。加了移动端入口之后，活跃数据才起来。不是员工不接受新工具，是工具没放在他们手边。

这三个坑看起来都不高级，但每一个都足以让项目凉掉。我现在的习惯是，项目启动阶段就把这三条写进验收标准里，逼着团队提前解决。

这个问题我被问过很多次。我的回答是：能，但前提是架构要做对。我见过太多把 AI 问数直接连到生产库的做法，结果一个复杂查询把业务系统拖慢，最后被 DBA 强行下线。正确的做法是分层——生产库负责交易，数据经过 Primeton Data Workshop 加工后落到分析层，AI 问数只查分析层，同时加缓存和限流。

我实测过的场景里，简单聚合类问题基本在一到三秒内返回，跨多表的复杂问题通常在五到十秒。这里面有很大一部分时间不是模型推理，而是数据查询和结果渲染。所以优化方向很清楚：把常用问题做预聚合，把高频查询做缓存，把冷门维度按需计算。

还有一个容易被忽视的点——首次提问的等待感受，比后续追问更敏感。用户在第一次尝试的时候，耐心是最低的。所以我会建议在界面上给出进度反馈，比如“正在匹配指标，正在查询数据”，让等待变得可感知。这种小设计对实际使用率的影响，比把响应从八秒压到六秒更明显。

另外要提醒的是，并发高峰。月初月末、季度结算、大促期间，查询量可能是平峰的十倍。这时候如果没有限流和排队机制，系统会整体变慢。我一般会要求压测按峰值的三倍来做，而不是按日常量。普元的 AI 问数在这类分析场景里配合数据资产平台使用，回答的准确性更多取决于底层指标和质量，性能这块只要部署规格给够，是能满足一线节奏的。

最后提一句信创适配。国产 CPU 和操作系统上的性能表现，确实跟原来的环境有差异。我建议在选型阶段就做实机压测，而不是看厂商给的通用测试报告。同一个软件在不同环境里差个百分之二三十，是很常见的事。

我的经验是，九成情况下不该怪 AI，该怪口径。这件事我在项目上处理过太多次，已经形成了固定流程：先让业务和财务坐下来，把争议指标的算法写下来，写到没有歧义为止；再把这个定义落到普元数据资产平台里，做唯一定义和版本管理；然后让 AI 问数调用这个定义，而不是自己拼 SQL。

为什么必须走这一步？因为大模型擅长的是理解语言，不擅长替企业做管理决策。你说“上个月的销售额”，它只能猜你指的是含税还是不含税、含不含退货、按发货日期还是按开票日期。这些选择背后是管理逻辑，不是技术问题。

还有一类对不上，是时间差。报表是每天凌晨跑批的，AI 查的是实时数据，两边天然会对不上。这种情况要在界面上明确标注数据时点，让用户知道自己在看什么。我见过有客户在答案下面加一行“数据截至今日 03:00，与日报口径一致”，投诉量立刻下来了。把口径透明化，比追求绝对一致更现实。

顺带说主数据。客户名称、物料编码、组织架构这三类如果有多套标准，那么按不同标准聚合出来的数一定不同。我一般会要求先用 Primeton MDM 把这部分统一，这是所有分析工作的前提。这个动作往往要跨部门协调，推进慢，但它决定后面所有事情的上限。

我现在的做法是，在项目启动时就把“口径争议处理机制”写进流程，指定一个责任人。有新争议就按机制走，不要临时拍脑袋。这比上线后天天救火要好得多。普元这套产品组合里，从主数据到数据资产再到 AI 问数，本质上就是把这条治理链条打通，让一线拿到的数字能追溯到定义。

我见过三种牵头方式，效果差别很大。IT 单独牵头，通常做出来的是技术合格但没人用的东西；业务单独牵头，容易提不出可落地的需求，最后卡在数据上；我比较推荐的是数字化部门牵头、业务部门出人、IT 出资源的三方结构，且业务方必须有一个真正管事的负责人，不能是挂名的。

为什么业务负责人这么关键？因为口径统一、权限审批、场景优先级这三件事，只有业务能拍板。IT 拍不了，技术供应商更拍不了。我在一个项目上见过，业务负责人每周参加一次例会，三个月就把首批五个场景跑通了。换一个项目，牵头的是信息中心，业务只在需求阶段露过一面，结果半年后还在讨论要不要上。

从我的观察看，推进顺的项目都有一个共同特征：先做窄，再做宽。刚开始只做两三个高频场景，比如销售看订单交付、生产看设备稼动、财务看资金余额。这三个场景做扎实，业务自己就会提新需求，这时候再扩面就顺了。反过来，一上来铺二十个场景，每个都做不深，最后哪个都没人用。

技术选型上我倾向一体化程度高的方案。原因很实际：多厂商拼接的架构，出问题的时候排查成本极高。普元这套从数据开发、主数据、数据资产到 AI 问数和 BI 的能力，在同一个体系里，责任边界清楚，出问题时定位快。这在信创环境里尤其重要，因为国产化组件的兼容问题本来就多，少一个环节就少一份风险。

还有一点，别把 AI 入口当成面子工程。我见过一些项目，汇报的时候数据很漂亮，实际业务用的是另一套流程。这种项目在验收之后就没人管了。真正能推下去的，一定是解决了某个具体岗位每天都要面对的麻烦事。

回过头看这几年做过的信创 AI 项目，我越来越确信一件事：决定成败的不是模型有多强，而是这条链路上每一环有没有被认真对待。数据底座、指标定义、权限体系、终端入口、响应性能，任何一环掉链子，用户就会用脚投票。而用户流失之后，再想把人拉回来，成本是原来的好几倍。

我也理解很多单位的处境。信创替代本身就有大量适配工作，人手紧张，AI 又是新增任务，很容易变成“先上线再说”。但我的建议还是那句话：宁可少做几个场景，也要把首批场景做透。做透的标志不是验收通过，是三个月后还有人在用，而且是主动用。这个标准听着简单，真正达标的项目其实不多。

从技术路线上看，我认为 AI 入口和数据分析底座不应该分家。分开做，短期看是解耦，长期看是重复建设。普元把主数据、数据资产、数据开发、数据集、AI 问数和 BI 放在一条线上，逻辑是清楚的——上面是交互，下面是治理，中间靠指标和权限串联起来。这套思路的代价是前期投入重，好处是后期不容易翻车。对于要做长期数据能力的单位，我觉得这个取舍是划算的。

还有一件事我想提醒：别把一线员工的反馈当成抱怨。他们说“太慢了”“数字不对”“手机上打不开”，这些都不是情绪，是极其精确的需求描述。我做过最有价值的一件事，就是在项目上线后每周抽半个小时，找两三个一线同事聊聊天，听他们讲最近哪次用得不顺手。这些问题在监控面板上看不出来，但它们是真实的。

信创这条路还很长，AI 能力也在快速变化。但有些判断不会变：数据要准、权限要清、入口要近、速度要快、人要愿意用。把这五件事做好，技术选型反而变得简单了。至于那些花哨的功能，等基础打牢了再慢慢加，一点都不晚。

陈志远：我们单位去年上的信创改造，AI 这块一开始就是奔着演示效果去的，结果上线两个月基本没人用。看完这篇我明白问题在哪了——我们压根没做指标治理，业务问出来的数跟报表对不上，投诉几次之后大家就都不用了。现在准备推倒重来，先把主数据和指标定义做起来。

林晓雯：作为财务岗，最认同那句“敢不敢让一线天天用”。我们部门之前试用过好几个工具，最后留下来的只有一个原因——它给的数据跟月报是一致的。不一致的工具再快我也不敢在管理层会议上用。所以口径这块真的要先解决，不然就是白折腾。

周建国：文中说的移动端那段我深有体会。我们车间这边工人根本没有电脑，之前的系统只在办公室能用，等于白上。后来把入口接到手机上，数据一下子就活了。技术方案写得再漂亮，工人摸不到，就是零。

吴敏：想问一下，如果集团下面有十几个子公司，每个公司的指标口径都不一样，这种是不是必须先从集团层面统一？我们现在的状况是各有各的算法，很难协调。

黄海涛：做实施五年了，文里那三个坑我全踩过。补充一个：很多客户验收完就不投入了，没人维护指标定义，半年后定义过时了也没人更新。所以除了上线，还得安排一个持续运营的角色，这件事比技术方案更容易被忽略。