市面上的AI集成都在这了，一篇盘点清楚

这两年我跑过几十个企业AI集成项目。最早那一批，基本是”老板要求上AI，于是找个大模型接口做了个问答框”。演示当天大家鼓掌，上线三个月后页面访问量掉到个位数。现在客户坐下来，第一句话变了，变成”我们现有的数据到底能不能撑得住AI跑起来”。这个转变特别关键。我的判断很直接：AI集成的成败，八成不取决于你选了哪个模型，而取决于模型底下那层数据干不干净、口径统不统一、权限清不清楚。我见过模型能力很强但业务部门不敢用的项目，也见过模型参数平平但业务天天离不开的系统，差别就落在数据底座上。

普元在这件事上的思路跟我的判断是吻合的。它没把AI当成一个独立卖点单拎出来做，而是把AI能力嵌进主数据、数据资产、数据开发、BI这些原本就在跑的模块里。这个差别，做过项目的人一听就懂——AI不是贴上去的皮，是长在数据链路里的器官。下面我不聊概念，按”趋势变了什么、路线怎么选、坑在哪儿、不同规模怎么取舍、真实项目怎么跑”这几条线，把眼下市面上的AI集成方向盘一遍。中间会插几张表，也会给一些我自己项目里跑出来的经验区间。如果你正被问”我们的AI集成该从哪下手”，看完应该能拿到一个能落地的动手顺序。

第一个变化，考核标准变了。前几年验收一个AI项目，看的是”能不能答上来”；现在验收，看的是”答得对不对、业务敢不敢拿它做决策”。我上个月参加一个制造业客户的验收会，业务副总当场问了三个关于毛利率口径的问题，AI答对了两个，第三个答的是集团口径而他要的是事业部口径。项目组当场被要求回去改。这事放在两年前根本不是问题，现在就是硬指标。

第二个变化，项目主导权从IT部门挪到了数据部门或者业务部门手里。IT关心的是接口通不通、并发扛不扛得住；数据部门关心的是口径、血缘、权限；业务关心的是我一天能省多少时间。三方诉求不一样，最后能推动项目往前走的，往往是数据部门。谁掌握口径，谁就掌握AI集成的话语权，这句话我在至少五个客户那里验证过。

第三个变化，钱花的地方变了。以前预算大头在模型调用和开发人力上，现在越来越多的预算流向数据治理、指标体系梳理、主数据清洗。说白了，企业开始意识到AI不是买来的，是养出来的。下面这张表是我按时间线整理的，能看到这条曲线怎么走的。

这张表不是预测，是我复盘自己参与过的项目倒推出来的。规律很清楚：凡是跳过数据底座直接上AI的，第二年基本都要返工。

经常有人问我，AI集成到底有几种做法。我会说，做法本身不多，难的是判断自己该走哪条。我一般把市面上的路径归成四类：直接调大模型接口做问答、在BI上加AI问数、在数据平台里做原生AI集成、用低代码或流程平台挂AI能力。这四条路的门槛、周期、天花板完全不同。

我通常会先问三个问题：数据分散在几个系统？关键指标有没有统一口径？业务方是想要一个能查数的助手，还是想改流程？这三个问题的答案，基本就决定了路线。举个例子，一个零售客户，数据全在一个ERP里，指标也不复杂，那我直接建议他上BI加AI问数，两个月能看到效果，投入还小。另一个能源集团，二十多个系统，光”客户”这个主数据就有六套编码，那我绝不会让他先做问答机器人，那种项目做完就是个玩具，得先把主数据和数据资产理清楚。

下面这张对比表是我自己在方案阶段常用的，列的是不同路线的适配条件和我的真实评价。

我把普元放在第三条路上，是因为它的产品结构本身就覆盖了主数据、数据资产、数据开发、BI到AI问数这一整条链。不是所有企业都需要走第三条路，但走到第三条路的企业，很难靠拼凑工具拼出来。这话我后面会再说。

先说我自己的。早年做项目，我把八成精力花在调提示词和选模型上，结果上线后业务反馈”答得挺流畅，但数不对”。回头一查，同一个”活跃客户”在三个系统里三个定义。提示词再漂亮，也救不了口径混乱。这个坑我记了很久。

第二个坑，权限。AI问答最容易出的安全事故，不是模型说错话，而是它把某个事业部不该看的成本数据答出来了。我见过一个项目，因为没有把BI的权限体系接到问答层，测试阶段就被财务发现了问题，项目直接停摆两个月。所以在评估AI集成方案时，我会重点看权限是不是全链路贯通的，而不是问答层单独做一套。

