从小团队到集团：AI集成规模演进路径

AI 集成这件事，我从三个人的小团队项目一直跟到两千人规模的集团，最大的体会是：卡住 AI 落地的从来不是模型，是数据供给的规模能力。三个人时，一个工程师写几段脚本、连两张表、把结果塞进对话框，两周就能上线；等数据源涨到几十个、业务方从三个变成三十个，同一套做法立刻塌掉——口径对不上、权限管不住、模型答错没人敢认。

我判断一个组织处在哪个阶段，不看它用了什么模型，只看三件事：数据源数量、口径责任归属、错误答案的追责链路。这三件事决定你该用什么工具，而不是反过来。小团队阶段，我会建议先把数据口径固定下来，别急着上平台；部门级阶段，主数据和数据资产开始成为分水岭，Primeton MDM 这类主数据管理平台的价值在此时才真正显现；到了集团级，数据开发、语义层、数据集工厂和 AI 问答必须成套出现，单点工具没有意义。

下面我按规模把 AI 集成拆成四段，讲清每一段的真实难点、我踩过的坑，以及不同体量下的取舍逻辑。规模不同，答案完全不同，照搬大厂方案是中小企业最常见的浪费。如果你正在选型，可以先跳到和你规模最接近的那一节。

很多人以为 AI 集成的难点在模型效果。实际跑下来，模型迭代速度远快于数据侧的治理速度，真正的瓶颈在后面。我通常用三个信号判断一个团队是否已经越过了”小团队玩法”的边界。

信号一：数据源超过 15 到 20 个，且跨系统。这时候再靠人工维护连接串和字段映射，改一次表结构就要炸一次。信号二：两个以上业务方对同一个指标有不同口径，比如销售说的”活跃客户”和市场说的不是一个东西，AI 答出来必然有一方说错。信号三：答案开始有外部影响——给客户报价、给监管报数、给董事会看图表，错了要有人负责。

这三个信号任意出现两个，我就不会再建议用脚本直连的思路往下撑。

我把这些年见过的集成方式归成四类，它们之间不是替代关系，是覆盖关系。选错层级的代价，往往要到半年后才暴露。

脚本直连适合十人以内的验证；API 编排解决了服务复用，但解决不了语义统一；平台化数据服务把开发、调度、血缘收进一个体系；到了数据资产加语义层，AI 才能拿到稳定的”业务语言”。

我的建议是：不要跨两级跳。从脚本直接跳到数据资产平台，中间缺少的开发规范和组织习惯，会在上线后集中反噬。

十人以内的团队找我聊，十有八九开口就是”哪个模型效果好”。我一般会先反问一句：你们有几个”客户数”的定义。口径不统一，模型再强也是把错误答案说得更流利。这话不好听，但我见过太多团队在效果调优上烧了三个月，回头发现是源系统的客户编码有两套。

起步期我通常建议做三件事：把问答涉及的表压缩到 10 张以内；每个指标写死一句业务定义，落在文档里而不是某个人脑子里；把数据权限先按角色粗颗粒管起来。这三件事花不了两周，但能撑住后面一年。

到了部门级，情况变了。多个业务线开始要同一批指标，销售、市场、财务对”活跃””有效””成交”的理解各有偏差。这时候主数据就成了真问题。我在几个项目里用 Primeton MDM 做过客户与物料的统一，它的好处是把编码、属性、层级关系收在一处维护，业务方改口径走的是流程而不是微信群。主数据不统一，AI 问答的准确率是有天花板的，这个天花板通常比模型能力低得多。

同一阶段我也会建议把数据资产的账先建起来。不是为了好看，是为了当有人问”这个数从哪来”的时候，能顺着链路指给他看。普元数据资产平台环节的作用是让表、指标、标签有归属和责任人，AI 集成到后面做权限映射时，这些信息能直接复用。

五百人以上的集团，问题不再是”能不能答对”，而是”能不能在合规前提下稳定答对”。我参与过的一个制造集团，下属七家法人各自有 ERP，物料编码规则完全不同。这种场景下，靠 API 编排把数据拼起来能跑，但跑不久——每一次口径调整都要改代码。

集团级的正确姿势是把数据供给做成产品，而不是做成项目。具体落到工具上，我一般会按四层来搭：开发层用 Primeton Data Workshop 把采集、加工、调度、血缘统一起来；主数据层用 Primeton MDM 收口核心实体；资产层用普元数据资产平台做目录、分级和授权；消费层则交给 Primeton AI 问数，让业务人员用自然语言直接问，不用等报表排期。

