在前一篇《AI提数中表字段定位：Schema Linking、元数据检索与业务语义匹配》中，我们把用户的数据需求从标准语义任务推进到了SQL Plan。
也就是说，系统已经知道：

查什么指标：支付GMV
用什么字段：paid_gmv_amt
查哪张表：dws_trade_buyer_month
按什么维度分组：receiver_receiver_city_code
加什么条件：stat_month = 202604、receiver_province_code = 44、buyer_type_code = B
怎么聚合：SUM

这一篇要继续往下走，用SQL Plan的输出去做SQL生成和校验执行；

一、为什么SQL生成不能等同于“让大模型写SQL”

本篇文章实际是解决一个更靠近生产的问题：

如何把SQL Plan稳定转成可执行SQL，并且确保这条SQL安全、正确、可控、可解释？

很多人理解AI提数，会把这一层简单看成：

让大模型写SQL

这个理解太粗了。
企业级AI提数里的SQL生成不是创作任务，而是一个受约束的工程任务。它不是让模型自由发挥，而是基于前面已经生成的SQL Plan，在查询生成层、安全治理层、查询执行层中逐步完成：

→ SQL Plan
→ SQL生成
→ SQL校验
→ 权限与安全治理
→ 性能与资源控制
→ 查询执行
→ 结果校验
→ 交互反馈

直接让大模型从用户问题写SQL，风险非常高：

所以，第八篇的核心观点是：

SQL生成不是让大模型自由写SQL，而是基于SQL Plan进行受约束、可校验、可治理的工程化生成。

这一层做不好，前面对话理解、业务语义、表字段定位做得再准，也可能在最后一步翻车。

二、SQL生成与校验在AI提数架构中的位置

从整体架构看，第八篇覆盖的是三个层：

→ 查询生成层
→ 安全治理层
→ 查询执行层

它们在AI提数主链路中的位置如下：

→ 交互入口层
→ 对话理解层
→ 业务语义层
→ 表字段定位层
→ 查询生成层
→ 安全治理层
→ 查询执行层
→ 结果解释与反馈层

1. 查询生成层的目的

查询生成层的核心目标是：

把SQL Plan稳定转换成目标查询引擎可以执行的SQL。

它主要负责：

SQL生成
SQL方言适配
SQL语法校验
SQL语义校验
SQL Plan一致性校验
输出可执行SQL和校验报告

这里重点不是“生成一段SQL文本”，而是“按计划、按方言、按规则生成SQL”。
SQLGlot官方将其定位为SQL parser、transpiler、optimizer和engine，可用于SQL解析、转译、优化和多方言处理；这说明在工程实践中，SQL处理应该尽量结构化，而不是完全依赖字符串拼接或大模型自由生成。(SQLGlot)

2. 安全治理层的目的

安全治理层的核心目标是：

保证SQL不越权、不泄露、不危险、不拖垮系统。

它主要负责：

权限校验
行列权限注入
敏感字段处理
危险SQL拦截
导出审批控制
性能与资源治理
审计记录

这一层不只是“安全部门的事”，而是AI提数能不能进生产的基础。

3. 查询执行层的目的

查询执行层的核心目标是：

把通过校验的SQL稳定执行，并把执行状态、结果质量和异常反馈回系统。

它主要负责：

同步查询
异步任务
执行状态管理
超时控制
失败重试
执行结果校验
执行审计

查询执行层不是简单调用数据库接口。它要管任务、管资源、管异常、管审计，还要把错误反馈给前面的表字段定位层、SQL Plan层和交互层。

4. 与交互层的关系

SQL生成与执行不是后端黑盒。它需要和交互层形成闭环：

这就是企业级AI提数和普通Text-to-SQL Demo的差别：
不是“生成SQL就结束”，而是要把生成、校验、执行、反馈全部产品化。

三、输入与输出：SQL Plan进来，可信查询任务包出去

1. 输入：SQL Plan

