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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

比如查询结果是：

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

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

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

系统还可以进一步说明：“当前查询结果显示，物料 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、并把结果转化为业务语言的智能问数系统。

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

刘守国 手机/微信：13533786006

李   丹 手机/微信：18565067696

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

图片来源于网络，如有侵权请联系删除

技术支持：何笑雨

编辑：刘颖、叶健文、吴伟佳