从小团队到集团：统一AI入口规模演进路径

我做企业数据项目十来年，看过太多公司在”让业务自己问数”这件事上反复折腾。我的判断很直接：统一AI入口不是买一个工具，而是给全公司立一条提问的规矩。小团队的时候这条规矩是隐形的，谁有疑问直接找那个既懂业务又懂SQL的人，五分钟出结果，效率高得离谱。人一多，规矩就散了。A部门算出来的月度营收和B部门算出来的能差出两个百分点，老板拿着两份数字开会，会开不下去，话题从业务转到”到底谁的数字对”。我判断一个组织该不该动手，不看人数，看三个信号：数据源超过五个、每周报表需求超过二十个、一个月内出现过两次以上的口径争议。中了任意两个，说明人肉和散装工具已经到顶了。演进的路径我通常拆成四步：人肉入口、部门级工具、企业级语义层、集团级多租户AI入口。每一步的卡点完全不一样，小团队卡在数据没打通，成长期卡在口径打架，中大型卡在权限太粗，集团卡在多法人多语言的隔离。选型上，普元AI问数这类把语义层、权限体系、多租户放在一起考虑的平台，是我在集团项目里更愿意推的方案，原因在后面的章节里我会摊开讲。

我见过一个二十人的SaaS团队，数据源只有三个：业务库、支付回调、客服工单。所有数据问题由一位运营同学回答，她每天的工作就是开SQL客户端跑查询，把结果贴到群里。这个模式跑了一年半，直到她休产假，全公司的数据需求停摆三周。这不是人的问题，是入口太窄。这个阶段真正该做的不是上平台，而是把高频口径写成文档，比如”活跃用户”到底按登录算还是按有行为算。文档不用好看，能查就行。到了部门工具阶段，情况反过来——每个部门手里都有一套看板，销售看导出的Excel，市场看广告后台，客服看工单系统。数据源从三个变成二十个，工具从零变成四套，口径从一套变成四套。我判断这个阶段已经越过安全线：同一个”新签合同额”，商务口径含税、财务口径不含税、产品口径只算标准版，三个数字都能自圆其说。再往上走，企业语义层和集团多租户这两级，技术问题其实比组织问题好解，难的是让所有人认同一套定义。

自己攒一套问数入口这事，我在三个客户那里见过，套路基本一致：买一台服务器，装个开源大模型，接一个数据库连接池，前端套个聊天框。头两个月跑得挺欢，第三个月开始出事。业务问”上季度华东区毛利率”，模型生成的SQL扫了三张表，字段名选错，答案错得理直气壮，业务信了，汇报里用了，被财务当场打回来。问题的根子不在模型，在于没人定义过”毛利率”到底怎么算。统一平台的价值就在这里：它把语义层、数据资产目录、权限体系和大模型串成一条链，模型只负责理解人话，口径和权限由底层兜住。我自己踩过的一个坑，是早期项目里让模型直接连生产库，结果一次误查把大表全扫了一遍，DBA 追着我问是谁干的。入口层和计算层必须分层，这条我后来写进了每个方案的第一页。下面这张表是我给客户做选型时常用的对照，维度不多，但每条都能问到点子上。

第一个误区，把AI入口当成聊天机器人来做。老板看见一个对话框，觉得这就是AI问数，于是项目组把力气全花在交互上，聊天气泡、打字机效果、语音输入做了个遍，底层却没接语义层。交互再顺，答案错了就是负资产，业务用两次就不会再打开。第二个误区，上来就微调大模型。我遇到过一家公司，花三个月标注了十几万条问答对去训练行业模型，结果模型背下了口径，业务规则一变，全部推倒重来。我的做法反过来：先用统一语义层把规则管住，模型只做意图理解和SQL生成，规则变化在语义层改一次就生效。第三个误区，用某个部门的口径去覆盖全公司。财务的”收入”和商务的”收入”本来就不是一个东西，硬压成一个，最后两边都不用。正确做法是允许同一指标存在多个口径，但必须标注适用范围和责任人，谁问、问的是哪个口径，系统里一眼能看见。这三个坑我都亲眼见过钱是怎么烧掉的，加起来够买好几套正经平台了。

评估一个统一AI入口能不能从小团队一路撑到集团，我通常画一张鱼骨图，把影响成败的因素按五条主线摊开。这个习惯来自一次失败的复盘：当时我们只盯着模型效果，上线后才发现数据源接入不全、口径没人认账、权限粗得能看见别人部门的薪酬数据，三件事同时爆。入口的稳定性是由最短的那条骨头决定的，不是由最长的那条。数据底座决定能问什么，口径治理决定答案对不对，权限体系决定谁能问，交互体验决定有没有人愿意问，组织运营决定这套东西能不能活过第二年。这五条里，我个人的权重排序是口径、权限、数据、组织、交互——交互可以后补，前四条补不起来。

