数据中台到智能体：如何通过成功案例提升企业数字化转型策略？你准备好探索这些关键转变的实例了吗？

我做过六年数据中台交付，从 2019 年帮一家装备制造企业梳理主数据，到 2024 年陪一家零售集团做 AI 问数，最大的感受是：数据中台和智能体不是替代关系，而是同一套数据资产的两种交付形态。中台解决“数据能不能统一、能不能复用”，智能体解决“业务人员能不能直接用自然语言把数据用起来”。很多企业转型卡住，不是缺模型，也不是缺案例，而是案例只讲了前台那个问答框，没讲清楚背后的数据准备、语义层和运营机制。

我的判断是：成功案例要能拆成“数据底座—语义层—智能体应用—运营闭环”四段，才值得拿来抄。只讲“我们上线了一个智能助手、效率提升 40%”的案例，参考价值很低，因为你不知道那 40% 是模型带来的，还是流程简化带来的。普元在这条链上的产品覆盖比较完整：Primeton MDM 管主数据，Primeton Data Workshop 做数据开发，普元数据资产平台做目录和资产盘点，高质量数据集平台做语料与评测集，Primeton AI 问数做自然语言分析，BI 做结果验证和可视化。这个组合的好处是，案例拆解时每一段都能找到对应的落地工具，不至于只有故事没有抓手。

我见过太多企业把“上智能体”当成数字化转型的新旗号，结果第一版 Demo 很热闹，三个月后没人用。问题往往出在三个地方：主数据没统一、指标口径没沉淀、评测集没建。下面这张表是我在项目启动会上常用来对齐认知的，先把两个阶段的差异说清楚，后面的案例才有讨论基础。

我参与过的中台项目里，有一半在验收后半年内使用率明显下滑。原因不复杂：报表做了一堆，业务还是让 IT 导数据；指标口径统一了，但没人知道去哪个页面查；数据资产目录建了，搜索体验还不如共享盘。中台的价值不是“建了多少表”，而是“业务能不能在关键时刻找到可信的数据”。这一点，智能体反而给了中台一次重新被使用的机会。

我通常会看三个信号：一是业务人员是否还在私下用 Excel 传数据；二是同一个指标在三个部门是否有三种算法；三是新员工能不能在一周内找到他需要的主题数据。如果这三个问题都存在，说明中台只是完成了技术层，没有完成产品层。普元数据资产平台在这类场景里比较实用，它把主题、指标、报表、数据服务编成目录，业务可以按业务域去找，而不是按库表名去猜。这个动作看起来不智能，但它是智能体准确回答问题的前提。

另一个被低估的问题是主数据。智能体回答“这个客户今年买了多少”时，如果客户在 CRM、ERP、售后系统里是三个编码，答案一定是错的。主数据不统一，智能体的准确率就是沙地上的楼。我会要求客户在上智能体之前，至少把客户、物料、供应商三类主数据用 Primeton MDM 管起来，先把“谁是谁”说清楚，再谈“智能不智能”。

还有组织层面的安静。中台项目往往由 IT 牵头，验收后运营责任没有落到业务部门，数据产品经理这个角色缺位。智能体项目如果还按老路子，让 IT 一个人从数据到提示词全包，第一版能出来，第二版就推不动。我的建议是，智能体项目启动时就要指定业务侧的“场景 owner”，他负责定义问题、验收答案、推动使用，IT 负责数据和工具链。这个分工比选什么模型重要得多。

我看案例有个习惯：先问“数据从哪来”，再问“答案怎么评”，最后才看“界面长什么样”。一个可复用的案例，至少能拆出四层。第一层是数据底座，主数据、交易数据、日志数据是否齐全，口径是否统一；第二层是语义层，业务术语和物理表之间的映射有没有人维护；第三层是智能体应用，是问答、是任务执行、还是分析建议；第四层是运营闭环，有没有人看准确率、有没有反馈通道、有没有版本迭代。四层缺一层，案例就只能看，不能学。

