业务系统有表格，BI 有看板，AI 问数还需要做什么？

副标题：不是让 AI 替代业务系统和 BI，而是让它基于同一批可核对的业务事实回答、追问并持续执行

很多企业现在并不是没有数据入口。

业务人员每天在业务系统里查订单、发票和客户明细；管理人员打开 BI 看板看趋势；技术人员又接入一个 AI 问数入口。于是一个问题自然出现了：

text 复制代码

业务系统已经有表格，BI 已经有看板，AI 问数还需要做什么？

如果 AI 只是把看板上已经存在的数字再说一遍，它的价值确实有限。更合理的分工是：

业务系统负责把事情做完，并允许用户查看和操作明细；
BI 负责把固定的指标、趋势和对比持续展示出来；
AI 负责承接临时问题、追问和解释；具备调度和发送能力的 Agent，还可以把一次分析变成周期任务；无论哪种方式，都应该回到同一批业务事实。

AI 不是第四套报表，业务系统、BI 和 AI 也不是互相替代的三个产品。

先把三个入口分清楚

同一批销售数据，可能对应三种完全不同的使用场景：

用户问题	更合适的入口	用户真正需要的结果
我要查看这张发票的明细，并继续筛选客户和商品	业务系统表格	可分页、可筛选、可进入后续业务流程的明细
本月和上月的销售趋势怎样？哪个区域变化最大？	BI 看板	固定指标、趋势、对比和管理层视图
为什么三月份销售额下降？先看哪些客户？	AI 问数	临时分析、追问、解释和下一步查询

这三个问题都可能使用"销售额"，但它们的交互方式不同。

业务系统关注的是一条记录接下来要做什么；BI 关注的是一段时间整体发生了什么；AI 关注的是用户此刻想知道什么，以及这个问题能不能继续追问下去。

因此，入口可以独立，事实不能各自猜：

text 复制代码

同一批业务事实和确认过的口径
                 ↓
业务系统模型    BI 模型    AI 查询模型
       ↓          ↓          ↓
    明细表格     管理看板     自然语言问数

Foggy 首先解决的是业务系统里的表格

Foggy 的起点不是先做一个 BI 平台，而是解决业务系统中的动态查询问题。

在复杂业务系统里，一张列表通常同时需要：

多种筛选条件；
分页和排序；
服务端汇总；
字段权限和数据范围；
导出与详情查询；
前端表格列和后端查询参数保持一致。

如果每增加一个字段，都要分别修改页面、Form / DTO、Controller、Repository 和 SQL，查询能力很快就会变成重复开发。

Foggy 的做法是把这部分查询约束收进语义模型和查询协议：

text 复制代码

TM：描述数据来源、字段和关联
QM：描述某个业务入口允许查询什么
DSL：描述这一次具体怎么筛选、分组和排序
查询引擎：校验并编译为物理查询
前端组件：把查询结果渲染成业务表格

所以，对 Foggy 来说，业务表格不是 AI 之外的旧能力，而是语义查询最早、最稳定的使用场景。

AI 问数只是多了一个自然语言入口：用户不必先找到筛选器和字段，但最终仍然应该落到受控的 QM、DSL 和查询引擎上。

一批事实，三个入口可以各自表达

以 Wide World Importers 的 OLTP 发票明细为例，当前发票查询模型使用：

text 复制代码

QueryModel：wwi_oltp_invoice_lines
默认日期：invoiceDate
默认销售额：totalIncludingTax
物理来源：Sales.InvoiceLines.ExtendedPrice

模型还暴露了实际可执行的时间成员：

text 复制代码

invoiceDate$calendarYear
invoiceDate$calendarMonthNumber
invoiceDate$calendarMonthLabel

这里没有把 time$year、time$month 当成可以随意调用的字段。通用名称可以帮助人理解，但真正执行时必须使用 QM 已经暴露的成员。