第七篇已经讲过，表字段定位层的输出不是SQL，而是SQL Plan。第八篇的输入就是这个SQL Plan。

一个比较完整的SQL Plan应该包含：

query_type
dialect
main_table
join_plan
select_items
metric_items
dimension_items
output_fields
where_conditions
group_by
having
order_by
limit
partition_filters
permission_filters
sensitive_fields
risk_flags

示例：

{
  "query_type": "group_metric_query",
  "dialect": "spark_sql",
  "from": {
    "main_table": "dws_trade_buyer_month",
    "alias": "t"
  },
  "select": [
    {
      "role": "dimension",
      "field": "receiver_receiver_city_code",
      "alias": "收货城市"
    },
    {
      "role": "metric",
      "expr_type": "aggregation",
      "aggregation": "SUM",
      "field": "paid_gmv_amt",
      "alias": "支付GMV"
    }
  ],
  "where": [
    {
      "source": "time",
      "field": "stat_month",
      "operator": "=",
      "value": "202604"
    },
    {
      "source": "user_filter",
      "field": "receiver_province_code",
      "operator": "=",
      "value": "44"
    },
    {
      "source": "user_filter",
      "field": "buyer_type_code",
      "operator": "=",
      "value": "B"
    }
  ],
  "group_by": ["receiver_receiver_city_code"],
  "permission_filters": [],
  "risk_flags": []
}

SQL Plan一定要强结构化。
不要把它做成半截SQL，也不要做成自然语言说明。

2. 输出：可信查询任务包

SQL生成与校验层的输出也不应该只是一段SQL。
更合理的输出是一个可信查询任务包：

{
  "sql": "SELECT receiver_receiver_city_code AS `收货城市`, SUM(paid_gmv_amt) AS `支付GMV` FROM dws_trade_buyer_month WHERE stat_month = '202604' AND operation_operation_region_code = 'EAST_CN' AND buyer_type_code = 'BIZ' GROUP BY receiver_receiver_city_code",
  "dialect": "spark_sql",
  "validation_report": {
    "syntax_valid": true,
    "semantic_valid": true,
    "plan_consistent": true,
    "permission_valid": true,
    "performance_risk": "low"
  },
  "execution_mode": "sync",
  "risk_flags": [],
  "interaction_message": {
    "need_confirm": false,
    "explanation": "本次查询使用支付GMV指标，按收货城市分组，过滤华东区域、企业买家和202604统计期。"
  }
}

这个任务包至少包括：

可执行SQL
SQL方言
SQL校验报告
权限校验结果
安全风险标记
性能评估结果
执行模式：同步/异步
查询任务ID
结果元数据
交互层反馈内容
审计信息

这一章的核心判断是：

这一层的输出不是孤立SQL，而是可执行、可审计、可解释、可反馈的可信查询任务包。

四、查询生成层：从SQL Plan到可执行SQL

查询生成层是第八篇的第一个核心层。它解决的是：

SQL Plan如何稳定变成SQL？

这里可以分成几个子能力：模板生成、AST生成、LLM辅助生成、混合生成、方言适配、SQL校验。

1. 查询生成层的目标

查询生成层要解决四件事：

把SQL Plan转成SQL
适配目标SQL方言
保证SQL语法正确
保证SQL与SQL Plan一致

这一步最怕“看起来能跑，实际上偏离Plan”。
例如SQL Plan里明确要求：

where: operation_operation_region_code = 'EAST_CN'

但生成出来的SQL漏掉了这个条件。
这不是小问题，而是结果口径错误，甚至可能是权限风险。

2. SQL生成方法一：模板生成

模板生成适合高频、标准、结构稳定的查询。
例如：

单指标查询
分组统计
趋势查询
排名查询
明细查询

模板示例：

SELECT
  {dimension_fields},
  {metric_exprs}
FROM {main_table}
WHERE {where_conditions}
GROUP BY {group_by_fields}
ORDER BY {order_by_exprs}
LIMIT {limit}

