告别复杂报表系统,AI 如何用一句话帮企业自动查数据?

企业不是没有数据，而是查数据太慢。库存、销售、采购、财务等数据都在系统里，但业务人员想看一个结果，往往还要找人导表、写 SQL、做报表。AI 查报表的价值，就是让用户用一句话提问，系统自动查询数据、生成表格和分析结果。但要做到这一点，AI 不能只是连接数据库，还要先看懂业务字段、数据口径和权限范围。只有这样，企业才能从“找人导数”，走向“一句话查数”。

上一篇我们讲了数据表处理的上半场：先确定用户能查什么表，再把技术字段翻译成业务语言，让大模型真正看懂企业数据表。

但看懂表结构，还只是第一步。真正进入业务使用时，用户不会问“请帮我写一条 SQL”，而是会直接问：“库存少于 100 的物料有哪些？”“这个组织下面哪些物料出库最多？”“最近哪些产品质量异常？”

系统要做的，是把这些自然语言问题转换成可执行的 SQL，再把查询结果变成业务人员能看懂的表格、图表和分析说明。

这就是数据表处理的下半场。它要解决的不是“AI 能不能写 SQL”，而是 SQL 是否符合当前业务口径，是否只查询当前用户有权限的数据，执行失败后能不能自动修正，查询结果能不能翻译成业务人员看得懂的语言，以及能不能继续生成图表、分析说明和后续追问。

SQL 生成不能完全放任大模型

让大模型生成 SQL，本身并不难。难的是让它生成符合业务规则、权限范围和数据库语法的 SQL。

比如用户问：“本季度库存不足的物料有哪些？”系统生成 SQL 时，需要同时考虑很多问题：查哪些表，哪些表之间怎么关联，当前用户属于哪个组织，时间范围怎么写，库存不足的判断条件是什么，数据库是 PostgreSQL 还是 Oracle，日期、分页、类型转换语法是否正确。

如果直接让模型自由发挥，它可能会编造表名、错用字段、JOIN 错关系，甚至查到不该查的数据。

所以，我们的方案不会让模型“裸写 SQL”，而是把用户问题、表结构说明、基础 SQL、组织编码和业务规则一起提供给模型，让它在约束范围内生成 SQL。

也就是说，自然语言问报表不是简单地把一句话交给大模型，而是要先把“能查什么、怎么查、按什么口径查”讲清楚。这样生成出来的 SQL，才更接近企业真实业务，也更具备上线使用的基础。

基础 SQL 的作用：给模型划定查询路线

可以把基础 SQL 理解成一条“查询路线”。它告诉模型：这个报表主要查哪张表，可能关联哪些表，表与表之间怎么连接，哪些条件是当前报表本来就需要保留的。

这样，模型不是从零开始猜 SQL，而是在已有业务报表逻辑的基础上生成查询。比如用户问：“当前仓库中，哪些良品库存低于 100？”系统不会让模型随便找库存相关表，而是先拿到当前菜单对应的基础 SQL 和字段说明，再让模型基于这些信息生成查询逻辑。

这时模型需要做的不是“自由发挥”，而是在已有查询路线中补充用户问题对应的条件：查当前库存报表允许的表，限定当前组织，筛选在库数据，筛选良品，筛选数量小于 100，并返回物料编码、仓库、数量等字段。

这样生成出来的 SQL 更接近业务真实口径，也更不容易越权。对企业来说，基础 SQL 的价值不只是提高生成准确率，更重要的是把 AI 的查询范围限制在业务系统允许的边界内，减少乱查表、乱关联和乱生成的风险。

简单问题直接生成，复杂问题先拆解

企业报表问题有简单的，也有复杂的。

简单问题，比如“库存少于 100 的物料有哪些？”，通常可以直接基于表结构说明和业务规则生成 SQL。

但复杂问题就不能只看一句话表面意思。比如：“统计本季度各仓库不良品数量，并按数量从高到低排序。”这个问题里其实包含多个动作：限定时间范围，筛选质量状态为不良品，按仓库分组，统计数量，再按数量排序。如果再加上组织权限、仓库范围、产品类型，问题就会更复杂。

