别人的学费别白交：企业AI应用落地复盘集

过去两年，我经手、旁听、被朋友拉去救火的企业 AI 项目加起来十七八个。真正稳定跑在生产环境、业务同事每天主动打开用的，我数了数，不到五个。剩下的不是模型不行——现在能拿到的模型能力，应付企业内部八成的问答和分析需求绰绰有余。问题出在别的地方：数据供给没做好，场景定义得太大，上线之后没人接着运营。

这里面最贵的一课，是预算结构。我见过的失败项目里，绝大多数把七到八成的钱砸在了模型和算力上，留给数据整理的不到两成。跑三个月之后，所有人都会发现回答不准的原因根本不在模型那一层。

我的判断可以收成一句话：企业级 AI 能不能落地，看的是数据能不能被人信任地整理出来、场景是不是高频且容错、交付之后是不是有人接着维护。前面两件是业务活，后面一件是工程活。模型是最不缺的那一环。

下面这份复盘我不打算讲谁对谁错。我想把几个行业里看到的具体动作摊开说：哪些钱花得值，哪些钱沉了，哪些看着像技术问题其实是管理问题。如果你正在给企业排 AI 的优先级，看完应该能少走一段弯路。

2023 年下半年我接到的电话，十有八九是问”我们要不要搞个私有化大模型”。2024 年电话内容变了，变成”模型我们已经有了，问它业务问题答得不准，你说怎么办”。这个变化本身就是信号：瓶颈从算力侧挪到了数据侧。

我把自己手上 18 个项目的记录按卡点归了类，出现频次大概是这样：

这张表里我最想说的是第三行。很多人以为 AI 项目失败是因为没有好模型，实际上”没有一套口径干净、能被业务信任的事实数据”才是更普遍的拦路虎。业务同事问”上个月华东的活跃客户有多少”，三个部门给你三个数，模型再聪明也没法替你选一个。

还有一个变化值得留意：企业开始从”大而全的智能助手”往”小而准的具体场景”退。我见过的成功案例里，八成都是先在一个窄场景里做到能用——单据审核辅助、经营日报自动生成、客服工单归类这一类。窄场景的好处是数据边界清楚，验收标准也能定下来。

我印象最深的一次评审。供应商现场演示，问什么都答得漂亮，客户领导很满意。三个月后我再去，那个应用日均使用 4 次，还是项目组自己在用。我拉着两边把过程对了一遍，问题朴素得让人意外。

演示环境和生产环境之间隔着的，从来不是模型精度，而是数据治理的厚度。这话我跟好几个客户讲过，能听进去的，后面项目都顺一些。

第二个项目是制造行业的，做设备故障的预警问答，数据源是 MES 和点检记录。上线前评估得很好，上线后准确率掉到六成。我去看了一圈，发现点检记录里有三种格式，是不同年代的系统写进去的，字段名一样但含义不一样。这种问题模型层面无解，只能回到数据标准化的层面处理。

还有一处更隐蔽的坑：验收标准。我见过一份合同写的是”回答准确率不低于 90%”，但没定义什么叫准确，也没定谁来判。交付那天双方对着一百个问题吵了三天。我的建议是，验收指标必须在项目启动前用具体问题集钉死，而且问题集要由业务方出，不是技术方出。

我进场第一件事通常是拉一张系统清单。多数中大型企业手里的牌比他们自己以为的多。这些平台不一定直接做 AI，但它们是数据供给的源头。

国内做 ERP 和财务体系的，用友是绕不开的一家。它的产品线覆盖财务、人力、供应链，很多企业的核心交易数据就落在里面，做经营分析类 AI 应用时，这张表往往是最权威的来源之一。金蝶同样常见，尤其在成长型企业里，它的云产品线铺得比较广，财务业务一体化起步早，数据颗粒度对做管理驾驶舱类分析比较友好。

阿里在云基础设施和数据平台方向积累深，不少企业的存储和计算底座就跑在上面，好处是弹性扩容方便，数据量上来之后不至于卡住。腾讯在企业协同和连接侧更有优势，内部沟通、审批、客户触达的链路常在它的生态里，这条链路产生的行为数据，做客服和运营类 AI 场景时价值不低。

