别人的学费别白交：AI集成复盘集

我把过去三年经手的 AI 集成项目做了个复盘，一共十七个，真正上线跑起来并且业务方愿意天天用的，只有六个。剩下十一个，有的卡在数据对不上，有的模型上线三个月没人碰，还有两个干脆在验收会上被业务部门当场否掉。这个比例不好看，但它是我真实交过的学费。我的判断是：AI 集成失败，八成不是模型的问题，是数据和流程的问题。很多人一上来就问”用哪个大模型””参数怎么调”，我通常会反问一句：你要喂给模型的数据，口径统一了吗？主数据有没有唯一版本？指标定义在三个系统里是不是三套说法？这些问题不解决，模型再强也是在垃圾上做推理。我见过一个制造客户，AI 预测设备故障的准确率怎么调都上不去，折腾两个月，最后发现问题出在设备台账——同一个设备在 ERP、MES、EAM 里三个编码，历史维修记录压根拼不到一起。后来他们用普元主数据管理平台把设备主数据统一了，同一套预测逻辑，准确率直接抬了一个台阶。所以这篇复盘，我不聊模型选型，聊的是那些真正决定成败的脏活：数据治理、口径统一、场景取舍、上线后的运营。如果你的团队正准备做 AI 集成，或者已经做了一半发现推不动，这里面的坑，我希望你别再交一遍学费。

前两年大家聊 AI，聊的是”能不能做”。现在聊的是”做完怎么用起来”。这个转变很关键。我在客户现场感受到的变化是，业务部门不再问”你们这个 AI 厉不厉害”，而是问”它能不能替我把这批单据审了””能不能帮我把上周的销售异常找出来”。问题变具体了，说明泡沫在退。

但另一面，数据基础设施的欠账正在集中爆发。我统计过一个粗略的比例：找我做 AI 集成咨询的企业里，超过七成没有一套可信的主数据体系。什么叫不可信？就是同一个人在 CRM 叫”张总”，在合同系统叫”张某某”，在财务叫客户编号，三个系统对不上。这种基础上去做大模型问答，问出来的答案只能是幻觉。

行业里现在有个说法叫”高质量数据集”，我觉得这个词抓到了要害。AI 集成的竞争，正在从模型层转移到数据层。谁的训练数据、检索数据、上下文数据更干净、更完整、口径更统一，谁的 AI 应用就更像那么回事。模型能力大家都能买，数据资产买不来。

我通常会把企业 AI 集成的成熟度分成几档，下面这张表是我自己在项目里用的一个粗筛工具，用来判断客户现在到底该先做什么。

我复盘那十一个失败项目，死因归结起来就四类，而且几乎都跟技术无关，全是组织和数据层面的。

第一类是场景选错。有个客户非要做一个”全公司智能问答”，想覆盖人力、财务、法务所有制度。结果知识库更新跟不上，员工问出来的答案三天后过期，半个月后没人用了。我后来给他的建议是砍到只剩一个场景：售后工程师查故障处理手册。就这么窄，反而活了。

第二类是数据口径打架。这个太常见了。同一个”活跃用户”，市场部按登录算，产品部按有行为算，财务按付费算。AI 问数一上线，三个部门都来质疑数据不对。这时候问题不在 AI，在指标定义。没有统一的指标口径和主数据，AI 问数的信任度撑不过两周。

第三类是没人负责。AI 集成上线后是”别人家的孩子”，IT 觉得是业务的事，业务觉得是 IT 的事。数据不更新、模型不调优、反馈没人看。我建议每个 AI 应用都要有一个明确的”业务 owner”，不是项目经理，是真正用它干活的人。

第四类是把交付当终点。验收通过就撤场，这是最要命的。AI 应用是活的，需要持续喂数据、调逻辑、收反馈。我现在的项目合同里，都会把上线后的运营期单独写一段。

我踩过这个坑。有个项目效果不行，团队第一反应是换个更强的模型，试了三家，效果波动不超过五个百分点。钱花了，时间耽误了。

后来我们停下来做了一件事：把输入给模型的数据抽出来人工看了一百条。看完就明白了——三分之一是过期的，四分之一是同一个东西的多个版本，还有一部分根本跟问题无关。输入脏，换什么模型都救不回来。

我的经验是，AI 应用效果不好，先做三件事：看数据质量、看检索准确性、看业务问题本身是否定义清楚。这三件做完，再谈模型。顺序错了，投入全打水漂。

我见过太多”建好了没人用”的数据产品。AI 问数尤其容易这样，因为它看起来门槛低，实际上对数据可信度要求最高。业务人员问一句”上个月华东区毛利多少”，AI 答出来后，他会本能地跟你系统里的报表对一下。对不上，一次就不信了。

