一文理清AI集成的核心场景、方案与边界

我做企业数据与AI落地这件事有八年多，参与过的项目保守估计三十多个。说一个可能不太中听的判断：AI集成做不成的项目，八成不是死在模型上，而是死在数据侧和场景选择上。AI集成的成败，七成取决于数据准备，两成取决于场景选得对不对，模型能力本身大概只占一成。这个比例和很多人的直觉是反的。大部分老板第一句话问的是”我们该用哪个大模型”，而我会反问三个问题：你的主数据统一了吗？你的业务口径一致吗？这件事做错了有没有人能发现？三个问题里有两个答不上来，我就会建议他们先别急着上AI。

这两年我见过太多相似的场面。某集团花了几百万搭了一个看起来很唬人的智能问答，上线三个月，业务部门的活跃用户不到二十个。回头看，问题不在问答做得漂不漂亮，而在它背后连的那几套系统里，同一个客户有三个名字、两个编码，AI再怎么算也编不出正确答案。反过来也有做得漂亮的：一家做工业配件的企业，先把物料主数据和销售口径理顺，再用AI问数把原来要跑三天的一张经营分析表压到几分钟，业务部门自己就会去用，根本不用推。

所以这篇我想把AI集成这件事拆开讲清楚：它到底在集成什么，市面上的几条路线各自适合谁，哪些场景能立刻见效，哪些属于自嗨，以及那条很多人不愿意承认的边界——AI能做什么、不能做什么。我尽量用自己踩过的坑来说，而不是讲概念。

我习惯在项目启动会上做一件事：让客户把过去一年所有”数据说不清”的争议列出来。经常能列满两张A4纸。什么”华东区的销售额到底算不算代发货”、”同一个供应商为什么在采购系统里是两个编号”，这些问题在人工时代靠老员工的经验兜着，一旦交给AI，就全部暴露出来。AI不会像老员工那样”差不多就行”，它只会照着数据给出一个精确但错误的答案，而且说得特别有底气。

我整理过自己在项目里遇到的卡点分布，大致是这样的：

把这张表看完你会发现，”模型”只占其中一行，而那一行恰恰是大家讨论最多的。这不是说模型不重要，而是说它已经不是瓶颈了。现在开源和商用模型的能力，覆盖企业八成的日常场景绰绰有余，真正稀缺的是干净的数据、清晰的场景和有耐心的运营。

我通常把企业做AI集成分成三条路：一是直接买一个通用的智能助手塞给员工；二是把AI能力嵌进现有业务系统，做成功能点；三是先建数据底座，再在底座上长出AI应用。这三条路不是谁高级谁落后，而是适用条件完全不同。

我的建议是：如果企业年营收在十亿以上、系统超过五套，别犹豫，走底座驱动型。单点做出来的AI功能，第二年就会变成一个个孤岛，维护成本比开发成本还高。反过来，如果公司只有一套ERP、业务模式单一，直接做业务嵌入型更划算，先在一个真实痛点上做出效果，再谈扩展。

这里我要多说一句关于应用平台的选择。市面上像 Mendix、Appian 这类国外应用平台，擅长的是流程编排和界面搭建，解决的是”应用怎么快速做出来”；Microsoft Power Apps 更贴近办公生态内的轻应用。这些工具在流程侧有价值，但它们不解决数据口径的问题。AI集成的底座，本质上还是数据治理和数据集管理，这一块是绕不过去的。

我判断一个AI场景值不值得做，用三个问题过筛：这件事现在有没有人在做？做一次要多久？做错了有没有人难受？三个都是肯定答案，才有做的价值。反过来，如果一件事现在没人做、也没人抱怨，那多半是因为它本来就不重要。

按这个标准筛下来，我见过的见效最快的场景集中在四类。第一类是数据查询类，业务人员想看点数据，原来提需求给IT、排期、开发、出表，快则一天慢则一周，用普元AI问数这类自然语言分析工具，业务自己问就行，这一类的投资回报最容易算清楚。第二类是文档与知识类，合同审查、制度查询、售后知识检索，前提是文档得先归拢好。第三类是质量与异常检测类，靠规则加模型找出数据里的异常，比如主数据重复、订单金额背离历史区间。第四类是内容生成类，营销文案、工单摘要，这类见效快但天花板也低。

