如果你在软件公司或企业的开发中心做行业应用——ERP、财务、供应链、CRM、政务系统——报表和查询是绕不开的功能。AI编程这么热，一个很自然的问题就是：这些事能不能用 AI 提效，让开发人员从无止境的排期里松一口气？

答案是能，但前提是先分清任务。业务方随口一句“做个报表查个数据”，在工程上大概可以分成三种任务：固定报表、自助报表、通用查询。它们的交付物不同、代码重心不同，AI 该接在哪一段也完全不同。

本文按这三种任务分开讲：痛点在哪里、方案结构长什么样、AI 接在哪一步、在自己的应用里落地时要注意什么。

先把结论放在前面：这三种任务都能用 AI 显著提效，但没有一种是“把数据和需求一起丢给大模型”。三类方案的共同结构是：AI 只做它擅长的语义理解与步骤规划，真正的执行交给确定性引擎。位置选对了，AI 是产能；位置选错了，AI 是负债。

1 任务分解：三种功能，三种交付物

1.1 固定报表开发：交付的是一份模板

中国式复杂报表是最讲究形式的一类：多级表头、合并单元格、斜线格、跨页小计、打印边距，乃至某个数字的字体和对齐。这类报表是开发者做给系统用的，产物通常是一份报表模板，加上背后的数据准备。

对程序员来说，这类任务之所以最先能被 AI 改造，是因为它的产物本身就是“给人看、给人改”的东西——模板可以被打开、被拖动、被逐格核对，而不是一段只有机器才懂的渲染代码。

1.2 自助报表：交付的是一个工具

自助报表的最终用户是业务人员：他想按省份看、再按年份拆、顺手算个占比，希望自己拖字段或者提一句需求就能出表。

所以要做的不是替客户完成一次分析，而是交付一个能力：一个能嵌进系统、业务人员能反复使用的工具。这类功能一旦做成黑盒，支持成本会迅速失控——用户说不清哪一步错了，也无法复现，最后只能“重做一遍再看看”。

1.3 通用查询：交付的是一个框和一套元数据

企业应用里到处是查询界面：订单、客户、库存、财务各做各的筛选面板，每个模块单独开发。加一个筛选条件就要改前端、调接口、发版本，业务响应速度被拖得很慢。

通用查询想解决的就是这件事：把这些分散的查询收敛成一个输入框，用户用自然语言提问，系统给结果；开发侧维护的不再是一页页界面，而是元数据、词典和一套查询服务。

表1 三类功能的工程视角对比

项目	固定报表	自助报表	通用查询
交付产物	报表模板	可嵌入的自助分析页面	查询页面 + 元数据与词典
工作重心	模板布局、取数逻辑	命令集与执行引擎对接	元数据/词典/权限及接口
AI 介入点	生成调用 API 的 Java 程序	把口语拆成汉语命令	把口语转成规范问句
验收方式	IDE 里可视化审模板	分步执行、看中间结果	用户确认规范问句
失败模式	模板幻觉、渲染代码不可读	黑盒、算力与数据出域	关联与口径猜错且不报

三种任务的差别不只是难度，而是“错在哪里、谁能发现、怎么改”。这决定了 AI 在每一类任务里应该站在什么位置。

2 固定报表：把 AI 接在“生成 API 调用程序”这一段

2.1 两条看起来可行的路，为什么都不通

第一条路，是让 AI 直接生成报表模板。这条路很快会撞墙：报表模板是私有格式，公开语料几乎为零；而一张报表里的多源混算、嵌套逻辑、像素级排版和打印设置交织在一起，不是一段线性文本能描述清楚的。硬让模型上，结果就是幻觉频发。

第二条路，是让 AI 直接写报表渲染程序。这看起来更“工程”：产出代码，编译运行，报表就出来了。但它过不了上线这一关：生成的渲染代码层层嵌套，报表稍复杂些就可能上万行，人读不懂就无法确认；报表需求又大多是临时性的，做完就改，指望测试集守住不现实。出了问题不知道错在哪一段，团队自然不敢用。

