AI 生成 SQL 查询后，怎样先验正确性再读取业务数据？

先把口头问题写成查询说明

“上个月的订单额”里至少有几项没有说明：按下单日、支付日还是发货日归属？订单额是含税金额、实收金额，还是扣除退款后的净额？取消订单算不算？跨时区时间戳按哪个时区截月？“各产品线”按下单时记录的产品线，还是当前产品目录里的分类？

如果这些条件没有先确定，模型只能替人猜。猜出的 SQL 即使没有语法错误，也可能把正确的问题算错。查询前先写一张任务卡：

任务卡不是模型提示词的替代品。它的用途是让提问人、数据负责人和审核人对“要算什么”达成一致。口径尚未定下来的项目应标为待确认，不要要求 AI 通过 SQL 把它补出来。

• 要回答的业务问题，以及结果会用于哪项讨论；
• 指标名称、计算方式、单位和金额口径；
• 时间范围、时区、归属日期和边界是否包含；
• 分组字段、筛选条件、排除项和退款/取消规则；
• 允许访问的数据表、字段范围和数据负责人；
• 一条可人工核对的预期结果或已知样例。

分开检查语法、字段和业务含义

收到 SQL 后，先看它引用的表、列、关联键和过滤条件。字段名相似并不代表业务含义相同；created_at 可能是记录创建时间，paid_at 才可能是支付时间。模型也可能把客户表和订单表以错误字段连接，导致一笔订单重复计数。

可以按四层逐项检查：

不要用“SQL 跑成功了”作为通过标准。先选一小组由负责人确认的记录，手算或用既有报表对照几个关键值：订单数量、金额合计、分组数和边界日期记录。若对照不一致，记录差异来自哪里——是口径不同、字段定义不同、关联重复，还是源数据本身有缺口。不能解释差异时，先暂停把整批结果用于决策。

• 语法与结构： 是否只有预期的查询语句；有没有额外语句、写操作、调用函数或访问未批准的 schema。
• 字段与关联： 每个字段来自哪张表；连接是一对一还是一对多；重复行是否会改变汇总值。
• 口径与边界： 日期范围是否含首尾；金额、币种、税额、退款和取消规则是否与任务卡一致；空值如何处理。
• 结果解释： 行数和汇总值是否在业务上说得通；异常变化是否能回到原始记录解释，而不是靠模型生成原因。

执行环境要先限制权限和影响范围

只读限制应由数据库账号和服务端流程落实，不能只在提示词里写“不要修改数据”。以 PostgreSQL 为例，官方文档说明可以把当前事务设为 READ ONLY；同时也明确指出，这是高层次的只读模式，并非“什么都不会写入磁盘”的绝对保证。数据库角色仍应只获得完成当前查询所需的读取权限。

再为查询设置合理的语句超时、锁等待限制、结果行数和返回字节上限。LIMIT 能限制返回行数，但不一定能阻止数据库扫描大量记录；因此还要在数据库层控制查询成本，并在执行前审查筛选条件和执行计划。不要把预估成本写成固定的运行时间保证。

用户提供的值应作为参数传入。OWASP 的 SQL 注入预防指南优先推荐参数化查询，并指出动态表名、列名或排序字段不能总是通过绑定变量处理；这些标识符应从固定白名单选择。AI 生成的字符串拼接不能因为看起来合理就直接放行。

一条可以考虑的流程是：先在隔离的开发或测试环境使用经批准的样本审查查询；再由服务端解析 SQL 结构，只允许团队明确批准的只读语句和 schema；执行时用低权限账号、参数绑定、超时及结果限制；结果交给负责人复核后再进入报表。不同数据库的事务、角色和安全功能不同，具体配置要按实际产品文档与企业安全要求实施。

用小样本验证结果，不把敏感数据复制给模型

测试样本的目的，是验证口径和边界，不是把整个生产库复制到新环境。优先使用合成数据或经过批准、最少必要的脱敏样本。设计几条能暴露错误的记录：时间范围起点前一条、起点当天一条、结束当天一条、取消或退款订单，以及产品分类发生变更的记录。

如果查询涉及多个表，还要准备会触发重复计数的样例。例如一个客户有多笔订单、一笔订单有多行明细、一个产品被多个分类关联。核对原始行、连接后行数和最终汇总，避免“总额看起来合理”掩盖重复计算。

测试说明里记录数据库类型和版本、schema 版本、查询版本、输入参数、样本范围、预期值、实际值和审核人。日志应保留足够的追溯信息，但不应把完整的客户明细或敏感字段复制到普通应用日志。若查询结果要交给模型继续总结，也要再次检查接收方是否获准访问这些数据，以及摘要是否会暴露不必要的细节。

先定义拒绝条件和人工接手方式

遇到以下情况时，不应继续执行或把结果用于对外答复：任务卡里没有指标口径；查询引用未批准的表或字段；模型要求扩大数据库权限；关联关系无法解释；结果超过预期范围但找不到来源；数据库返回错误后模型自行改写查询并尝试新范围；样本验证失败；或审核人无法说明结果代表什么。

拒绝后把问题交回对应负责人：业务负责人确认指标，数据负责人确认字段和关联，数据库管理员确认权限与执行控制。人工接手信息应包括原始业务问题、任务卡、生成的 SQL、已核对的部分、失败原因和需要确认的事项。不要只保留一句“AI 查询失败”，否则下一位接手人仍要从头猜。

上线前的 SQL 审核清单

这套检查不能保证所有查询都正确，也不能代替数据库安全审计。它帮助团队把“模型给出 SQL”拆成可验证的业务定义、权限控制、结果核对和责任交接；任何一层不明确，都应先停在草稿阶段。

• 业务负责人确认指标、时间范围、过滤条件和排除项。
• 查询只访问授权的 schema、表和字段，关联关系已确认。
• SQL 结构经过解析或团队定义的审核方式检查，不依赖简单正则来判断安全。
• 值使用参数绑定；动态标识符来自明确白名单。
• 数据库账号遵循最小权限，事务只读限制由服务端执行。
• 有语句超时、锁限制和结果行数/字节上限。
• 小样本包含边界、空值、重复关联和业务例外，预期结果由人确认。
• 输出保留口径、来源和审核记录；日志不复制不必要的原始敏感结果。
• 查询不能确认、执行失败或结果异常时，有明确的停止和人工接手路径。