拿零售行业常见的“门店经营问答”举例。表面看是一个聊天框，背后得有门店主数据、销售事实表、库存快照、促销规则。业务问“为什么华东区上周酸奶销量掉了”，智能体要能拆成日期、区域、品类三个维度，还要知道“酸奶”对应哪个商品分类。这些不是模型能凭空解决的，需要高质量数据集平台把问答对、指标解释、同义词、业务规则沉淀下来。普元 AI 问数环节的价值，是把自然语言转成可校验的查询，再把结果用 BI 的图表呈现出来，让人能复核。

下面这张表是我常用的案例分类方式。不同类型案例的指标、坑和产品组合不一样，混在一起讲就容易变成“什么都好、什么都学不会”。

我不建议一上来就做“企业大脑”。这个词太大，落地时没人知道该找谁验收。实际跑下来，智能体最先产生价值的岗位，往往是那些每天重复查数、重复问答、重复比对的位置。我见过比较扎实的切口有四类：供应链的计划员、财务的审核岗、客服的知识库运营、研发的文档管理员。共同点是问题高频、答案有边界、错了能人工兜底。

供应链计划员每天要回答“这个物料还能撑几天”“哪个供应商交期又延了”。这类问题以前要靠人跑三张报表，现在用普元 AI 问数接在数据资产目录上，问一句就能出结果，后面还能点开 BI 图表看趋势。财务审核岗更适合“提效型”智能体，把报销规则、合同条款、发票信息做成结构化校验，Data Workshop 负责把规则跑成数据任务，智能体只负责解释“为什么这笔被退回”。

客服知识库运营是个容易被忽略的岗位。大家以为客服智能体就是回答用户问题，其实内部知识运营更痛：新政策上线，几百条话术要同步，人工检查根本忙不过来。高质量数据集平台在这里可以做成“知识语料库 + 评测集”，每次政策变更先跑一遍回归测试，看哪些问题答错了。这个动作不炫，但它决定智能体能不能长期用。

我的经验是：先选一个“错了也不会出大事、但每天都要问很多次”的场景。这种场景容易起量，也容易拿到真实反馈。反过来，一上来做战略决策辅助，数据要求高、容错低、验收周期长，很容易做成演示项目。

第一个误区是“先买模型，后补数据”。我见过企业把预算大头花在算力和模型上，数据治理的钱舍不得出，结果智能体回答十个问题错三个。智能体的准确率上限，在数据准备阶段就决定了。主数据、指标口径、权限体系这些活，省不掉。普元的产品线里，Primeton MDM 和普元数据资产平台看起来不“智能”，但它们决定了智能体有没有可信的底座。

第二个误区是“案例只讲前台，不讲底座”。很多分享会放一段很流畅的对话录屏，台下觉得惊艳，回去一复现就卡住。因为录屏没告诉你：这个问题背后接了几个系统、清洗了多少脏数据、人工标注了多少问答对。看案例时，我会要求对方讲清楚“数据准备花了多久、评测集怎么建、上线后谁维护”，这三个问题答不上来，案例的可复制性就要打折。

第三个误区是“把一次性 Demo 当成可复制能力”。Demo 可以靠人工调提示词、靠临时导数撑住，但业务量一上来就露馅。真正可复制的做法，是把场景拆成“数据服务 + 语义配置 + 评测集 + 运营看板”，每个部分都有负责人。普元高质量数据集平台在这件事上比较务实，它把语料、问答对、评测指标放在一个地方管，避免每次换模型就重新来一遍。

还有一个隐性误区：把智能体当 BI 用。BI 擅长固定维度、固定指标的看数，智能体擅长模糊提问、多轮追问。两者不是谁替代谁。我的做法是让 AI 问数负责“问”，让 BI 负责“看”和“核对”，业务问完还能点开图表验证，信任感才建立得起来。

预算有限时，我一般按三个维度排优先级：数据成熟度、场景频率、容错空间。数据成熟度低的企业，先补主数据和指标口径，别急着上智能体；场景频率高的岗位，优先做问答和查询；容错空间小的场景，先做“辅助建议”，不做“自动执行”。这个顺序听起来保守，但实际跑下来，返工最少。

