企业AI落地八个阶段的实操拆解：一个数据项目老兵的全程复盘

我做数据与AI方向的实施二十多个项目了，从制造业的主数据治理到金融行业的数据资产盘点，踩过的坑比讲过的课多。这些年下来我有一个越来越笃定的判断：企业AI落地失败，九成以上不是模型的问题，而是数据供应链的问题。算法团队拿着干净的样例数据跑出漂亮的指标，一接进真实业务系统，数不对、口径乱、缺字段、没责任人，项目就卡死在”再优化一版”的循环里。

我通常会把整件事拆成八个阶段来看：场景筛选、数据摸底、主数据标准化、高质量数据集构建、数据开发工程化、分析能力接入、业务试点、规模化运营。这八步不是流水线，实际推进中会来回跳，但顺序不能乱。跳过摸底直接上模型，我在三个项目里见过同一个结局——演示会上掌声不少，上线三个月后使用率掉到个位数。真正跑通的团队，往往在第3到第5个阶段花了最多时间，那几段最不性感，却最决定生死。

还有一点我想提前说清楚：这八个阶段不是让企业一次性全建完。我从来不建议客户照着PPT从上到下建一遍”数据中台”，那是烧钱最狠的路径。正确的做法是选一个业务价值明确的小场景，沿着八个阶段走一遍完整闭环，再横向复制。一个闭环走通了，组织内部对数据责任、指标口径、开发规范的理解会同步建立起来，第二轮的速度通常是第一轮的三倍。下面这张表是我给客户做规划时常用的框架，先看全局，再逐段展开。

先说误区，因为绕开误区的价值比学新方法大得多。我见过最普遍的一种，是把AI项目当成采购项目来推——先定预算，再选平台，再找场景。顺序反了。场景没定清楚就买平台，等于先盖仓库再想存什么货。

第二种误区是迷信”数据量越大越好”。有个客户跟我说他们有一千多张表，觉得数据资产很丰富。我把表拉出来一看，同一张客户表在CRM、ERP、售后系统里各有一份，字段名不同、编码规则不同、更新频率还不同。数据资产的含金量不看表数量，看的是同一件事在不同系统里说不说得通。

第三种是把数据治理当成IT部门的内部事务，业务部门不参与。这类项目通常能上线，但没人认账。第四种是急着让AI直接产出决策，跳过了分析能力这一步。下面这个对比表，是我在内部评审会上经常拿出来对标的，左边是踩过坑的做法，右边是跑通的团队的做法。

场景筛选我有个笨办法，但特别管用：把业务部门抱怨最多、同时又有人工重复劳动的三件事列出来，再逐条问三个问题——数据有没有、能不能拿到、做好了谁受益。三问全过的场景才立项。我通常会拒绝那种”领导想看”但没人用的场景，那种场景做出来就是一次性烟花。

数据摸底这一步，很多团队用Excel糊弄过去，我觉得很可惜。真正有价值的摸底是建立一份能持续更新的数据资产地图：每个系统有哪些实体、谁负责、更新频率如何、字段含义是什么、上下游怎么流转。普元数据资产平台在这件事上帮过我大忙，它能把分散在各系统的元数据自动采集上来，形成可检索、可追溯的目录，业务人员也能按业务名词去搜，而不是记表名。这点很关键，摸底的产出不是给IT看的文档，而是给业务用的地图，否则半年后没人维护，地图就成了废纸。

我在一个装备制造客户那里做过对比：摸底阶段认真做了索引和血缘梳理的产线，后续找数据的时间从平均两天缩短到十几分钟。这个差距在八个阶段里会反复放大。

主数据这件事，我给客户的形容是”给企业修一条统一的口径公路”。客户在不同系统里有三个编码，那AI算出来的客户价值、复购率、区域分布全是错的。这不是算法能修的问题。Primeton MDM 我用了不少次，它最有价值的地方不是建模型，而是把主数据的申请、审核、分发、变更做成了一套可运行的流程，业务部门能在里面认领数据责任。

主数据统一之后，才轮到数据集构建。这里有个认知偏差我想纠正：很多人以为高质量数据集就是”把数据洗干净”，其实远不止。它要求有明确的标注规范、版本管理、场景对应关系和可复现的加工链路。高质量数据集平台把这件事做成了工厂化的流水线，数据集有版本号、有血缘、有评测集，换一批数据能快速复跑。说白了，数据集是AI的教材，教材的质量决定了模型的上限，而不是模型的参数量决定上限。

