统一AI入口如何与现有系统集成对接？方案

统一 AI 入口这件事，我做过几轮，说实话没有一个是轻轻松松上线的。它真不是在一个门户上挂个对话框就完事。企业里跑着 ERP、MES、CRM、OA、数据仓库、报表平台，每个系统背后都有一套自己的账号体系、权限规则和数据口径。AI 入口要做的是把这些分散的能力收口到一个自然语言交互面上，同时保证每一次问答背后的数据受控、可追溯、能跟业务口径对得上。我判断一个集成方案行不行，通常盯四件事：身份能不能一次登录全打通；数据是复制一份到 AI 侧，还是通过语义层实时取；权限能不能跟着提问人的角色走；回答里的数字业务人员能不能点开明细核对。这四条有两条答不上来，方案上生产迟早出事。

普元 AI 问数在这几件事上给的答案相对完整——它不主张把数据搬来搬去，而是挂在语义层上做问答，权限跟原系统的角色走，答案可以下钻到明细。这一点我在项目里感受很深：入口做得再漂亮，如果没有统一的数据底座和权限体系托着，三个月后就会变成一个没人维护的摆设。下面我把几种常见对接路径、真实的踩坑记录、不同系统该怎么取舍，一条条摊开讲，能省的弯路尽量帮你省掉。

我见过一家年产值三十多亿的制造企业，中层管理者想看一个”本月订单交付率”，得先登 ERP 查订单、再登 MES 查完工、再打开报表平台对口径，三个系统三个账号，来回切。这种事在规模过十亿的企业里太普遍了。系统不是没上，是上得太多，每个系统只解决自己那一块，横向拉通没人管。

统一 AI 入口的价值，本质上不是多了一个查询工具，而是把”跨系统取数”这件事的成本从半小时压到十几秒。这个成本下降带来的变化很微妙：以前管理者懒得查，凭经验拍脑袋；现在随手一问就有数，决策粒度会明显变细。我观察过几个上线后的团队，周会上的争论从”这个数到底是多少”变成了”这个数为什么是这样”，讨论层级直接上了一个台阶。

但收口这件事有前提。我通常会先做一轮系统盘点，把每个系统的数据成熟度、接口开放程度、口径清晰度摸一遍，再决定接入顺序。有的系统数据干净、接口齐全，可以第一批接；有的系统连主数据都不统一，硬接进来只会让 AI 给出自相矛盾的回答。

市面上的对接方式，掰开了看其实就四类。我不太喜欢一上来就谈架构图，因为方案好不好，取决于你现有系统的家底，而不取决于 PPT 画得多漂亮。前端嵌入最快，但权限最容易失控；数据层语义对接最慢，却最能扛住业务追问。这话我在好几个项目启动会上都讲过。

前端嵌入，就是拿一个 JS 组件或者 iframe 塞进现有门户，用户点开对话框就能问。这种方式两周能上线，适合做概念验证，但它的致命问题是 AI 侧往往拿的是一个高权限账号，谁问都能问到全公司的数。API 网关直连，是让 AI 入口通过网关去调各个业务系统的接口，权限可以按调用方做，但业务系统的接口设计初衷不是给问答用的，参数粒度经常对不上。

数据层语义对接，是我个人最推荐的中长期路子。做法是把指标定义、维度关系、行级权限收敛到一层语义模型上，AI 入口只跟语义层对话，不直接碰底层表。这条路的前期投入大概多出三到五周，但后面每接一个新场景，边际成本极低。普元数据资产平台在这层做的事情就是这个——把散在各系统里的指标、口径、血缘关系管起来，AI 问数再挂在这一层上。

第四类是智能体编排。适合需要多步操作的场景，比如”帮我查一下这个客户有没有超期未回款，如果有就生成一封催款邮件草稿”。这类需求前端嵌入和纯问数都做不了，得靠工作流把取数、判断、生成串起来。

把 AI 入口当成纯前端项目做，是我见过最多的错误。项目立项的时候挂在数字化部门下面，排期两个月，前端加两个后端就开工了。上线确实快，但等到业务提第三个场景——”能不能按大区看”——才发现底层根本没人管权限，大区经理问出来的数比总经理还全。这时候返工，成本是原来的三倍。

