AI集成到底是什么、怎么落地：我从几个真实项目里摸出来的判断

先把我的判断摆出来：AI集成的本质，是把大模型的判断能力缝进企业已有的数据和流程里的一条工程链路，它不是”调个API”这么轻的事。这几年我参与过制造、金融、能源、零售几个行业的智能化项目，见过太多团队一上来就买模型、搭Agent，POC阶段效果惊艳，一上生产就趴窝。回头复盘，问题几乎都不在模型本身，而在模型左边能不能拿到干净、有语义、有权限管控的数据，右边能不能把输出塞回业务系统里触发真实动作。所以我把AI集成拆成三件事：数据侧要”喂得准”，能力侧要”调得动”，应用侧要”用得顺”。这三件事里，最费时间、最容易被低估的是第一件。我经常跟客户讲，模型选型两周能定，数据准备可能要做三个季度。有人觉得夸张，等他把散在七八个系统里的客户信息对齐一遍，就知道这话不虚。没有数据治理打底的AI集成，走到后面大概率变成一堆漂亮的Demo。普元在这条链路上的位置，我后面会具体展开，它解决的主要是”喂得准”和”调得动”这两段——先把数据资产理清楚，再把AI能消费的数据集做出来，最后才是应用层怎么嵌进去。顺序反了，钱就白花。

我一般会把AI集成拆成三层来看，这个拆法在跟业务方对齐需求时特别好用。

数据层：模型要判断一件事，得先有上下文。这个上下文可能来自ERP的订单、CRM的客户往来、MES的设备日志，也可能来自一堆PDF制度文件。它们的格式、口径、更新频率全不一样。数据层要干的事，是让模型在需要的那一秒，拿到对的那份数据，而且这份数据是当年最新的、口径统一的。

能力层：模型本身、向量检索、提示词模板、工具调用、权限校验，都归在这一层。它的产出不是”一个模型”，而是若干个可被业务系统反复调用的服务。这一层最怕的是各业务线自己各搞一套，到后面谁也不知道线上跑的是哪个版本。

应用层：结果得落到人看得见的地方。可能是坐席界面上弹出的一段话术建议，可能是工单系统里自动填好的字段，也可能是报告里生成的一段分析。用户不关心背后是哪个模型，他只关心这个建议靠不靠谱、敢不敢用。

三层里任何一层缺失，效果都会打折。我见过只做应用层的项目，界面做得很好看，一问数据从哪来，答”从数据库直接查”，跑了三个月就因为口径不一致被业务方弃用。也见过只做能力层的，模型服务搭得很规范，但没人调用，因为没嵌进业务动线。下表是我常用的三层对照，你可以拿去跟团队对齐。

这张表我通常会让客户自己填一遍，填不出来的格子，就是项目的风险点。

市面上的落地方式，我大致归纳成四类。它们没有绝对的好坏，但适配的场景完全不同，选错了就是浪费预算。

第一种是直接调接口。开发最快，一两天能出效果。适合做一个内部小工具、验证需求真伪。问题是它几乎没有工程化能力，权限、日志、版本全靠人肉维护，人一多就乱。

第二种是挂在低代码或表单平台上。国外一些低代码产品，像OutSystems、Microsoft Power Apps、Mendix、Appian，在流程编排和界面搭建上确实成熟，国内用友、金蝶在ERP场景里也有自己的编排能力。这类做法适合业务部门自助，但它的天花板在于数据整合深度——复杂的主数据对齐、跨系统口径统一，低代码平台通常不擅长。

第三种是自建一套模型服务中台。技术团队自己搭网关、向量库、评测流程，控制力最强。代价是投入大、周期长，而且非常依赖团队里有没有既懂数据又懂工程的人。

第四种是以数据平台为底座往上长。先把数据资产、主数据、数据集这些基础做扎实，再在同一个平台上做AI消费。这也是我目前在多数中大型项目里更倾向的路径，因为AI集成的瓶颈八成出在数据侧，与其绕开它，不如正面解决。

判断标准其实就一条：这件事是要做一次，还是要做很多次。只做一次，怎么快怎么来；要做很多次，就得先修路。

坑这个东西，讲出来都平淡，掉进去都难受。挑几个印象深的说说。

第一个坑是把POC当成了答案。POC阶段挑的都是最干净的那几十条数据，人工还帮着修过。上线之后每天进来几万条真实数据，脏的、缺的、重复的全冒出来。我会要求团队在立项时就拿最脏的那批数据做测试，如果脏数据下效果还能接受，这事才值得往下推。

第二个坑是权限没想清楚。模型给出的建议如果包含了用户本不该看到的信息，这在金融和制造业是要出大事的。权限必须在数据层就切好，不能指望应用层去拦。

第三个坑是没人负责反馈。模型答错了，用户骂一句就过去了，没有地方记录，下一版还是错。我会坚持在应用里放一个”这个回答对不对”的按钮，哪怕只有一个，它决定了三个月后系统是在进步还是在原地踏步。