两条路的共同问题，是让 AI 直接产出“最终形态”。而最终形态恰恰是最难审、最难改的那一层。

2.2 可行方案：AI 写程序，引擎出模板，人在 IDE 里审

润乾报表的做法是把 AI 往后撤一步：不让它画报表，让它写一段调用API 的 Java 程序，由引擎按 rpx 模板生成报表。如图1所示，链路是“描述需求 → 生成调用 API 的 Java 程序 → 输出 rpx 模板 → 可视化查看与微调”。

图1 固定报表的 AI 闭环：自然语言需求、API 代码生成、报表输出与审核迭代

关键在中间这一层，但要先说清楚一件事：那段 Java 代码往往很长、结构复杂，你不需要读懂它，它的职责是调用 API 把模板造出来。程序员真正要看、要改的，是它生成出来的 rpx 模板——在报表 IDE 里按可视化方式检查行列结构、分组层级、公式引用和数据源绑定，直接在格子上改。

也就是说，AI 产出的程序是“生成模板的手段”，模板才是“可评审的产物”。评审发生在模板层，修改也发生在模板层；哪一格不对，在 IDE 里就能定位，不必回头读那段代码，也不必把整个生成过程重跑一遍。对开发团队来说，这才是这类方案能进项目的原因——交付物是看得见的模板，而不是只能整体接受或丢弃的黑盒。

2.3 一条真实指令，能细到什么程度

中国式复杂报表的难点，往往不在取数，而在排版：分栏、横向流动、合并、跨页。这些需求过去要靠经验和反复调试。现在可以先用自然语言把布局讲清楚，让 Agent 生成骨架。

图2 Agent 指令示例：一句话描述“一页三组、横向流动”的复杂布局

图2 的指令是这样写的：连接 demo 数据源，用销售额数据生成数据集并按销售额排序；一页排三组相同的列，序号、产品名称、产品销售额三列为一组，同一行并排显示 3 条记录（第 1 行是记录 1、2、3，第 2 行是 4、5、6）；数据按记录顺序“横向流动”，不是传统的一行一条往下扩展，而是从左到右、从上到下依次填充；最后生成指定的 rpx 文件。

这段话把“横向流动”这种说不清、画不出的布局讲明白了——它本质上是把纵向报表切成三栏并排。生成结果如图3所示，三组并列、记录按顺序横向填充，与描述一致。

图3 生成结果：三组并列、按记录顺序横向流动的报表

2.4 Copilot：最后一公里，用汉语改模板

Agent 生成的模板通常还差一点：某个单元格要做组内排名、单价要分段显示、颜色要按阈值变化。

这些事情继续交给 Agent 并不划算。它可能改好了这一处，又在别处搞出新问题，你还得再核对一遍，一来一回反而更慢。更合适的做法是直接在 IDE 上改：位置、布局、合并这类事情，GUI 拖一拖最快；但公式调整、条件格式这类操作，靠菜单一层层点并不方便。Copilot 提供的正是这一段——在 IDE 里选中单元格，用汉语把需求说清楚。

图4 在报表 IDE 中选中单元格，用汉语完成局部修改

如图4所示，在 IDE 里选中 G5，输入“G5 组内降序排名”，工具直接落到模板上。同类指令还有“把单价按 500 以下、500 到 1000、1000 到 1500 分三段显示”“小于 1000 暗红加粗，大于 10000 浅蓝下划线”。

这就是常说的从 GUI 到 LUI：不用记菜单路径，说一句话就改。但它和纯对话式产品有个重要区别——改动的结果仍然落在可视化模板上，改完立刻看得见，不存在“说完了不知道它改到哪儿去了”的问题。

2.5 给开发团队的几条建议

先审结构，再看结果。AI 生成的模板，先看行列结构、分组层级、公式引用对不对，再跑数据。结构对了，结果大概率对；结构错了，跑出来再漂亮也是错的。

