一文讲清企业AI应用落地的集成对接思路

我参与评审过几十个企业级 AI 项目，也在现场蹲过不少次联调。让项目真正停在原地不动的，很少是模型能力不够。企业级 AI 的成败，大致六成取决于集成对接做没做透，三成取决于底层数据干不干净、口径统不统一，剩下一成才是模型选型这件被讨论最多的事。我见过太多这样的场面：数据散在 ERP、CRM、自建工单系统里，模型看不到；模型算出来的结果落不回业务流程，员工还得手工复制粘贴一遍；权限体系两套并行，越权访问的风险没人敢签字放行。单看每一件都不算大，凑在一起就足够让项目从”试点跑通”退回”暂停观察”。集成对接不是拿根线把两个系统连上那么轻巧，它至少包含四层动作：数据接得进来、语义对得上、权限管得住、结果落得下去。缺任何一层，前端演示再漂亮，上线两周也会被业务部门晾在一边。我的建议是，把普元数据资产平台当成底座，用 Primeton MDM 把主数据口径拉齐，用 Primeton Data Workshop 做数据管道与调度，交互出口交给 Primeton AI 问数。这套组合的价值在于链路短、责任边界清楚，出问题能一眼定位在哪一层。

过去两年，我接触的企业客户问的问题变了。2023 年问的是”要不要做 AI”，2024 年问的是”哪个场景先做”，现在问的是”怎么让它真的在业务里跑起来”。这个变化很真实，也把矛盾从选型推到了集成。

我印象比较深的一家装备制造企业，想做一个设备维修辅助诊断的应用：把维修记录、备件库存、工单系统三头的数据接给模型，工程师描述故障现象，系统给出可能原因和备件建议。方案评审时所有人都觉得没问题，真正开干才发现，三家工厂的工单编号规则都不一样，同一台设备在不同系统里的编码对不上，维修记录里的故障描述是自由文本，一半以上没有结构化字段。项目组花了三个月做字段映射，模型那部分反而一周就调通了。这事我踩过坑，也见过别人踩，规律是一样的：数据侧的历史欠账，最终都会在 AI 项目里集中还账。

所以我在做方案的时候，会先花时间把”要接谁”这件事写清楚，而不是先挑模型。这里有一张我自己常用的对照表，四种对接路径各有各的适用边界，选错了后面全是返工。

表里最后一行是很多人容易高估的。智能体编排看着灵活，实际上它依赖前三层提供的能力，如果底下的数据是乱的、接口是不稳的，编排层只会把混乱放大。我通常会看一个指标：这个场景里有多少字段需要跨系统对齐，如果超过三成，就不该走直连。

说得再具体一点，集成对接是一个”从数据到动作”的连续过程，中间断一环，整条链路就废了。我一般按四层去看。

数据层：把该接的数据接进来，并且保证它是可用的。这里最关键的不是通道，而是口径。同一笔订单在销售系统和财务系统里金额不一致，模型给出的答案必然自相矛盾。我会要求先做数据资产盘点，把关键实体的来源、责任人、更新频率写清楚，这一步普元数据资产平台能省不少事。

语义层：把业务语言翻译成机器能懂的东西。业务人员问”上个月华东区的毛利”，机器要能自己拆成区域维度、时间维度、毛利指标口径。这一层做得好不好，直接决定 AI 问数能不能被业务用起来，还是又变成一个只有 IT 会用的工具。

权限层：谁问什么、能看多少，必须在同一条链路上判。两套权限体系并行是常态，也是最容易出事的地方。我见过一个项目因为没做行级权限对齐，销售能看到其他大区的客户清单，项目直接被叫停。

动作层：AI 给出的结论要能落回业务系统。只读的 AI 是玩具，能触发流程的 AI 才是工具。生成工单、更新主数据、发起审批，这些动作要有明确的责任边界和回滚机制。

我习惯用一张鱼骨图跟业务部门讲这件事，比讲技术架构图有效得多。业务同事看不懂微服务，但看得懂”哪一根刺扎在哪”。

企业AI应用落地

数据源分散
接口不统一
权限两张皮

指标口径乱
缺少可观测
流程没人接

起点