比如SQL Plan是：

维度：receiver_receiver_city_code
指标：SUM(paid_gmv_amt)
表：dws_trade_buyer_month
条件：stat_month='202604'、receiver_province_code='44'

模板可以稳定生成：

SELECT
  receiver_receiver_city_code AS `收货城市`,
  SUM(paid_gmv_amt) AS `支付GMV`
FROM dws_trade_buyer_month
WHERE stat_month = '202604'
  AND operation_operation_region_code = 'EAST_CN'
GROUP BY receiver_receiver_city_code;

模板生成的优点很明确：

稳定
可控
易校验
适合高频场景
便于审计

但也有不足：

复杂查询模板容易膨胀
派生计算支持弱
多层子查询不够灵活
维护成本会上升

所以商品策略上不要指望模板覆盖所有查询。
更合理的是：模板覆盖80%的高频标准查询，复杂查询走AST或LLM辅助。

3. SQL生成方法二：AST生成

AST生成不是拼SQL字符串，而是构建结构化语法树，再渲染成目标方言SQL。
它适合：

跨方言SQL生成
规则改写
SQL结构校验
复杂查询组合
自动插入权限条件
自动补充分区条件

为什么AST更适合企业级系统？
因为字符串拼接很容易出问题，比如：

WHERE条件拼接顺序错
字段别名冲突
括号缺失
SQL注入风险
方言函数不一致

AST方式可以把SQL当成结构化对象处理：

Select节点
From节点
Join节点
Where节点
GroupBy节点
OrderBy节点
Limit节点

再根据目标方言渲染成SQL。
商品视角看，AST生成适合成为企业级AI提数的主生成方式。
它比模板更灵活，比LLM自由生成更稳定。

4. SQL生成方法三：LLM辅助生成

LLM不是不能用，而是不能乱用。
LLM适合处理：

复杂同比环比
窗口函数
多层子查询
复杂派生指标
非标准计算逻辑
自然语言解释转SQL片段

比如用户问：

看一下华东区域各收货城市支付GMV同比增长率

这里可能需要：

当前期支付GMV
去年同期支付GMV
增长额
增长率

这类查询如果全部靠模板，会比较僵硬；如果靠AST，也需要较复杂的规则。LLM可以辅助生成派生表达式或子查询结构。

但不建议这样：

用户原问题 → LLM → SQL

建议这样：

→ SQL Plan
→ 模板/AST生成基础SQL
→ LLM辅助生成复杂片段
→ SQL Parser校验
→ SQL Plan一致性校验
→ 安全治理层校验

也就是说，LLM只能在受控空间内工作。它可以补复杂逻辑，但不能绕开SQL Plan、字段候选、权限规则和校验器。

5. 混合生成策略

企业级系统更推荐混合策略。

核心原则是：

SQL生成方法不应该押注单一路线，而应该采用模板、AST、LLM和规则校验协同的混合架构。

6. SQL方言适配

企业数据环境通常不是单一数据库。
可能同时存在：

Hive
SparkSQL
MySQL
PostgreSQL
ClickHouse
Doris
Trino
Oracle
SQL Server

同一个SQL Plan，在不同引擎上生成的SQL可能不同。
方言差异包括：

方言适配建议遵循：

SQL Plan保持方言无关
SQL生成器按dialect渲染
函数通过方言函数映射表转换
SQL Parser做目标方言二次验证

7. SQL校验体系

查询生成层至少要做三类校验：

语法校验
语义校验
SQL Plan一致性校验

7.1 语法校验

语法校验解决的是：

SQL能不能被目标方言解析？

检查内容包括：

SQL是否能被Parser解析
括号是否匹配
函数调用是否正确
别名是否规范
字符串转义是否安全
是否存在非法SQL片段

语法校验不应该等到数据库执行时报错，而应该在执行前完成。

7.2 语义校验

语义校验解决的是：

SQL虽然语法正确，但业务和结构是否正确？

检查内容包括：

