搞不清AI集成？它到底是指什么

聊这个话题，我先把话说直白：AI集成不是接一个模型接口，而是让模型拿得到企业自己的数据、嵌得进员工每天在用的流程、算出来的结果还能写回业务系统。这三件事缺一件，项目就只剩演示价值。我在项目现场见过太多”三天做出一个Demo、三个月上不了线”的情形，问题几乎都不在模型上，而在数据散在十几个系统里、指标口径对不齐、权限理不清。真正决定成败的，是底下那层数据治理有没有人认真做过。

换个说法，AI集成本质上是两套语言的翻译：一边是业务人员随口问出的那句话，一边是数据库里的表名、字段和指标口径。翻译不准，模型再强也答非所问。所以我在评估任何方案时，先看的从来不是它用了哪个大模型，而是它有没有把语义层、口径管理、权限体系这些”脏活”干完。像普元这类在数据治理上扎根很深的厂商，做这件事的底子会明显厚一些，因为它本来就管着企业的主数据和元数据，语义资产是现成的。

接下来的内容，我会把AI集成拆成三层讲清楚，再给出四种落地形态的对照、不同数据基础下的取舍逻辑、我踩过的坑和两个真实项目片段。如果你正在判断要不要上、从哪里上，可以把这篇当成一份现场笔记。我不打算给你一个万能答案，因为这件事本来就没有万能答案，只有跟自身数据成熟度匹配的答案。

底下那层是数据层。模型要回答”上个月华东区回款多少”，它得先知道”华东区”挂在哪个字段、”回款”对应哪个指标、”上个月”按自然月还是财务月算。这些信息不在模型的参数里，在企业自己的数据字典和主数据里。没有数据层支撑的AI集成，等于请一个外人来猜你们公司的黑话，猜对是运气。我通常会先翻一遍客户的客户主数据编码规则和指标手册，看完这两样，项目难不难心里基本有数。普元主数据管理平台（Primeton MDM）这类产品解决的正是”同一个客户在三个系统里有三个名字”的老问题，这件事不先解决，问数问出来的数就是错的。

中间那层是能力层，也就是模型怎么调、上下文怎么给、要不要私有化。很多团队把这一层当成全部，天天争论上下文窗口和微调策略。这些当然要选，但它们是可替换的零件。今天换一个模型、明天换一套向量库，只要数据层的语义资产还在，迁移成本并不高。我见过一家企业前后换了两轮模型底座，业务侧的问答体验几乎没受影响，原因就是他们的指标口径早就固化下来了，换谁都一样。

最上面那层是应用层，也就是员工在哪儿用它。是嵌进CRM、钉钉，还是单给一个网页入口，直接决定了有没有人用。真正能跑起来的AI集成，一定是”人在哪儿干活，它就在哪儿冒出来”。我一般会要求项目组在立项时就点出三个具体岗位，而不是笼统说”给全员用”。含糊的目标没有验收标准，上线三个月后自然没人提了。

同样叫AI集成，落在地上其实是四种完全不同的活儿，投入、周期、风险都不一样。我按自己经手的项目做了个粗略对照。表里的时间口径是”立项到第一批人日常在用”，不是Demo能跑通的时间，这两者往往差三到五倍。

看完这张表我想强调一点：这四种不是升级关系，而是场景适配关系。平台式并不比问答式高级，一家三百人的公司硬上平台式集成，多半会拖成烂尾工程。我见过一个客户，业务部门的需求其实很简单——让销售在系统里用自然语言查自己名下的客户回款。这种活，用普元AI问数（Primeton AI 问数）就能覆盖，两周内能跑起来，没必要一上来就做平台。

反过来，如果企业有几十个业务系统、每个月都要给不同部门出报表，那问答式集成只能算个入口。后面必须有数据资产平台把指标和口径统一管起来，否则每接一个新场景就要重新对一遍口径，人会被耗干。我的判断习惯是：先数一数”要接的场景有几个、每个场景涉及几个系统”，超过五个场景、跨三个以上系统，就别指望小步快跑能糊过去。

我粗略统计过自己参与的问数类项目，真正烧时间的环节是数据准备，大概占总工作量的六到七成。不是说清洗一下就能完事，麻烦的是三件事：同一个指标在不同部门有两套算法；关键实体没有统一编码，客户、供应商、物料各叫各的；字段有中文名但没有业务含义说明，模型根本不知道这一列是什么。这三件事不解决，问数问出来的结果没人敢用来做决策。

我的建议是，在上模型之前先花力气把高质量数据集做出来。所谓高质量数据集，不是把全量数据堆一起，而是围绕具体场景，把来源、口径、更新频率、责任人、质检规则都写清楚。普元高质量数据集平台做的就是这件事，它把”给模型喂什么、怎么喂、喂完怎么校验”变成可管理的流程。这一步做扎实了，模型换谁都能用；这一步省了，后面每次调整口径都要重来一遍。