这种情况下，系统可以先让模型分析问题，把它拆成多个查询条件，再提取最终 SQL。这样可以降低复杂聚合、排序、筛选和多表关联场景中的生成错误。

所以，在自然语言问数场景中，不同问题适合不同处理方式。简单问题追求响应效率，复杂问题则更需要先做问题拆解和查询规划。这样既能提高生成效率，也能提高复杂报表查询的稳定性。

SQL 执行失败后，要能自动修正

真实业务场景中，AI 生成的 SQL 不可能每次都一次成功。它可能字段名写错，可能日期格式不兼容，可能数据库方言不一致，可能某个 JOIN 条件缺失，也可能直接返回数据库报错。

所以，我们的流程里有一个重要环节：SQL 自动修正。系统会先执行 SQL。如果执行成功，就进入结果处理；如果执行失败，就读取数据库返回的错误信息，再把原始问题、当前 SQL、表结构和错误原因重新交给模型，让它修正 SQL。

这个过程可以理解为：生成 SQL → 执行 → 报错 → 根据错误修正 → 再执行

这样系统不是一次失败就结束，而是形成一个闭环。这对企业报表查询很重要。因为真实业务库往往表多、字段多、语法规则多，不同数据库的写法也不一样。如果没有自动修正机制，AI 报表查询很容易停留在“演示能跑，落地不稳”的阶段。

对企业用户来说，他们并不关心后台 SQL 改了几次，他们关心的是最终能不能稳定查出结果。SQL 自动修正，就是让自然语言问报表从“能生成”走向“能执行”的关键一步。

查询结果不能只返回一张冷冰冰的表

SQL 查询成功后，也不能直接把数据库结果原样丢给用户。因为返回结果里可能还是英文列名、编码值和大量数据，业务人员看起来仍然不直观。

比如查询结果是：

mtrl_code	lpn_qty	loc_stat	qlty_stat
A001	80	1	2

如果直接返回这样的结果，业务人员可能还要再问：mtrl_code 是什么？loc_stat = 1 代表什么？qlty_stat = 2 是良品还是不良品？

所以系统还要继续做结果语义化，包括把英文列名翻译成中文，把编码值转成业务含义，把结果整理成 Markdown 表格，再根据数据生成柱状图、折线图、饼图等 ECharts 图表，并生成一段中文分析说明。

上面的结果，就应该转成业务人员能看懂的形式：

物料编码	数量	位置状态	质量状态
A001	80	在库	良品

系统还可以进一步说明：“当前查询结果显示，物料 A001 在库良品数量为 80，低于库存阈值 100，建议关注补货情况。”如果结果适合做图表，还可以生成库存分布图、仓库对比图或趋势图。

这一步决定了 AI 查报表的最终体验。因为企业用户真正需要的不是一段 SQL，也不是一堆数据库字段，而是一份能直接辅助判断的业务结果。

结果还要能继续追问

企业数据分析很少是一问一答就结束。

用户问完“哪些物料库存低于 100？”，下一步可能会继续问：“这些物料最近 30 天出库情况如何？”“哪些仓库缺口最大？”“这些物料对应哪些供应商？”“是否存在连续多周低库存的情况？”

所以，系统在返回结果后，还可以根据当前问题和结果生成相关追问。这样用户就可以围绕同一批数据继续探索，而不是每次重新组织问题。

这也是自然语言问报表和传统报表系统的不同之处。传统报表通常是固定菜单、固定字段、固定筛选条件；而 AI 报表查询更像是一个可以持续对话的数据分析助手。用户可以先查一个结果，再围绕结果继续追问原因、趋势、异常和关联对象。

因此，查询结果不仅要能展示，还要能继续分析。系统可以进一步生成 Markdown 表格、ECharts 图表、分析报告和相关问题，支持用户进行多轮数据探索。

一个完整例子：问一句话，查出库存风险

假设用户问：“当前仓库中，哪些良品库存低于 100？”系统会怎么处理？

第一步，判断用户所在菜单和权限，只获取当前库存报表允许查询的数据表和字段。

第二步，整理字段含义，比如 mtrl_code 是物料编码，lpn_qty 是数量，loc_stat 是位置状态，qlty_stat 是质量状态。第三步，补充枚举值，比如 loc_stat = 1 表示在库，qlty_stat = 2 表示良品。

