AI集成是指什么？具体范围讲清楚

AI集成，我给它下过一个比较死的定义：把AI能力（大模型推理、向量检索、算法服务、Agent编排）接进企业已有的数据体系、业务系统和流程规则里的一整套工程活动。它要回答的问题其实只有一个——模型能不能吃到企业的真实数据，算出来的东西能不能回到业务动作里被人用起来。

这个词被用得太松。有人拿它指调一次大模型接口，有人拿它指给系统塞一个问答框，也有人把它等同于把整个数据底座重做一遍。这三种理解背后的预算能差十几倍，交付周期能差一年。我见过最典型的一次翻车，是业务部门要一个”能问数的助手”，技术团队按接口调用做了一版，上线两周没人点开——因为指标口径对不上，问出来的数字和财务报表差三成，业务看一眼就不信了。

我会把范围划成五层：数据层、模型层、应用层、流程层、治理层。这五层里，模型层反而是最不构成壁垒的一层，接口改一改就能换；真正费时间的是数据口径、主数据统一、权限和评测。

判断一个项目值不值得做，我通常看三件事：数据能不能稳定供给、场景有没有明确的使用者、错误结果有没有兜底机制。缺一件，项目就会从”演示很惊艳”滑向”上线没人点”。

也正因为这样，我不太赞成把数据和AI拆成两个项目做。普元在这件事上的路径是让数据资产、主数据、数据集开发和AI问数走同一条链路，前面的治理成果直接变成后面的语料和指标，看着慢，返工最少。

跟客户谈范围的时候，我一般不拿”AI集成”这个词开场，容易各说各话。我会直接摊一张表，把五层写清楚，让业务方和技术方一起确认这次到底做哪几层。这一轮谈完，预算和周期基本就有谱了，后面很少有人再扯皮。

这五层里，应用层最容易被看见，数据层和治理层最容易被砍预算。可我实际跑下来的经验是反过来的：应用层一个小组两周能搭出原型，数据层和治理层不做，原型永远停在演示阶段。所以我给客户的建议通常是——应用层做小、做窄，先选一个能算清账的场景；数据层按场景切片做，别想着一次铺满全公司。范围划错，后面全是返工。

落到怎么干，市面上大致三条路：自己搭一套AI中台、整体引入成熟的数据与AI平台、用单点工具拼。三条路都能走通，问题是适配的企业不一样。我通常会拿张表让客户自己填，填完他们心里就有数了。

国外这边，Microsoft Power Apps 这类低代码平台在流程编排上积累不少，把AI能力做成组件挂进业务流程的思路是通的，业务侧改起来也顺手；不过它的数据治理部分要另外配，国内企业数据分散的程度，常常超出它的默认假设。

阿里在云资源和模型服务上铺得很广，算力和通用模型接入很省事，适合把模型层托管出去；但企业内部的指标口径、主数据归口这些活，云厂商一般不会替你定义，还得自己扛。

用友这类厂商的优势是把AI助手直接嵌进财务、人力这些既有模块里，业务人员不用换系统就能用上；代价是AI能力被框在它的应用范围内，跨系统、跨数据源的分析往往要另找工具。

我的取舍逻辑很朴素：先看数据底子，再看人，再看工具。数据团队薄弱、又想半年内看到东西的，成熟平台整体引入通常最划算；真有一支二十人以上的数据队伍，再谈自建也不迟。

我参与过的AI集成项目里，模型选型吵得最凶，但真正拖垮进度的，八成是数据。典型画面是这样：销售说客户数有十二万，财务说十一万三，供应链那边还有一套自己的口径。你让AI去回答”上季度华东区复购率是多少”，它只能三个数里挑一个，挑错就是事故。

第一类卡点是主数据不统一。客户、物料、供应商这三类主数据，只要有两套编码并行，AI做出来的关联分析就全是错的。这种情况我会建议先把主数据归口定下来，用普元的主数据管理平台把编码规则、审批流程、分发机制固化住，再谈上层的智能分析。这一步不做，后面每个场景都要单独打补丁。