表是否存在
字段是否存在
字段是否属于对应表
字段别名是否冲突
非聚合字段是否进入Group By
聚合方式是否符合指标定义
Join字段是否存在
Where字段和值是否匹配

Apache Calcite提供标准SQL parser、validator和JDBC driver，并支持查询优化；其能力说明SQL处理不应停留在字符串层面，而应该有解析、校验和优化过程。

7.3 SQL Plan一致性校验

这是AI提数中特别重要的一类校验。
它检查：

Select是否覆盖Plan中的指标和维度
Where是否覆盖用户条件、时间条件、口径条件
Group By是否覆盖维度字段
Order By是否符合排序计划
Limit是否符合限制
Join是否符合Join Plan
权限过滤是否未被覆盖

比如SQL Plan里要求：

stat_month = '202604'
operation_operation_region_code = 'EAST_CN'
buyer_type_code = 'BIZ'

生成SQL必须完整包含这些条件。漏掉任何一个，SQL语法可能仍然正确，但结果已经不可信。
查询生成层的核心观点是：

SQL校验不能只做语法校验，还要校验SQL是否忠实执行了SQL Plan。

五、安全治理层：权限、安全、性能与资源控制

SQL生成后，不能马上执行。
它必须经过安全治理层。
安全治理层解决的是：

这条SQL能不能执行？
该不该执行？
谁能执行？
能查多少？
能不能导出？
会不会泄露？
会不会拖垮系统？

1. 安全治理层的目标

安全治理层不是一个“最后拦截器”。它应该贯穿：

SQL Plan阶段
SQL生成阶段
SQL校验阶段
SQL执行前阶段
SQL执行后审计阶段

核心职责包括：

权限校验
行列权限注入
敏感字段处理
危险SQL拦截
导出审批控制
性能与资源治理
审计记录

2. 权限校验

权限校验至少覆盖：

表权限
字段权限
指标权限
维度权限
行权限
列权限
导出权限
审批权限

例如，一个用户可能有支付GMV汇总指标权限，但没有买家明细权限；可能能看华东区域域数据，但不能看全站数据；可能能看脱敏买家手机号，但不能看明文买家手机号。

这就要求权限体系和SQL Plan绑定，而不是只在数据库层报错。

3. 行列权限注入

如果用户只能看华东区域数据，系统应该自动注入：

AND operation_operation_region_code = 'EAST_CN'

如果用户只能看本组织数据，可能需要注入：

AND org_code IN (...)

如果SQL Plan没有权限条件，安全治理层必须做两种处理之一：

自动注入权限条件
或者阻断执行

不能让一条缺少权限过滤的SQL直接进入执行层。

4. 敏感字段处理

敏感字段包括：

买家手机号
证件号
买家标识
详细地址
商家结算金额
账户信息

处理策略可以分层：

例如用户要求：

导出华东区域企业买家买家手机号和支付GMV

即使SQL可以生成，也不能直接执行。系统需要判断：

是否有买家明细权限
是否有买家手机号字段权限
是否需要脱敏
是否允许导出
是否需要审批

5. 危险SQL拦截

AI提数原则上只允许SELECT。
必须拦截：

DROP
DELETE
UPDATE
INSERT
TRUNCATE
ALTER
CREATE
GRANT
SELECT * 敏感明细
无条件全表扫描
导出敏感数据

这部分不是形式主义，而是生产系统底线。

6. 导出与审批控制

导出不是查询的简单后置动作。
它需要单独治理：

是否明细数据
是否包含敏感字段
是否超过行数限制
是否需要审批
是否需要水印
是否需要审计

比如汇总结果可以直接展示，但百万行买家明细导出必须走审批、脱敏、水印和审计。
交互层也要配合：如果触发审批，要展示审批入口，而不是只返回“无权限”。

7. 性能与资源治理

AI生成的SQL即使正确，也可能非常重。
常见风险：