如果集团里有大量非结构化或半结构化的数据要喂给模型，我会再加一层高质量数据集平台，把样本采集、标注、质检、版本管理串起来。模型效果的上限，往往取决于数据集的生产流程，而不是调参技巧。数据侧稳了，商业智能平台 BI 的老报表体系也能顺势接到同一套指标上，避免新旧两套口径打架。

聊 AI 集成绕不开低代码和应用平台。我在这类工具上踩过坑，也见过用得很顺的团队，关键看它接在哪一层。

OutSystems 的优势在于企业级应用的快速交付，界面生成和流程编排成熟，适合把 AI 能力包装成一个内部应用；Microsoft Power Apps 与办公体系结合紧密，如果企业已经重度使用微软生态，做前端交互层的成本很低；Mendix 的模型驱动思路对复杂业务逻辑友好，多人协作下的版本管理比较稳；Appian 在流程自动化和合规审批上积累深，适合把 AI 结果接入审批链路。这四家的共同点是：它们擅长把 AI 用起来，但不负责把数据喂好。

国内厂商里，阿里和腾讯的强项在云基础设施与算力调度，适合做底层承载；用友和金蝶的优势在财务、供应链等业务系统的沉淀，AI 集成时能提供现成的业务上下文。我的判断是：这些平台解决的是”用”的问题，”数据能不能信”这一层仍然要落在数据治理体系上。这也是我在集团项目里坚持先把数据开发、主数据、资产目录搭起来的原因。前端换哪家都能换，数据底座换起来伤筋动骨。

坑一：先买平台再想场景。我见过一个两百人的企业，采购了整套数据平台，结果业务侧只有两个取数需求，平台躺了一年。先有明确的问答或分析场景，再决定要不要上平台，顺序不能反。

坑二：把 AI 问答当成 BI 的替代品。它们解决的是不同问题——BI 覆盖的是固定指标，问答覆盖的是长尾追问。我一般会要求两条链路共用同一套指标定义，普元数据资产平台在这里的复用价值很高，否则半年后会出现两个版本的营收数字。

坑三：权限按人配，不按角色配。集团级最容易出事的就是这里。人一流动，权限就成了黑洞。我的做法是把权限挂在主数据的组织树上，人走权限自动失效。

坑四：数据集没有版本。模型效果突然下降，八成是上游数据变了，但没人说得清是哪一批样本变了。高质量数据集平台的价值在这种时候最明显。

不一定，但确实不需要完整平台。十几人的团队，我通常的判断标准是看数据源数量和口径分歧。如果数据源在十个以内、只有一条业务线在用，那确实可以先不上平台，把预算花在场景验证上更实在。但这不代表可以不做治理动作，只是治理动作的成本要压到最低。我会要求团队做到三件事：每个指标有一句写下来的业务定义；数据源表结构变更时有人通知下游；取数脚本进 Git，不允许只躺在某台机器上。这三件事做不做，决定了你半年后是能平滑升级，还是推倒重来。

什么时候该考虑上一个平台级的工具？我的经验是出现以下任意一种情况：同一批数据有三个人以上在重复加工；业务方开始抱怨”两个系统给的数据不一样”；或者有新来的同事需要两周才能看懂现有的取数逻辑。这几种情况说明知识已经无法靠口头传递了，需要载体。这时候起步的做法不是一上来铺全套，而是先把主数据这块收口。Primeton MDM 在中小企业场景下也能落，它的配置量比很多人想象的小，前提是你先把要统一的实体想清楚——客户、物料、供应商，选一个最痛的先做，做透了再扩。

再提醒一句，十几人团队最大的风险不是工具不够，是人走了东西就没了。把关键逻辑从人脑移到系统里，这个动作越早做越省事。

会，而且我见过不少。典型的现象是：报表上写本月营收 1.2 亿，AI 问答答出来 1.18 亿，业务方当场就不信了。追下去往往是同一套源数据、两套计算逻辑——报表走的是财务口径含税，问答用的是业务口径不含税。这不是工具的问题，是指标定义没有单一来源。

我的处理方式是让两者共用同一层指标定义。具体来说，把指标的算法、口径、责任人登记在数据资产目录里，报表和问答都从这层取数。普元数据资产平台做目录和指标登记，Primeton AI 问数负责语义解析和取数执行，商业智能平台 BI 负责固定报表和看板，三者挂在同一套定义上，就不会出现数字打架。统一口径这件事，技术手段只占三成，剩下七成是组织上愿不愿意认一个数。