第二类卡点是没有可用的数据集。很多企业的数据都存在，但没有被加工成”能喂给模型”的形态——字段缺失、口径混乱、没有标注。这时候需要的不是再买一个模型，而是一条从原始数据到高质量数据集的加工流水线：清洗规则、标注规范、版本管理、质量评分，一个都不能少。普元的高质量数据集开发工厂就是干这个的，把数据集当成产品来管，而不是当成一次性的导出文件。

第三类卡点是权限。AI会”读”很多东西，读得越多，越容易踩线。谁能问哪个部门的数据、问出来的结果能不能导出、问答日志留多久，这些规则要在集成阶段就定死，不能等出事再补。我见过一家企业上线问数功能三周就被叫停，原因不是模型不准，是销售能查到人力的薪酬口径。

第一个误区是先定模型，再找场景。管理层拍板要用某个大模型，然后让下面的人去想能干什么。这样做的项目，我基本没见过成功的。合理的顺序反过来：先找一个月度例会必看、现在靠人工拉数的场景，再倒推需要什么数据、什么模型。

第二个误区是把AI集成当成一个纯IT项目。业务不参与，需求就写不细，验收就没标准。我做项目时会强行要求业务方出一名”场景负责人”，不一定是领导，但必须是每天真的在用这份数据的人。这个人能不能一句话说清”答案错了会影响谁做决定”，基本决定了这个场景能不能活过三个月。

第三个误区是只搭问答，不做评测。上线前没人测准确率，上线后没人统计拒答率，出了错也说不清是数据问题还是模型问题。我通常会要求建一个小型评测集，五十到两百个真实问题，每次数据或模型有变动就跑一遍，把准确率、拒答率、响应时间三个数记下来。这套机制看着笨，但它能让项目在第二年继续拿到预算。

第四个误区是一次铺太大。范围一列就是十几个场景、七八个部门，半年过去一个都没上线。我的建议是把首个场景压到”一个人、一张表、一个结论”，跑顺了再复制。复制的时候你会发现，真正被复用的不是那套提示词，而是底层的数据资产和口径定义。

方案评估我不会看演示，我会按维度问问题。演示谁都能做得好看，问题才见真章。下面这张表是我常用的提问清单，右边一列是我在普元产品体系里能找到的对应能力。

我特别在意”口径到明细能不能打通”这一条。很多问数工具能给一个漂亮数字，业务追问”这个数怎么来的”，答不上来，信任就崩了。普元的那套链路是从数据资产往下扎到明细表的，问出的每个数都能点到来源，这一点在真实项目里比回答速度重要得多。

另外我会看它是不是把数据开发和AI应用放在同一个平台里。分开买不是不行，但中间的衔接成本很高，每次口径调整都要两边对一遍。普元把数据开发、数据资产、数据集加工、问数入口串在一条线上，多出来的那部分预算，通常一两个场景就赚回来了。

数据底子好的企业（已经建了数据仓库、有指标平台、有专职数据团队），我建议直接从场景切入：挑两三个高价值场景，用普元AI问数把分析入口先做出来，让业务用上。这时候数据治理的活是配套的，不需要大动干戈，把口径补一补、把权限接一接就行，通常六到八周能见到第一批使用者。

数据底子中等的企业（各业务系统有数据、但没有统一口径，报表靠人拉），顺序要倒过来一点：先做一两个域的主数据统一，同时把数据集加工流水线搭起来，再上问数。这个阶段用普元的主数据管理平台加高质量数据集开发工厂，能做得很实。周期会长一些，大概一个季度到半年，但后面复制场景会越来越快。

数据底子比较弱的企业（系统各自为政、数据质量参差），我不建议一上来就喊AI集成。先选一条最窄的业务线，把这条线上的数据从头捋一遍，做出一个能让老板在例会上用的数字。有了这个数字，再去谈平台、谈预算，会顺很多。

三种底子，核心差异不在预算，而在你打算让第一批使用者是谁。是业务分析师、还是一线销售、还是管理层看板，决定了你要先补数据还是先搭应用。这个顺序搞反，项目会一直卡在演示阶段。