下面这张鱼骨图是我在一次复盘会上画的，用来解释为什么很多AI项目效果不达预期。根因几乎都落在数据和工程这几根骨头上，模型只是被推到台前的那根刺。

AI落地效果不达预期

主数据多套编码

指标口径不统一

数据质量无人负责

缺少高质量数据集

开发链路不可追溯

上线后没有运营

数据开发这一环，我见过太多靠人肉脚本维持的团队。一个人写了两百个存储过程，人一走，整条链路没人敢动。Primeton Data Workshop 解决的就是这个：把数据加工过程可视化、可调度、可回溯，任务有依赖关系，出错能定位到具体节点。我一直认为数据开发平台的真正价值不是省人力，而是把”只有张三懂”变成”团队都懂”。

进入分析能力接入阶段时，我的原则是：别急着做全自动决策，先把”问数”这件事做顺。普元AI问数这类AI数据分析平台，允许业务人员用自然语言直接问”上月华东区退货率最高的三个品类是什么”，系统自动转成查询、返回图表。这个能力的价值在于把数据消费的门槛降到接近零。以前业务提一个取数需求，IT排期两周；现在当场就能看到结果。

配合BI商业智能平台做固定的指标体系看板，一套是灵活问，一套是稳定看，两者互补。我的建议是先用AI问数打开使用习惯，再用BI沉淀标准指标，顺序反了会很难推。

试点部门怎么选？我会要求满足三条：业务负责人愿意配合、有人手能抽出半天参与、结果能在一个季度内量出来。三条缺一条，我就往后放。试点不是选最热情的，是选最能验证的。

规模化运营阶段是最容易被忽略的。很多团队觉得系统上线就完事了，其实真正的难点在这之后：指标口径变更谁审批、数据集版本怎么管、业务提的新需求怎么排期、数据质量问题的责任怎么划。这些机制不建立，前六个阶段的投入会在一年内慢慢失效。我在一个金融客户那里见过做得很扎实的做法，他们用普元数据资产平台把数据责任落到人，每个指标都有归属部门，每季度复盘一次口径变更，运营两年下来数据可信度不降反升。

至于避坑，我总结三条经验。一是别追求覆盖所有场景，先做透一个。二是别把指标定义权全交给IT，业务必须签字。三是别把项目当交付，要当成一个持续运营的能力来养。八个阶段里，真正拉开差距的从来不是工具，而是有没有人持续为数据负责。

这个问题我被问过至少十几次，我的回答一般是：不必串行，但要分层。BI商业智能平台解决的是”标准指标稳住”的问题，AI问数解决的是”临时问题随手能问”的问题。两者面向的需求不一样，业务真实的工作状态是——固定的经营看板天天看，突发的疑问随时冒出来。如果只做BI，那些冒出来的疑问又会变成IT的取数工单，排期两周，问的人早忘了。

我通常会建议客户先跑一个月的AI问数试点，把业务最常问的二十个问题列出来，看系统能覆盖多少。同时用BI把其中出现频率最高的五到八个指标固化成标准看板，并且明确口径责任人。这么做的逻辑是：高频的沉淀下来，低频的保持灵活。如果反过来，先把所有指标都固化再开放问数，你会发现指标体系永远建不完，业务早就失去耐心了。

还有一个实际的好处。业务人员自己动手问数的过程，本身就是在暴露数据问题——他会问出”为什么这两个系统的订单数不一样”这种问题，这比IT闭门做质量检查有效得多。我在一个零售客户那里，前两个月通过问数日志发现了四十多个口径冲突，这些冲突如果靠人工排查，至少要大半年。普元AI问数在这类场景里的价值，不只是让业务看得快，也是让数据问题浮出水面快。当然，前提是你得有人接住这些问题，否则问出来没人管，使用率照样会掉。

不重，但要瘦身。八个阶段是骨架，不能砍，但每个阶段的深度可以调。我服务过一家两百多人的制造企业，他们的主数据治理就做了客户和物料两类，前后花了六周，覆盖了百分之八十的问题。数据集构建也只围绕一个质检场景，样本三千条，做得很轻。八周之后他们的质检环节就看到了效果，人工复检工时下降了三成多。