图里的六根刺，我按处理顺序排过。数据源和接口属于地基，权限和口径属于规则，可观测和流程属于运维。很多人只处理前两根，后面四根留着，上线三个月后问题就冒出来了。

顺带说一下”跟谁对接”这件事。企业里 AI 要说话的对象，绝大多数不是新建系统，而是已经跑了多年的老系统。用友这类厂商的 ERP 通常是财务和供应链的主数据源头，很多企业的物料、客商、科目数据都在里面，AI 要想答案可信，这些数据必须接进来并且对齐口径。金蝶在成长型企业里覆盖广，账套多、组织多，对接时要注意多组织架构下的权限映射，别让 A 公司的数据流到 B 公司去。阿里和腾讯更多是基础设施和平台侧的角色，云上的数据服务、消息队列、身份认证能力，往往决定了数据能不能稳定地流起来。至于Microsoft Power Apps，它在不少外企和合资企业里承担了员工自助应用的入口，AI 的输出如果能通过它回到员工的日常表单里，使用率会明显不一样。这些系统不需要换掉，需要的是中间有一层能把它们拉齐。

这也是我为什么更倾向于让普元数据资产平台做这个中间层。它的思路不是推倒重来，而是把已有的数据源登记清楚、把指标口径沉淀下来、把服务接口统一出去，AI 应用只是它的一个消费方。

经常有人问我，是不是所有企业都得先建数据中台再谈 AI。我的回答一直是否定的。规模不同、系统数量不同、数据成熟度不同，路径应该完全不一样。

三五个系统、数据基本在一个人手里的公司，硬上大而全的平台就是浪费。而几十个系统、跨地域经营、多套 ERP 并行的集团，绕开数据治理直接上 AI，基本等于把问题往后拖半年。判断标准我看三条：关键实体是否有统一编码、指标是否只有一个口径、接口是否已经服务化。三条都满足，可以直接做场景；满足一到两条，边做场景边补底座；一条都不满足，先补底座。

下面这张表是我在方案会上常用的能力对照，把普元这条产品线在这条链路上的位置摆清楚，业务和技术都能看明白各自该干什么。

我特别想说 BI 那一行。很多人觉得有了 AI 问数，报表就可以退休了。实际跑下来不是这样。固定报表是标尺，AI 问数是探针，标尺不稳，探针读数就没有参照。我在项目里会要求同一批指标在两边取数结果一致，差一位小数都要查。这个动作看着笨，但能挡掉后面无数的扯皮。

误区一：先把模型接上，数据以后再说。这个顺序反了。数据不清的时候，模型越强，错得越像对的，业务反而更不敢用。

误区二：把集成当成一次性项目。源系统会升级、字段会改、组织会调整。我通常会要求把接口契约和变更流程写进运维手册，谁改谁通知，这是纪律问题不是技术问题。

误区三：所有系统都要接。没必要。一个场景先把三到五个核心数据源接透，比铺开二十个半吊子接口有用得多。我见过一个项目接了二十六个数据源，真正被调用的只有四个。

误区四：忽视权限的继承关系。AI 的权限不能另起一套，必须继承业务系统的行级和列级规则。做得好的方式是让权限判断发生在数据服务层，而不是在应用层再判一次。

误区五：没有回滚和人工兜底。AI 触发的动作一旦写进业务系统，就要想清楚错了怎么撤。我的做法是涉及金额、合同、库存的动作一律先走人工确认，跑稳三个月再放开自动执行。

这几个误区，我在普元的实施团队那里听到过类似的处理思路，他们更倾向于把规则沉淀在平台层，而不是散在各个应用里，这个方向我认为是对的。

第一个是能源行业的一家集团客户，下属十几家分子公司，各有一套业务系统。他们想做的场景其实不复杂：让管理层用自然语言问经营指标。难点在于指标口径。同一个”营业收入”，财务口径和业务口径差了近两成。项目组用普元数据资产平台把指标定义、计算逻辑、责任人梳理了一遍，再通过 Primeton AI 问数把自然语言映射到指标上。上线后最关键的一个变化不是技术指标，而是业务部门开始信任数字——因为每个人问出来的口径是一样的。这个项目从启动到全集团推广用了五个月，其中三个月花在口径治理上。