Agent 当骨架生成器，Copilot 做精修。复杂布局、批量相似的模板适合 Agent 一次成型；一次性小改动用 Copilot 更快。两者配合，才是完整的工作流。

把需求写成“布局规格”。“横向流动”“一页三组”这类词对模型是有效约束；“好看一点”“紧凑一些”没有信息量。描述越接近结构，返工越少——这条对固定报表和自助报表都成立。

效率上，复杂报表开发从小时级压到分钟级，开发效率提升 50% 以上。但对程序员来说，真正省下来的往往不是“第一次做”，而是“改”——需求变一次的成本降下来，才是长期的收益。

3 自助报表：为什么不能把数据和需求直接丢给 AI

3.1 先问一句：AI 都能直接生成报表页面了，还要再做吗

现在把数据和需求一起交给 AI，它也能直接生成报表页面，那还有必要专门做一个自助报表功能吗？

乍一看，这样确实能出东西；但放进产品里用起来，通常会遇到三个问题。

第一是黑盒。AI 直接给出报表，中间过程不透明。结果不对时，业务用户既定位不到是哪一步错了，也无法只改一处，只能换个说法重来，结果可能本来对的地方又改错了。几次之后，人就失去耐心了。

第二是算力。让模型直接吃数据、做推理、出结果，开销是跟数据量走的：数据越大，token 和算力消耗越高。而不少企业本身就没有多少算力余量，很难为一个查询功能长期兜这笔账。

第三是安全。这条路要求频繁把业务数据送进大模型，如果模型在公网，就会把数据出域的风险直接摆上桌面，很多行业根本不会讨论这种方案。

3.2 方案结构：口语进，汉语命令出，规则引擎执行

润乾报表的做法是把用户需求让 AI 拆成一串可执行的汉语命令，再由规则引擎逐步执行。如图5所示，左侧是命令序列，右侧是 LLM 规划面板：一句“订单金额超过 5000、按省份和年份分组汇总、再算省内金额比例环比、金额按货币格式”的需求，被拆成 7 步，并标注了每步的类型——数据过滤操作、聚合计算、组内跨行计算、明细字段显示控制、外观格式与样式设置。

图5 自助报表：左侧汉语命令序列，右侧 LLM 规划出的分步指令

图 6 规划执行结果：左侧报表随规划命令逐步生成，右侧为待执行的新命令

这张图里最值得程序员注意的，不是界面，而是命令是有限集合、参数是结构化的。AI 的输出被约束在这套指令集里，而不是自由发挥成一段脚本。指令集越稳定，模型能“飘”的空间越小，你也越敢把它放进产品。

表2 部分典型汉语命令族

命令类别	典型写法	作用
表头与维度	左表头 客户省 签单年	设定行、列维度的分组字段
数据过滤	过滤 订单金额 大于 5000	按条件筛选记录
聚合计算	订单金额 求和	生成指标值
组内跨行计算	在客户省 范围内 计算 订单金额 比例环比 命名为 省内金额比例环比	分区内的占比、环比、排名、累计
明细控制	隐藏全部明细	控制明细行是否展示
排序	排序 订购年 升序	结果排序
外观与格式	位置 订单金额 显示为 "#,##0.00"	数字格式、条件样式

回看 上小节 的三个问题，这套结构正好一一对应。过程不再是黑盒：每一步命令都看得见、改得动，错了只改那一条，还能单独执行看中间结果。算力不再随数据量膨胀：AI 只做翻译和规划，不碰数据，消耗跟需求的复杂度走，而不是跟数据规模走。数据不出私域：进模型的只有表样、字段和需求，业务数据始终留在自己的库里。

3.3 两种用法：单步执行与整体规划

单步执行是一步一步输入、一步一步执行、一步一步完善，适合调试和精细控制；整体规划是把一段宏观需求整体交给 AI 拆解，再决定整体执行还是逐步执行。

对用户的价值在于排障粒度。拆错了，改的是某一条命令，不是推翻重来；某一步结果不对，单独执行那一步就能看到中间结果。这相当于给“自然语言做表”装了一个单步调试器，问题定位到步骤，而不是在一整段生成物里试错。