按月查询 2016 年 1 月到 5 月的开票含税销售额，可以使用这样的查询 DSL：

json 复制代码

{
  "columns": [
    "invoiceDate$calendarMonthNumber",
    "invoiceDate$calendarMonthLabel",
    "sum(totalIncludingTax) as totalIncludingTax"
  ],
  "groupBy": [
    "invoiceDate$calendarMonthNumber",
    "invoiceDate$calendarMonthLabel"
  ],
  "slice": [
    {
      "field": "invoiceDate$id",
      "op": "[)",
      "value": ["2016-01-01", "2016-06-01"]
    }
  ],
  "orderBy": [
    { "field": "invoiceDate$calendarMonthNumber", "dir": "ASC" }
  ],
  "limit": 12
}

这次查询返回的样例结果是：

月份	开票含税销售额
2016-01	5,103,948.25
2016-02	4,596,534.78
2016-03	5,330,250.56
2016-04	5,236,062.81
2016-05	5,704,232.71
合计	25,971,029.11

同一组事实，在三个入口可以有三种呈现方式：

业务系统把月份和金额渲染为可筛选表格，并允许继续查看发票明细；
BI 把月份作为横轴、金额作为指标，生成趋势和管理视图；
AI 把自然语言问题映射到这组字段，返回结果并说明使用的是发票日期和含税金额。

这里共享的是事实、指标、日期和过滤边界，不是要求三个入口的页面完全相同。

这个例子证明的是查询口径和结果可以对照，不代表某个 BI 产品已经通过现成连接器自动接入 Foggy。BI 具体读取同步表、汇总表还是语义查询 API，仍然是数据实施和系统集成工作。

同样，语义模型也不等于完整的 AI Agent。自然语言路由、可信上下文注入和宿主页面接入仍属于应用层工作；本文重点说明的是三种入口如何共享受控的事实和查询边界。

BI 不一定复用业务系统 QM

业务系统和 BI 需要的模型边界通常不同：

text 复制代码

业务系统 QM：发票明细、客户筛选、单据状态、分页和业务操作
BI 模型：月度汇总、区域趋势、同比环比、宽表和预聚合
AI 查询模型：用户问法、指标选择、追问和结果解释

因此，企业不一定要让 BI 直接复用业务系统的 QM。BI 可以使用自己的分析模型、同步表或汇总表；业务系统继续使用面向页面和流程的 QM。

但双方至少要能对照这些内容：

对齐项	需要说明什么
来源事实	订单、发票、回款，还是同步后的事实表？
指标公式	含税还是未税？是否存在逐行舍入？
日期字段	下单日期、发货日期、开票日期还是回款日期？
数据粒度	订单行、发票行还是月度汇总？
状态条件	是否排除取消、退货、贷项或草稿？
权限范围	三个入口对同一用户的可见范围有什么差异？
刷新时间	BI 的统计截止时间是什么？

如果这些信息没有对齐，三个入口即使都生成了正确 SQL，也可能分别得到三个"看起来合理"的销售额。

数据实施负责同步、粒度、来源和派生逻辑；语义引擎负责把已经确认的业务规则变成可复用、可校验的查询能力。两者不能互相替代。

AI 问数真正补上的是什么

AI 问数最适合处理的是固定报表没有提前准备的问题。它可以从一个月度趋势继续追问到客户、商品和明细，而不要求 IT 人员先为每一种可能的问题各做一张报表。

例如 BI 已经有"月度销售趋势"，但用户临时问：

text 复制代码

三月份比二月份少了多少？先列出下降最多的客户，再按商品看其中一家客户少买了什么。

这不是一个单独的固定指标，而是一条逐步形成的分析路径：

text 复制代码

月度汇总
  → 两期差异
  → 客户排行
  → 商品结构
  → 明细核对

AI 的价值在于承接这种临时路径，并在每一步继续使用受控的业务模型。它不应该看到"销售额"三个字，就临时决定使用订单还是发票，也不应该在下钻时悄悄切换到另一张事实表。