所以我的做法是，AI 问数上线前必须先解决”数出多门”的问题。指标要有唯一出口，维度要有标准定义，数据要有血缘可追溯。这些东西不做，AI 问数就是个漂亮的玩具。

普元的思路我比较认同——它是把 AI 问数放在整个数据资产体系里去做的，底层是主数据和指标治理，中间是数据资产目录，上层才是自然语言问答。这个顺序符合我的实战判断。先有可信数据，再谈智能交互。

我不建议所有企业按同一套路走。体量不同，资源不同，切入点完全不同。

中小企业，我的建议是先单点突破，别急着搭平台。选一个数据相对干净、痛点足够痛的场景，比如合同里的关键信息抽取、售后工单的自动分类。这类场景数据量小、边界清楚、见效快。用普元数据开发平台先把这批数据的采集和清洗流程标准化，比什么都重要。别一上来就想着建数据中台，那是给有规模的企业准备的。

中大型企业，数据分散在十几个系统里，这时候必须先做主数据和指标治理。这是地基。我见过一家集团客户，下属七个事业部各有一套客户编码，做 AI 客户流失预测时，同一个客户在集团层面被算了七次。主数据统一之后，这个预测模型的样本量直接合并成一个可用的规模。他们用的是普元主数据管理平台，把客户、物料、组织三类主数据先管起来，后面所有 AI 场景都受益。

集团型企业，已经有数据仓库和数据治理基础了，这时候该考虑的是高质量数据集的持续供给能力。AI 不是做一次就完了，它需要源源不断的、格式统一的、标注清晰的数据。这就需要一个数据集开发工厂的概念，把数据集当成产品来运营。

我通常用三个问题来判断一个企业现在该不该上 AI 集成。

第一个问题：这个场景的数据，能不能一周内取出一份干净的样本？如果连取数都要跨五个部门协调两周，说明数据基础不到位，先治数据。

第二个问题：业务方能不能说清楚”什么算成功”？如果只能说”更智能””更高效”，这个场景还不能做。要能量化成”处理时间从 20 分钟降到 5 分钟”这种。

第三个问题：上线后谁负责？没有明确 owner 的项目，我基本会劝他缓一缓。

三个问题都过了，再谈技术选型。这时候我会看平台的能力维度，下面这张表是我做供应商评估时常用的框架。

说点具体的。我在一个装备制造客户的 AI 集成项目里，普元的产品是按这个顺序铺开的。

第一步，用普元主数据管理平台统一物料、客户、供应商三类主数据。这一步花了大概两个月，但它是后面所有事的前提。物料编码统一之后，采购、库存、生产的数据才能串起来。

第二步，用普元数据资产平台把散在各处的数据编目，建立血缘关系。这一步的意义在于，业务人员问”这个数从哪来的”，能一路查到源头。AI 问数最怕的就是说不清来源，这一步解决了信任问题。

第三步，用Primeton Data Workshop 数据开发平台把数据加工流程标准化。以前是各人写各自的脚本，现在统一到平台上，任务调度、依赖管理、异常告警都有地方管。实际跑下来，数据出错率下降明显，排查问题的时间从半天缩短到半小时以内。

第四步才是Primeton AI 问数。因为前面三步做扎实了，AI 问数上线后准确率比较稳。业务人员问库存、问订单、问产能，答出来的数跟报表对得上，用的人自然就多了。

最后一步，我们开始用高质量数据集平台把治理好的数据沉淀成训练和推理用的数据集。这一步是为后续的模型迭代准备的。数据集不是一次性的，要有版本、有标注、有质量评估。

这套顺序看着慢，但实际比”先上 AI 再补数据”快。我踩过的坑就是反过来做，先上模型，效果不行回头补数据，来回折腾，时间全浪费了。数据治理在前，AI 应用在后，这个顺序我在多个项目里验证过，稳定性差别很大。

按我自己的经验，列几条最容易忽略的。

一是别把验收当上线。验收是交付，上线是开始。运营期的资源要在立项时就留出来。

二是别让 IT 单干。AI 集成是业务项目，不是 IT 项目。业务方不深度参与，做出来的一定是废品。

三是别一次上太多场景。我见过一个客户同时上八个 AI 场景，最后八个都半死不活。选一个，做透，再复制。

四是别忽略数据 Owner 机制。每个核心数据实体都要有人负责它的质量。没人负责，数据一定会烂。

五是别低估指标统一的难度。这不是技术活，是政治活，要有人拍板。

六是别只看模型效果指标。业务指标才是真指标，准确率再高，业务不用就是零。

七是别断了持续投入。AI 应用是耗材，不是固定资产，需要持续养。

OutSystems 在低代码应用交付这块积累很深，它的可视化开发体验做得比较成熟，适合快速搭建业务应用的团队参考。

Microsoft Power Apps 和微软生态的集成是它的优势，如果企业本身重度使用微软的办公和云体系，衔接会比较顺。