大表无分区条件
明细查询无Limit
高基数字段Group By
笛卡尔积Join
多层子查询嵌套
大范围历史扫描
窗口函数过重
Join表过多

性能校验规则包括：

是否包含必要分区条件
扫描时间范围是否过大
明细查询是否带Limit
Group By维度基数是否过高
Join表数量是否超阈值
Join是否存在无条件关联
预计扫描量是否超限
预计返回行数是否超限

可以基于：

表大小
分区数量
统计信息
历史执行耗时
查询引擎Explain
扫描字节数估算
返回行数估算

做执行前成本评估。

8. 风险处置策略

不同风险要有不同处置方式。

安全治理层的核心观点是：

安全治理层不只是权限拦截器，而是权限、安全、性能、资源和审计的统一治理层。

六、查询执行层：执行调度、任务管理与结果校验

SQL通过查询生成层和安全治理层后，才进入查询执行层。
查询执行层解决的是：

怎么执行？
怎么管理任务？
怎么处理异常？
怎么校验结果？
怎么把状态反馈给用户？

1. 查询执行层的目标

查询执行层负责：

安全执行通过校验的SQL
管理执行状态和任务生命周期
识别执行异常和结果异常
把状态反馈给交互层
沉淀执行日志和审计记录

它不是简单调用数据库，而是一个完整任务系统。

2. 同步查询

同步查询适合：

小结果集
汇总指标
短耗时查询
低风险查询
高置信SQL

例如：

查华东区域上月支付GMV
查各收货城市支付GMV排名
查近6个月支付GMV趋势

这类查询如果数据源稳定、扫描范围可控，可以同步返回。

3. 异步查询

异步查询适合：

大表扫描
明细导出
多表Join
长耗时查询
需审批查询

异步任务需要支持：

任务提交
进度查询
取消任务
失败重试
结果缓存
过期清理
下载控制
审批状态联动

例如用户要导出百万级明细数据，不能让前端一直等待。系统应该返回任务ID，并告诉用户：

查询任务已提交，预计需要几分钟。完成后可在任务中心下载。

4. 查询任务管理

任务管理需要记录：

任务ID
执行SQL
执行用户
提交时间
运行状态
查询引擎
耗时
扫描量
返回行数
错误信息
取消操作
重试机制
审批状态

这部分对商品体验和审计都很重要。
用户需要知道任务是否还在运行。管理员需要知道谁发起了高消耗查询。系统需要知道失败是否可以重试。

5. 执行审计

执行审计必须记录：

谁查了什么
使用了哪个SQL Plan
使用了哪个SQL
命中哪些表字段
是否导出
是否涉及敏感字段
是否发生权限裁剪
是否触发审批
是否被用户采纳

审计不是只为了合规，也为了排查问题。
比如用户反馈“这个数不对”，系统可以回看：

当时使用了哪个口径
查了哪张表
加了哪些条件
有没有权限裁剪
有没有默认过滤

6. 执行结果校验

SQL跑完不代表结果可信。结果还要校验。

6.1 空结果校验

空结果可能来自：

确实没有数据
时间条件错误
权限裁剪过严
过滤条件错误
Join导致数据丢失
数据未刷新

系统不能只说“无数据”。更好的反馈是：

本次查询无结果。可能原因包括：当前202604统计期数据未刷新、企业买家条件过窄、或当前权限范围内无数据。

6.2 异常值校验

检查：

结果是否异常为负
同比环比波动是否异常
指标是否超历史范围
Top项是否异常集中
分组结果是否维度爆炸

例如支付GMV突然为负、买家数突然翻10倍，都应该触发提示。

6.3 结果行数校验

检查：

明细是否返回过多
分组是否过细
导出是否超过限制
分页是否需要

6.4 口径一致性校验

检查：

是否使用官方指标
是否使用推荐数据源
是否补齐默认口径条件
是否发生权限裁剪
是否命中风险标记

查询执行层的核心观点是：

