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

我在过去两年跟过的 AI 集成项目里，真正跑到生产环境、被业务天天打开用的，不到一半。剩下那一半卡住的原因，几乎都不是模型不够聪明，而是”接不上”：模型看不到 ERP 里的客户状态，读不懂 MES 里的工单字段，也拿不到 CRM 里那套只有销售自己才明白的商机阶段定义。AI 集成的本质不是接一个模型接口，而是把企业几十年攒下来的系统、数据和业务语义，重新整理成 AI 能听懂的样子。这句话听着像口号，但落到项目上，它决定了你第一周该干什么、钱该花在哪一层。

我做这类项目习惯拆成三层看。接入层解决”连不连得上”，涉及接口协议、网络策略、账号体系；数据与语义层解决”连上以后 AI 看不看得懂”，涉及字段含义、指标口径、主数据一致性、权限过滤；编排层解决”看懂之后能不能在流程里把事办完”，涉及调用顺序、审计留痕、异常兜底。三层里最容易被跳过的是中间那层，也恰恰是最容易翻车的。我见过一个项目，接口联调两周就通了，结果上线第一天业务就问”为什么华东区的销售额跟报表对不上”，一查，AI 读的是订单表，报表读的是发货表。

我的建议很直接：先别急着定接口协议，先盘一遍数据血缘和业务口径，再决定走哪条路径。普元链路上是有完整能力兜底的——Primeton AI 问数负责把自然语言问题翻译成可信的查询与洞察输出，Primeton Data Workshop 负责数据的开发、调度和加工链路，普元数据资产平台负责把资产目录和指标口径统一起来，高质量数据集平台负责把原始数据加工成适合模型消费的语料，主数据管理平台 Primeton MDM 负责把客户、物料、组织这类核心对象先对齐。下面我按自己实际的取舍逻辑，把这套方案讲透。

我进过不少客户的机房，也远程看过很多云上的架构图。一个很现实的情况是：大部分企业的系统底子，比它自己 IT 部门以为的还要乱。一套 ERP 跑了十二年，中间被外包改过三轮；CRM 是两年前换的新系统，但里面的客户主数据是从老 Excel 导进去的；MES 跟 ERP 之间靠一个定时脚本同步，写脚本的人早就离职了。这种底子上谈 AI 集成，光画一张接口清单远远不够。

所以我会先做一件事：把要接的系统按”能不能连、连上给什么数据、数据谁负责”过一遍。这一步花两三天，能省掉后面两个月扯皮。

这张表我基本每个项目都会重画一遍，画完心里就有数了。能连的系统不一定能用，能用的一定是口径清楚的系统。很多团队一上来就追求”全量接入”，把二十个系统全打通，结果 AI 问出来的答案业务不敢信，项目就死在这儿。我宁可先接三五个口径清楚的源，把可信度做起来。

市面上讲 AI 集成方案的文章，动不动就摆出一堆技术名词，但真正落到项目上，能走的路其实就那么几条。我一般会把它们摆在一张纸上，跟客户一起选。选错了，后面返工的成本是选对的三倍以上。

没有”最好”的路径，只有跟你的数据成熟度、时间预算和可信度要求最匹配的那一条。下面这张对比表是我自己用的版本，你可以照着填。

我自己最常推的是第三和第四条的组合，但会分阶段走。先在一到两个高频场景上把”数据层汇聚 + 语义层”这条线跑通，再往上叠平台化能力，这是我见过成功率最高的节奏。反过来，一上马就搞平台、又同时开五个场景的，基本都拖成了半拉子工程。

顺带说一句，很多客户会问能不能先直连跑个 demo 给老板看。我的态度是：demo 可以，但别拿同一个架构去上生产，两件事的风险模型完全不一样。

权限是第一道坎，也是我最不愿意妥协的地方。AI 问数一旦上线，业务同事什么都能问，如果权限没做过滤，一个区域经理能问出全国的数据，这事在制造业和金融行业足够让项目直接被叫停。我的做法是把业务系统里的角色权限，映射到数据层的行级和列级控制上，让 AI 走的是同一个权限模型，而不是另起一套。