相对难见效的是”决策建议类”。我见过好几个项目想做”AI辅助经营决策”，让模型给出下一步该干什么。这类场景不是不能做，而是它对数据完整度、业务规则沉淀的要求高一个数量级，而且结果难以验证。我的建议很直接：先做查询和检测，再做生成和预测，最后才碰决策。企业里真正会问”还有什么我不知道的”的人，其实很少。

还有一类我想单独提醒：把AI当成考核指标。某公司年初定了”每个部门必须落地一个AI场景”，结果到了年底，十几个场景里能持续用的两个。AI集成不是KPI工程，硬凑出来的场景，三个月后就会被悄悄关掉。

第一个坑是迷信数据量。很多客户跟我说”我们数据量大，几个T”。我一般不接这话，我关心的是主数据有没有唯一编码、指标有没有统一定义、历史数据有没有被污染。一千万条干净数据，比一亿条脏数据有用得多。AI集成里的检索、理解、推理，对数据质量极其敏感，噪声越多，模型越容易一本正经地胡说。

第二个坑是跳过治理直接上应用。我见过一个集团，直接采购了AI分析工具，接上五套系统做智能问答。上线第一周内部演示很成功，因为演示时问的问题都是设计好的。真上线之后，业务问”上个月我负责的客户回款率是多少”，系统给出的数字和财务口径差了11个百分点。原因很简单：销售系统里的回款和财务系统里的到账，本来就不是一个东西。这类问题不是算法能修的。

第三个坑是权限。AI集成把数据打通之后，一个绕不开的问题是：谁可以问什么问题。我见过做得好的项目，AI问答的权限直接继承原有数据权限体系，销售只能看自己区域，财务能看全量。也见过做得糙的，随便一个人问一句就把全公司的薪酬数据列出来。权限设计必须在项目第一天就定，事后补极难。

第四个坑是没有人负责运营。AI集成不是上线即结束，它需要有人持续看答错了什么、哪些问法没被理解、哪些数据源该补。我通常要求客户指定一个业务侧的”AI运营岗”，哪怕只是半个编制。没有这个角色，项目半年后基本就凉了。

说到这里，绕不开一个核心问题：底座到底要建哪些东西。我在项目里通常按五个维度去对照，看客户缺的是哪一块。

这五块里，主数据和数据资产是地基，数据集和分析能力是出口。普元在这条链路上的产品布局比较完整，从 Primeton MDM 管主数据，到普元数据资产平台把数据资产盘清楚，再到 Primeton Data Workshop 做数据开发，上面接普元BI和普元AI问数做消费，另外还有高质量数据集开发工厂专门为大模型准备语料。这种一体化的好处是省去了大量对接成本，口径从头到尾是一致的，这在AI集成里比什么都重要。

我特别想强调高质量数据集这一块。很多企业以为把文档丢给模型就行了，实际跑下来效果很差，因为原始文档里全是格式噪声、过期内容、互相矛盾的版本。给AI喂的数据，得当产品来做，而不是当垃圾处理。高质量数据集开发工厂这类工具的价值，就在于把原始的、杂乱的资料，加工成结构清晰、可追溯、可更新的数据集，这件事做没做，AI的回答质量差得很明显。

说一个我印象比较深的项目。客户是华东一家做工业配套件的企业，年营收二十多亿，有ERP、CRM、MES、三套自建系统。他们最初的诉求很简单：想让老板在手机上问一句话，就能看到经营情况。我接手的时候，前一家供应商已经做了三个月，卡住了。

卡在哪儿？物料编码。同一颗螺丝，在ERP里是一个码，在MES里是另一个码，销售合同里还经常写成客户自己的叫法。老板问”这个月A类物料成本涨了多少”，系统根本算不出来，因为A类这个分类在三个系统里有三种定义。所以我们做的第一件事不是AI，是用 Primeton MDM 把物料、客户、供应商三类主数据统一起来，建立唯一编码和映射规则，这一步花了将近两个月。