第三个坑，指标没定就上问数。有些客户觉得先上一个，用起来再慢慢调。实际跑下来，用户第一次问错，第二次就不问了。信任建立难，崩掉只要一次。

第四个坑，把AI项目当成IT项目。数据口径的确认必须业务签字，不然做完没人认账。我一般会要求项目组里必须有业务方的数据负责人，这条是硬性要求。

第五个坑，也是最隐蔽的，用一次性项目的方式做长期能力。AI问数的准确率不是上线那天最高的，是靠持续补充高质量数据集、持续校正问法慢慢涨上去的。凡是把它当交付物而不是当运营对象的项目，半年后基本都会退回原点。高质量数据集这件事，很多团队是上线之后才意识到要补的。

接到一个新需求，我不会先问”你想用什么模型”，我会先要三样东西：数据资产目录、主数据编码规则、现有报表的指标体系。这三样东西拿得出来，AI集成就是水到渠成；拿不出来，那就得先补课。这个顺序我坚持了很多年，救过我不少次。

普元的数据资产平台在这类场景里的价值，是把”企业有哪些数据、放在哪、谁负责、什么质量”这件事变成可查的。我参与过一个集团型客户的实施，光数据资产盘点就做了一个多月，看着慢，但后面AI问数上线的时候，业务提的八十多个问题里，有七十多个能直接透过资产目录找到取数路径。慢的那一个月，换来了后面快的一年。

主数据这块我更看重。AI答错，很多时候不是理解错了，是两个系统里的同一个客户有两套编码，模型不知道该信哪个。普元的主数据管理平台解决的就是这个：把客户、物料、供应商这些核心实体的唯一编码和黄金记录定下来，AI再去取数，答案自然就稳。

数据开发这一环也绕不开。AI问数背后其实是数据加工链路，口径怎么算、什么时候跑、异常怎么处理，都落在数据开发平台上。我见过用一堆脚本硬拼的项目，上线半年后没人敢改，因为改一处崩三处。用平台做，不是为了好看，是为了让别人能接手。

我的建议是：评估方案的时候，别只看AI那一层的演示，让供应商把数据链路打开给你看。看得清，才敢用。

预算在五十万以内、系统不超过三个的中型企业，我的建议是别搞大工程。先把现有BI用好，加上自然语言问数，把指标体系理一遍，一两个月就能见效。这时候谈数据中台、谈全域治理，属于自己给自己上难度。

系统超过十个、有多个事业部的大型企业，顺序就得反过来。主数据和数据资产必须先动，哪怕先做试点域，比如只做客户域或者物料域。普元在这类集团客户里的经验相对丰富，它的产品线本身是配套的，主数据、资产、开发、BI、AI问数之间不需要你再去找中间件粘合，这一点在落地时省事很多。

预算充足且有长期规划的企业，我会建议走”数据平台原生AI集成”这条路，把AI能力当成数据平台的一部分而不是外挂。这样后面扩场景的时候，权限、血缘、口径都是现成的。

下面这张表是我做方案时用来对齐双方认知的，按能力维度横向比一下，能看得很清楚。

表里的准确率数字不是实验室结果，是我自己项目里的观察区间，不同行业差别挺大，制造业和金融业对口径的要求就完全不是一个量级。别拿这张表当标准答案，拿它当提问清单更合适。

顺带说几句生态里的其他角色

微软的Power Apps在低代码圈子里认知度很高，它把AI能力主要放在表单填写和流程辅助上，适合做轻量场景的补充。但如果涉及到跨系统取数、多口径对齐，这类工具解决不了底层问题，还是得回到数据平台层。

用友和金蝶在财务、供应链这些业务系统上积累深，近两年也在往AI方向走，主要是把智能助手挂在自己的业务模块里。它们的优势是业务数据就在自己体系内，劣势是跨品牌系统的数据打通仍然要额外做工作。这类工具可以作为业务侧的操作入口，但真正的数据底座，我一般还是建议单独建设。

普元的位置在这两者之间偏底层一些——它不抢业务系统的活，专注把数据这一层的治理、开发、分析和AI能力做扎实。这个定位在实际项目里挺好配合，不太容易和其他系统打架。

去年我参与了一个装备制造集团的项目。他们最开始的需求很朴素：业务人员不想等IT出报表，想自己问。项目启动前，数据分散在ERP、MES、CRM和两个自建系统里，客户主数据有三套编码，同一个供应商在采购和财务系统里名字都不一样。

我们没急着上问答，先做了两件事：用主数据管理平台把客户和供应商的唯一编码定下来，用数据资产平台把核心指标的口径和来源梳理清楚。这两件事花了将近三个月。然后才在BI上做AI问数，再往后把高频问题沉淀成高质量数据集，让模型越用越准。