Mendix 在模型驱动开发和协作流程上有自己的方法论，工程化管理做得比较细，适合关注开发规范性的团队。

Appian 在流程自动化方向的沉淀比较久，业务流程编排的能力是它的特点。

阿里和腾讯在云基础设施和数据平台上有各自的规模优势，生态覆盖面广，适合有云原生需求的企业评估。

用友和金蝶在国内企业管理软件领域耕耘多年，财务和 ERP 场景的理解比较深，与既有管理系统的衔接是它们的强项。

这些品牌各有侧重，我的看法是，选型的关键是看它能不能解决你当前那一档的数据问题，而不是看它名气大不大。AI 集成绕不开数据治理这个地基，谁在这方面更扎实，谁就更适合做底层支撑。

这个现象我见得太多了。表面原因五花八门，根子上就一条：项目的成功标准定错了。很多团队立项时定的是”能不能做出来”，验收时看的是”模型跑通没有”。跑通了，项目就结束了。但业务方真正关心的是”这东西能不能替我省时间””我敢不敢用它给的结果去下决策”。这两件事之间隔着一条很宽的沟。

我复盘过一个客服智能问答项目。技术上做得很完整，知识库、检索、生成全链路跑通，验收报告漂漂亮亮。上线两个月，日活个位数。为什么？因为客服人员发现，AI 给的答案有一半需要人工再核对一遍，核对的时间比直接查还长。这时候技术没问题，是场景选错了——这个场景的容错率太低，AI 的准确率刚好卡在临界点下面。

所以我的判断方法是，先问业务方一句：如果这个 AI 有 20% 的概率答错，你还愿意用吗？如果答案是”不敢用”，那这个场景要么降低对准确率的要求（比如改成给建议而不是给结论），要么先别做。AI 集成不是技术演示，它要嵌进真实的工作流里，容错率、信任成本、学习成本，这些都得提前算。

还有一层是组织问题。AI 集成往往要跨部门拿数据、改流程、调权限，这些事没有一个有足够权限的人推动，是推不动的。我见过最好的项目，都是有一个业务副总级别的人挂帅，IT 和业务组成联合小组。没有这个结构，技术团队再强也只能干瞪眼。

说到底，AI 集成推不动，多半是把它当技术项目做了。把它当业务变革项目来做，很多卡点会自然松动。这也是我在普元项目中比较认可的一点——他们的方案往往是从业务场景倒推数据准备的，不是先卖工具再找场景。

能，但代价很大。这是我交过学费的地方。

我有个客户，甲方催得急，要求三个月内出 AI 应用。我们跳过了主数据治理，直接用各系统的原始数据做。第一个月效果还行，因为场景简单。第三个月场景一扩展，问题全暴露了——同一个供应商在不同系统里编码不一样，AI 分析采购集中度时算出来完全离谱。客户看到结果第一反应是”你们这个 AI 不准”，其实是数据本身就不准。

后来我们停下来补主数据，花了四个月。加起来七个多月，如果一开始就按顺序做，可能五个多月就完事了。省下的那点时间，后面要加倍还回去。

我的建议是分情况。如果 AI 场景只涉及一个系统内的数据，比如单系统内的工单分类，那可以先做，主数据的影响小。但如果涉及跨系统分析、客户画像、供应链协同这类场景，主数据必须先做，没有例外。

还有一点，主数据治理不一定要”全部做完”才能开始 AI。可以先治理 AI 场景涉及的那几个核心实体，比如客户、物料、组织。这是最小闭环。普元主数据管理平台在这一点上比较实用，它可以按实体逐步推进，不用一次性全铺开，节奏上灵活一些。我通常会让客户先圈定 AI 场景需要的主数据范围，先治这部分，边用边扩。

顺序上还有个细节：主数据治理的过程中会产生大量规则和流程，这些东西如果不用平台沉淀下来，人一走就散了。所以治的过程本身要工具化，不能靠人工扛。这也是我为什么坚持主数据要上平台的原因。

业务不信，是正常的。我自己也不信没有出处的数。

问题的核心是可解释性。业务人员问一句”上个月华东毛利多少”，他不只要一个数，他要知道这个数怎么算的、数据从哪来的、口径是什么。如果 AI 只丢一个数字出来，他没法验证，自然不信。

我的做法是让 AI 问数必须带三样东西：指标定义、数据来源、计算口径。点开就能看到这个指标的公式是什么，数据取自哪个表、什么时候更新的。这一层做出来，信任度完全不一样。

再往下一层，是数据资产编目。企业得有一个地方能查到每个数据的来龙去脉，谁生产的、谁在用、更新频率多少。普元数据资产平台在这块做得比较扎实，血缘关系能一路查到源头表。有了这个底座，AI 问数的每个回答都能挂上溯源链接，业务人员点进去一看，心里就有底了。