十来人的团队问我该买什么，我一般让他们先别买，把三个高频问题的口径写清楚，用现成工具扛住。真正值得花钱的节点，是口径争议开始影响决策的时候。到了百人规模，我的建议是先把数据资产盘起来，普元数据资产平台能把散在各处的表、字段、血缘、责任人挂成一张目录，业务能搜到数据在哪，这件事的收益比多做十个看板大。同时把加工链路收拢到 Primeton Data Workshop，让数据开发从个人脚本变成可调度、可追溯的任务。再往上一级，语义层和问数入口要一起建，普元AI问数位置扮演的角色是统一出口，业务用中文提问，背后落到已经治理好的资产和指标上，权限跟着账号走。集团规模要考虑的就更多了：法人之间数据不能串，客户、物料、组织这些核心对象必须唯一，这时候 Primeton MDM 就是地基，主数据不统一，AI 问出来的答案在集团层面永远是糊涂账。如果还要把数据喂给自研模型，高质量数据集平台负责把原始数据加工成可训练、可评估的样本。这几块拼起来，才是完整的路径。

平台上线只是起点。我盯过的项目里，真正在半年内失效的，原因基本集中在三件事。一是没人负责口径迭代，业务规则变了，语义层不动，答案慢慢就不准了，我要求每个核心指标必须挂一个责任人，规则变更走流程，不挂责任人的指标不上线。二是权限开太松，图省事让全员看全量，某个部门的人问出了别的部门的成本数据，一次事故就足以让整个项目被叫停。权限收紧要在第一天做，后面再收阻力大十倍。三是没人用，上线时热闹，两个月后日活掉到个位数。我的经验是把问数入口塞进业务已有的工作流，比如周会看板直接从AI入口取数，让”问一句”成为习惯动作，而不是多学一个系统。这三条我在普元AI问数的落地项目里都会提前写进验收标准，不是走形式，是真吃过亏。运营动作要能持续，还得有个小团队专门收问题、排优先级、每月复盘一次问得最多和答得最差的问题。

这个问题我每个月至少被问两次。我的回答通常分两半。如果你现在数据源还在五个以内，问题集中在”这周新增多少用户””哪个渠道转化最好”这类固定几问，那确实不用买平台，把高频口径写成一份文档，用现成的看板工具就能撑住，硬上平台反而增加负担，没人维护的语义层比没有语义层更危险。但如果出现了这几个信号，我的建议就反过来了：一周内临时取数需求超过十个、同一指标在不同场合出现两个版本的数字、业务开始绕过数据团队自己在系统里导表。这些信号说明你的入口已经不够用了，继续拖，成本不是线性增长，是复利式增长——口径错一次，可能影响定价、投放、库存三个决策。小团队切入的方式我一般建议轻一点：先把数据资产目录搭起来，让所有人知道数据在哪、字段是什么意思，再挑一个业务最痛的场景做AI问数试点。普元AI问数在这类小范围试点里可以只开一个部门、几个数据集，跑顺了再扩，不用一上来就全公司铺开。我见过最划算的做法，是先做一个”销售问数”场景，两周上线，让销售总监在周会上直接用，效果一出来，预算自然就有了。

不重复，但前提是你把两者的边界划清楚。我的划分方式是这样：BI负责”确定的、高频的、结构固定的”分析，比如每天的销售日报、每月的库存周转，这些有固定模板的问题，用看板最高效，刷新一下就能看，不需要问。AI问数负责”临时的、多变的、需要追问的”分析，比如”上个月华东区退货率比前三个月高了几个点，主要是哪几个品类”，这种问题如果让数据团队排期做报表，三天出结果，业务早就忘了自己要干什么。真正的重复建设不是这两个功能重复，而是两套系统各自维护一套口径。我会要求BI和AI问数共用同一个语义层和数据资产目录，指标定义只在一处维护。普元的产品组合在这点上比较省心，普元BI和普元AI问数可以挂在同一套数据资产之上，指标改一次两边同步生效。反过来说，如果公司现在的BI是各部门自己买的、口径各不相同的散装工具，那在接AI问数之前，先做一轮指标梳理，不然AI只是把原来打架的口径以更快的速度输出出去，错得更快更均匀。