如果问题存在多个合法口径，AI 还需要结合上下文：

当前用户是谁、属于哪个组织；
当前在什么业务页面或工作任务中；
页面已经选中了哪个客户、月份或单据；
企业默认采用订单还是发票口径；
当前用户的可信权限范围是什么；
结果的统计截止时间是什么。

所以，企业建立 AI Agent 不只是建立一套语义层。提问者角色、页面信息、任务状态和可信权限上下文，同样是 AI 判断问题含义的重要输入。

AI 不只是回答问题，还可以按规则主动做事

问数是最容易被看见的一层：用户提问，Agent 查询，返回结果。但 AI 带来的扩展能力，不应该只停留在"把人工查数变成聊天"。如果 Agent 具备定时任务、权限执行和消息发送能力，用户还可以直接提出这样的要求：

text 复制代码

每天上午 8 点，把昨天的销售额发给我。

每月第一天，把销售额下降最多的大客户发给我。

这已经不是一次查询，而是在创建一个持续运行的业务任务。Agent 至少需要把自然语言拆成几个可确认的部分：

任务部分	需要明确什么
触发时间	每天、每月第一天，使用哪个时区？
统计窗口	"昨天"是哪个日期？"上个月"是否必须是完整月份？
指标口径	使用订单销售额、开票销售额，还是其他已确认指标？
分析逻辑	"下降最多"比较哪两个周期，按下降金额还是降幅排序；"大客户"按客户等级还是销售额排名？
接收对象	发给谁，是否需要按每个用户的权限过滤？
发送渠道	站内消息、邮件、企业 IM，还是其他渠道？

例如，"每月第一天"通常应该发送上一个完整月份的结果，而不是把刚开始的当月数据混进来；"销售额下降最多"也必须明确比较周期，"大客户"还需要有清晰定义。Agent 只能依据已经配置的默认规则或可信上下文补全信息；如果存在多种合法解释，就应该先追问，而不是默默选择一个口径。

一个更可靠的确认过程可能是：

text 复制代码

你说的"销售额"是订单含税销售额还是开票含税销售额？
"下降最多"是否按上个月和上上个月比较下降金额？
"大客户"按客户等级，还是按销售额排名定义？需要发送前 10 名吗？
确认后，我会在每月第一天发送到你已授权的企业 IM。

任务真正执行时，链路大致是：

text 复制代码

自然语言任务
  → 固化周期、指标、过滤条件、排序和收件人
  → 到时调用受控 QM / DSL 查询
  → 检查数据截止时间和刷新状态
  → 生成表格、摘要或异常说明
  → 在已接入且用户授权的渠道中发送
  → 记录执行结果、失败原因和下一次执行时间

创建或启用一个周期任务本身就是一次外部副作用。Agent 应该先展示任务定义，让用户确认后再生效；任务生效后，还需要支持暂停、修改和撤销，并保留执行记录。

过去，这类需求通常需要 IT 人员拆成报表 SQL、定时脚本、消息模板、发送渠道、权限校验、失败重试和上线配置。在不少企业里，从需求提出到第一次上线，快也要一天；如果还要做定周期迭代、多个接收人和多个渠道，周期可能是 2 周到 1 个月。遇到更定制化的场景，客户甚至需要再采购一套报表、调度或消息分发产品。

Agent 的意义，是把"提出一个业务要求"和"配置一个可持续执行的任务"之间的距离缩短。它不代表所有工作都被 AI 自动完成：任务调度、消息通道、权限、审计、失败告警和人工停用仍然是产品能力。但语义层能够保证每次任务执行时，昨天的销售额、上个月的销售额和下降最多客户都回到同一套可核对的业务定义。

因此，语义层解决的是"每次应该查什么、怎么算"；Agent 的任务能力解决的是"什么时候查、为谁查、查完送到哪里"。两者结合，AI 才不只是一个临时问数入口，而是可以持续参与业务工作的执行入口。