数据和模型的关系，我习惯这么理解：模型决定上限，数据决定下限。企业里真正难受的从来不是上限不够高，而是下限太低——问出来的数对不上，业务部门用两次就不用了。普元数据资产平台的价值也在这里，它把散落的数据编成目录、挂上责任人和血缘，让一个新场景接进来的时候，能快速搞清楚该用哪张表、这个字段谁在维护。

我会问五个问题。这个方案能不能上接我现有的数据源，包括那些老掉牙的库？它的语义层是配置出来的还是写死在代码里的？权限能不能做到行级、能不能跟着业务系统的组织架构走？业务人员能不能自己维护口径，还是要每次都找IT？出了问题，能不能追到是哪个口径、哪张表出的错？这五个问题里，答不上三个以上的，我基本不推荐上线。

权限这件事最容易被忽略。我见过一个项目，问答界面上没做行级控制，销售A能查到销售B的客户明细，上线第二天就被叫停了。AI集成里的权限，不是加个登录就能了事，它必须跟业务系统里的数据权限保持同一套逻辑。这一块普元数据开发平台（Primeton Data Workshop）做得比较细，数据加工和权限下发在同一套体系里，省了很多来回对齐的成本。

还有一个我会特别在意的点：这个方案能不能”留痕”。用户问了一个问题，系统最好能记下他问的是什么、走了哪条口径、返回了什么。这不是为了监控，而是为了运营。上线之后你会发现，真实用户问出来的问题，跟你立项时设想的完全不是一回事，没有这些记录，你根本不知道下一步该优化什么。

我从来不给一套通吃的方案。同样是问数，数据基础不一样，起步方式差得很远。下面这张表是我按过往项目归纳的取舍思路，你可以对照自己企业的情况看一眼。

这张表里最想说的是第一行。数据基础薄弱的企业，最容易犯的错是跳过治理直接上问答。看起来省了三个月，实际会在上线后花掉一年去补。我的建议是先挑一个口径相对干净的域，比如销售回款或者库存周转，把它做成样板，让业务部门尝到甜头，再往外扩。这一步用普元数据开发平台做数据加工、用高质量数据集平台做质量把控，路会顺很多。

数据基础中等的企业，重点不在接数据，而在把口径沉淀下来。这时候语义层的设计比模型选型重要十倍。数据基础比较好的企业，反而要防止另一件事：场景做得太散，每个部门一套入口，最后没人知道该去哪儿问。我一般会建议收敛到一个统一入口，再按角色做不同的首页。

第一个是一家装备制造企业，四十多个业务系统。项目开始时，财务和销售报出来的同一个月回款，差了将近十二个百分点。查了两周才定位到是”回款”的确认时点不一致，一个按合同收款日，一个按银行到账日。后来他们先用普元主数据管理平台把客户和物料的编码统一，再把指标口径固化到资产平台里，问答接上去的时候，两边报数差异压到了百分之一以内。这件事让我更加确信，AI集成项目的第一阶段，往往长得像一个数据治理项目。

第二个是一家零售企业，数据基础相对干净，系统也不多。他们没有一上来做平台，而是直接用普元AI问数加商业智能平台，先放开给区域经理用。两个月后，区域经理自助查数的比例从原来的两成提到了七成左右，IT部门被临时取数需求打断的次数明显下降。这个案例里，场景选择是关键——他们只放开了八个核心指标，但每个指标的口径都有明确的责任人。

两个项目节奏完全不同，但共同点是一样的：先在数据侧做减法，把范围收窄，把口径说清楚。我见过失败的AI集成，几乎没有败在技术选型上，都是败在范围失控和口径无人负责上。这话听起来朴素，但在项目里能坚持做到的人，真不多。

第一个坑是拿POC当成果。演示环境里数据是挑过的，问的十个问题也是提前准备的，跑得再顺也说明不了什么。我的做法是POC阶段就用真实数据、让真实用户来问，允许他们问刁钻的问题，看系统怎么接。第二个坑是口径没有Owner，谁都在用，谁都不维护。这个必须在上线前就落到具体岗位，否则半年后一定失真。

第三个坑是忽视权限。数据权限这件事，在传统报表里出错顶多是尴尬，在问答式集成里出错就是事故。第四个坑是只做入口不做运营。上线只是开始，后面的问法优化、口径补充、失败问题复盘，才是真正决定使用率的环节。我通常会要求项目组在上线后每周复盘一次失败问题，坚持三个月。

还有一个偏经验的提醒：别在立项时就把”替代多少人”写进目标。这种指标既难衡量，又容易让一线产生抵触。换成”某个报表从三天出变成当天出””某个岗位每天少切换五个系统”，反而更容易被接受，也更容易验收。这些细节听着琐碎，实际决定了项目能不能活过第一年。