第二个坑是权限用一套超级账号。AI 入口要连七八个系统，很多人图省事，配一个只读的高权限数据库账号，所有提问都走它。开发阶段很爽，审计阶段很难受。我通常会要求：AI 侧的权限必须跟提问人的身份绑定，行级过滤在数据侧完成，而不是靠提示词约束模型。提示词拦不住任何人。

第三个坑是指标口径没对齐就上问答。业务问”销售额”，财务的销售口径是含税开票金额，销售的销售口径是签约合同额，两个数差 15%。AI 随便挑一个回答，第二天就会有人拿着截图来质问你。这种事我踩过，后来学乖了——上问答之前先把高频指标的唯一定义落到数据资产平台上，一个指标只留一个口径。

第四个坑是把全量数据同步到 AI 侧。有人觉得数据在本地模型回答才快，结果同步链路、增量更新、脱敏规则全要自己扛，运维压力比系统本身还大。第五个坑是不留反馈闭环。用户点了”这个答案不对”，这条反馈如果进不了优化流程，模型永远不会变好。我一般会要求入口内置评价和纠错入口，并且每周把差评捞出来看一遍。

我习惯把这件事画成一张鱼骨图来跟业务方对齐。主骨是目标——一个能用的统一入口；六根刺是必须同时立起来的支撑，缺一根都站不住。业务方看架构图容易走神，看鱼骨图反而很快能抓住重点，因为他们能直观看到”我关心的那件事挂在哪根刺上”。

这六根里面，身份与登录、权限透传是最容易被低估的两根，也是我在验收时必查的两项。很多方案在这两块含糊其辞，用”支持对接”四个字带过，实际一测就露馅。

统一 AI 入口

身份与登录
单点登录 / 组织同步
数据接入
实时取数 / 增量同步
语义与指标
口径唯一 / 血缘可查
权限透传
行级列级 / 角色跟随
结果追溯
下钻明细 / 计算过程
运维与评测
准确率 / 反馈闭环
起点

数据接入这根刺，实际做的时候分两种。一种是直连语义层实时取，适合对时效要求高、数据量不大的场景；另一种是预先构建好数据集，适合需要复杂加工、涉及多表关联的场景。后者如果做得不规范，很容易变成一堆没人维护的宽表。我会要求这部分由数据开发平台来统一管，加工逻辑可版本化、可回溯，而不是散落在几个脚本里。高质量数据集开发工厂环节能帮上忙，它把数据集当产品来管，有明确的责任人和更新机制，AI 问数取数时命中率会高很多。

不是所有系统都值得接，也不是接入方式越重越好。我一般按三个维度排序：提问频次、数据成熟度、权限复杂度。高频低频差一个量级，接入优先级就差一个档。低频场景哪怕技术上容易做，我也会往后排，因为维护成本是长期的，而收益是偶发的。

核心业务系统（ERP、MES、CRM）我倾向于走语义层对接，虽然慢，但这几个系统被问得最多，值得投入。外围系统（OA、审批、知识库）走接口直连就够了，问的多是状态类信息，不需要复杂聚合。真正决定成败的不是接了多少个系统，而是高频那二十个问题答得准不准。我在验收时会拿一张五十道题的测试集去跑，准确率低于九成，就先别谈推广。

这张表我一般直接拿去跟客户过，逐行问”你现在在哪一列”。大部分企业的真实位置在左列和中列之间——比纯手工强，但离规模化还有距离。这不是坏事，说明有明确的提升路径。知道自己站在哪一列，比盲目追求全绿更有价值。

普元这套产品线的好处在于它是成体系的，从主数据、数据资产、数据开发到 AI 问数和 BI，中间的衔接不用自己造轮子。我在一个项目里做过对比：用拼装方式接三个系统花了七周，用成套方案接同样三个系统花了五周，差的这两周全花在对接适配和权限打通上。