查询执行层不只是把SQL跑起来，还要管理任务、校验结果、审计过程，并把异常反馈给用户和系统。

七、失败异常处理：SQL失败后系统应该怎么做

企业AI提数一定会失败。
关键不是“避免所有失败”，而是失败后能不能定位原因、自动修复、清楚反馈。

1. 常见失败类型

2. 自动修复策略

不同错误要回流到不同层。

字段不存在 → 回到表字段定位层重新召回字段
方言错误 → 方言转换或函数映射修复
Group By缺失 → 根据SQL Plan补齐
缺少分区 → 追问时间或使用默认时间
权限不足 → 返回权限说明或申请入口
扫描过大 → 建议缩小范围或转异步任务
Join导致空结果 → 回到Join路径重选

这就是闭环。
如果所有失败都只返回“SQL执行失败”，用户体验会很差，系统也不会变好。

3. 错误反馈结构

建议错误反馈结构化。

{
  "error_type": "FIELD_NOT_FOUND",
  "message": "字段 paid_gmv_amt 不存在于当前表",
  "repair_action": "RESELECT_FIELD",
  "next_step": "metadata_recalling",
  "user_message": "当前字段不可用，我会重新选择可用字段。"
}

错误反馈至少包含：

错误类型
技术原因
业务解释
修复动作
下一步状态
面向用户的提示语

4. 失败回流机制

失败不应该停在执行层。
应该回流到：

SQL Plan修正
表字段重新定位
业务语义消歧
权限申请流程
交互层澄清
Bad Case库
评测集

例如：

字段不存在 → 说明元数据或字段映射有问题
权限不足 → 说明需要权限申请入口
空结果 → 可能是条件过严，也可能是Join路径错误
执行超时 → 可能需要性能规则或预聚合表

核心观点：

SQL失败不是终点，而是反馈到SQL Plan、表字段定位、业务语义层和交互层的修正信号。

八、与交互层的钩子：SQL不是黑盒，要能确认、解释、修正

AI提数要让用户信任，不能只返回结果。
它要告诉用户：

用了什么指标
查了哪张表
加了什么条件
是否裁剪了权限
是否用了默认口径
为什么失败
下一步怎么修

1. 执行前确认卡

以下场景建议触发确认：

非推荐数据源
中置信字段
敏感字段
大范围扫描
复杂Join
导出明细
默认口径存在歧义

确认卡展示：

指标口径
数据源
时间范围
过滤条件
权限裁剪
预计扫描量
风险提示
是否继续执行

示例：

本次查询将使用：
指标：支付GMV
数据源：dws_trade_buyer_month
时间：202604统计期
过滤：华东区域、企业买家
维度：收货城市
权限：按当前用户组织权限裁剪
风险：低

是否继续执行？

2. SQL解释卡

SQL解释卡不一定展示完整SQL，可以展示SQL背后的业务解释：

本次查了哪张表
用了哪些字段
按什么维度分组
加了哪些过滤条件
是否使用默认口径
是否注入权限条件

对普通业务用户来说，解释“用了什么口径和条件”比展示一大段SQL更重要。
对技术用户，可以提供“查看SQL”入口。

3. 错误反馈卡

不同错误对应不同交互动作：

4. 用户修正入口

用户可能会继续说：

不是这个口径
换一张表
不要按收货城市，按收货省份
时间改成近三个月
这个SQL条件不对
把结果导出Excel

这些反馈不能只作为新问题处理，而要回流到当前SQL Plan：

SQL Plan修正
表字段重选
业务语义消歧
对话状态更新
Bad Case库
评测集

交互层的核心观点是：

交互层不是SQL执行后的展示层，而是SQL生成、确认、执行、修正闭环的一部分。

九、技术架构：SQL生成、治理与执行的一体化链路

整体技术架构可以这样设计：

SQL Plan输入
↓
Plan Validator
↓
Query Generation Layer
  ├─ Template Generator
  ├─ AST Generator
  ├─ LLM-assisted Generator
  └─ Dialect Adapter
