先把结论放在前面：这三种任务都能用 AI 显著提效，但没有一种是"把数据和需求一起丢给大模型"。AI 的输出必须落到一个人能看懂、能改的中间物上——出了问题能定位，上线之后能维护。

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

02

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

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

✗ 路 一：让 AI 直接生成报表模板

报表模板是私有格式，公开语料几乎为零；多源混算、嵌套逻辑、像素级排版和打印设置交织在一起，不是一段线性文本能描述清楚的。硬让模型上，结果就是幻觉频发。

✗ 路 二：让 AI 直接写报表渲染程序

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

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

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

润乾报表的做法是把 AI 往后撤一步：不让它画报表，让它写一段调用 API 的 Java 程序，由引擎按 rpx 模板生成报表。链路是这样一条闭环：

图 1 · 固定报表的 AI 闭环

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

也就是说，AI 产出的程序是"生成模板的手段"，模板才是"可评审的产物"。评审发生在模板层，修改也发生在模板层；哪一格不对，在 IDE 里就能定位，不必回头读代码，也不必把整个生成过程重跑一遍。交付物是看得见的模板，而不是只能整体接受或丢弃的黑盒。

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

中国式复杂报表的难点，往往不在取数，而在排版：分栏、横向流动、合并、跨页。现在可以先用自然语言把布局讲清楚，让 Agent 生成骨架。比如这条指令：

图 2 · 横向流动布局示意（三组并列、按记录顺序填充）

图 3 · 执行结果: 三组并列、按记录顺序横向流动 (真实生成报表)

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

Agent 生成的模板通常还差一点：某个单元格要做组内排名、单价要分段显示、颜色要按阈值变化。这些事继续交给 Agent 并不划算——它可能改好了这一处，又在别处搞出新问题。更合适的做法是直接在 IDE 上改：选中单元格，用汉语把需求说清楚。

图 4 · 在报表 IDE 中选中单元格，用汉语完成局部修改（实际操作截图）

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

给开发团队的几条建议

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

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

3 把需求写成"布局规格"。"横向流动""一页三组"这类词对模型是有效约束；"好看一点""紧凑一些"没有信息量。描述越接近结构，返工越少。

50%+

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

04

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

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

市面上的 ChatBI，为什么大多落不进应用系统

形态重

多是独立的数据分析产品，自带登录、看板、管理后台。要嵌进业务系统，得打通账号、权限、数据、界面风格，工作量不亚于自研一套查询模块。

栈太重

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

黑箱化

纯大模型生成 SQL 本质是概率猜测：简单查询看着准，一到多表关联、复杂口径就容易翻车；更麻烦的是错了也不报，照样返回一个看似合理的结果。

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

润乾 NLQ 的链路是：业务口语 → AI 转译成一句语义规范问句 → 用户确认 → 规则引擎确定性地编译成 SQL → 执行返回。以"去年谁没开单"为例：

业务用户看不懂 SQL，但看得懂"去年没有订单的员工"是不是自己想问的。

图7 · 规范问句编译链示意 (口语→规范问句 → 确定性编译出SQL)

图 8 · 问数框运行现场：口语「去年谁没开单」→ 规范问句 → SQL → 结果（实际截图）

这条链路同时解决了三件事：业务用户能确认——他看不懂 SQL，但看得懂规范问句是不是自己想问的；关联与口径不靠猜——主表子表的存在性判断、JOIN 关系由元数据与规则层决定；结果可复现——确认之后是确定性编译。

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

从"每页做查询"到"一个组件 + 一套元数据"

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

接入方式按组件的标准来：标准 JDBC 驱动，加载 JAR 包、配置数据源、在代码里调用；前端就是一个输入框。核心是规则引擎，不需要 GPU、不需要向量库，普通 CPU 服务器就能跑。权限也不用另做一套：直接继承系统原有权限体系，不同岗位的人问同一句话，返回各自权限范围内的数据。

覆盖范围：不能只查"北京的订单"

只能处理简单条件筛选的问数，是玩具。通用查询需要覆盖四类查询范式，再加上取数之后的跨行运算，才能覆盖绝大多数常用需求：

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

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

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

做问数最重的一块其实不是查询本身，而是元数据：表结构、字段映射、汉语词典、口径定义、提示词。过去靠熟手一点点配，一个主题域动辄一两天。现在可以把这条流水线交给智能体：连库读表结构、生成 DQL 元数据、构建汉语词典、编写提示词、配置数据源、Web 上线、JDBC 真连真查——人只在每一步做确认。

数周 → 几天

原本数周甚至上周的元数据配置工期，现在一两天就能跑通。形态上是 MCP 一体化服务：既能被智能体当工具调用，也能配 SKILL 端到端搭建。维护也轻——新增业务加一条词典配置，普通开发就能做。

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

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

✓ 可以替代

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

→ 建议保留

极高频的固定操作（点按钮比打字快）、强引导型的新手场景、极复杂的多步深度分析——还是走原来的功能入口更顺手。