数据中台建好只是起点。本文通过一个真实案例，完整呈现企业如何以数据治理为底座、以AI智能体为入口，构建起"感知需求→智能匹配→持续演进"的对话式数据分析服务体系，实现运营模式的根本性升级。
数据中台建好了，为什么用户还是用不起来？
数据要素市场化进程加速的背景下，大量数科公司和数据运营企业完成了数据中台建设。平台汇聚了丰富的公共数据与市场化数据资源，资产目录清晰、API接口齐备、数据产品陆续上架——从项目交付角度看，建设任务已经完成。
然而，上线后的运营数据常常令人困惑：用户活跃度远低于预期，大量数据产品无人问津，业务人员的反馈集中在"找不到""不会用""不敢用"三个关键词上。
H市某数据要素流通平台就典型地体现了这一困境。该平台是国家"数据要素X"联合创新实验室的核心基础设施，上线后运营团队很快发现：找数据靠关键词硬搜，搜出来不知道哪个是自己要的；用数据靠自己摸索，功能完备但指引不足，新用户面对密密麻麻的菜单栏无从下手；运营需求难以系统收集，数据产品上架凭感觉，迭代缺少方向。一位运营成员这样形容当时的处境："我们像守着金矿却发不出工资。"
这个困境指向一个核心问题：数据中台解决的是"有没有"的问题，但"能不能用得好"是另一个维度。在数据"可被访问"和数据"能被用好"之间，存在一条需要被跨越的鸿沟。
一、数科公司的"数据悖论"：资源越丰富，用数越困难
传统数据平台的设计思路可以概括为一句话——"我有什么，你来用"。目录建好了、API接口开放了、数据产品上架了，建设方的任务似乎就完成了。但站在业务人员视角，他们面对的是一堆看不懂的技术表名、摸不透的数据口径，以及一个"你自己找"的沉默界面。
从实践来看，这个矛盾在三个层面表现得尤为突出。
找数难。 平台资源目录动辄上百项，检索方式却基本停留在关键词匹配。用户输入"企业经营情况"，系统返回的是按技术名称排列的几十张数据库表，没有任何业务语义的引导。该选哪张表、字段之间是什么关系、口径是否一致，全靠用户自己摸索判断。
用数难。 平台功能完备——数据查询、下载、申请、API调用一应俱全，但使用门槛不低。新用户登录后面对满屏的功能入口，不知道从哪个开始。更麻烦的是，同一种数据在不同子系统中的口径可能不一致，用户需要自己理解各字段的业务含义，很多时候正是卡在了这一步。
运营难。 用户遇到了什么问题、哪些数据产品没人用、哪些高频需求还没被覆盖——这些信息分散在客服记录、搜索日志和零散的反馈邮件里，缺乏系统化的收集和分析机制。运营团队安排数据产品上架，更多时候是在"凭感觉"而非"靠数据"。
这三个问题不是技术架构成熟的平台能自动解决的。它们指向的是同一个方向：在数据"可被访问"和数据"能被用好"之间，缺了一个能理解业务语义的智能入口。
二、为什么有了大模型不等于有了AI用数
一个自然的想法是：既然大语言模型能理解自然语言，那在数据库前面放一个大模型，让业务人员用对话的方式查数据，问题不就解决了吗？
事情没有这么简单。
大模型擅长的是语言理解和文本生成，但它并不天然"理解"企业的数据。大模型可能知道"客户"这个词的含义，但它不知道在ERP系统里"客户编码"指的是签约主体、在CRM里"联系人名称"指的是业务对接人——如果这些元数据没有被清晰地梳理和描述，AI生成的查询结果看起来流畅，但可能把不同口径的数据混在一起，输出一份"看似合理却不可信"的分析结论。
要让AI真正"读懂"企业的数据，至少需要三个基础条件。
数据可信。 AI的推理能力再强，也无法替数据"编造"质量。如果一个字段存在大量空值或格式错误，模型可能在上下文推理中将其补全为一个不确定的数值，用户难以判断该数值的依据来自哪里。数据质量的底线，直接决定了AI输出的可信度。从DAMA数据管理知识体系的框架来看，这对应的是数据质量管理域——确保数据在完整性、一致性、准确性等维度的基本达标。
数据可理解。 大模型面对数据库时，看到的是一堆技术字段名和数据类型。它需要额外的"翻译层"来理解这些字段在业务世界里的实际含义。"订单金额"是含税还是不含税、更新频率是实时还是T+1、与哪些上游表存在依赖关系——这些信息属于元数据管理的范畴。元数据越丰富，AI对数据的理解就越接近业务人员的认知。
实体可关联。 同一个客户可能在采购系统、销售系统和售后系统中以不同编码存在，如果主数据没有统一管理，AI在跨系统分析时就会把同一个人算成三个不同的人。数据标准和主数据管理解决的就是这个问题——确保"一致性"在跨系统的数据使用中不丢失。
这恰好对应了DAMA框架中数据质量、元数据和主数据三个核心管理域。它们不是AI项目的"前期准备工作"，而是AI能产生可靠输出的必要基础设施。国内一些数据中台产品在实践中提出了"理采存管用"的五阶段闭环——"理"产出的资产目录是AI理解"有什么数据"的入口，"管"建立的标准和质量规则是AI输出可信度的保障，而这些最终都服务于"用"的环节。
换句话说，治理不是AI的绊脚石，而是AI的语义底座。
三、落地实录：从智能客服到智能中枢的认知升级
理论分析归理论分析，真正到了项目现场，挑战才逐一浮现。
3.1 项目起点：客户要的是智能客服，但问题不在问答
项目启动初期，实施顾问团队进驻江苏某国企数科公司，对数据要素流通平台的运营现状进行了全面诊断。客户最初的诉求很朴素——做一个智能客服机器人，把重复性的咨询问答自动化，减少人工坐席的工作量。
但顾问在调研中发现了一个更深层的结构性问题：平台上已有百余款数据产品，但用户的实际使用率远低于资源的上架率。大量数据产品无人问津，不是因为质量不好，而是因为用户根本不知道它们的存在，或者知道了也不知道怎么用。平台的问题不在"回答用户的问题"，而在"感知用户的需求"和"把需求匹配到正确的数据产品"上。
经过几轮深入讨论，项目定位从"做一个问答机器人"升级为"构建一个能感知需求、智能匹配、持续演进的运营中枢"。这个认知转变，是后续所有工作的出发点。
3.2 知识库底座：近三周的"笨功夫"
智能体的智能从哪里来？从知识库里来。平台中的资源目录、数据产品描述、使用流程说明、制度规范文档，构成了智能体理解业务世界的"教材"。
但把这些材料整合为统一的运营知识库，比预想的要耗时得多。出人意料的是，主要困难不在技术上，而在业务语义的统一。同一个数据产品——比如"企业经营画像"——在市场监管部门的口径里侧重合规，在经济发展部门的口径里侧重增长。不同部门对同一个字段的定义、同一个指标的算法，存在大量隐性差异。
项目团队花了近三周时间，逐一拉通核心数据资产的业务口径，才把知识库的语义层梳理清楚。一位参与该阶段的项目成员回忆："那三周是最枯燥的，但也是最重要的——如果没有这一步，智能体上线后给出的答案可能是'逻辑正确但口径错位'，那比不给答案更危险。"
3.3 感知与匹配：让智能体"看懂"用户
知识库就绪后，团队构建了"感知-匹配-演进"三位一体的智能体架构。这不是一个独立于平台之外的聊天机器人，而是深度嵌入数据中台治理成果之上的能力层。
在匹配机制上，团队采用了语义检索与模糊检索双模并行策略——用户用自然语言输入"看看本市上季度制造业的经营情况"，系统先在知识库中做语义匹配，定位到相关的数据产品和指标定义，再生成准确的查询路径。模糊检索作为补充，覆盖用户输入不精确、指标名称记不全等常见场景。
在感知机制上，团队引入了需求感知引擎。用户的搜索失败记录、浏览过程中的中断点、发起但未完成的申请——这些"沉默的信号"被系统自动捕获和分析，定期生成需求洞察报告。报告会告诉运营团队：最近一个月哪些数据产品被高频搜索但找不到、哪些已有产品上线后使用率为零、哪些用户群体有相似的需求模式但尚未被覆盖。
一位运营负责人后来总结："以前我们是闭着眼推数据产品，智能体给了我们一扇窗户，能看清楚用户真正在找什么。"
3.4 运营闭环：最意外的变化发生在流程层面
智能体上线后，最显著的变化不是技术指标，而是运营决策方式的转变。
过去，运营团队讨论"下一批数据产品上什么"，基本靠个人判断和经验。运营会议上经常出现的情况是：一个人觉得A重要，另一个人觉得B更紧迫，缺乏统一的数据依据来支撑决策。
智能体上线后，需求洞察报告成为运营会议的固定议程。报告中按需求强度排序的数据产品缺口清单，直接转化为上架优先级列表。团队从"凭感觉拍板"切换到"靠数据决策"，数据产品迭代周期从按月计缩短为按周计。一位客户方项目负责人评价说："以前推数据产品像蒙着眼睛打靶，智能体给了我们一杆瞄准镜。"
四、效果：从"数据可用"到"数据好用"的量化跃迁
智能体上线运行一段时间后，项目组对关键运营指标进行了复盘。以下对比基于实际运营数据（部分指标采用区间表述以保护商业信息）：
| 指标 | 上线前 | 上线后 |
|---|---|---|
| 基础咨询工单量 | 人工坐席处理为主 | 显著下降，高频重复咨询由智能体承接 |
| 用户检索耗时 | 多次关键词尝试，平均耗时较长 | 大幅缩短，自然语言直达目标 |
| 首次申请成功率 | 偏低，用户常因选错数据产品而退回重提 | 明显提升 |
| 数据产品迭代周期 | 按月计，上架决策凭经验判断 | 按周计，需求洞察驱动优先级排序 |
| 运营模式 | 被动响应，需求收集碎片化 | 主动感知，需求驱动、持续演进 |
从项目组的复盘来看，效果改善并非来自某一个"杀手级功能"，而是知识库梳理、感知机制、匹配引擎和运营闭环四件事叠加之后的系统性变化。智能体只是表面上的交互入口，真正起作用的，是背后被组织起来的治理成果和运营机制。
五、启示：AI用数在企业落地的三个关键前提
从江苏某国企数科的实践来看，AI用数智能体的落地路径，可以从三个维度来把握。
治理先行，但不求完美。 实践中最常见的两个极端是：要么"等治理全部到位了再上AI"，项目遥遥无期；要么"不管治理先上AI"，上线后发现输出不可信、用户不买账，项目搁浅。较为稳妥的做法是在核心数据域——通常是高频使用的业务主数据、核心指标和关键分析表——把元数据、数据标准和基础质量做扎实，然后在这些域上启动AI用数，边治理边验证，以用促治。治理不需要一步到位，但在AI开始"读数据"之前，核心域的语义和口径必须有一套经得起推敲的基准。
入口做简单，能力做深。 AI用数智能体的用户体验门槛，直接决定了它在组织内的扩散速度。衡量标准可以很朴素——一个没有经过培训的业务人员，能不能在不看任何说明的情况下，三分钟之内查到他想要的数据。自然语言查询、智能检索建议、自动图表生成，这些能力今天已经可以在现有数据中台之上叠加部署，关键是把体验做得足够轻。入口越简单，业务人员越愿意用；用得越多，平台治理成果的价值就越能被感知。
运营闭环比功能上线更重要。 智能体项目最容易犯的错误，是把它当成一个"交付即结束"的IT工程。从实践来看，智能体部署上线只是开始，真正的价值增长来自持续运营。需求感知→数据产品迭代→效果验证的闭环机制，是决定AI用数长期价值的关键变量。运营团队从"凭经验"到"靠数据"的决策方式转变，往往比技术方案本身更能说明项目的成功程度。
目前业界已有成熟的AI用数智能体方案，提供开箱即用的自然语言用数能力，支持集成主流大模型和数据不出域的私有化部署。但工具本身不是关键——关键是企业是否做好了让数据"被AI读懂"的准备。治理是基础，入口是桥梁，运营闭环是持续引擎。三件事做到位了，AI用数才不是一次技术演示，而是一项可以持续生长的组织能力。
参考来源：
[1] DAMA International，《DAMA数据管理知识体系指南（DAMA-DMBOK2）》，机械工业出版社
[2] 全国信息技术标准化技术委员会，《GB/T 36073-2025 数据管理能力成熟度评估模型》（DCMM 2.0）
[3] 全国信息技术标准化技术委员会，《GB/T 36344-2018 信息技术 数据质量评价指标》
[4] 国家数据局，《"数据要素×"三年行动计划（2024—2026年）》