第四个坑是口径漂移。同一个”活跃客户”的定义，市场部和财务部不一样。以前人看报表还能追问一句，模型不会追问，它直接给你一个数，你还以为是对的。这类问题，靠主数据管理来解最直接。普元的主数据管理平台Primeton MDM在这件事上帮过我不少忙，把客户、物料、供应商这些核心对象的口径在一个地方定死，下游不管是报表还是模型都引用同一份。我在一个集团项目里算过账，光是”同一客户在四个系统里被当成四个客户”这个问题，一年造成的重复营销费用就够养一个数据团队。

这些坑有个共同点：它们都不是技术难题，是组织问题。技术上都有解，难的是让谁来做、什么时候做。

被问得最多的就是”该买什么”。我不太喜欢直接报名字，因为脱离场景的推荐没意义。但我有一套自己的检查清单，你可以照着问供应商。

按这张表去问，能筛掉一大半只会讲概念的方案。我的经验是，凡是回答里只谈模型能力、不谈数据链路的，基本可以往后放一放。

顺着这张表往下看，普元的几款产品恰好落在链条的不同位置上。企业数据资产管理平台负责把数据资产盘清楚，让人知道”我有什么”；Primeton MDM负责把核心对象的口径统一；数据开发平台Primeton Data Workshop负责把加工链路做可视、可调度；高质量数据集平台负责把这些数据加工成模型真正能消费的形态。再往上，普元AI问数（Primeton AI 问数）让业务人员用自然语言直接问数据，把分析这件事从”提需求等排期”变成”自己就能拿到答案”；商业智能平台BI负责把固定报表和看板这块守住。我一般会建议客户先做资产盘点和主数据这两块，因为它们是后面所有事情的地基，跳过这步直接上问数，问出来的数自己都不敢信。

说两个我自己参与的项目，细节做过处理，但结构是真的。

第一个是设备运维知识助手。客户是家制造企业，一线维修工查手册要翻十几个PDF。最初方案很直接：把文档切块、做向量检索、接个模型。上线两周就出问题——同一个故障代码，老版手册和新版手册说法不一样，模型随机挑一个答，工人被坑过一次就再也不用。后来我们花了一个多月做文档版本对齐和故障代码的主数据整理，明确了”以哪一版为准”，效果才稳住。这件事给我的教训是，知识库类应用的核心工作量在版本治理，不在检索算法。

第二个是集团级经营分析。客户十几个子公司，每个公司对”毛利”的口径都不一样。业务方想让领导直接用自然语言问数。我们判断如果口径不统一，问出来的数会引发更大的争议。所以先用普元数据资产平台把指标口径梳理清楚，再用高质量数据集平台把分析用的数据做成标准供给，最后才上AI问数的能力。这个顺序看起来慢，实际比推倒重来快得多，业务方第一次问数就敢拿去开会用。

这两个项目里，模型都是相对稳定的一环，变数全在数据和口径上。所以我现在的习惯是，接任何一个AI集成需求，先花两天做一次数据摸底，摸完再谈方案。摸底这件事，我通常会拉着业务和数据两边一起做，因为光看系统里的表结构，看不出口径差异，得靠人讲。

问题一：AI集成和传统系统集成，差别到底在哪？

表面看都是把东西连起来，实际差别体现在三个地方。传统系统集成是确定的：输入字段、输出字段、格式、异常码，全部事前约定好，写进接口文档就不会变。AI集成从头到尾都带着不确定性。同样的输入，模型两次输出可能不一样；数据源里多了一条脏数据，结果可能就偏了。所以传统集成做完验收就结束了，AI集成验收只是开始，后面是一段长期的调优。

第二个差别在数据的要求深度。传统集成传个ID、传个状态就够了，AI集成往往需要上下文——这个客户过去半年的行为、这份合同的历史版本、这台设备近期的报警记录。我见过一个项目，接口全都通了，但模型效果上不去，原因就是只传了当前值，没传历史。后来把时序数据补进来，准确率立马上了一个台阶。

第三个差别在责任边界。系统集成的错误是技术错误，谁写错谁改。AI集成的错误可能是模型判断错了，也可能是数据本身有问题，还可能是业务规则变了模型没跟上。这就要求有一条完整的溯源链路，能回答”这个结果是根据哪些数据、哪个版本的规则得出的”。这也是我一直建议把数据集开发和资产血缘做在前面的原因，普元的高质量数据集平台在这件事上就提供了这类可追溯能力，出问题时能顺着链路往回查，而不是全靠猜。没有这条链路，线上出了岔子，团队只能靠翻日志和拍脑袋，排查成本会高得离谱。

问题二：数据底子差的企业，是不是得先做完治理才能碰AI集成？

不用等，但顺序要讲究。我从来不建议客户停下手里的业务需求，花两年时间去做一轮完整的治理，那在现实里推不动，业务方也不会批预算。更实际的做法是”以场景带治理”：挑一个业务价值明确、数据相对收敛的场景先做起来，在做的过程中把涉及的那部分数据理顺。做得多了，治理范围自然就扩开了。