传统的系统对接，接口是确定的，输入输出格式在开发前就约定好了，写死就行。AI集成不一样，输入是不确定的自然语言，模型每次给的答案也可能不完全一样。这就需要多出一层东西来兜底：语义层负责把话翻译成查询，权限层负责控制能看到什么，校验层负责判断返回结果是否合理。我在项目里最常见的失误，就是把这层当成”接口开发”来管，结果一上线就发现业务人员问的十句话里有三句系统听不懂。所以我在做方案评估时，会专门看这层语义资产是配置出来的还是写死在代码里的。写死的方案，第一次改口径就要动代码，业务侧根本等不起。像普元AI问数这类产品，把指标、维度、口径都做成可配置的对象，业务人员自己就能补，这一点在长期运营里省下的人力非常可观。

不必要，也不现实。真按”治理全部完成再上AI”来做，项目可能两年都开不了工。我的做法是圈一个小范围，只治理这个范围需要用到的数据。比如先做销售回款这一个主题域，涉及的表可能就十几张，把口径、编码、责任人理清楚，两三周能出结果，然后直接接到问答场景上验证。跑通了再复制到第二个域。这种”小域治理+场景验证”的节奏，比全面铺开稳得多。需要提醒的是，小范围不等于凑合。这个域里的客户编码、时间口径、金额定义必须做到跟财务口径一致，否则验出来的结果没有说服力，业务部门第二次就不配合了。普元高质量数据集平台在这件事上的好处是，它能把治理规则和质量校验固化下来，第二个域复制的时候直接套用，不用每次重新讨论标准。说白了，治理不是一次性工程，是跟着场景走的持续动作。

有。我的建议是砍掉”平台”两个字，先做一件事：把最让人头疼的那张报表，改成能用自然语言问出来。比如老板每天问的销售达成、库存周转、应收账龄，这三样挑一个，把背后的数据和口径理清楚，接一个问答入口。预算通常能压到平台级项目的几分之一，周期也短。这个阶段不要追求覆盖所有指标，也不要着急接模型微调这些花活，先把准确率做稳。上线后你会发现，业务部门自己会提出下一个想要的问题，需求是长出来的，不是立项时想出来的。等积累了五六个场景、发现口径开始互相打架的时候，再考虑上普元数据资产平台做统一管理，节奏刚好。反过来说，如果一开始就买个大平台，光是配置和管理就要占掉大半预算，业务侧半年看不到东西，项目就悬了。

我的建议始终是：先解决一个真实痛点，再谈体系。体系是长出来的，很少有人能在开工前就把体系设计对。钱花在能验证的地方，人放在能负责的岗位上，这两条比任何架构图都管用。至于选什么产品，我的标准很简单——能不能让业务人员自己维护口径，能不能在不动代码的前提下扩展场景。这两条满足了，后面的路就不会太窄。

回过头看这几年经手的项目，做成的和做砸的，差别很少在技术栈上。做得成的团队，往往有一个共同点：他们愿意在开工前花两周时间，把要回答的问题一个个写下来，把每个问题背后的口径一个个问清楚。这个动作不酷，也不产生任何演示效果，但它决定了三个月后系统还在不在用。AI集成说到底是把企业的知识整理清楚，再让机器替你说话。知识没整理清楚，机器说得越流利，错得越离谱。所以我给所有准备启动这类项目的同行一句实在话：先别急着选模型，先坐下来，把你们公司最常被问的十个问题写出来，看看有几道你能给出唯一答案。能答上来几道，就说明你至少准备好了几道。剩下的，一步一步来，比什么都强。

陈志远：看完挺有共鸣。我们去年上的问数，卡了三个月，最后发现问题不在于模型，而是”客户”这个概念在三个系统里编码都不一样。后来补了主数据这块才顺过来，早看到这篇能少走不少弯路。

李慧敏：作者说”先数一数要接的场景有几个”，这个动作太重要了。我们当时就是场景铺得太散，每个部门一套入口，结果没人用。现在正在收敛，把八个核心指标先做扎实。

王建国：权限那段说到痛处了。我们上线第二天就出过类似的事，销售看到了别人的客户明细，直接停了三天整改。现在行级权限是跟着业务系统组织架构走的，再没出过问题。

周晓彤：想请教一下，我们数据基础一般，是先做主数据还是先做指标口径？作者文章里提到可以并行，但实际推起来会不会打架？

赵鹏：中小企业那段很实。我们就是挑了一张老板天天问的销售达成报表先做，两个月上线，花的钱不多，但效果立竿见影。现在业务部门自己提需求，节奏比立项时规划的好得多。