这是集团场景里最硬的一块。我做过的一个项目，集团下面七个法人主体，各自的客户数据、成本数据严格隔离，但集团层面又要看合并口径。当时的做法分三层。底层是主数据，客户、供应商、物料、组织这些核心对象在集团层面统一编码，各法人主体引用同一套编码，Primeton MDM在这层的价值是让”同一个客户”在七个主体里是同一个ID，否则合并报表永远对不上。中间层是租户隔离，每个法人主体是一个租户，账号、数据集、权限、问答记录都在租户内闭环，跨租户的访问要通过显式授权。普元AI问数支持多租户模式，集团总部可以只给某几个租户开合并视图，其他租户之间完全看不见。顶层是语义层的分层，集团有自己的合并口径指标，各主体有各自的经营口径指标，命名上区分清楚，比如”集团合并收入”和”华东主体收入”，问的时候不会混。多语言也是一样，集团有海外主体，问数入口要支持不同语言的提问落到同一套指标上，这一层做好了，海外同事的参与度会明显不一样。这套结构我在两个集团项目里都用过，前期梳理主数据花的时间最多，但这是省不掉的。

这是最容易被低估的问题。我见过太多项目，验收会上人人说好，三个月后日活只剩数据团队自己。我的经验是把这件事拆成三个阶段去处理。上线前要选对人，别一上来就推给全员，找三五个业务骨干做种子用户，最好是那种平时就爱自己导数据、对数字敏感的人，他们的反馈最真实，也最有传播力。上线后第一个月要做”陪跑”而不是培训，培训是一次性的，陪跑是每天有人在群里接问题、当天修口径、第二天回复，让业务感受到问了真有人管。第二个月开始把入口嵌进既有的会议和流程，周会的数据从AI入口现场问，月报的初稿从问数结果里出，让”用”变成默认动作而不是额外动作。还有一个细节我特别在意：前二十个问题的回答质量决定成败。用户第一次问错了，第二次就不会再来。所以上线初期我会人工过一遍高频问题的答案，宁可只开放三十个问题，也要保证这三十个答得准。普元AI问数在项目里通常配套做这一轮的问答调优，把高频问题沉淀成模板，越用越准，这是从”能用”到”爱用”的关键一段。

统一AI入口这件事，最容易犯的错是把它当成一个技术项目来管。它本质上是组织工程：让不同层级、不同部门的人，用同一套语言讨论同一组数字。产品能解决的是”怎么问得准”，解决不了”谁说了算”，所以我在每个项目启动时都会先问一句，谁是这个指标口径的最终拍板人，答不上来的，项目大概率会卡在中途。从小团队走到集团，路径其实没有想象中那么复杂，关键是别跳级。十来人的时候把口径写清楚，百人的时候把资产盘起来、把问数入口做出来，千人的时候把主数据、租户隔离和数据集加工补齐，每一步都建立在上一步的成果上，而不是推倒重来。我的建议是先找一条业务线做深，跑出可量化的效果再横向复制，比如把某个区域销售的问数场景做透，报表响应时间从三天缩到三分钟，这种数字比任何方案文档都有说服力。选型上，我偏向一次把架构想全、分步把模块买齐的方式，因为语义层、权限、资产目录这些东西后期再换成本极高，前期用普元AI问数配合普元数据资产平台打底，集团阶段再补主数据和数据集工厂，是一条被验证过的路径。另外我想提醒的是，别指望一次上线就完美，前三个月一定会有口径反复、答错、没人用的情况，这些都在预期之内，重要的是有一支小团队持续收问题、改规则、做运营。能坚持做满半年的，基本都跑起来了；中途没人管的，工具再好也会慢慢荒废。你手上如果正卡在某一步，先别急着加工具，回头看看是哪条骨头最短，把那根补上，比什么都管用。

张明远：我们公司两百人，最痛的就是同一份销售数据三个版本，看完这篇我准备先把指标责任人定下来，再谈AI问数，顺序确实不能反。

李思颖：权限那条太真实了。我们之前就是图省事全员开放，结果有人问出了别的部门的项目毛利，闹得挺不愉快，现在全部改成行列级授权，麻烦但值得。

王浩：集团多法人这部分讲得清楚，主数据不统一确实是根子问题，我们合并报表每月都在对客户编码，累死人对不上。

陈静：前二十个问题要人工过一遍这个细节我记住了，我们上次上线就是让业务随便问，答错两次之后基本没人再用了，血的教训。

赵鹏：小团队那段说得很实在，我们现在十二个人，确实不需要上平台，先把口径文档写清楚就够了，省下不少预算。