固定报表是企业数据系统中占比最大且不可替代的组成部分，无论是销售周报、库存月报，还是管理层的核心指标看板，这些逻辑固定、口径统一、定期更新的报表，承载着企业日常运营中绝大部分的数据输出需求，而在固定报表的使用过程中，对已有报表数据进行再查询和筛选，又是极其常见的场景，比如：
* 物流系统想查“上周发往华北的订单”
* 地铁票务系统想查“6 号线上午 9 点到 12 点的进站刷卡情况”
* 人力资源系统想查“一季度技术部迟到和加班情况”
这些查询要求往往非常灵活，都有大量“换条件看数据”的需求，每一个场景的条件组合都不尽相同

参数模版能用，但不好用

以前没有 AI 的时候，解决这类需求只能用参数模板：设计好下拉框、日期选择器、输入框等一系列控件，用户通过点选来设置筛选条件

但参数模板的弊端也很明显，最关键的是不够灵活：用户只能在预设的控件范围内操作，想查什么得看模板里有什么，而且参数一多，模板就变得臃肿不堪，用户要在密密麻麻的控件中找到自己想要的，操作体验极差

现在有了 AI，能否用 AI 来解决这个问题呢？

ChatBI 很火，但也没涉及这个问题

AI 在数据分析领域最火的莫过于 ChatBI——让业务用户用自然语言查询分析数据，系统自动出图表，这场景很酷，也很有用，但它和固定报表的数据查询筛选，压根不是同一回事

首先，定位不同
ChatBI 解决的是“临时性、探索性”的数据分析需求——业务人员临时想看看某个维度的数据，问一句，系统现查现出，而固定报表解决的是“确定性、周期性”的数据输出需求，逻辑固定、口径固定，两者面对的是完全不同的使用场景

其次，ChatBI 并没有涉及“对做好的表做灵活筛选”这件事， 它能让业务人员自己从零开始查数据做报表，但不能对已经做好的固定报表进行便捷的数据筛选，换句话说，ChatBI 是针对数据操作，而固定报表查询是针对报表操作——这是两个不同的命题

所以，固定报表查询这个具体而实际的问题，变成了“灯下黑”的角落

润乾的探索：让固定报表听懂人话

在行业普遍忽视固定报表查询这个场景的时候，专业的老牌报表工具润乾报表做出了一些非常务实的探索

润乾的做法是推出自然语言筛选功能，将传统的参数模板升级为智能对话接口，用户直接在报表界面上输入自然语言，就可以筛选出准确的数据，比如在报表页面输入汉语命令“查询上周发货到华北的订单”

程序就会解析筛选意图，动态生成过滤条件并刷新数据，用户不需要挨个控件设置条件，筛什么自己说就行

这其实还原了人最原始也是最高效的交互方式——我说，你懂，你做到，业务人员再也不用在一排下拉框里小心翼翼地点选了，技术人员也不用总改参数了

采取的什么技术方案？

实现这种功能，容易想到的方案就是用 LLM 将用户的自然语言翻译成 SQL 去执行查询，固定报表的数据范围已经被限定在一个已知的数据集上，筛选只是生成 WHERE 子句，准确率应该会相当高
确实是这样，但准确率高并不等于就能实用，对于企业级应用来说，即使准确率已经达到 90%，剩下 10% 的不确定性也依然不可信任——因为业务用户无法挑出这些错误
纯 AI 大模型方案始终无法彻底规避“幻觉”问题，既使简单场景下准确率很高，也难以胜任严肃的企业场景

面对这一困境，润乾另辟蹊径，采用了 “规则引擎主导 + LLM 辅助” 的新型架构

这套架构的核心思想是：不让大模型直接生成 WHERE 子句，而是让它只做擅长的事——理解自然语言并将其规范；而最后 SQL 的生成则交给确定性的规则引擎来完成

被 LLM 规范后的汉语命令，也是汉语，是可以被用户读懂的，比如用户说“上周发往华北的订单”，LLM 将其规范化为“发货日期在 2026-06-15 至 2026-06-21 且收货地区等于华北的订单”，如果转换有错误，用户当场就可以发现并拒绝

这样就可以将 LLM 的“幻觉”风险隔离在用户可见、可纠正的规范汉语命令层面，不让它渗透到最终的 SQL 生成环节，既享受了 AI 的灵活，又保证了结果的可信任
而且 LLM 不涉及数据相关，也更容易满足企业数据安全合规的要求

这种方案没有追求颠覆式的革命，而是让 AI 以一种温和的方式嵌入到已有的报表体系中——不改报表、不改模板，只是给用户多了一个“说话”的入口

这或许才是 AI 赋能固定报表的正确姿势：不是取代，而是增强；不是推倒重来，而是锦上添花，让那些已经在用的固定报表，变得更好用、更智能、更符合 AI 时代对“好用和智能”的定义
当然这也只是 AI 赋能固定报表的一个场景，更多的探索，还需要报表厂商们再接再厉了