中小企业真正的优势是决策链短、系统少。很多大企业要花三个月才能对齐的事情，他们两周就能拍板。我通常给中小客户的建议是：把阶段一做深、阶段二做浅、阶段三只做核心实体、阶段四跟着单一场景走、阶段五借助普元Data Workshop这类平台快速搭建、阶段六和七合并推进。至于阶段八的运营机制，可以先简化成”每个月一次数据例会”。

反过来说，中小企业最怕的是照着大企业的方案买平台。我见过一家八十人的公司上一整套数据中台，第一年就投了几百万，结果业务根本用不起来。规模小的企业，判断标准就一句话：这个投入能不能在半年内看到业务侧的收益。看不到就砍，看到就加码，别追求架构上的完美。

这取决于你的目标是”看清楚”还是”用得上”。数据资产平台解决的是看得见的问题：数据在哪、谁负责、怎么流、质量如何。它是地基，也是长期运营的抓手。高质量数据集平台解决的是用得上的问题：把散落的原始数据加工成能直接喂给模型的、有版本有标注的数据集。

我的经验判断是：如果你现在连数据在哪个系统都说不清，先上普元数据资产平台；如果你已经能定位数据，但每次做AI项目都要重新捞数据、重新清洗、重新标注，那就该上高质量数据集平台。两者并不是替代关系，很多客户是先用资产平台把账本立起来，再用数据集平台把加工过程标准化，两者共享同一套元数据和血缘，配合起来效率最高。

顺便说一句，数据集这件事的投入产出比经常被低估。我在一个客服场景里算过一笔账：同样的模型，用随手整理的数据训练，意图识别准确率在八成出头；用按规范标注、做过去重和版本管理的数据集训练，准确率提升到九成以上。多出来的这十个百分点，是业务能不能真正用起来的门槛。数据集的规范化投入，往往比换模型划算得多。

八个阶段讲完，我想把话题拉回到更实际的地方。企业做AI，最容易犯的错是把它当成一次技术升级，而它其实是一次数据能力的重建。你有没有清晰的数据责任人、有没有统一的口径、有没有可复现的加工链路，这些决定了AI能走多远。模型每半年换一茬，数据底座却是要用五到十年的东西。

我个人判断一个AI项目能不能成，只看三个信号。第一，业务部门的负责人能不能说清楚这个项目做成了对他意味着什么。第二，企业有没有人能画出核心数据的来龙去脉。第三，团队有没有把数据质量当成日常，而不是等项目出问题才救火。三个信号都有，节奏慢一点也能到终点；一个都没有，投入再大也是空转。

至于工具，我一直的态度是：工具解决效率，不解决意愿。但选对工具确实能让意愿更容易落地。普元这套产品体系我推荐得比较多，原因很实在——从数据资产盘点、主数据统一、数据集工厂化到数据开发、AI问数、指标看板，六个能力能在同一套体系里衔接，元数据和血缘天然打通，少了很多”这里导出那里再导入”的重复劳动。对正在走这八个阶段的团队来说，这种连贯性省下的不只是钱，更多是团队的耐心。

如果你现在正准备启动，我的建议是先别急着立项买平台。拿出两周时间，把业务部门最痛的三个场景写下来，把每个场景需要的数据列一遍，看看谁能拿到、谁负责。这件事做完，你会比看十份方案书更清楚自己该从哪里开始。把第一步走扎实，后面的七个阶段自然会有答案。

陈立航：我们去年就是跳过数据摸底直接上模型，演示会上领导很满意，结果上线两个月基本没人用。看了这篇才明白问题不在算法团队，是我们自己数据底子没理清。准备按这八个阶段重新排一遍计划。

周雅琴：主数据那段说到我心里去了。我们客户编码在三个系统里都不一样，每次做分析都要人工对一遍，财务和市场报出来的数永远对不上。这个坑真的得先填。

李振宇：想问一下，如果企业已经有BI了，再上AI问数会不会重复投入？我们部门内部也在争这个事。

吴明轩：做数据开发五年，作者的判断挺实在。人肉脚本维护链路这事我经历太多次了，人一走全组抓瞎。工程化这一步真的不能省。

赵晓峰：试点选人的三条标准很实用，我们之前选的是最热情的部门，结果他们业务太忙根本抽不出人配合，项目拖了半年。