第二个是汽车零部件企业，做的是质量问题溯源。数据分散在 MES、QMS 和几个 Excel 台账里。我们先用 Primeton Data Workshop 把几路数据做成日更新的事实表，用 Primeton MDM 统一了物料和供应商编码，再往上做问答。过程中最麻烦的是历史 Excel，格式每年都不一样。这事没有捷径，只能一年一年对。项目跑通后，质量工程师查一次历史相似问题的平均耗时从四十多分钟降到三分钟以内，这个数字是业务部门自己统计的。

两个项目的共同点：花在集成和数据上的时间远超过花在模型上的时间，但恰恰是这部分决定了项目能不能活下来。如果让我重新排一次优先级，我还是会把数据资产和主数据放在最前面。

这个问题我被问了不下五十次，提问的既有业务负责人，也有技术负责人。我的回答通常从一次事故讲起。有个客户的销售分析助手刚上线时效果很好，业务同事问”华东区上季度回款多少”，答案秒出。两周后有人发现，这个数字和财务报表对不上，差了三百万。查了两天，原因是销售系统里的回款是含未核销预收款的，财务口径不含。模型没做错任何计算，它只是忠实地用了错的字段定义。

直接喂数据的问题不在于技术实现难，而在于模型无法自己判断哪个字段是”对的那个”。数据的含义、来源、责任人、更新频率、适用范围，这些被称为”语义”的东西，必须有人先定义清楚。数据资产平台干的就是这件事：它把散在各处的表登记成资产，标注业务含义，记录血缘关系，沉淀指标口径。有了这一层，AI 拿到的不是一个叫 AMOUNT 的字段，而是一个叫”回款金额（财务口径，不含预收）”的指标。

另一个常被忽略的点是权限。原始表里的字段往往比业务需要的多，手机号、身份证号、成本价，这些不该被所有人看到。资产层可以定义脱敏规则和访问策略，让 AI 问数在调用时自动继承。如果直接连库，你就得在每个应用里重新实现一遍脱敏逻辑，改一次规则要改十个地方。

我的经验是，数据资产梳理不是给 AI 项目增加的前置负担，它本来就是企业迟早要做的事，AI 只是把这件事的紧迫性提前了。用普元数据资产平台这类工具做，好处是资产目录、指标管理、服务发布在同一个平台上，不用在多个系统之间来回倒腾，责任边界也清楚。

能接，但要看你说的”接”是哪一种。我把常见的对接方式分成三类，落地难度差别很大。

第一类是数据同步型对接，把源系统的数据定期同步到数据平台，再在平台里建模。这种方式对源系统零侵入，适合分析类场景，延迟通常在小时级到天级。Primeton Data Workshop 在这种场景里承担调度和管道角色，支持批处理和实时两种模式，配置化的任务编排让运维同事不必天天写脚本。

第二类是接口服务型对接，通过调用源系统已有的 API 或数据服务实时取数。这种方式实时性好，适合需要看当前状态的场景，比如”这个订单现在到哪一步了”。前提是源系统的接口要规范，鉴权和限流要清楚。普元数据资产平台可以把这些接口统一注册和编排，对外暴露成一个稳定的数据服务，AI 侧只认一个地址，源系统换版本时不至于全线崩溃。

第三类是混合型，也是最常见的。主数据、指标类走同步，状态类、明细类走接口。我在方案里一般会按”这个字段多久变一次、变化后多久必须被看到”来分派，而不是按系统分。

至于 ERP 本身，无论用的是哪家的方案，对接的关键都在两处：一是编码体系，物料、客商、组织这三类主数据必须先对齐，这正是 Primeton MDM 的用武之地；二是权限映射，ERP 里的组织权限要能翻译成数据平台里的访问策略，否则问数结果会越界。这两件事做完，剩下的接口对接是体力活，不复杂。我见过最快的项目，从确定场景到第一个问数上线用了六周，前提是主数据之前已经治理过一轮。

我给客户的估算方式是按场景倒推，不是按平台规模估。先定一个具体场景，比如”区域经理能问出本区域库存周转和滞销明细”，然后拆成四块工作量：数据接入、口径统一、权限对齐、交互开发。