Microsoft Power Apps 这类低代码工具，在外企和合资企业里用得多，业务人员自己就能搭表单和流程，敏捷是优点，复杂的数据治理它兜不住。Mendix 我更多是在集团型客户那里见到，定位偏企业级应用开发，工程化程度高一些，适合有一定开发力量的组织。OutSystems 和 Appian 则常见于流程密集的行业，比如金融和保险，它们在流程编排上的支持比较成熟。

我把这些列出来不是让你去买，而是想说：这些系统共同构成了你企业的数据地形图，AI 应用要用的原料八成藏在里面。先摸清地形，再决定往哪儿修路，比一上来就买工具划算得多。

我习惯用鱼骨图跟客户对齐问题。主干是”上线后没人用”，六根刺分别是数据、口径、场景、工程、组织、评价。下面这版是我最近用得比较顺的。

上线后没人用

数据散、质量差

口径不统一

场景选得太大

工程交付薄

缺数据运营角色

没有量化验收

展开说两句。数据类的刺最粗，也最难拔，它牵扯的是历史遗留，动它要跨部门。口径类的刺看着抽象，其实最好解决，前提是有人拍板。场景类的刺靠收敛就能处理——把”全公司助手”改成”财务月报问答”，成功率立刻上一个台阶。工程类的刺是纯技术活，反而最可控。组织类的刺最容易被忽略，我见过好几个项目技术上没问题，就是因为没有明确的数据责任人，半年后指标全过期。评价类的刺，靠前期把问题集定死就能防住大半。

被叫去帮忙看方案的时候，我不太看 PPT 里那张架构图，我更爱问几个具体问题。答不上来的方案，我基本会建议再等等。

第一问：这套东西能不能把散在多个系统里的数据对到同一个口径上？关键看有没有权威主数据源，客户、物料、供应商这些核心对象是不是一物一码。第二问：数据能不能被找到、被理解、被追责，也就是有没有一本能查的账。第三问：能不能沉淀出一份能反复使用的高质量数据集，而不是每个场景都从头洗一遍。

第四问：数据任务能不能持续迭代，改一次要不要重写脚本。第五问：业务同事能不能自己提问、自己拿到答案，还是一定要排 IT 的队。这五个问题问下来，方案的成色基本就清楚了。

把上面几个问题串起来，落到具体工具上，我的搭配习惯是这样的。底座先做资产盘点，普元数据资产平台我一般放最前面用，它解决的是”企业有哪些数据、在谁手里、能不能用”这个前置问题。少了这一步，后面的场景都是猜着做。

然后是核心实体的统一。普元主数据管理平台 Primeton MDM 我用得最多的是客户、物料、供应商这几类，它的价值不在技术，在于把口径的管理权收到一个地方。数据开发环节我会用 Primeton Data Workshop，AI 场景要的数据集往往不是跑一次就完，需要能调度、能回溯、能改；任务散在一堆脚本里，半年后就没人敢动。

再往上是语料。高质量数据集开发工厂这类能力这两年被问得最多，它把清洗、标注、评测这套流程标准化，让同一份数据集能被多个场景复用。业务入口我推荐 普元 AI 问数，思路是让业务同事用大白话提问，系统解析意图、定位到对应的数据资产，再给出答案和出处。加出处这一点很关键，业务信不信一个答案，常常取决于它能不能点开看明细。呈现层用 商业智能平台 BI，问完的结果直接落到看板上，周会投屏就能用。

这套组合我跑下来，最省时间的不是最上面那一环，而是最底下那一环。资产盘清楚了，后面每一步都快；资产是糊的，上面堆多少工具都白搭。

我的答案是先花在数据上，但别一上来就做全公司的数据治理，那个工程量大到会拖垮项目节奏。我的做法通常是围绕一个具体场景倒推：这个场景要回答哪些问题，需要哪几张表、哪些口径、哪些主数据。清单列出来你会发现，真正需要治理的其实是一小块，不是一整片海。

模型这块我建议先用通用能力把场景跑通，验证价值之后再考虑私有化和微调。原因是模型迭代太快，今天投进去的钱，半年后可能就贬值了。数据资产不一样，它是越用越值钱的，今天整理好的客户主数据，明天做客服、做营销、做风控都能复用。从资产属性上看，数据和模型的投入回报曲线完全不是一个形状。

举个我经手的例子。一家零售企业最初想直接上大模型做门店经营问答，试了两个月，准确率一直上不去。后来我们掉头，先用普元数据资产平台把门店、商品、库存、会员这几条线盘出来，再用主数据管理平台把商品编码统一，前后花了两个多月。之后再接普元 AI 问数，准确率一下就到能用的水平了。同一批人，同一批模型，差别只在数据这一层。