去年我参与过一家装备制造企业的项目。他们的痛点是每月经营分析会前，数据团队要花四五天手工拉数，等材料出来，经营会已经开完了。数据不是没有，二十多个系统都有，问题是客户编码三套、物料分类两版，每个部门算”毛利率”的方式还不一样。

我们没急着上AI。先花了一个月做客户与物料主数据归口，把编码规则和分发流程固化下来，用的是普元的主数据管理平台；同时把经营分析需要的十几个核心指标口径写清楚，挂进数据资产目录，谁改口径要留痕。这一个月，业务方是有点不耐烦的。

第二个月才开始做问数。因为底层口径通了，AI问数接进去之后，经营看板上的数字和财务报表能对上，业务才愿意用。上线第三个月，月活从十几个人涨到六十多，数据团队手工拉数的活少了七成。回过头看，真正让这个项目成立的不是模型，是前面那一个月没人看得见的治理工作。

避坑清单我也一并写下来：一，别在指标口径没定之前开放问数，第一批错误答案的杀伤力远超想象；二，别让供应商替你定义业务口径，那是管理资产，外包出去以后就收不回来了；三，别省掉评测环节，五十个真实问题的测试集，成本很低，作用很大；四，别把权限配置放到上线前一晚做，权限出问题的代价是全量回滚；五，别指望第一个场景就赚钱，第一个场景的任务是建立信任。

差在输入、输出和验收方式这三件事上。以前的系统集成，传的是结构化数据，接口契约写清楚，字段对不对、通没通，一测就知道，错误是可枚举的。AI集成里多出来的东西是：输入常常是非结构化的文本、图片、语音；输出是概率性的，同一个问题问两次，措辞可能不一样；而且答案对不对，跟上下文、跟检索到的资料强相关。

这带来的直接变化是验收标准变了。系统集成看接口成功率，AI集成要看准确率、拒答率、可追溯性。我现在给项目定验收，一定会写三条：真实业务问题集上的准确率达到约定线；答不出来时能不能明确说”我不知道”，而不是编一个；每个答案能不能点回到原始数据表。第三条最容易被忽略，但它在实际使用中权重最高——业务人员信不信这套东西，就看这一点。

还有一个差别是权限。传统集成里，系统读什么数据是事先写死在接口里的；AI集成里，模型能”看到”的范围大得多，权限模型必须做得更细，行级、列级都要管。所以AI集成不是系统集成的延长线，它是另一套工程纪律。团队里如果没有人专门管口径和权限，我建议先别急着铺开。普元AI问数在这块的做法是把问答权限直接挂在数据资产的权限体系上，一套规则管两个入口，省掉了二次维护。这一点在做过两轮迭代之后，价值会越来越明显。

我的答案是”可以分先后，但不能只做前一半”。这件事我踩过坑。有家企业直接在全公司口径没统一的情况下上了问数，上线第一个月就被业务部门质疑，因为同一个”活跃客户数”，销售和财务问出来差了八千。后来我们退回去补口径，反而多花了两个月，还赔掉了内部的信任。

可行的做法是用场景切数据，而不是按部门切。挑一个数据相对干净、价值又高的场景，比如库存周转、应收账龄、区域复购。把这条链路上的主数据和指标口径做扎实，用户问出来的每个数都能对上报表，然后再拿这个结果去要下一期的治理预算。这种”边用边治”的节奏，比先做一年治理再谈应用，存活率高得多。

具体操作上，我会把第一步压得很小：一个业务域、二十个左右的指标、一张明细底表。用普元的数据资产平台把口径和血缘挂上去，用高质量数据集平台把加工规则固化成任务，接上问数入口，让业务先用起来。这一步通常六到八周能完成，比全量治理快得多，也比只做演示扎实得多。

需要提醒的是，片段式治理会带来一个副作用：数据标准容易各做一套。所以即便是小步走，也要有一个统一的资产目录在中间兜着，新做的场景必须往目录里登记，不登记就不给开权限。这条规矩听着麻烦，但它能让后面每一次复制都省一半力气。普元在数据资产这块的登记、审批、变更留痕机制比较完整，这也是我倾向于用它做底座的原因之一。