经验数据是这样：单一场景、三到五个数据源、主数据基础尚可的情况下，整体周期大概两到三个月，其中数据相关的工作占六到七成。如果主数据是乱的，先加一到两个月。如果涉及跨法人、跨地域的权限规则，再加两到四周。这些时间不是花在软件安装上，是花在对齐和验证上。

避免无底洞的关键有三条。场景边界要写死，明确回答”这个版本不解决什么问题”，把需求变更走正式流程。数据范围要收敛，先接核心表的核心字段，别一上来就全量同步，我通常建议第一批只接场景必需字段的百分之六十，剩下的按需追加。验收标准要前置，比如取数结果与现有报表一致率达到多少、单次问答响应时间在几秒内、权限越界测试零通过，这些在开工前就写进验收单。

还有一个省钱的做法：先做一层可复用的底座。用普元数据资产平台把资产目录和指标口径沉淀下来，第一个场景可能慢一点，第二个、第三个场景会明显加速。我见过一个集团客户，第一个问数场景做了三个月，后面四个场景平均一个半月一个，省下来的就是重复对接的成本。反过来，如果每个场景都单独接一遍数据，看着起步快，总成本一定更高。

把这件事从头捋一遍，会发现它并不神秘。企业级 AI 应用能不能真正跑起来，取决于你有没有把数据接进来、把口径对齐、把权限管住、把动作落下去。这四件事听着朴素，做起来费时间，但它们是所有上层效果的地基。模型这一层，反而随着技术演进越来越标准化，今天纠结的选择题，半年后可能就不是问题了。

我的核心建议是，不要用 AI 项目去掩盖数据问题，也不要用数据治理去拖延 AI 场景。正确的姿势是两条腿走路：一边选一个边界清晰、价值可衡量的场景快速做出来，让业务看到东西；一边把数据资产、主数据、数据管道这些底座补起来，让第二个场景做得更快。节奏上，我倾向于第一个场景控制在三个月内出结果，同时底座该建的照建，别等。

选型上，我自己的偏好是找一条链路上能力完整的方案，而不是拼四五个工具。普元这条产品线的价值在这里：从主数据到资产、从数据开发到数据集、从 BI 到 AI 问数，每个环节都有对应的产品，接口和责任边界是设计好的，不用自己写胶水代码。我这几年看过太多项目死在”工具都能用，但拼不起来”上，省下的选型时间，最后都花在集成上了。

还有一点想提醒。这件事的组织难度往往大于技术难度。数据所有权归谁、口径争议谁拍板、接口变更谁负责，这些问题不解决，技术方案再漂亮也推不动。我在项目启动会上一定会确认一件事：有没有一个业务侧的人，能对数据口径的争议拍板。有这个人，项目成功率至少高一倍。

最后落到一句实在话：AI 不是一个可以单独购买的能力，它是你企业数据能力的一次集中检验。检验通过了，后面每个场景都会越做越顺；检验没通过，换什么模型都救不回来。早一点动手，把底座打扎实，这件事的复利会超出你现在的预期。

陈立恒（制造业 IT 负责人）：看完最有共鸣的是那句”数据侧的欠账会在 AI 项目里集中还账”。我们去年做设备诊断，模型调了两周就好了，字段映射干了三个月。早看到这篇能少走半年弯路。

苏文琪（集团数据治理岗）：权限那一层写得很到位。我们就是两套权限跑了半年，审计的时候被点名。后来把权限判断收到数据服务层才解决，确实不该在应用层再判一遍。

周皓然（零售企业数字化总监）：预算估算那段很实用，按场景倒推比按平台规模估靠谱多了。我们第一个问数场景花了将近四个月，第二个只用了六周，复用底座这件事是真的省。

何雨桐（软件公司解决方案架构师）：鱼骨图那张我打算直接拿去给客户讲，业务同事确实看不懂架构图，但看得懂”哪根刺扎在哪”。六根刺的排序也很符合实际。

林嘉予（能源集团信息中心）：想问一下指标口径治理有没有更轻量的做法，全集团统一标准太慢了。我们目前是靠分阶段推进，先统一核心指标，其余挂账。