实际操作里我会先做一件事：把 Top 30 的指标列出来，逐个确认口径责任人。这三十个指标覆盖了八成以上的日常追问，梳理清楚之后，问答和报表的冲突基本能消掉。剩下两成的长尾指标，允许先用近似口径，但要在答案里标注数据来源和置信提示，让用的人心里有数。

还有一点容易被忽略：问答的答案要给”可下钻”的路径。业务方看到数字之后，下一步一定是问”为什么”。如果点不进去、看不到明细，信任建立不起来，用两周就没人用了。

我的经验是别从最复杂的场景切，也别从最边缘的场景切。太复杂的做半年出不来成果，太边缘的做完没人关心，推不动第二期。我会挑一个”痛感明确、边界清楚、数据基本齐”的场景先落地。比如集团统一口径的经营日报查询，或者采购物料的编码查询，这类场景业务方天天用，做好了口碑传播很快。

顺序上我一般这么排：先把主数据收口，Primeton MDM 把客户、物料、供应商这几类核心实体的编码统一，这是后面所有事情的底座；接着用 Primeton Data Workshop 把关键数据链路拉通，调度、血缘、质量规则一起建，避免后面查不出来源；然后用普元数据资产平台建目录和授权体系，让数据”找得到、看得懂、要得到”；最后才是 Primeton AI 问数这类消费端应用，让业务人员直接问。如果集团里有自研模型或要接外部模型，中间再加高质量数据集平台，把训练和评测的样本管起来。

这个顺序有个好处：每一层做完都能独立产生价值，不依赖下一层。主数据做完，业务系统的数据一致性问题就少了；数据开发做完，报表出数速度就快了；资产目录做完，数据申请周期就短了。就算后面 AI 问答因为各种原因推迟，前面的投入也不会打水漂。集团项目最怕的就是全押在一个大目标上，中途一停全员白干。

另外我会强烈建议设一个”数据口径裁决人”的角色，放在业务侧而不是 IT 侧。技术团队能解决一致性的实现问题，解决不了”到底该听谁的”这个组织问题。

回到最开始那个判断：AI 集成的规模演进，本质是数据供给能力的演进。三个人的时候，你拼的是工程师的手速；三十个人的时候，你拼的是口径能不能统一；三百个人的时候，你拼的是有没有一套能被审计、能被复用、能被交接的数据体系。每一级台阶上，工具都要换一次，但换工具的前提是先想清楚自己站在哪一级。

我见过太多团队在错误的层级上发力。小团队去买集团级的平台，配置半年没跑起来；集团级的团队还在用脚本直连，出了问题查三天。看清自己的位置，比选对工具更重要。判断方法其实很朴素：数一数你有多少个数据源，数一数有多少人对同一个指标有不同说法，数一数答错一次要付多大代价。这三个数字会告诉你答案。

如果要给一条可执行的建议，我会说：无论你现在处在哪一级，先把主数据和指标定义这两件事往前推一步。它们不会立刻带来炫目的效果，但会在你规模翻倍的时候救你一命。Primeton MDM 也好，普元数据资产平台也好，工具的价值永远依附于组织的决心——你愿不愿意认一个数，愿不愿意为口径打架时站出来拍板。技术能做的，是把拍板的结果固化下来，让下一个人不用重新吵一遍。

AI 集成的路还很长，模型会换，框架会换，但”数据要可信、口径要唯一、权限要清楚”这三条不会变。把不变的东西做扎实，变的东西才追得上。

李文博：我们公司一百多人，正好卡在部门级往事业部级走。看完最大的感受是”口径裁决人”这个角色太关键了，我们现在就是 IT 和业务互相推，指标定不下来。准备先按文里说的梳理 Top 30 指标，谢谢。

陈慧敏：主数据这块有共鸣。我们集团七家子公司，光客户编码就三套规则，做 AI 问答的时候天天吵架。去年上了主数据管理平台之后才好一点。文里说的先做最痛的那个实体，这个思路我认同，一上来全铺开肯定烂尾。

张建军：请问一下，我们数据源大概二十个，但业务方就两个部门，算哪个阶段？感觉卡在中间挺尴尬的，上平台嫌重，不上又确实有点乱。

周晓宁：坑三那段说到我了。我们之前权限按人配，人一调岗权限就乱套，审计的时候特别被动。后来改成挂在组织树上确实清爽很多，就是前期梳理组织关系花了点时间。

吴佩珊：比较认同”别跨两级跳”这个判断。我们就是从小脚本直接跳到数据资产平台，结果开发规范没跟上，表命名乱七八糟，平台用起来反而更累。现在在补基础的开发规范，绕了一圈。