3.4 落地时要注意的工程点

指令集是你的契约。它连着提示词、连着历史数据、也连着用户的肌肉记忆。改指令集要像改 API 一样谨慎，最好有版本号。

数据不进模型。只把表样、字段和需求交给 AI，数据留在你自己的库里。这样 token 消耗比“让模型算数”低两个数量级，也自然绕开了数据出域。

每一步都要能单独执行。这是给业务用户的“退一步改一步”，也是给你自己的排障能力。没有这一步，白盒就只是口号。

4 通用查询：一个问数框，替代一堆查询界面

4.1 开发侧的真实成本，不在界面本身

做查询最贵的从来不是那个筛选框，而是重复：每个模块一套面板、一套接口、一套权限判断；需求一改就要改前端、联调、发版。界面长得都差不多，代码却要写很多遍。

市面上做智能问数的 ChatBI 产品不少，看起来正好能解决这个问题，但这些方案大多“太重”，落到应用系统里并不好用。

一是形态重。它们多是独立的数据分析产品，自带登录、看板、管理后台。要嵌进业务系统，得打通账号、权限、数据、界面风格，工作量不亚于自研一套查询模块；用户查个数据还要跳转系统，体验像外挂。

二是栈太重。主流方案是“大模型 + 向量库 + RAG 知识库”三件套，需要 GPU 服务器、专人做数据标注和提示词调优，还要持续维护知识库。为一个查询功能搭一整套 AI 基建，很难算得过账。

三是黑箱化，这一点更关键。纯大模型生成 SQL 本质是概率猜测：简单查询看着准，一到多表关联、复杂口径就容易翻车；更麻烦的是错了也不报，照样返回一个看似合理的结果，而业务用户根本识别不出来。

4.2 为什么纯 AI生成 SQL 不能直接用

简单查询它确实做得不错：单表、条件明确、字段名直白。但真实业务查询大多是分组聚合、多表关联、条件组合，一旦涉及口径和关联关系，模型的猜测就开始翻车。更麻烦的是它的失败方式——不报错，返回一个看起来很正常的结果。

对业务用户来说，90% 的准确率没有意义。他不知道这一次是不是撞上了那 10%，看不懂 SQL，就没有能力核对。于是功能上线了，却没人敢用。

4.3 方案：规范问句 + 规则编译

润乾 NLQ 的链路是：业务口语 → AI 转译成一句语义规范问句 → 用户确认 → 规则引擎确定性地编译成 SQL → 执行返回。如图7所示。

图7 通用查询：规范问句、查询项与来源条件、编译出的 SQL 与结果

图7 里，“去年谁没开单”被转成规范问句“2025年，没有订单，员工”；下面用一张表列出了选项目、来源和条件——员工取姓名、职务、出生日期、性别、年龄，订单取签单日期 2025 年、订单“没有”；再往下是编译出的 SQL 和查询结果。

这张图同时解决了三件事。业务用户能确认：他看不懂 SQL，但看得懂“去年没有订单的员工”是不是自己想问的。关联与口径不靠猜：主表子表的存在性判断、JOIN 关系由元数据与规则层决定，不交给模型自由发挥。结果可复现：确认之后是确定性编译，同一句规范问句永远编译成同样的 SQL。

AI在这里的边界被划得很清楚：不懂表结构、不猜外键、不写 SQL、不做口径决策，只做语义转译。它只需要一个通用大模型的 API Key，不需要微调、不需要训练——这对开发团队意味着，模型可以换，链路不用动。

4.4 对开发工作的改变：从“每页做查询”到“一个组件 + 一套元数据”

表3 传统查询界面与问数框的工作量对比

工作项	传统做法：每页一套查询界面	NLQ 方案：一个通用问数框
前端	每页一套筛选面板，条件变了改页面	一个标准输入框组件
后端	每页一个查询接口，逐个联调	统一查询服务，JDBC 调用
口径与关联	散落在各接口的 SQL 里	元数据与词典集中定义
权限	各接口分别实现，容易漏	继承系统原有权限体系
新增需求	改前端、调接口、发版本	加一条词典配置