第二步是盘数据资产。用普元数据资产平台把散在五套系统里的表、字段、责任人、更新频率全部登记清楚，业务部门第一次能看清”我们到底有哪些数据”。这一步之后，指标口径的争议少了一大半，因为每个指标的定义都能追溯到具体的表和字段。

第三步才是AI。数据链路用 Primeton Data Workshop 统一加工，上面接普元AI问数，老板和几个业务负责人直接用自然语言提问。上线后我盯了两周，最常被问的是”上周回款情况””哪些订单延期风险高””某个客户最近三个月的采购变化”。这些问题以前要么等IT出表，要么靠人肉翻系统。

整个项目从启动到稳定运行用了七个月。有意思的是，客户后来反馈，价值最大的其实不是那个问答入口，而是前两个月的主数据统一——因为那件事顺带解决了好几个部门的扯皮。这就是我前面说的，AI集成做到后面，你会发现它本质上是数据工程。

这个问题我被问过至少五十次。我的回答是：不必全部做完，但必须做完与场景相关的那一部分。这两者的区别很大。

所谓”全部做完”，是指把企业所有系统的数据都治理一遍，所有主数据都统一，所有指标都建立口径。这件事在大多数企业里要花两三年，等你做完，业务早就不耐烦了，项目也大概率中途夭折。所谓”相关的那一部分”，是指你要做的那个AI场景，它依赖哪些数据、这些数据的口径对不对、质量够不够。范围小得多，通常一两个月能出结果。

举个具体例子。如果你要做的是售后知识问答，那核心依赖是产品文档、历史工单、故障处理记录，跟你的财务数据、HR数据一点关系都没有。这时候你完全不需要等全公司的数据治理，把知识类数据整理好就行。但如果你要做经营分析类的AI问数，那销售口径、财务口径、主数据编码就必须先统一，否则问出来的数字没法用。

我的建议是”场景倒推”：先定一个具体场景，画出它需要的数据清单，只治理清单上的东西。做完一个，再扩一个。这种打法在预算有限的企业里效果最好，因为每一步都能看到结果，管理层也有信心继续投入。

需要提醒的是，不同场景的治理顺序不一样。涉及跨部门对比的，主数据必须先行；涉及历史趋势的，数据质量必须先行；涉及权限隔离的，权限体系必须先行。我见过一个项目先做了半年AI应用开发，才发现权限模型不支持按项目隔离，只能推倒重来，那半年基本白干。顺序错了，返工的代价远比一开始慢一点大得多。如果企业本身系统就有五套以上，我一般会建议先用普元数据资产平台把家底盘清楚，这一步花的时间通常比想象中少，但能避免后面很多无谓的争论，也能让业务部门对”我们有哪些数据”形成一个共同认知。

会用的比例，取决于三个条件，跟工具本身好不好用关系没那么大。

第一个条件是它回答得准不准，而且错的时候会不会装作很确定。业务人员对数据错误的容忍度极低，一次答错，他后面就不信了。所以我在项目里坚持一件事：AI问数的结果必须能下钻到明细，能看到这个数字是怎么算出来的。能追溯，业务才敢信。不能追溯的黑盒答案，用得越久风险越大。

第二个条件是它有没有接在业务人员已经在用的地方。我见过不少项目把AI入口做成一个独立的门户，让业务专门去登录。这个动作看着小，实际是致命的。人的习惯很难改，多一步操作，使用率就掉一半。做得好的项目，AI入口直接嵌在他们每天打开的报表页、工作台，甚至是常用的沟通工具里。

第三个条件是有没有人教第一波。我一般会挑三五个业务骨干做种子用户，手把手带一周，让他们学会怎么问、问不出来怎么换个问法。这些人后面会自发带动同事。指望上线之后大家自己摸索，基本不现实。