接下来，系统会结合基础 SQL、组织编码和业务规则生成 SQL，并执行查询。如果执行时报错，系统会根据错误信息自动修正后再次执行。

查询成功后，系统会把结果中的字段名和状态值翻译成中文，生成表格、图表和分析说明。

最终用户看到的不是一段 SQL，而是一份清楚的业务结果：哪些物料库存不足，数量是多少，属于哪个仓库，是否需要补货，还能继续追问“这些物料近 30 天出库情况如何”。

这就是 Text2SQL 的价值：让用户用自然语言问问题，让系统在后台完成表结构理解、SQL 生成、执行修正和结果解释。用户不需要知道数据库字段叫什么，也不需要自己写 SQL，就能更快获得可以辅助判断的业务结果。

哪些企业尤其需要自然语言问报表

如果企业已经有大量业务系统和数据库，比如 ERP、MES、WMS、CRM、财务系统、供应链系统、生产管理系统，那么自然语言问报表通常会有很大的应用空间。

这类企业经常会遇到几个问题：

业务人员查数依赖技术人员，临时分析需求响应慢；

报表系统很多，但数据口径不统一；

字段名复杂，业务人员看不懂；

SQL 查询门槛高，普通员工不会写；

管理层想快速看经营数据，但每次都要等别人整理；

大模型虽然能生成 SQL，但结果不稳定，权限也不好控制。

如果这些问题已经影响到经营分析、库存管理、质量追踪、采购决策或客户运营，那么企业就不只是需要一个“数据库查询工具”，而是需要一套能理解业务字段、遵守权限边界、自动修正 SQL、并把结果转化为业务语言的智能问数系统。

对企业来说，自然语言问报表的价值不是炫技，而是让业务人员少等报表、少找技术、少做重复导数，把更多时间放在判断问题和解决问题上。

结语

企业报表查询，不能只靠模型猜 SQL。

很多企业希望 AI 能直接查报表、做分析，这是正确的方向。但如果只是让模型凭感觉生成 SQL，很容易出错。

因为企业数据表背后不仅有字段名，还有字段含义、枚举值对应的业务状态、用户权限范围、组织边界、业务口径和数据库语法规则。这些如果没有提前处理和约束，AI 很容易查错、查偏，甚至越权。

所以，真正可用的 Text2SQL，不只是一个“自然语言转 SQL”的小工具，而是一条完整的闭环链路：获取表结构 → 字段语义化 → 构造 Prompt Schema → SQL 生成和自动修正 → 结果语义化、图表展示和多轮追问

打通这条链路后，企业用户才能真正做到：用一句话查数据，用一张图看趋势，用一段分析理解业务变化。

下一篇，我们将继续讲企业知识库中的另一类复杂资料：工程图纸如何进入知识库，以及图纸中的参数、区域和结构如何被 AI 理解。

如果您的企业正在建设内部知识库、智能问答系统或业务智能体，尤其遇到复杂文档处理、表格问答、图纸资料理解、多部门权限控制、答案来源追溯等问题，欢迎与中山大学智能软件研究中心团队交流。

人工智能与机器人专委会可信知识库技术专家

何笑雨

中山大学软件工程学院副教授，博导

中山大学百人计划青年学术骨干。博士毕业于中山大学，先后在中山大学和南洋理工大学从事博士后研究工作。从事大模型、智能体、智能计算相关的基础研究，在AIJ,SIOPT, TEVC等期刊发表学术论文三十余篇，谷歌学术引用1000+,H指数17。主持国家自然科学基金，广东省重点研发子课题等科研项目十余个。在可信知识库方面为广汽本田、海天味业等多家企业提供落地服务。

产学研合作联系

刘守国手机/微信：13533786006

李丹手机/微信：18565067696

《“具智AI”知识专栏》由广东省制造业协会人工智能与机器人专委会与中山大学智能软件研究中心联合打造，由中山大学等高校专家定期分享人工智能与机器人最前沿技术硬核知识

往期内容

一套能用起来的知识库，要先解决这三个问题

PDF不是简单转文字：可信知识库如何处理复杂文档？

AI 查报表为什么总出错？问题可能出在字段语义没讲清楚