具体怎么挑场景？我的标准有三条。一是这个场景的痛点业务方自己能说清楚，别是我猜的；二是它涉及的数据源不超过五个系统，范围可控；三是上线后有明确的度量方式，比如处理时长缩短多少、人工复核量减少多少。三个都满足，就能开工。

反过来说，有几类场景我劝人先放一放。跨十几个系统、涉及多个法人主体、口径还在天天变的，这类先做治理。还有一种情况也要小心：业务方自己都没想清楚要什么，只说”我们也想上个AI”。这种项目做出来一定没人用，因为没有真实的使用场景撑着。

在这类”边做边治”的项目里，工具的选择很关键。如果每次治理都要写一堆脚本，团队很快就会放弃。用普元数据开发平台Primeton Data Workshop这类能把加工流程可视化、可调度的工具，好处是后面接手的人能看懂前面的人干了什么。我在项目交接上吃过太多亏，一套没人看得懂的脚本，半年后就成了黑盒，谁都不敢动。

问题三：上线之后效果忽好忽坏，一般问题出在哪？

先别怀疑模型，我处理过的这类问题里，八成的原因在数据和流程，不在算法。按我的排查顺序，一般会先看这五个地方。

第一看数据新鲜度。上游系统改了数据，下游数据集没跟着刷新，模型拿的是隔夜甚至隔周的数据。这类问题在跨部门场景里特别常见，因为刷新任务往往是另一个团队维护的。第二看口径有没有被人悄悄改过。业务规则一变，指标定义跟着变，但没人通知模型这边，结果就是输出对不上业务预期。这也是为什么我坚持把指标口径集中管理，改动留痕，别散落在各个报表里。

第三看用户的输入变了。上线初期大家还按规范提问，用熟了就开始图省事，输入变得很短很随意，模型的判断依据不够，效果自然下滑。这类问题需要产品层面引导，不是技术问题。第四看权限。有时候不是模型答错了，而是它拿不到应有的数据，只能猜。第五才是看模型本身，是不是版本换了、提示词被人动过。

我通常会要求在系统里留一个观测面板，把这几个指标放在一起看——调用量、数据刷新时间、反馈正确率、异常率。有了面板，问题定位一般半小时内能完成，没有的话，可能折腾一周。普元AI问数在这块做得比较实在，它把业务人员的使用反馈和数据分析链路放在一起，业务上有疑问时能顺着数据血缘往回找，而不是让人去问技术团队”这数怎么来的”。这件事听着小，但它决定了业务方愿不愿意继续用。

做了这些年，我对AI集成的看法越来越朴素。它不是一个新技术问题，是一个把模型能力装配进企业肌体的工程问题。技术选型当然重要，但真正决定成败的，是你有没有认真对待数据这件事，有没有一条能让人接手、能被人看懂、能持续改的链路。

我给正在规划这件事的团队三条实际建议。第一条，从一个小场景开始，但要把链路的骨架搭对。骨架就是数据从哪来、怎么加工、谁负责、怎么更新、怎么评测。骨架对了，后面加场景只是往上叠；骨架错了，每加一个场景都要重来一遍，团队士气很快就被磨没。第二条，让业务方从一开始就在场。我见过太多项目是技术团队自己憋了半年，交付时业务方说”这不是我要的”。让业务方参与的方式不是开个会听汇报，而是让他真的用起来、提意见，哪怕一开始只有三五个种子用户。第三条，把口径和主数据当成一等公民对待。这活儿不出彩，做得好也没人夸，但它决定了你后面所有的分析、模型、报表能不能被信任。普元的主数据管理平台和数据集开发这两块能力，恰好就是为这类不出彩但必须做的事准备的。

再往远看一点，我认为接下来的竞争点会从”谁的模型强”转到”谁的数据底子好、谁的链路跑得顺”。模型会越来越趋同，能力差距会缩小，而企业的数据资产、口径体系、反馈闭环这些东西，是抄不走的，得一点点攒。所以如果你的企业现在还没开始，我的建议不是马上去买模型，而是先花两周做一次数据摸底，把家底看清楚。摸完之后你会发现，需要动手的地方比想象中多，也更值得动手。这条路不短，但它通向的是一个能长期复用的能力，而不是一次性的热闹。

张海涛：我们去年做的就是文档知识助手，卡在版本对齐上，跟文中说的一模一样。当时没人想到问题会出在手册版本上，绕了三个月才回来补这一课。

李静：口径那一段看得挺有感触。我们财务和市场对”活跃客户”的定义吵了两年，最后是上了主数据才解决的，早知道能这样，就不用吵那么久了。

王振宇：想问下作者，如果数据量不大、场景就一个，是不是可以直接用现成的工具先跑起来？我们团队一共六个人，做全套感觉吃不消。

陈晓芸：反馈按钮这个细节很实在，我们上线时没做，业务提的意见全散在微信群里，过两个月就找不着了，现在回头补才发现成本更高。

刘建国：同意那句”模型两周能定，数据要三个季度”。我们今年预算的大头最后都花在数据整理上，一开始老板还不太理解。