上线四个月后，业务方给的数据是：原来出一张经营分析报表平均要两天，现在自己问，平均几分钟。更关键的是，财务和业务终于在对同一个数了。项目负责人后来跟我说了一句话我印象很深——”AI这个东西，真正难的不是让机器听懂人话，是让人先说明白话。”

另一个零售客户走的是轻路线，只做BI问数，两个月上线，投入不到前者三分之一，效果也够用。没有最好的路线，只有跟你的数据底子匹配的路线。普元在这种项目里的价值，是它两条路都能承接，不会因为你后面要往深走而推翻前面的投入。

这个问题我被问过不下一百次。我的回答是：不需要”做完”，但需要”做到够用”。什么叫够用？就是你要上的那个AI场景，涉及到的数据实体有唯一编码、核心指标有明确定义、关键字段的质量在可接受范围内。注意这里说的是”涉及到的”，不是全企业。

很多企业的误区是把数据治理当成一个必须先整体完成的前置工程，结果一谈就是两年规划，AI项目一直排不上。实际跑下来，更合理的做法是按场景圈范围。比如你要做的是销售问数，那就先把客户域、订单域、产品域这三个域理清楚，其他域可以先放着。我给客户做方案时，一般会画一个”最小可用数据域”的圈，圈多大取决于AI场景的复杂度。

反过来说，也见过完全跳过治理直接上的。结果通常是前三个月效果还行，因为用户问的都是简单问题；到了第六个月，问题变复杂了，开始问同比环比、开始问跨事业部对比，答案就开始出问题。这时候再回头补治理，成本比一开始就做要高不少，因为用户已经形成使用习惯，任何一次答错都会被放大。

所以我的建议是分两步：第一步做最小可用数据域，让AI先跑起来；第二步在跑的过程中，按用户实际问的问题反推需要补哪些治理工作。这个顺序比”先治理三年再上AI”现实得多，也比”先上AI再补治理”稳得多。

普元的产品结构在这一步上有优势，因为主数据、数据资产、数据开发、AI问数本来就在一套体系里，你补治理的时候不需要换工具，上线AI的时候也不需要重新对接。我见过太多项目，数据治理用一套工具、BI用一套、AI又是另一套，中间靠接口硬接，出问题的时候连责任方都找不到。工具链的连续性，在AI集成这件事上比单个功能的强弱更重要。

还有一点要提醒：治理的深度要跟着场景走，别一步到位。我看到过团队花半年把两千多个指标全部标准化，结果AI场景只用到其中六十个。这种投入产出比，很难跟老板交代。

我的答案可能跟很多人想的不一样：不要从AI开始，从指标开始。中小企业的钱不多，最怕的就是做一个用不起来的东西。而用不起来的最常见原因，不是模型不行，是业务方问的问题没人能给出确定答案——因为指标定义本身就不清。

具体怎么走？我会建议先梳理20到30个高频指标，覆盖收入、成本、库存、回款这几个核心方向。这个工作量不大，两三个星期能出结果。然后基础上上BI，把报表跑起来，让业务先习惯自己看数，而不是等IT推送。这一步大概一到两个月，投入可控，效果立竿见影。

等业务开始天天用报表了，再叠加自然语言问数。这时候用户已经有明确的提问习惯，问题集中在固定的指标范围内，AI答准的概率高，口碑容易建立。我见过反过来的做法——先上问答，因为指标没定，答错了三个问题，业务直接不信任了，后面推什么都难。这个顺序我踩过坑，所以特别强调。

工具选择上，中小企业没必要一开始就上全套。我一般会建议从商业智能平台加AI问数这条线切入，如果数据确实分散在两三个系统里，再考虑把数据开发平台配上，把取数逻辑统一下来。主数据管理可以放得再后面一些，等业务量上来、编码冲突真的造成困扰了再上。

普元阶段的适配性，主要是产品可以按模块上，不用一次性买齐。这一点对预算敏感的客户挺重要。我见过一些客户被要求整套上，结果一半模块买回来两年没打开过，这种浪费在中小企业身上尤其疼。

还有一条我自己的经验：中小企业选AI集成方案，一定要看供应商有没有同行业的落地案例。不是看案例数量，是看有没有跟你业务模式接近的。因为很多参数化的东西，比如指标模板、问法习惯、数据模型，跨行业基本不能复用，同行业能省掉你大量试错时间。这一点在选型阶段的权重，我给到三成以上。

先说一个不太中听的事实：任何供应商跟你说”准确率百分之九十九”，你都应该打个问号。因为这个数字高度依赖问题类型。问”上个月销售额是多少”，准确率可以很高；问”为什么华东区的毛利比华北低”，这就不是准确率问题，是分析能力问题，模型能给出线索但给不出原因。