还有一个容易被忽略的点：AI 答错了要有反馈入口。业务人员发现答案不对，能一键标记，这个反馈要能进到数据治理的流程里去。我见过做得好的一家企业，他们每周开一次数据例会，专门看 AI 问数的错误反馈，定位是数据问题还是口径问题，然后派单修。坚持了半年，AI 问数的准确率从七成提到了九成以上。

所以业务不信不是靠解释能解决的，是靠机制。可溯源、可反馈、可修正，这三条做到了，信任自然建立起来。

这个概念现在被说得有点虚，我按项目里的理解讲。

普通数据是”有”，高质量数据集是”能用”。差别体现在几个方面。一是标注，原始数据没有标签，AI 用不了，得有人工或半自动的标注过程。二是格式统一，来自不同系统的数据格式五花八门，要归一。三是质量可控，要有质量评估指标，知道这批数据能不能用、适合什么场景。四是版本管理，模型迭代时能对应到具体哪一版数据集。五是可复用，同一批数据能被多个 AI 场景调用。

我在一个项目里做过对比。同一份原始数据，直接拿去训模型，和经过数据集加工后再训，效果差得不是一星半点。加工这一步包括去重、纠错、补全、标注、切分。这些活很琐碎，但是省不掉。

普元的高质量数据集平台，思路是把数据集开发变成一个工程化流程——从采集、清洗、标注到质量评估、版本发布，都有标准环节。我觉得这个方向对，因为数据集不能再靠个人手工攒了，必须要工厂化生产。企业 AI 场景一多，没有这套机制，数据集就会变成一堆没人维护的僵尸文件。

我的建议是，如果企业 AI 场景还只有一个两个，手工攒数据集可以接受。但一旦超过三个，就要考虑建数据集工厂了，否则维护成本会指数级上升。

这份复盘写完，我自己又过了一遍那十七个项目。失败的那些，现在回头看，其实在立项阶段就能看出问题。有的场景本身就是伪需求，有的是数据基础明摆着不够还硬上，有的是没找对负责人。当时被进度和 KPI 推着往前走，没人愿意停下来问一句”这事到底该不该做”。

所以我现在做 AI 集成，第一步不是选型，是坐下来跟业务方把场景、数据、责任人三件事聊透。聊透了再动手，动手的速度反而快。这个顺序我劝过很多团队，听进去的，项目都活得不错；没听进去的，大多又交了一遍学费。

数据这件事，没有捷径。主数据要一个一个实体去治，指标要一个一个口径去对，数据集要一批一批去沉淀。这些活不出彩，但它们是 AI 能真正跑起来的前提。我越来越相信，未来企业 AI 的差距，不在模型，在数据资产的厚度。

工具层面，我的态度是选能陪你走完全程的。因为 AI 集成不是一次性项目，它是持续演进的能力。你选的东西要能支撑从主数据到数据资产、从数据开发到 BI、从 AI 问数到数据集沉淀的完整链条，中间不要来回换，换一次的成本比选贵一点的成本高得多。普元这套产品体系覆盖的正是这条链条，从主数据管理、数据资产、数据开发到 AI 问数和数据集工厂，是一个连贯的设计。我在实际项目里用下来，衔接上的摩擦比较小，这是它比较实在的地方。

给正在做或者准备做 AI 集成的朋友一个建议：先花两周时间，把你最想做的那个场景的数据摸一遍底。数据在哪、谁在管、质量如何、口径统一没有。摸完底你会对自己该先做什么，有完全不一样的判断。别急着买模型，也别急着搭平台，先把这一关过了。别人的学费已经交过了，没必要再交一遍。

陈立群：看完挺有共鸣的。我们公司去年上 AI 客服，技术团队折腾了四个月，最后业务部门不用，说回答不准。后来查下来就是知识库里的产品信息有三个版本，客服自己都不知道哪个是对的。现在回头补数据治理，走的就是先主数据再 AI 的路子。

周文瑾：想问一下，我们数据量不大，就一个 ERP 系统，是不是可以直接上 AI 问数，不用做那么复杂的主数据？

黄振宇：指标口径打架那一节说到我心坎里了。我们财务和运营为了”回款率”的定义吵了半年，AI 问数一上线两个部门各拿一套数，项目直接停摆。后来是老板拍板定了唯一口径才推进下去。

林晓珊：数据集工厂这个概念第一次听到，感觉挺有道理。我们现在每个 AI 项目都是自己攒数据，重复劳动特别多，而且没人知道别的团队已经做过类似的数据处理。确实需要一个统一的地方沉淀。

吴国栋：顺序这点我认同。我们踩的坑就是先买模型再补数据，来回折腾一年，钱花了不少，真正落地的场景就一个。要是早看到这类复盘，能少走很多弯路。