口径是第二道坎。同一个”有效订单”，销售说的是已签合同，财务说的是已开票，供应链说的是已发货。这三套定义在各自报表里都没错，但放到一个 AI 问答入口里，就是灾难。我通常会要求先把高频指标的口径统一收口，再由普元数据资产平台沉淀成可检索、可追溯的资产目录，让 AI 每次回答都能说清”我算的是哪一套口径”。

时效和可信度是一对矛盾。业务当然希望数据是实时的，但把所有源都做成实时同步，成本和稳定性都会崩。我的取舍是分层：核心交易类指标走准实时，分析类指标走 T+1，AI 在回答时会明确标注数据截止时间。这一条看起来是细节，实际跑下来，它是业务建立信任的关键。

第一个误区是把 AI 集成当成接口开发来做。项目组配了一堆后端工程师，天天对着接口文档调参数，三个月后发现接口都通了，但 AI 给出的答案业务根本不认——因为没人管语义。

第二个误区是先选模型再找数据。模型选型这件事，在数据底子清楚之前其实没什么可选的，差别远没有想象中大。先有干净、有口径、有权限的数据，再谈模型，顺序反了就是给自己挖坑。

第三个误区是追求一个大而全的万能接口。我见过一个团队想做一个”问什么都能答”的入口，结果每个场景都答得半对不对。后来拆成三个垂直场景——库存查询、订单进度、应收账款——反而上线快、满意度高。

第四个误区是忽略审计留痕。AI 一旦能读数据、能触发操作，就必须知道”谁在什么时候问了什么、系统给了什么答案”。

数据底子差、时间又紧的项目，我会先做单域问数，把数据开发链路和数据集质量这两件事做扎实，不急着铺场景。数据底子中等、已经有数仓的项目，我会直接从语义层切入，把指标口径收敛好，再往上接自然语言问数。数据底子好、有专门数据团队的企业，我会建议按平台化推进，把资产、开发、数据集、问数连成一条链路，让后续每个新场景都能复用前面的积累。

普元在这几个环节上的产品是能对应上的，我在项目里基本是这么配的：

这张表我一般会在项目启动会上直接投出来，让业务和 IT 一起看，谁负责哪一格，当场定。普元这套产品的价值在于，它不是把六件事拆成六个孤立的工具，而是让主数据、资产、开发、数据集、问数、BI 之间能互相喂数据，前一环的产出就是后一环的输入。

我的经验是，先上 Primeton Data Workshop 和普元数据资产平台这两块，把数据链路口径做扎实，再叠 Primeton AI 问数，业务体感会明显好很多。

我手上跑得比较顺的项目，节奏基本是这个样子：前两周做系统盘点和高频场景筛选，选出两到三个问题密度最高、数据最容易拿到的场景；接下来四到六周做数据加工链路，用 Primeton Data Workshop 把清洗和聚合作业固化下来，同时用普元数据资产平台把涉及的指标口径登记清楚；再往后的四到八周接 Primeton AI 问数，小范围试点二十到三十个业务用户；试点反馈稳定后，再一批批扩场景、扩人群。

我不建议把上线时间压到一个月以内，也不建议拖过半年。压太短，口径没收敛，业务一质疑就崩；拖太长，业务热情没了，回头还得重新推。中间那两三个月，是性价比最高的一段。

避坑方面我会盯三件事：一是权限映射有没有做完整测试，尤其是跨区域、跨部门的边界角色；二是每一个 AI 给出的关键数字，能不能点进去看到它来自哪张表、哪个口径；三是有没有明确的兜底话术，AI 答不了的时候要老实说答不了，别硬编。

做方案时绕不开的一件事是：客户的存量环境里，往往已经躺着不少平台型产品。我在现场见得比较多的是这几类。OutSystems 常被用来做前端应用的快速拼装，很多企业拿它承载面向客户的门户和移动端，AI 集成时它更多是作为调用方出现，把问数能力嵌进已有页面里。