↓
SQL Parser / SQL Validator
↓
Governance Layer
  ├─ Permission Validator
  ├─ Security Validator
  ├─ Sensitive Data Handler
  ├─ Performance Validator
  └─ Audit Logger
↓
Execution Layer
  ├─ Sync Executor
  ├─ Async Task Manager
  ├─ Result Validator
  └─ Error Handler
↓
Interaction Adapter
↓
Feedback Loop

核心模块说明：

这套架构的重点是把SQL生成从“单点能力”变成“一条受控链路”。

十、评估体系：SQL生成与执行怎么判断好坏

没有评估体系，就不知道系统到底是在变好还是变坏。
建议分六类指标。

1. 查询生成指标

SQL生成成功率
SQL语法正确率
SQL方言正确率
SQL Plan覆盖率
模板命中率
AST生成成功率
LLM重试率

这些指标回答：

SQL能不能稳定生成？
生成方式是否可控？
是否过度依赖LLM？

2. SQL校验指标

语法校验通过率
语义校验通过率
Plan一致性通过率
Group By错误拦截率
Join风险拦截率
字段幻觉拦截率

这些指标回答：

SQL有没有被有效校验？
校验层能不能拦住错误？

3. 安全治理指标

权限条件注入率
敏感字段拦截率
危险SQL拦截率
性能风险拦截率
权限违规拦截率
导出审批命中率
审计日志完整率

这些指标回答：

SQL是否安全？
是否越权？
是否有审计？

4. 执行指标

SQL执行成功率
平均执行耗时
扫描数据量
超时率
失败重试率
异步任务完成率
任务取消率

这些指标回答：

查询执行是否稳定？
资源消耗是否可控？

5. 结果可信指标

结果一致率
空结果解释准确率
异常值识别率
用户采纳率
用户纠错率
Bad Case复发率

这些指标回答：

用户是否相信结果？
结果是否符合业务预期？

6. 商品体验指标

确认卡通过率
权限申请转化率
错误反馈解决率
用户二次追问率
用户放弃率
查询完成平均轮次

这些指标回答：

用户是否顺利完成提数？
交互是否增加负担？
错误是否能被修复？

十一、常见问题与方法

这些问题非常真实。企业AI提数落地时，真正让系统不可用的往往不是“模型不会写SQL”，而是这些工程细节没有做好。

十二、总结：从SQL Plan到可信查询执行

第八篇讲的是AI提数链路中非常关键的一段：

→ SQL Plan
→ SQL生成
→ SQL校验
→ 安全治理
→ 查询执行
→ 结果校验
→ 交互反馈

这段链路覆盖三个架构层：

查询生成层
安全治理层
查询执行层

查询生成层负责把SQL Plan变成可执行SQL。
安全治理层负责保证SQL不越权、不泄露、不危险、不拖垮系统。
查询执行层负责把SQL稳定跑起来，并把执行状态、结果质量和异常反馈给用户和系统。

这篇文章要强调的不是“大模型能不能写SQL”，而是：

企业级AI提数能不能把SQL生成、SQL校验、权限安全、性能治理、查询执行、异常处理和交互反馈做成一条可信链路。

如果只靠LLM自由生成SQL，系统很难稳定。
如果基于SQL Plan进行受控生成，并配合语法校验、语义校验、权限校验、性能校验和结果校验，系统才有机会进入生产。

最后可以用三句话收束：

SQL生成不是让大模型自由写SQL，而是基于SQL Plan进行受约束、可校验、可解释的工程化生成。

SQL校验不能只停留在语法层，还要覆盖语义、权限、安全、性能、执行结果和业务口径一致性。

企业级AI提数真正可信的链路，不是“自然语言到SQL”，而是“自然语言到结构化任务，到标准语义，到SQL Plan，再到可信查询执行”。

下一篇会进一步推进AI提数结果解释与反馈闭环：如何让用户理解、相信并修正数据结果。