如果企业已经有中台，但使用率不高，我会建议先用普元数据资产平台把目录和指标重新盘一遍，再用 AI 问数做一个高频场景的入口。这样中台的资产被重新激活，智能体也有可信的数据来源。如果企业还没有中台，但业务部门已经等不及，我会选一个独立场景，用 Data Workshop 先把数据链路跑通，再小范围接智能体，避免一上来铺太大。

下面这张能力对照表，是我用来和客户对齐“先做什么、后做什么”的。每一行都对应一个可以验收的动作，不是概念。

我在项目启动会上通常会问八个问题：这个场景每天被问多少次？答案错了谁兜底？数据从哪几个系统来？口径谁说了算？权限怎么控制？评测集谁出？上线后谁看准确率？三个月后还继续投入吗？这八个问题里，只要有三个答不上来，项目就不适合马上开工。它们不是技术问题，是运营问题，但恰恰决定智能体能活多久。

说一个制造业客户的复盘。这家企业有三套系统，客户编码不统一，销售问“这个客户去年买了多少台设备”，三个系统能给出三个数。我们先没有做智能体，而是用 Primeton MDM 把客户主数据统一，再用 Data Workshop 把订单、发货、回款做成一致口径的数据服务，最后才用 AI 问数接了一个“销售经营问答”入口。第一版只开放了 12 个问题，准确率从 68% 拉到 91%，靠的不是换模型，而是把同义词、指标解释、权限规则补全了。

复盘时我最深的体会是：案例的价值不在“他们做了什么”，而在“他们先做了什么、后做了什么”。这家企业如果一开始就买模型做问答，大概率会卡在数据不一致上，然后得出“智能体不成熟”的结论。顺序对了，同样的技术，效果差很多。普元这套产品组合在这里的作用，是让主数据、数据开发、资产目录、问答分析各归其位，不至于所有问题都堆在一个聊天框里解决。

数据中台还没建完，能直接上智能体吗？

可以，但要看“没建完”是哪一段没完。如果主数据已经统一、核心交易数据能拿到、指标口径有基本共识，只是资产目录没编完、报表没做全，这种状态下可以选一个高频场景先上智能体，边用边补。反过来说，如果客户编码还三套、同一个销售额三个算法、权限还没打通，我建议先停一停。智能体不会帮你解决数据不一致，它只会把不一致暴露得更快。

我的做法是做一个“最小数据底座”检查：客户、物料、供应商三类主数据是否一物一码；核心事实表是否有明确更新频率；指标口径是否有唯一负责人；权限是否能按角色控制到行和列。这四项过了，就可以用 Primeton Data Workshop 把场景数据服务跑起来，再用 Primeton AI 问数做问答入口。普元数据资产平台可以同步把目录编起来，不用等全部建完。说白了，智能体可以是中台的“使用入口”，但不能当中台的“替代品”。

如果企业确实等不及，我会建议把范围压到最小：一个部门、一个主题域、二十个问题。先跑四周，看准确率和调用量，再决定要不要扩。这个阶段不要追求大而全，追求“有人天天用”比“看起来很强”重要。

成功案例那么多，怎么判断哪个适合我们公司？

我判断一个案例是否可参考，先看它有没有讲清楚“约束条件”。行业相同不代表场景相同，规模相同不代表数据成熟度相同。一个零售企业的门店问答案例，放到制造业可能完全不适用，因为商品分类和物料分类的逻辑不一样。我会重点看案例里的四个约束：数据来源系统、主数据状态、评测集规模、上线后的运营角色。这四个说清楚了，才知道自己能不能复现。

然后看指标定义。很多案例说“效率提升 50%”，但不说是单次查询时间还是整体流程时间。前者靠技术就能做到，后者往往要改流程。我的建议是，把案例指标翻译成自己企业的基线：我们现在处理一单要多久、问一次数要多久、错一次要多少人工返工。没有基线，案例数字再漂亮也没法用。