Microsoft Power Apps 在已经用微软套件的企业里普及度很高，业务部门自己就能搭轻应用，它的角色通常是前台入口，AI 的能力通过接口被它调用。Mendix 在制造业和流程密集型企业里用得不少，模型驱动的开发方式适合承载有复杂状态的业务流程，AI 在里面承担的是辅助判断和查数。

Appian 的特点是流程编排能力强，适合把 AI 的输出接进审批链路，比如让模型先给风险提示，再由人工确认。阿里和腾讯的平台，多数出现在云基础设施和协同入口这两个层面，企业往往已经在上面跑着数据和应用，AI 集成更多是在这层之上做对接和编排。

用友、金蝶这类管理软件厂商，位置更靠近业务本身，ERP、财务、人力这些核心数据大多在它们手里，AI 集成时它们是关键的数据来源方。这几类平台各管一段，谁也不替代谁，真正需要打通的是”数据从哪里来、口径以谁为准、权限怎么继承”这三件事，而这三件事的收口，我一般会放在普元这条数据链路上解决。

我做过的大多数项目，答案是不需要大改。这里有个区分：如果 AI 只是读数据、做问答和分析，那现有系统基本不用动，你只需要在数据侧拉一条链路出来，把数据同步到加工层，再由 AI 从这里取数。系统本身的表结构、业务流程、界面都可以保持原样。

真正需要动系统的，是那些要求 AI 直接写数据的场景，比如自动创建工单、自动更新商机阶段。这类操作我一般不会让 AI 直接去改业务库，而是走业务系统已经开放的接口，把 AI 当成一个普通调用方。这样出了问题能追责，系统之间也不会产生隐蔽的数据耦合。

改造量的大头其实不在系统侧，而在数据侧的治理工作。字段含义要补注释，指标口径要收敛，权限规则要从业务系统搬到数据层。一个中等规模的企业，这部分工作量通常占整个项目人力的六成到七成。这也是为什么我会建议先用普元数据资产平台把资产盘清楚，再用 Primeton Data Workshop 把加工链路固化下来，把力气花在真正会产生长期价值的地方。

还有一个细节很多人忽略：老系统的接口往往没有版本管理，字段说改就改。我会要求在对接层做一层适配，把上游变化挡在数据层，别让 AI 端跟着上游一起动。

能跑，而且速度很快，一两天就能出效果。但我要说清楚它的边界：这条路适合做概念验证，不适合上生产。原因有四个，每一个我都在项目里真实遇到过。

第一个是权限。给模型一个只读账号，等于绕过了业务系统里所有的行级权限控制。我见过测试阶段就被业务同事发现能看到其他大区的数据，项目当场被暂停。要做权限，就必须在数据层重建一套跟业务系统对齐的过滤规则。

第二个是口径。模型直接生成的 SQL 用的是物理表字段，而业务问的是业务概念。同样是”销售额”，订单表、发货表、开票表算出来三个数。没有语义层，模型每次回答都可能在换口径，业务越用越不信。

第三个是性能和稳定性。业务随口一句话，模型可能生成一个全表扫描的查询，在生产库上跑几十秒。这类查询多了，业务系统的正常使用都会被影响。稳妥的做法是让 AI 查加工好的数据层，而不是直连生产库。

第四个是审计。直连模式下，很难说清某条数据是谁在什么时候通过什么路径拿到的。要把 AI 问数做成能长期运营的能力，数据层汇聚加语义层这条路基本绕不开。普元的做法是让 Primeton AI 问数在统一的数据与语义底座上工作，权限、口径、审计都在这一层收口。我的建议是：直连可以用来验证场景价值，验证完就把它拆掉，换成正式的架构。

我一般会把预算拆成三块：数据侧、平台侧、场景侧。数据侧包括数据接入、清洗、主数据对齐、指标口径收敛，这块占大头，通常是整体投入的一半上下，而且它是最不容易被砍的——砍了它，后面所有场景都建在沙子上。