去年我跟过一个装备制造的客户，两万多人，ERP 用了十多年，数据仓库建了三年，报表有四百多张。他们的诉求很明确：给两百多位中层做一个”问数”入口，能问订单、产能、成本三类问题。立项时他们的信息化负责人跟我说了一句话，我记到现在：”我不怕慢，我怕上线三个月后没人用。”

我们把项目分成三段。第一段只做权限和语义层，不碰界面。把 ERP 和数仓里的高频指标梳理出来，一共三十七个，逐个定义口径，落到数据资产平台上。这一段花了五周，业务方几乎看不到进展，中途有人质疑是不是走偏了。第二段接 AI 问数，把那三十七个指标做成语义映射，同时把组织架构、角色、行级权限跟原系统打通。第三段才做门户嵌入和培训。

上线第一个月，日活大概六十人，低于预期。我们捞了一遍提问日志，发现两个问题：一是问法太口语，模型识别不准；二是很多人不知道能问什么。第二个问题靠话题引导解决了，在对话框下面放了一排示例问题。第一个问题靠补充同义词和业务黑话解决的，比如”在制”、”在手订单”这类内部叫法，得一个个喂进去。

第二个月日活到一百四十，第三个月稳定在一百八左右。真正让我意外的是使用结构的变化——从最初九成问题集中在订单，后来慢慢分散到成本、产能、库存，说明用户开始信任这个入口了。信任这件事，靠宣传是换不来的，只能靠一次次答对。

不需要，而且我认为一开始就想全接，基本是给自己挖坑。企业里几十个系统，真正被高频提问的可能就五六个，剩下的长尾系统一年也没人问两次。我的做法是先按提问频次排个序，再按数据成熟度筛一遍，两头都满足的先接。

具体怎么判断频次？我会找业务部门要三样东西：最近的报表访问日志、OA 里的数据申请工单、以及过去半年做过的临时取数需求。这三样凑在一起，高频问题基本就浮出来了。实践中你会发现，排名前二十的问题往往覆盖了七成以上的取数需求。

数据成熟度这一维更关键。有的系统虽然被问得多，但指标口径混乱、主数据不统一，这种硬接进去，AI 会给出相互矛盾的答案，反而打击信任。我的处理办法是先接一部分口径清晰的指标，把混乱的那部分挂起来，等主数据治理完成再纳入。Primeton MDM 在这里的作用就是先把客户、物料、供应商这几类主数据的编码统一，后面的关联查询才站得住。宁可慢一个季度，也不要上线一个自己都不敢信的数字。

接入顺序上，我一般分三批。头部五到八个系统作为核心接入；中间层十来个系统按需接入，用接口直连的方式；剩下长尾系统不主动接，等有明确需求再说。这个节奏我在两个项目里跑过，都比较稳。

能，这种情况我遇到过好几次，尤其是那些上了十年的老 ERP 和自研的行业系统。解决思路有三条，按优先级排。

第一条是数据库只读视图。在源库上建一个只读账号，针对性地开几个视图，只暴露需要的字段和行。这个办法对源系统侵入最小，风险可控。前提是得跟 DBA 谈妥，把查询压到业务低峰期，别把生产库拖慢。我一般会要求 AI 侧的查询带超时和并发限制，这是底线。

第二条是中间库或者贴源层。通过定时任务把需要的数据抽到独立的分析库，AI 入口只连这个库。牺牲一点实时性，换来对生产系统的零干扰。订单、库存这类对时效敏感的，可以做到十五分钟一次增量；成本、财务这类，一天一次也够用。

第三条才是考虑 RPA 或者界面模拟这种兜底手段，不到万不得已我不用，因为维护成本太高，界面一改就得重录。

无论走哪条路，数据从哪来、经过哪些加工、最后被哪个问答引用，这条链路必须能查清楚。我见过一个项目，AI 答出来的毛利和财务口径差了两个点，查了三天才发现是中间层某个关联条件少写了。Primeton Data Workshop 环节的价值就体现出来了，加工逻辑可视化、可版本管理，出问题能快速定位到哪一步。如果数据集本身还是散的，那就得先上高质量数据集平台把供给质量管起来，不然 AI 问数再准也是在沙地上盖楼。