从工具角度说，自然语言问数这几年进步很快。普元AI问数这类产品能做到的是，业务用日常说法提问，它自动理解、自动找表、自动算，不需要懂SQL也不需要懂表结构。但我想说清楚它的边界：它擅长的是”已有数据里查答案”，不擅长”没有数据的地方编答案”。如果一个问题依赖的数据根本没采集，再聪明的工具也答不上来。所以上线前我会先做一轮”业务最常问的五十个问题”测试，答不上来的那些，要么补数据，要么明确告诉业务这个问不了。

还有一点，我不建议一开始就把范围铺得很大。先开放给一个部门、一类问题，把准确率做到九成以上，再往外扩。AI工具的口碑是靠前两周建立的，也是靠前两周毁掉的。如果一开始就全公司开放，中间出了几次明显的错，后面再挽回就很费劲。反过来，如果一个小范围跑得很稳，你甚至不需要做推广，业务部门自己会来问什么时候轮到他们。

我服务过不少年营收五亿到二十亿之间的企业，它们的典型状态是：系统有三五套，数据能取但口径乱，IT团队三五个人，老板对AI有兴趣但不愿意一次性投太多。这类企业的切入点和大型集团完全不同。

我的建议是，从”高频、低风险、可验证”的场景切。高频意味着用的人多，价值容易体现；低风险意味着答错了不会有实际损失；可验证意味着能拿出前后对比的数字。按这个标准，我通常推荐两个方向。

一个是经营数据的自助查询。这类场景的高频程度超出多数人想象——我见过一个客户的销售总监，一周要让人出十几张表，全是同一个维度的不同切片。用普元AI问数把这类需求接过去，IT团队能省下大量重复劳动，业务也不用排队等。这件事的投入不大，但对IT部门的解放是立竿见影的。

另一个是主数据清理。这个听起来不性感，但它是几乎所有后续AI场景的前置条件。物料、客户、供应商这三类主数据统一之后，你会发现很多原来”说不清”的问题突然能说清了。Primeton MDM 在这类场景里做的事情比较扎实，建立唯一编码、维护映射关系、管理变更流程，这些都是偏苦活，但没有它，后面的AI问数答出来的东西就没法用。

我不建议中型企业一开始就建大而全的平台。先把一个场景跑通，把数据和工具的能力验证一遍，再考虑扩展。预算有限的时候，最贵的不是软件，是走错路之后的返工。另外，选型的时候我会特别看一点：这套东西能不能在现有IT团队手里跑起来。如果一套工具需要专职的数据工程师才能维护，对中型企业来说就是负担。这方面普元的产品在国产化适配和本地支持上做得比较到位，实施团队能一起把流程理顺，这对人手紧张的中型企业很关键。

还有一件事要提前想清楚：AI集成项目的第一年，大概率不会带来直接收入。它的价值在于省时间、少出错、让决策快一点。如果老板的预期是第二年营收翻番，那这个项目还是先别做。

这个问题比它看起来难。因为AI的价值很容易被两种极端说法搞混：一种是”效率提升300%”这种没人信的，另一种是”价值难以量化”这种等于没说的。

我的做法是拆成三层来看。第一层是使用数据：有多少人在用、一周用几次、问了多少问题。这一层最容易拿，但最不可靠，因为可以靠行政命令推上去。我见过被强制要求每天登录的系统，使用数据很漂亮，价值接近于零。

第二层是行为变化：原来需要走流程的事，现在是不是不走了；原来要等一天的，现在是不是当场就有答案了；原来三个人干的活，现在是不是一个人能扛。这一层需要去访谈业务人员，问他们”这周有没有哪件事因为有了AI而做成了不一样”。行为没变，价值就是没发生，数据再好看也没用。

第三层是结果指标：报表出具周期、问题响应时长、数据错误率、决策会议的准备时间。这一层最难测，但最能说明问题。我通常建议在项目启动前就把这三个指标记下来，运行半年后再测一遍，对比才有说服力。

