销售总监老李周一早会前打开ERP系统，想快速查一组数据："各区域本月销售额完成率是多少？和上个月环比变化怎么样？再拉出近六个月的月度趋势看看。"他打开BI工具点了半天，发现需要的维度分散在三个不同的报表里，做交叉分析得先导出Excel再手动合并。他给IT部门发了条消息，很快收到回复：需求已收到，排期大约三天后给结果。下周一的事情，周一才能拿到数据，老李看着手机叹了口气。
这不是老李一个人的问题。在大多数企业的实际工作场景中，业务人员想查询分析数据的路径是固定的：提需求、等排期、IT写SQL（Structured Query Language，结构化查询语言）、返回结果、发现不对、再沟通、再等。一个简单的问题来回几天是常态，复杂一点的交叉分析等一两周也不罕见。数据明明就存储在系统里，但业务人员就是拿不到、用不起来——技术门槛把数据的使用权牢牢锁在了IT部门手中。
这个问题背后更深层的矛盾在于：企业花大量资源建设数据平台、打通数据孤岛、汇聚数据资产，最终的目的是让数据服务于业务决策。但如果业务人员每一次查数据都必须经过IT翻译，数据中台建设得再好也只是IT团队的后台工具，距离真正赋能业务还差最后也是最关键的一步——让不懂SQL的人也能直接用数据。
二、前置条件：AI读懂数据的四项基础
AI智能用数（即通过自然语言对话的方式查询和分析企业数据）不是在空白系统上装一个聊天界面就能跑通的。一个用户输入"本月华东区销售额排名"，AI需要完成一系列动作：理解用户意图、定位相关数据表、确认字段含义、生成查询语句、返回结果并解读——这个链条的每一步都依赖于数据治理底座的支撑。说得更直白一点：AI不是魔法，它需要知道企业有哪些数据、数据是什么意思、能不能信得过。以下四项基础能力，是AI用数能否跑通的前提。
2.1 数据资产目录——让AI知道"有哪些数据"
数据资产目录（即对企业全部数据资源的系统性编目和索引）在AI用数场景下的角色发生了根本变化。过去，资产目录更多是一份给管理层汇报的"全景图"——展示企业有多少张表、多少项指标、覆盖了哪些业务域。但在AI用数场景中，资产目录变成了AI的导航地图。当用户用自然语言问"本月华东区销售额"，AI需要在资产目录中完成定位：销售额数据存在哪张表里、华东区对应哪些字段、这些表和字段之间是什么关系。目录全不全、目录里的元数据描述准不准，直接决定了AI能不能找到正确的数据。如果核心业务表根本没有纳入目录，AI的表现就是"未找到相关数据"——这不是模型能力不行，而是模型根本不知道数据在哪。正如数据目录领域的研究文献所指出的，数据目录是数据资产化的重要入口（arXiv 2402.05211），在AI驱动用数的场景中，这一入口的作用被进一步放大。
2.2 元数据管理——让AI理解"数据是什么意思"
元数据（Metadata）即"关于数据的数据"，通俗地说就是数据的"使用说明书"：这个字段叫什么名字、从哪个业务系统来、在业务中代表什么含义、数据类型和取值范围是什么。举个例子，一个字段名叫customer_name，如果不标注元数据，AI只知道这个字段存的是字符串。但如果标注了元数据——"此字段为ERP客户管理模块中的签约客户全称，与CRM系统中的company_name字段对应同一个业务实体"——AI就能在用户问"客户签约情况"时准确关联到这个字段。当同一个概念在不同系统中的叫法不同（比如ERP系统叫"客户名称"，CRM系统叫"签约主体"，财务系统叫"往来单位"），元数据层负责统一这些语义差异，为AI提供一个一致的"翻译层"。没有这个翻译层，AI永远读不懂企业数据的真实含义。
2.3 语义模型与数据标准——让AI跨系统理解业务
数据标准统一了核心业务实体的编码规则和口径定义。但更关键的是语义层面——不同业务系统对同一个概念的"口径"可能完全不同。以"销售额"为例：ERP系统按含税签约金额计算，财务系统按不含税实收金额计算，CRM系统按销售机会预估金额计算。三个系统明明都在说"销售额"，数字却对不上。如果这些口径差异没有在语义模型层面统一对齐，AI就只能忠实地汇总它能找到的数据——而它找到的数据本身口径就不一致。这就是为什么制造企业在用大模型查"华东区销售额"时，模型返回3200万、财务系统显示2800万的典型案例：不是模型算错了，是模型取得的数据口径源头就不统一。语义模型的价值就在于为AI提供一个统一的业务语义定义层，让"销售额"在企业内部有唯一且明确的含义。
2.4 数据质量——让AI输出的结果可信
数据质量（Data Quality）即数据的准确性、完整性、一致性和及时性，在AI用数场景中是最先暴露的问题，也最容易被人误判为"模型不行"。大语言模型的一个特征是对输入数据的"信任"——它不会主动质疑数据来源的可靠性，脏数据（缺失值、错误记录、重复数据）会被模型当作事实全盘接受，然后生成流畅但可能完全错误的分析结果。根据Data-Centric AI（以数据为中心的人工智能）的研究观点，AI系统的效果上限由数据质量决定，而非单纯由模型能力决定。在传统数据分析场景中，分析师面对一份脏数据至少还能凭经验识别异常值；但在AI自动查询分析的链路中，脏数据绕过人工审核直接进入结果，修复成本反而更高。龙石数据中台采用旁路监测模式应对这一挑战：数据正常入库不阻塞业务流转，质检规则在旁路并行扫描，发现问题后自动标记、告警并生成质量工单，在不影响业务时效的前提下持续提升数据质量的可见性和可管理性。
三、配置实战：让AI听懂销售问题
以下配置流程基于龙石AI用数智能体的管理端功能，覆盖从创建场景到发布上线的完整路径。每一步均可独立执行，读者可按顺序逐步操作。文中涉及的术语在首次出现时标注了中文解释。
3.1 步骤1：创建用数场景
目的：为"问数据"智能体定义工作上下文——关联哪个数据源、使用哪套指标体系、遵循什么样的分析规则。一个场景就是一个对话沙盒，用户进入不同场景就进入不同的数据工作区。
操作：进入智能体管理→数据知识管理→创建场景。填写三项核心信息：场景名称（如"销售数据分析"），场景描述（如"覆盖订单、回款、退货、客户维度，支持区域/产品/人效多维度分析"），关联业务领域。场景创建完成后，系统为该场景开辟独立的数据知识空间。
3.2 步骤2：接入元数据
目的：让AI知道该场景下可查询哪些数据表、每张表有哪些字段、每个字段的业务含义是什么。
操作：在数据知识管理中配置元数据源，系统自动采集关联数据库中的表结构、字段名称和字段类型。采集完成后，运营人员需为每个字段逐项补充业务含义说明——不只是写"字符串类型、长度50"，更要写清楚"这个字段在业务中代表什么、从哪个系统来、计算口径是什么"。同时设置字段启用状态：核心业务字段设为"可查询"，敏感字段（如客户联系方式、身份证号等）设为"不可查询"，实现字段级别的数据权限控制。
3.3 步骤3：提示词模板与召回测试
目的：引导大语言模型按照企业规范生成SQL和回答。提示词（Prompt）即发送给大模型的结构化指令文本，定义了AI的角色、行为边界和输出约束。
操作：平台内置了默认的提示词模板和召回测试机制，一般情况下直接使用即可。在提示词管理中可以查看和微调，但新手上路不必从头编写——默认模板已覆盖角色设定和基本的SQL生成规范。配置完成后，在测试界面输入几个真实的业务问题（如"本月各区域销售额排名"），观察AI返回的结果是否符合预期。如果结果偏差较大，再针对性地调整提示词或重新检查元数据标注，不必一开始就追求"完美"。测试覆盖单表查询、多表关联、聚合统计等几个典型场景即可。
3.4 步骤4：预设高频问题
目的：对企业内最高频的业务查询问题提前配置标准查询语句，确保这部分问题的回答准确率达到100%。
操作：收集业务部门最常问的销售数据问题，按分类录入预设问题库。常见分类包括区域销售分析（如"本月各区域销售额排名""各区域完成率对比"）、产品分析（如"各产品线销量排行""产品毛利率分布"）、人效看板（如"各团队人均产出""销售个人业绩排名"）、趋势分析（如"近六个月月度销售趋势""同比环比变化"）。每个预设问题配置对应的标准查询语句和预期回答格式。用户在前端使用时可点击预设问题直接查询，无需手动输入。
3.5 步骤5：发布上线
目的：将配置好的智能体和场景从管理端发布到应用端，面向业务用户开放使用。
操作：配置智能体的前端展示信息——名称（如"销售数据助手"）、图标、描述和开场白（如"请输入您想了解的销售数据问题"）。配置场景切换选项，使用户可以在不同业务场景之间灵活切换。确认用户权限分配：按角色设置数据库、表、字段级别的访问范围（如销售一部只能看到对应区域的客户和订单数据，销售总监可以看到全部数据）。设置用户配额（如每人每日200次查询），控制大模型调用成本。所有配置确认无误后，点击发布。
四、配置模板（核心模块）
以下配置模板汇总了步骤3.1至3.5中涉及的关键配置项，供读者在实际操作时参照使用。每个配置项均标注了推荐填写内容和配置说明。
| 配置项 | 填写内容 | 说明 |
|---|---|---|
| 场景名称 | 销售数据分析 | 按业务域命名，用户在前端切换场景时可见 |
| 场景描述 | 覆盖订单、回款、退货、客户维度，支持区域/产品/人效多维分析 | 描述场景覆盖的数据范围和可分析的维度，帮助用户理解该场景的适用边界 |
| 关联数据源 | sales_db（含订单表、回款表、客户表、区域表） | 选择该场景下可查询的数据库和数据表，未关联的数据源对AI不可见 |
| 元数据接入 | 自动采集表结构，逐字段补充业务含义说明 | 每字段须标注业务含义，仅靠字段名AI无法正确理解数据含义 |
| 字段权限 | 客户名称、签约金额→开启；客户联系方式→关闭 | 敏感字段设为不可查询，从源头阻断数据泄露风险 |
| 提示词模板 | 使用平台默认 | 平台内置了角色设定和SQL生成规范，新手上路直接用默认即可 |
| 预设问题 | "本月各区域销售额排名""近6月月度销售趋势""客户回款率分析""各产品线销量排行" | 高频问题预置标准查询，该类问题准确率可做到100% |
| 用户权限 | 销售部门全员→查询权限；销售总监→全部字段访问权限 | 按角色分配数据访问范围，遵循最小化原则 |
| 用户配额 | 每人每日200次查询 | 控制大模型Token消耗成本，可根据岗位调整 |
| 智能体外观 | 名称"销售数据助手"，开场白"请输入您想了解的销售数据问题，如：本月各区域销售额排名" | 增强用户辨识度，开场白引导用户发起查询 |
五、验证结果：自然语言查询实战
配置完成并发布上线后，业务人员打开"销售数据助手"智能体，即可以自然语言对话的方式查询和分析销售数据。以下展示三个典型查询示例，呈现AI用数在实际业务场景中的效果。
查询示例一：单维度排名统计。 用户输入"本月各区域销售额排名"，AI经过意图识别→数据表定位→SQL生成→结果返回的完整链路，输出华东、华南、华北、西南等各区域的销售额排名表格，同时自动生成一张柱状图直观呈现各区域对比，并配以文字解读："本月销售额最高为华东区（1,280万元），其次为华南区（965万元），西南区环比增幅最大（+12.3%）。整体完成率为82%，与上月同期相比增长5.2个百分点。"
查询示例二：多维度趋势分析。 用户输入"近六个月月度销售额趋势，按产品线分类"，AI返回一张趋势折线图，六条产品线（A/B/C/D/E/F）各自呈现近六个月的月度销售额变化曲线，下方附带明细数据表。文字解读自动提炼关键特征："六条产品线中，B产品线和D产品线呈现持续上升趋势，B产品线近六月累计增长34%；C产品线在第四个月出现明显下滑（环比-18%），建议关注原因。"
查询示例三：交叉维度分析。 用户输入"分析一下上季度客户回款率，按区域和大客户/中小客户分类"，AI返回分组柱状图——横轴为区域，每组两根柱子分别代表大客户回款率和中小客户回款率。文字解读标注关键发现："整体回款率82%，其中大客户回款率（91%）显著高于中小客户（74%）。华北区大客户回款率最低（79%），建议重点关注该区域大客户的回款跟进。"
上述查询结果的共同特征是：数据表格提供精确数值，可视化图表提供直观对比，文字解读提炼关键洞察——用户在不需要理解任何SQL语法或数据结构的前提下，通过自然语言对话完成了过去需要IT协助数日才能完成的分析工作。龙石AI用数智能体在返回数据结果的同时，自动生成自然语言描述对数据的关键特征进行提炼与解释，降低了业务人员理解数据结果的门槛。
六、避坑指南
AI用数在实际落地过程中，有三个高频踩坑点。以下逐一拆解现象、根因和解法。
坑一：元数据不全，AI"读不懂"数据。 现象：智能体配置完成、成功发布上线后，用户输入"本月销售额"，AI回复"未找到相关数据"，或者查询了错误的表返回了毫不相干的结果。根因：元数据接入不完整——数据表确实接入了，但字段的业务含义没有标注。AI只知道字段名叫sales_amount、类型是decimal(18,2)，但它不知道这个字段代表的是"含税签约金额"还是"不含税实收金额"，不知道它对应的是哪个统计口径，甚至不确定它在不同表中是不是同一个含义。在这种情况下，AI要么拒绝回答，要么给出一个看似合理但实际错误的答案。解法：元数据接入环节必须逐字段标注业务含义，不能只停留在字段类型和长度这些技术元数据层面。要把每个字段在业务中的含义、来源系统、计算口径写清楚，这一步做得越扎实，后续AI用数越可靠。这不是一次性工作，后续新增的数据表和数据字段也需要同步维护更新。
坑二：数据口径不统一，AI输出"看着对、实际错"。 现象：销售总监用AI查"本月销售额"得到3200万，觉得数据还不错。但财务部门出具的月度经营报告显示销售额2800万，差距400万。AI给出的数据"看着对"——格式规范、数字精确、图表美观——但"实际错"——和权威数据源对不上。根因：同一个"销售额"指标在不同的业务系统中口径不一致。ERP系统按含税签约金额计算，财务系统按不含税实收金额计算，CRM系统按销售机会预估金额计算。AI只是在忠实地汇总它能找到的数据，但这些数据源自不同口径，汇总本身就没有意义。解法：在数据标准层面统一核心指标的口径定义，明确"销售额"在企业内的唯一计算规则。如果多个口径在业务上都有存在的必要性，则必须用不同的指标名称加以区分（如"含税签约销售额""不含税实收销售额"），确保AI引用的每个指标在语义上单一、明确、无歧义。语义模型的建设是这道门槛的关键——它决定了AI是"理解业务"还是"堆砌数据"。
坑三：只配工具不建运营机制，"上线即终点"。 现象：智能体上线首月使用活跃，业务人员觉得新鲜纷纷试用。三个月后再看数据，日活跃用户大幅下滑，少数仍在使用的用户偶尔提问发现回答不对，不知道找谁反馈，默默放弃。智能体从"新工具"变成了"僵尸系统"。根因：AI用数不是一次性配置项目，而是一个需要持续运营的能力平台。没有用户反馈收集机制、没有问答质量监控、没有人持续优化提示词和元数据标注——智能体上线后不会自己变聪明，它只能停留在配置时的初始水平。解法：建立"用户反馈→工单处理→知识库更新→模型优化"的运营闭环。具体而言：用户对智能体回答结果可点赞或点踩，点踩记录自动生成反馈工单推送至数据治理团队；运营人员复核处理后，将优化结果更新至提示词模板或元数据标注；定期分析高频失败问题，系统性改进薄弱环节。运营闭环是AI用数从"能用"走向"好用"的关键机制。
七、小反转：真正决定效果的不是配置
看到这里，你可能会认为AI用数就是按照上面的六个步骤逐一配置、反复调优。配置本身确实不复杂——创建场景、接入元数据、编写提示词模板，有经验的运营人员几天之内就能完成部署。但真正决定AI用数效果的，不是提示词写得有多精妙、模型参数调得有多细致，而是配置背后数据治理的成熟度。
资产目录不完整，AI就找不到数据——这和提示词质量无关。元数据没有标注业务含义，AI就读不懂数据——这和模型能力无关。数据标准不统一，AI输出的结果就是"看着对、实际错"——这和查询逻辑无关。数据质量无人管理，AI给出的分析结论就不可信——这和算法精度无关。AI用数的上限，不由大模型的能力决定，由企业数据治理的成熟度决定。龙石AI用数智能体的一个核心设计前提是：数据治理到位后AI用数效果才好——治理的底子，不能省。
八、案例验证：一个已经跑通的样本
江苏某国企数科运营着一个数据要素流通平台，汇聚了大量公共数据与市场化数据资源。平台上线后，数据有了、功能全了，但面临一个典型的"最后一公里"问题：用户找数靠关键词硬搜，用数靠自己摸索，运营团队想收集用户需求却缺乏系统化手段——三大断层（找数难、用数难、运营难）导致平台价值没有充分释放。
龙石数据为平台部署了AI用数智能体，构建了"感知-匹配-演进"三位一体的智能入口。在技术层面，基于语义检索和模糊检索双模引擎理解用户的自然语言查询意图，自动引导用户从查找数据到申请使用的全流程。运营层面是这次部署中更值得关注的亮点——智能体持续分析用户的搜索失败记录和浏览行为中断点，自动识别潜在的数据需求并生成需求洞察报告，这些洞察直接驱动了数据产品的上架、优化和迭代，形成了"需求驱动供给"的良性循环。
上线后的效果从两个维度得到验证。效率维度：平台基础咨询工单量显著下降，用户从提出问题到获取数据的耗时大幅缩短。价值维度：系统持续挖掘出多个真实用户需求，其中部分高价值需求已进入产品开发流程，数据产品的复用率明显提升。运营团队的反馈很直白："以前推数据产品像蒙着眼睛打靶，智能体给了我们一杆瞄准镜。"这个案例的启示在于：AI用数的价值不仅是降低查询门槛，更在于打通了从"用户要什么"到"平台供给什么"的需求驱动链路。
九、常见问题（FAQ）
Q1：AI用数的准确率到底能达到多少？是不是和通用ChatGPT差不多？
AI用数的准确率取决于两个变量：数据治理的质量和问题本身的复杂度。简单场景（如按条件查询、单表统计、排名排序等），准确率可以做到接近100%；复杂场景（跨多表关联推理、涉及模糊业务概念的查询）会有一定误差。关键区别在于：企业AI用数不是开放域问答，而是在企业自身数据资产范围内做查询和分析——治理到位的元数据和数据标准，能大幅缩小AI的理解偏差。通用的ChatGPT不了解你企业的数据结构和业务口径，而企业AI用数的上下文由你自己的数据知识库定义，两套系统的性质不同，不宜直接类比。
Q2：我们公司用的是Oracle/SQL Server，不是MySQL，能用吗？
可以。AI用数智能体适配MySQL、达梦、Oracle、SQL Server等多类主流数据源，底层数据库类型不影响自然语言查询能力。在提示词模板的SQL约束规范中，将语法类型设置为与你实际使用的数据库对应的方言即可。如果企业同时使用多种数据库，可为不同场景分别配置对应的SQL语法约束。
Q3：数据不出域怎么保证？如果是私有化部署，大模型放在哪？
龙石AI用数智能体支持客户自备本地大模型（如DeepSeek或千问3），所有数据查询和推理分析在本地服务器上完成，企业数据不出域、不上云。大模型部署在客户自有服务器上，数据流转的全链路控制在企业内部网络范围内，符合数据安全合规要求。
Q4：我们的数据资产目录还没建全，能不能先用起来？
不需要等"完美"再启动。建议的策略是：先选定一个业务价值最高的用数场景（比如销售数据查询），把这个场景相关的几张核心表的元数据做扎实，配置好提示词和预设问题，先跑通再横向扩展。反过来看，AI用数的需求本身也会驱动数据治理的加速——当你发现某张表查询结果不可信时，自然会推动它的数据标准和质量管理。治理和用数可以并行推进、相互促进，而不是先做完一个再做另一个。
Q5：业务人员问的问题太口语化怎么办？比如"最近卖得怎么样"这种模糊问题。
这正是混合检索引擎发挥作用的地方。AI用数智能体的语义检索和模糊检索双模引擎能够理解"卖得怎么样"背后用户可能想查询的是销售额、增长趋势、完成率等指标。同时，预设问题功能把最高频的业务问题提前配置为标准查询，确保模糊问法也能命中准确结果。配合问题推荐功能——系统根据当前提问自动推送相关的待探索问题——引导用户逐步聚焦分析方向，让模糊的查询意图在交互过程中逐步明确。
Q6：多个部门使用同一个场景，怎么控制数据权限？
通过智能体权限管理，可以按角色进行数据库、表、字段三个级别的精细化权限控制。例如，销售一部只能看到华东区的客户和订单数据，销售二部只能看到华南区的数据，销售总监可以看到全部区域的数据。权限分配遵循最小化原则——每个用户只能查询被授权的数据范围，从机制层面杜绝越权访问。
Q7：AI给的结果万一错了，业务人员怎么判断？
这恰恰是数据解读和元数据标注的价值所在。AI返回结果时附带三层辅助判断信息：第一，文字解读——提炼数据的关键特征，便于用户快速理解结果含义和发现异常；第二，数据来源说明——标注数据取自哪个系统、哪个表，让用户知道结果的数据基础；第三，工单反馈机制——用户对结果不满意可一键提交反馈工单，运营人员复核处理后反馈修正结果。这三层机制共同构成了"可信用数"的保障体系，让用户在使用AI结果时有据可查、有错可纠。
十、方法论收尾
AI智能用数本质上是"理、采、存、管、用"五阶方法论中"用"这一环的自然延伸。它不是一个独立的新系统或新项目，而是数据治理水到渠成之后的能力升级。
值得强调的是：不是"等治理做完美了再上AI用数"，而是AI用数的需求反过来会推动"理"和"管"两个环节的加速。当业务人员用自然语言问数据问不准的时候，自然会暴露出数据标准不一致、元数据标注缺失、数据质量有问题——这些问题的根因和解决路径，都在"理采存管用"的前四环里。AI用数就像一面镜子，把治理层面的问题照得一清二楚。
对于已经按照"理采存管用"方法论推进数据治理的企业来说，AI用数不是另起炉灶的新投入，而是已有建设成果的价值释放。工具到位了、数据治理了、业务人员能自己查数据了——这才是数据中台建设的最终目的：让数据不仅是技术团队管理的资产，更是业务人员能用起来的工具。
参考来源：
Data-Centric AI, Andrew Ng et al.
DCMM 2.0 数据管理能力成熟度模型（GB/T 36073-2025）
DAMA-DMBOK 2.0 数据管理知识体系指南, DAMA International