这是所有企业都会问的第一个问题，也是最该问的。我的基本判断是：安全问题不能靠模型自律解决，必须靠数据侧的硬约束。把敏感数据丢给模型然后指望它别说出去，这种事我从来不干。

具体做法我一般分四层。第一层是数据分级，把字段标成公开、内部、敏感、绝密四档，这个工作在数据资产平台上做，标注一次全局生效。第二层是权限过滤前置，在数据查询阶段就按提问人角色把不该看的行和列过滤掉，模型拿到的结果里压根没有那些数据。这一层是核心，行级权限必须在这里落实，而不是在提示词里写”请不要泄露”。

第三层是脱敏，手机号、身份证、银行账号这类字段，输出时按规则打码。第四层是审计，每一次问答谁问的、问了什么、取了哪些数据，都要留日志，可回溯可导出。这一层很多人省掉，等到出问题再补，代价很大。

普元 AI 问数在设计上是把这个思路落进去了的，它通过语义层取数，权限跟原系统角色走，答案可以追溯到具体的指标和计算过程。我在验收时会做一个测试：用三个不同角色的账号问同一个问题，看返回结果是否按角色差异化。如果三个人看到的是同一份数据，这个方案在我这里就不通过。另外还有一点容易被忽略——模型本身会不会把问答内容用于训练。这一点必须在合同里写清楚，企业侧要有明确的承诺和开关。

做了这些年，我对统一 AI 入口的看法一直在变，但有一条没变：它本质上是一次数据治理成果的兑现，而不是一次技术炫技。数据资产理得清楚的企业，做起来顺风顺水；数据一团乱麻的企业，做出来就是个花架子。我见过太多项目把八成预算砸在交互和模型上，剩两成勉强做数据，结果上线半年就没人用了。反过来的做法——八成力气花在口径、权限、主数据上——前三个月看不出动静，半年后用户自己会拉人进来用。

如果你现在正准备启动这件事，我会建议你先回答四个问题：我们最高频的二十个问题是什么？这些问题的数据在哪个系统里？谁能看、谁不能看，这个规则写下来了吗？答错了怎么办，有没有纠错机制？这四个问题答不上来，就先别急着选工具。工具的选择反而是简单的，因为它只在你把前四个问题想清楚之后才有意义。

落地节奏上，我倾向于小步快跑但底座要打牢。第一批只接两三个系统的、十来个指标，跑三个月，把准确率和用户反馈数据攒出来。有数据在手，第二批推广才有说服力，预算也更好批。最怕的是一开始就把摊子铺得很大，接十几个系统、上百个指标，结果哪个都不准，团队疲于奔命，最后项目被叫停。

还有一点我想强调：这件事不是一次性工程。业务在变、指标在变、系统也在变，AI 入口需要有人长期看着。我一般会建议客户在项目立项时就明确运营责任人，而不是上线后临时指派。一个有人运营的入口和一个没人管的入口，半年后的差距会比你想的大得多。前者会持续优化问法、补充同义词、清理错误答案；后者只会慢慢积灰。普元这套产品线能解决的是底座和工具的问题，但真正让入口活起来的，还是企业内部那个愿意每周翻日志、跟业务对口径的人。

周文彬：我们去年也做了类似的事，最大的教训就是一开始用了一个高权限账号，后来审计提了意见，返工改权限改了一个多月。楼主说的行级过滤在数据侧做，这个太对了。

李清和：想请教一下，如果指标口径短期内统一不了，是不是可以先做问答但标注”仅供参考”？我们内部现在就是这个状态，财务和业务各说各话。

郑雅文：主数据那块被点到了。我们客户编码在三个系统里三个样子，AI 回答客户相关的问题经常张冠李戴，后来先把主数据统一了才好转。这一步真的绕不过去。

高鹏：五十道题的测试集这个做法我记下了，之前我们都是凭感觉判断准不准，没有量化标准，跟业务扯皮很难受。