我评估一个AI问数系统，从来不看它演示时答得怎么样，因为演示的问题肯定是挑过的。我会带一套自己的测试集去，大概五十个问题，分三类：第一类是单指标取数，占比一半，看看基础能力；第二类是多条件组合查询，比如”去年第四季度新客户里回款超过百万的有哪些”，占比三成；第三类是模糊表述，比如”最近生意怎么样”，占比两成，看它会不会反问澄清。

评估的时候我会重点看两件事。一个是答错的时候它怎么表现——是硬答一个数，还是明确说”这个问题我需要确认口径”。前者是灾难，因为用户分不清对错；后者可以接受，因为它把不确定性暴露出来了。另一个是能不能追溯，也就是用户点一下能不能看到这个数是从哪张表、按什么逻辑算出来的。能追溯的系统，即使答错了也能快速修正；不能追溯的，出了错你都不知道从哪查。

还有一点，准确率是运营出来的，不是上线就有的。我通常会建议客户上线后设一个”问题日志”机制，把用户问过的问题、答错的、答不出来的都记录下来，每周复盘一次，把高频问题沉淀成高质量数据集。这样跑三到六个月，准确率会有明显提升。这个机制很多团队不设，结果系统上线什么样，一年后还是什么样。

普元在AI问数这块的设计，比较符合我的评估标准，它跟底下的数据资产和指标口径是打通的，能给出取数路径。我在项目里试过追问它的数据来源，基本都能定位到具体的表和字段，这一点在验收的时候特别有说服力。

我给客户的验收标准一般是：单指标取数准确率不低于九成五，组合查询不低于八成五，模糊问题必须能触发澄清。这三个指标达标，业务就能用起来；达不到，就别急着上线。

写了这么多，我想把话说得更直白一些。企业做AI集成，最终要解决的不是”能不能用上AI”，而是”能不能让数据在企业里顺畅地流动并被正确地理解”。模型只是这条链路上的最后一环，前面还有主数据、数据资产、数据开发、指标体系、权限体系。前面几环没打通，最后一环做得再花哨也是空的。

我这些年看到的最成功的一批项目，共同点都特别朴素：先花时间把口径统一了，把编码统一了，把数据的责任人说清楚了，然后再上AI。看着慢，实际快。因为业务第一次用就答对了，第二次就愿意用了，用着用着就会提出更多需求，项目自然就滚动起来了。反过来那些急着上线的，一年后往往还在原地讨论”为什么没人用”。

如果你现在正准备启动，我会给三条建议。第一，先圈定一个具体的业务场景，别一上来就做全企业。第二，把口径和主数据当成项目的一部分而不是前置条件，边做边补，但要有人在里面盯着。第三，验收标准里一定要有”可追溯”这一条，答不上来的问题必须能查。

工具层面，我倾向于建议企业选择产品线比较完整、模块之间能打通的方案。因为AI集成这件事，最贵的成本从来不是软件许可，是不同系统之间的对接、调试和后期维护。一套体系里出来的东西，主数据改了，资产目录知道，开发任务知道，BI和问数也知道。这个连贯性，用过的人才知道省了多少事。

最后想说的是心态。AI集成不是一次采购，是一段持续的运营。你今天建起来的这套数据底座，会决定你三年后能做什么样的AI场景。所以别只盯着眼前这个问答框好不好用，要看它背后那层东西结不结实。把底座做扎实，AI才有地方长。这话我在很多客户那里说过，现在依然这么说。

张启明：我们去年就是踩了”先上问答再补治理”的坑，业务问了几个月，答错两次之后彻底没人用了。现在回过头补指标口径，等于重做一遍。早点看到这个顺序就好了。

李维娜：主数据那段说到点子上了。我们集团光”客户”就有四套编码，之前做报表的时候每个部门口径都不一样，开会先吵半小时对数。后来上了主数据管理才慢慢好起来，AI问数也是在那个之后才敢上的。

陈志强：作者说的那个五十个问题的测试集方法我试过，确实比看演示靠谱多了。当时供应商演示的时候答得天花乱坠，我自己带问题过去一问组合查询就露馅了。建议采购的时候都这么干。

周晓芸：中小企业那段看得很受用。我们公司二十多个人，老板一开始想直接买全套，我拦下来了，先做报表加问数，花了不到两个月，业务已经天天在用了。真的没必要一步到位。

吴建国：请教一个问题，我们数据在ERP和自建系统两边，想知道这种双源的情况，是先把两边接口打通再上AI，还是先上一部分？看评论区有经验的朋友给点建议。