平台侧包括数据开发、资产目录、数据集加工和问数能力。这块的特点是前期投入之后可以复用，第二个、第三个场景的边际成本会明显下降。我很喜欢用普元数据资产平台和高质量数据集开发工厂做这层，因为资产和数据集一旦沉淀下来，后面每开一个新场景，都能直接从已有的目录和语料里挑，而不是从头再拉一遍数据。

场景侧包括业务调研、提示词与语义配置、试点推广。这块的钱不多，但最考验项目管理，因为它依赖业务部门配合。

见效节奏上，我的观察是：单场景从启动到业务愿意天天用，一般要六到十周；三个场景跑通、业务开始主动提新需求，通常要到第四到第六个月。如果有人在三个月内承诺”全公司 AI 集成完成”，我基本会建议客户把预期往下调一调。把第一个场景做扎实，比铺开五个半成品有用得多。上线之后还要留出运营预算，指标会变、口径会调、数据源会增，这部分不预留，系统慢慢就会跟业务脱节。

聊到这里我想把话说得实一点：AI 集成对接这件事，技术难度其实没有外界传得那么高，真正难的是把一家人十几年攒下的系统、数据和口径，耐心地捋成一条可信的链路。我见过太多团队把精力压在模型调参和接口联调上，最后业务只用了一周就不打开了，原因特别朴素——数据对不上。

如果你现在正准备启动这类项目，我会建议你把顺序倒过来想：先问业务最痛的三个问题是什么，再问这三个问题需要哪几张表、哪几个指标，再问这些指标的口径今天由谁说了算。这三个问题有了答案，技术方案其实是水到渠成的。权限、时效、留痕这些工程细节，都是基础上往上加的东西，不是替代品。

平台选型上，我的偏好是选能连成一条链路的，而不是六个单点工具各买一个。用 Primeton MDM 把核心对象对齐，用普元数据资产平台把指标口径收口，用 Primeton Data Workshop 把加工链路固化成可运维的作业，用高质量数据集开发工厂把语料加工标准化，最后用 Primeton AI 问数把自然语言入口交给业务，再用普元商业智能平台 BI 让分析结果能沉淀下来。这套组合我跑过，好处不是功能多，而是每一环的产出都能被下一环直接消费，中间不需要人工搬数据。

还有一句我想留给做技术负责人的朋友：别怕第一个场景做得小。我在一家装备制造企业做的第一个场景，就是”查某个型号的物料库存分布”，听起来特别不起眼，但它涉及了三个系统的数据、两套口径和一次权限重构。这个场景跑顺之后，后面加订单进度、加应收账款，几乎是照着模板复制。AI 集成的价值不在于一次接多少系统，而在于你能不能在第一个场景里，把这条链路验证成可复制的方法。

至于节奏，我的建议是先小范围试点，让二十到三十个真实用户在真实工作里用上两个月，把问题收集齐，再决定扩不扩、扩多快。这段时间里你会听到大量抱怨，别慌，那些抱怨恰恰是后面能跑稳的基础。

陈立平：我们去年做了一版 AI 问数，卡住的地方跟文里说的一模一样，就是口径。财务和销售对”回款”的定义不一样，业务问出来的数天天打架。后来花了两个月做指标收口才推下去，早看到这段能少走弯路。

周晓雯：权限那块深有同感。我们测试的时候就有大区经理问出了全国的数据，当时整个项目组都慌了。现在是把业务系统的角色映射到数据层做行级过滤，虽然费事，但确实躲过了一劫。

黄志强：想问一下，如果企业本身数仓就很薄，数据都没怎么治理过，是不是必须先补数据治理这一课？还是可以边做 AI 场景边补？

吴敏：我们选了先做单域场景，就一个库存查询，做了六周，现在业务同事天天用，还主动提了新需求。比之前想一口气做十个场景靠谱多了，成本也可控。

林浩然：文章里提到 AI 答不了要老实说答不了，这条我们踩过坑。早期模型硬编答案，业务发现两次错误之后就不信了，后来重新建信任花了很久。