接入方式也按组件的标准来：标准 JDBC 驱动，加载 JAR 包、配置数据源、在代码里调用；前端就是一个输入框。核心是规则引擎，不需要 GPU、不需要向量库，普通 CPU 服务器就能跑。

权限不用另做一套：它直接对接系统现有的元数据、表结构和字段映射，并继承原有权限体系。不同岗位的人问同一句话，返回各自权限范围内的数据。

4.5 覆盖范围：不能只查“北京的订单”

只能处理简单条件筛选的问数，是玩具。润乾NLQ能有四类范式，以及取数之后的中行运算，覆盖绝大多数常用的查询需求。

表4 通用查询需要覆盖的四类查询范式

查询范式	典型问题	技术要点
单表明细筛选	上周发往华北地区的订单有哪些	条件过滤与明细返回
单表聚合排名	各省订单金额排名	分组、聚合、排名
主子实体关联过滤	上个月没有开单的员工	主表与子表的存在性判断
多维对齐汇总	按省份、年份汇总并计算	多维交叉统计
跨行运算	占比环比排名	针对结果集做跨行计算

多表 JOIN 不交给 AI 猜，由规则引擎按元数据自动计算。这既是准确率的来源，也是你能向客户解释“为什么这次和上次一样”的依据。

4.6 元数据可以交给智能体生成

做问数最重的一块其实不是查询本身，而是元数据：表结构、字段映射、汉语词典、口径定义、提示词。过去这一步靠熟手一点点配，一个主题域动辄一两天。

现在可以把这条流水线交给智能体：连库读表结构、生成 DQL 元数据、构建汉语词典、编写提示词、配置数据源、Web 上线、JDBC 真连真查，人只在每一步做确认。原本数周甚至上周的配置工期，现在一两天就能跑通。

形态上是 MCP 一体化服务：既能被智能体当工具调用，也能配 SKILL 端到端搭建。维护也轻——新增业务加一条词典配置，普通开发就能做，不用训练模型，也不用维护知识库。

4.7 落地边界：不是所有查询界面都该删

从实践看，最优组合是“问数框为主、高级筛选为辅”。

可以替代：临时多变的条件筛选、各类分组汇总排名、突发的非标准化查询。这类需求等开发排期最不划算，直接问就出结果。

建议保留：极高频的固定操作（比如“我的待办订单”，点按钮比打字快）、强引导型的新手场景、极复杂的多步深度分析——这几类还是走原来的功能入口更顺手。

5 三条路线的共同原则

把三种方案放在一起看，会发现结构是同一个：AI 做语义与规划，引擎做执行，只是中间物不同——固定报表是 rpx 模板，自助报表是汉语命令序列，通用查询是规范问句。

中间物必须是人能看懂、能改的东西。这不是为了某个理念，而是为了两件很实际的事：出了问题你能定位，上线之后你能维护。凡是 AI 直接产出最终形态的方案，都会在这两件事上付出代价。

成本要算全。算力、token、数据出域、支持人力，四项里任何一项失控，功能都活不长。把模型当翻译器而不是计算器，成本差两个数量级。

形态要组件化。开发商交付的是系统的一部分，用户不该为此跳转到另一个产品；能不能嵌、能不能连、能不能管、能不能养，比功能列表更重要。

6 结语

报表行业过去解决过两个问题：能不能做出中国式复杂报表，数据准备能不能从报表里解耦。现在多了新问题：如何利用 AI 提效？AI 生成的东西，怎么才能放心地放进生产？

润乾报表的路线一直没变：把 AI 的输出落到一个确定的、人能改的中间物上。对开发商来说，这意味着三件事可以分开做、按需做——固定报表用 Agent 加 Copilot，自助报表用汉语命令加规则引擎，通用查询用规范问句加一个问数框。

不必等一个“万能方案”。把 AI 放对位置，三类功能都能在自己的应用里先跑起来。