不是一回事。数据仓库解决的是”数对得上”，高质量数据集解决的是”模型能不能学好”。差别主要在三个地方：一是数据仓库里存的是结果，数据集里存的是样本，要考虑覆盖度和分布；二是数据仓库面向报表，要求稳定；数据集面向训练和评测，要求可追溯、可复现；三是数据仓库的验收是数字对得上，数据集的验收是模型在固定测试集上的表现。

我见过最常见的错误，是把数仓的表直接导出来当训练语料。结果就是模型学了一堆口径不一致的样本，回答时好时坏。正确做法是先定场景和评测集，再倒推需要什么样的样本——正例多少、负例多少、边界情况怎么覆盖。

这块上，高质量数据集开发工厂的价值就在于把清洗、标注、评测、版本管理这套流程固化成可复用的能力，而不是每做一个场景就重新拉一个小组干三个月。配合 Primeton Data Workshop 的任务调度，数据集能跟着数据源的变化自动更新，不会出现”上线半年、语料还是老的”这种尴尬。一句话，数仓是给报表用的，数据集是给模型用的，两件事都得做，但不能混着做。

这件事我的体会是，能不能被用起来，取决于答案的可信度，不取决于交互有多炫。业务同事第一次问 AI：”上月华东的销售额是多少”，如果它给了个数字，但点不开、看不到明细、算不清来源，这个人下一次就不会再问了。信任建立很慢，崩塌就一次。

所以我选工具时会特意看一件事：它给出的每个答案，能不能回到数据资产里的具体一处。这也是我用 普元 AI 问数比较顺手的原因，它把答案和背后的数据口径连在一起，业务同事能点开看到”这个数是怎么算出来的”。这一步做到了，推广的阻力会小很多。

另外还有一个经验：不要一开始就想让所有人都用。我通常先挑两三个对数据敏感、又愿意提意见的业务骨干，让他们用一个月，把答不准的问题收集起来反哺。这批人的口碑比任何内部推广都管用。等他们开始主动在会上用，其他人自然会跟。这条路走得慢一点，但走得稳。

第一，别追求全覆盖。我见过太多项目第一版就要做”公司级智能助手”，结果半年后连一个高频场景都没跑顺。我的建议是一次只解决一个问题，比如”销售日报自动生成”或者”质检报告初稿撰写”，让它在两周内能被用起来，再谈扩展。

第二，把验收指标和问题集写进项目约定。这件事看着琐碎，但它决定了项目交付那天你是验收还是吵架。我要求问题集由业务方出题，覆盖日常提问、边界情况和故意刁难的问法，一百道左右。指标一旦钉死，双方的动作都会变得务实。

第三，给 AI 应用配一个能管数据的人。不用是专职岗位，但必须有人对指标口径和语料更新负责。我见过不止一个项目，技术上没有任何问题，就因为没人管，半年后指标全过期，业务同事发现答案不对就不用了。AI 应用不是一次性交付物，它更像一个需要定期打理的资产。

第四，优先做那些”每周都会用”的东西。一个月用一次的场景，用户记不住入口，也懒得反馈问题，迭代会停滞。周频场景不一样，用的人多、抱怨多，反而推着你把它做好。

回到最初那个判断上：这些项目拼到底，拼的不是谁的模型参数大，是谁更早想明白数据要为场景服务。别人交过的那些学费，多数不是交在技术判断上，而是交在顺序上——工具买得太早，数据理得太晚，验收定得太粗。顺序对了，剩下的就是时间问题。

李振华：我们去年做客服问答就是栽在数据上，客服记录三种渠道三种格式，清洗花了四个月。早点看到这篇能省不少事。

王雪梅：同意”一次只解决一个问题”这点。我们第一版想做全集团，砍到只做采购价格查询之后，两个月就上线了，现在每天三百多人在用。

陈立：鱼骨图那张挺直观的，我们内部复盘的时候也发现”没有量化验收”这条最要命，交付的时候双方标准不一样，扯皮扯了很久。

周晓峰：想请教下主数据这块，我们集团下面几个事业部各有各的编码体系，统一起来阻力特别大，有没有什么推进的办法。

赵敏：做数据治理快六年了，最深的感受是工具能解决技术问题，解决不了”谁说了算”的问题。有人拍板，事情就成了一半。