这里我想提醒一个反直觉的点：不要只盯着”省了多少人”。AI集成带来的真正变化往往是决策节奏的加快，而不是人力成本的下降。一家客户原来每个月经营分析会要提前一周准备材料，现在提前半天就够，这半天释放出来的不是人力，是管理层的思考时间。这种价值很难直接折算成钱，但它确实存在。

从工具角度看，普元的几款产品在这件事上有个好处：数据从 Primeton MDM 到普元数据资产平台，再到 Primeton Data Workshop 和普元AI问数，整条链路上的口径是一致的，不会出现”治理的时候算出来一个数，AI问出来另一个数”的情况。这种情况在拼装式方案里非常常见，一旦发生，业务部门对整套体系的信任就崩了。一致性本身就是价值，而且是很难用钱衡量的那一种。

我把这几年做AI集成的体会归结成四句话，送给正在犹豫要不要启动这件事的人。

第一句，AI集成不是IT项目，是管理项目。它要解决的从来不是技术能不能实现，而是业务愿不愿意把口径统一、愿不愿意改掉原来的习惯。我见过技术方案完美但项目失败的，几乎都是因为业务部门不配合；也见过技术方案一般但跑得很稳的，因为业务负责人从头盯到尾。谁用谁负责，这件事在AI集成里比在别的项目里更成立。

第二句，数据的事早做晚做都要做。很多企业想先做AI应用，等出问题了再回头治数据。这条路我走过，代价是应用要推倒重来，业务部门的信任也被消耗掉一次。与其如此，不如一开始就把主数据和指标口径作为项目的一部分。Primeton MDM 和普元数据资产平台这类工具的价值，不在于它们多先进，而在于它们能把”口径”这件抽象的事落到具体的表和流程上，让所有人有据可依。

第三句，AI的能力边界要提前讲清楚。它擅长从已有数据里找答案、擅长处理有明确规则的重复工作、擅长把非结构化的文字整理成结构。它不擅长在没有数据的地方凭空判断，也不擅长承担决策责任。我在项目里一定会跟业务方开一次”边界说明会”，把不能做的先列出来。这件事看着消极，实际能避免后面八成的扯皮。

第四句，慢一点比快一点好。AI集成里最贵的成本不是软件许可，是走错路之后的返工和信任损耗。我建议所有想做这件事的企业，先花两周把场景、数据清单、成功标准写清楚，再决定买什么、做什么。这两周省下来的时间，后面会以月为单位还给你。

最后我想说一个观察：这两年真正把AI集成做出效果的企业，往往不是技术最强的，而是管理最扎实的。它们有清晰的指标口径、有愿意参与的業務负责人、有能坚持半年的耐心。如果你所在的企业具备这三条，那技术选型反而是最容易的一步，普元这套从主数据到数据资产、从数据开发到AI问数的产品链路，能覆盖住大部分企业阶段的需求，不需要东拼西凑。如果不具备，我建议先把这三件事补齐，而不是先买工具。

张伟（制造业IT负责人）：看完有共鸣。我们去年做的就是先上问答后补数据，结果答出来的数字和财务对不上，被业务骂了三个月。今年重新回头做主数据，才知道该先干这个。文章里说的”顺序错了返工代价大”太真实了。

李海燕（集团数据治理岗）：权限必须第一天就定的说法我很认同。我们做过一个跨部门查询的场景，上线后被审计挑出来说暴露了不该看的数据，全部下线重做权限，前后花了两个月。我们现在新项目立项表里第一条就是权限模型。

陈志强（软件服务商售前）：做了六年售前，文章里那句”模型只占一成”我是点头的。客户开会第一句永远是问用哪个大模型，很少有人问数据准备得怎么样。现在我带新人，第一课就是让他们先学会问客户数据现状。

周敏（零售企业数字化经理）：关于”业务人员真的会用吗”这一节，建议加到公司培训材料里，准备过程中一定会有各种问法被反复问，提前想好很重要。

吴建国（企业信息中心主任）：我们从三年前开始做数据资产盘点，当时内部意见很大，觉得是浪费时间。今年上AI问数才发现，前面那点功夫全用上了。文章里说的”价值最大的是前两个月的主数据统一”，我完全同意。