BI 的分发通常是把固定看板持续展示给一组用户；Agent 的分发则更像一次被授权的个性化任务，把某个时间窗口、某个用户权限范围内的结果主动送给特定的人。两者都在"分发数据"，但触发方式和结果形态并不相同。

AI 结果能不能继续回到业务表格

理想的工作流是：

text 复制代码

AI 问数
  → 返回汇总结果和查询条件
  → 用户继续追问或选择下钻维度
  → 生成结构化查询
  → 打开业务系统里的可筛选表格

这样 AI 负责理解问题和组织分析，业务系统负责明细、权限和后续操作，BI 负责固定的管理视图。

但这里要区分查询能力和宿主系统集成：

受控 DSL 可以让结果继续形成下一次查询；
真实跳转到某个业务系统页面，还需要宿主系统提供页面、路由、登录态和权限上下文；
如果这些接入证据还没有完成，就不能把"AI 结果已经一键打开业务详情"写成现成能力。

这个边界并不影响主线。先让三个入口围绕同一批事实工作，再根据真实项目是否反复需要详情跳转，决定是否补宿主集成。

什么时候应该用哪个入口

可以用下面这张表做一个简单判断：

场景	首选入口	为什么
处理一张订单、发票或客户明细	业务系统表格	需要筛选、分页、权限和业务操作
每天查看固定销售趋势和区域排名	BI 看板	需要稳定刷新、持续展示和分发
临时比较两个月、追问下降客户	AI 问数	问题路径不固定，需要自然语言和多轮追问
每天或每月自动发送个性化分析结果	AI Agent 定时任务	需要按周期执行、按权限生成并主动分发
需要判断数字从哪里来	AI 解释 + 业务 / BI 明细	既要理解口径，也要回到可核对的结果
需要改变订单或发票状态	业务系统流程	AI 可以辅助理解，但不能替代受控业务操作

这不是三选一。一个成熟的企业应用通常是三者组合：

text 复制代码

业务系统负责事实发生和明细操作
BI 负责固定观察和管理分发
AI 负责临时问题、结果解释和个性化周期任务

语义层不是把三个入口强行合并

容易产生的误解是：既然要统一口径，那就让业务系统、BI 和 AI 共用一个 QM、一个数据库和一套页面。

这通常不是必要条件。

更现实的方式是：

text 复制代码

共享：业务事实、指标定义、日期、粒度、状态、权限和刷新说明
独立：页面交互、模型边界、查询协议、缓存和预聚合策略

Foggy 首先帮助业务系统减少表格、接口和 SQL 的重复维护；BI 可以根据管理分析需要维护独立模型；AI 则通过受控模型访问已经确认的指标。

任何一个语义引擎都不是万能药。它不能替代：

业务人员对指标含义的确认；
数据实施人员对来源表和粒度的梳理；
同步链路和数据质量处理；
生产认证、权限和审计设计；
BI 看板和管理流程。

如果来源事实没有对齐，建再多模型也只是把不一致更稳定地输出出来。

结尾

业务系统有表格，BI 有看板，并不意味着 AI 没有位置；AI 问数也不意味着业务系统和 BI 可以被删掉。

三种入口解决的是不同问题：

业务系统让用户查看事实、处理流程和继续操作；
BI 让用户持续观察指标、趋势和管理范围；
AI 让用户用自然语言提出临时问题、追问和解释结果；具备调度能力的 Agent，还可以把一次性分析变成周期性任务并主动发送。

真正需要建设的不是"再加一个 AI 页面"，而是让三种入口能够回到同一批可核对的业务事实。模型可以独立，页面可以不同，查询协议也可以不同，但指标、日期、粒度、状态、权限和刷新边界不能各自猜。

你们现在最常见的情况是哪一种：业务系统表格查不到、BI 看板不够灵活，还是 AI 问数无法继续下钻？