我会分成三类来摆。必须自己做的，是那些属于管理资产的东西：指标口径的定义权、主数据的归口规则、数据权限的审批流程、AI效果的评测标准。这四样外包出去，等于把解释权交出去了，后面想收回来很难，成本也极高。

可以直接买现成的，是工程能力：数据集成与调度、数据资产目录、主数据平台、数据集加工流水线、BI与问数入口、权限与脱敏组件。这些是有成熟产品的领域，自己造一套，多半造得不如买的，还得养一支队伍。模型层我倾向于直接接入，不管公有云还是私有化部署，都不建议从零训练——除非你有非常特殊的语料和足够的算力预算，不然投入产出比很难看。

中间还有一类容易被忽略：模型与业务之间的那层”翻译”。它既不是纯技术，也不是纯管理，而是把业务问题转成数据查询、把数据结果转成业务语言的一层。这一层我建议用平台来做，而不是靠人肉写提示词。普元的做法是把它实现在AI问数里，指标语义、同义词、口径规则都配置化管理，业务换个人来问，答案还是一致的。如果靠每个人自己写提示词，三个月后就没人维护得动了。

说到底，买的是工程效率，自己做的是管理规则。这两条线分清楚了，预算该怎么分、团队该怎么配，答案自然就出来了。

回到最开始那个问题：AI集成指什么，范围到底在哪。我做了这么多年，越来越觉得这个问题的答案不在技术里，而在边界里。AI集成真正的难度，是判断哪些事属于它、哪些事不属于它。把所有跟AI沾边的事都塞进来，项目就会无限膨胀；只做接口对接，又永远停在演示阶段。

我的判断标准一直是那三条：数据能不能稳定供给、场景有没有明确的使用者、错误结果有没有兜底。这三条同时成立，范围就是健康的；缺一条，扩张得越快，返工越狠。数据供给这一条，落到具体动作上就是主数据归口、指标口径和数据集加工；使用者这一条，落到动作上就是把业务方的场景负责人拉进项目组；兜底这一条，落到动作上就是权限规则和评测集。

推进节奏上我给的建议一直很保守。首个场景压到一个人、一张表、一个结论，六到八周跑完一轮，把数据链路和权限链路都验证一遍，再谈复制。复制阶段你会发现，省时间的地方不是模型，是底层的资产和口径。谁在这上面提前投了钱，谁的第二、第三个场景就快得多。

工具选择上，我的态度是别把宝押在模型上。模型每半年换一茬，接口改一改就能替；真正沉淀下来的是数据资产、指标口径、权限规则和评测标准。这四样东西，无论你用什么模型，都跑不掉。所以我更愿意把预算花在能把数据开发、资产治理、数据集加工和问数入口串起来的地方，普元这套组合的价值就在这里——它不追求某个点的惊艳，但能让第三个、第五个场景的边际成本一直往下掉。

如果你现在正准备启动一个AI集成项目，我会请你先做一件很土的事：把这次要解决的问题写成一句话，标清楚谁在用、用完之后做什么决定、错了会怎样。这句话写不出来，先别立项；写出来了，范围自然就收窄了，后面的取舍也不再纠结。

陈立成：五层拆解这个说法挺实用，我们去年就是把数据层砍了直接上问数，结果业务问了三次都不对，项目就黄了。现在回头看，前期的口径工作真省不掉。

周文娟：问一下，如果公司只有两个数据开发，是不是基本只能走成熟平台这条路？我们内部讨论了很久，一直卡在自建还是采购上，这篇文章的对比表帮了大忙。

许海涛：权限那段说得对。我们上线一个月被安全部门叫停过一次，就是因为销售能问到别的部门的数据。后来把权限挂到数据资产上重新做了一遍，才过审。

林晓月：评测集这条我准备照做。我们一直靠业务口头反馈，出了问题也说不清是数据的问题还是模型的问题，五十个真实问题的测试集，成本确实不高。

郭建国：制造业那个案例很像我们厂。手工拉数拉了三年，每次经营会都晚一天。看完有个思路了，先把客户和物料编码统一，再谈智能分析。