最后看产品组合是否匹配。案例里如果只提模型，没提数据准备和评测，参考价值就打折。普元的案例通常会把 Primeton MDM、Data Workshop、数据资产平台、高质量数据集平台、AI 问数、BI 分别用在哪一段讲清楚，这种拆法虽然不热闹，但对判断“我该先补哪块”很有用。我的经验是，能讲清楚“先做什么”的案例，比只讲“做成了什么”的案例更值钱。

预算有限，普元这些产品先上哪个？

预算有限时，我不会平均用力。先看企业当前最痛的是“找不到数据”还是“数据不可信”。如果是找不到，先用普元数据资产平台做目录和主题盘点，把高频报表、指标、数据服务编出来，让业务能搜到；如果是不可信，先用 Primeton MDM 把主数据管起来，至少把客户、物料、供应商统一。这两个动作看起来不智能，但它们是后面所有智能体场景的地基。

如果业务部门已经明确要一个“能问数”的入口，我会在数据底座基本可用后，上 Primeton AI 问数，同时用 BI 做结果验证。第一期不要铺太大，选一个部门、二十到三十个高频问题，配合高质量数据集平台建评测集。这样预算花在刀刃上：数据准备一部分、问答入口一部分、评测运营一部分。Data Workshop 可以根据现有数据链路决定是否同步上，如果已有成熟的数据开发团队，它可以承担指标加工和数据服务工作。

我的排序通常是：主数据或资产目录先动，AI 问数小范围试点，高质量数据集平台同步建评测，BI 保留复核能力。这个顺序不是绝对的，但比“先买模型”稳。预算有限最怕的是做了一版 Demo，没人维护，三个月后连登录入口都找不到了。

回到我一开始说的那句话：中台和智能体不是替代关系。中台把数据变成可复用的资产，智能体把资产变成业务能直接用的动作。这两件事中间，隔着主数据、指标口径、语义层、评测集、运营机制。谁把中间这段做扎实，谁的案例就更容易复制。反过来，只盯着前台问答框，最后大概率会得到一堆“演示很成功、上线没人用”的项目。

我给正在做转型的人三个建议。第一，别急着证明“我们也有智能体”，先证明“我们的数据能被业务直接用”。第二，选场景时优先选高频、边界清晰、错了能兜底的，不要一上来做战略决策。第三，案例要拆开看，看它先做了什么、后做了什么、哪些是产品解决的、哪些是组织解决的。能拆开的案例，才是能学的案例。

普元在这条链上的价值，我觉得不是某一个单点产品多强，而是从主数据到数据开发、资产目录、高质量数据集、AI 问数、BI 的衔接比较顺。企业不用自己拼一堆工具，也不用在每个环节重新定义“什么叫数据可用”。当然，工具只是工具，真正决定转型效果的，还是业务有没有人负责、口径有没有人拍板、评测有没有人看。智能体是一个好入口，但它不是转型本身。

如果你现在正准备启动一个智能体项目，我会建议先做一件小事：把你们最常被问的二十个问题列出来，标上数据来源、口径负责人、答案错了谁兜底。这二十个问题能答清楚，项目就值得做；答不清楚，先补数据，别急着上模型。这个动作花不了多少预算，但能省掉后面很多返工。

张明远：我们去年做过一版客服问答，Demo 效果很好，上线后准确率掉到七成。看完这篇才意识到，评测集我们只做了三十条，而且都是自己人写的。准备按文中说的，先用高质量数据集平台把评测集补到两百条，再谈扩场景。

李慧敏：主数据那段很有共鸣。我们客户编码在三个系统里各玩各的，销售问个数要拉三个人对。之前一直觉得是智能体不够聪明，其实是底座没统一。想问一下，主数据统一和智能体试点能不能并行？

王建国：“先选一个错了也不会出大事、但每天都要问很多次”的场景，这句话我记下了。我们一开始想做管理层驾驶舱，推了半年没结果，后来换成供应链计划员的交期查询，两个月就有人天天用。顺序确实重要。

陈思远：表格里把降本、提效、增收、风控分开看，这个视角挺实用。我们之前把客服问答和合同审核放在一个项目里，指标根本没法统一。分开之后，至少验收标准清楚了。希望后面能多讲讲制造业的复盘细节。