SQL 能运行，不代表答案正确：给 AI 写的查询再加一道闸门
分类：开发者工具 Tag：SQLSure、SQL、Text-to-SQL、AI Agent、数据工程、dbt 作者：陈墨｜OC 编辑
陈墨
开源项目 SQLSure 最近在 Hacker News 引发关注。它不负责生成 SQL，而是在查询执行前检查另一类更麻烦的问题：连接后重复计算收入、把平均值相加、使用错误连接键，或者把敏感字段直接放进结果。
一句话结论：AI 把“写出能跑的 SQL”变得更容易以后，真正危险的部分正在变成那些不会报错、结果看起来也合理的错误。
数据库擅长判断语法和类型，却不知道“订单金额”在一对多连接后不能重复累加，也不知道“日均值”是否可以跨日期直接求和。一个查询可能顺利执行、返回漂亮报表，甚至通过人工扫一眼的审查，但最终数字仍然错八倍。
SQLSure 的办法不是再调用一次大模型，而是让团队先声明少量可验证事实：表的粒度是什么、主外键关系如何、哪些指标可加、哪些字段属于敏感信息。它可以从 dbt 的 unique 和 relationships 测试、数据库 PK/FK 或手写模型中读取这些规则，然后确定性地检查查询。
项目作者称，他们用 SQLSure 检查 BIRD 和 Spider 两个 Text-to-SQL 基准中的 2568 条专家答案，标记 45 处问题，并报告零误报；其中包括一条结果会放大八倍的 BIRD 查询。这个数字目前主要来自项目自己的可复现实验，不能当作独立机构认证。不过它指出的问题非常真实：Text-to-SQL 基准的“标准答案”本身也可能有错。
它也不是万能证明器。规则库没有声明的关系，只能得到“无法验证”，而不是“查询安全”；业务定义如果本身错误，检查器也会忠实执行错误规则。但这种诚实的不确定性，仍然比让生成 SQL 的模型再自我评价一次更可靠。
实际落地时，最费力的也不是安装工具，而是把团队默认存在脑子里的规则写出来。例如“订单表一行代表一张订单”“退款金额可以按日期相加”“账户余额只能取某个时点，不能跨天求和”。这些定义过去常由资深分析师口头把关，AI 大规模生成查询以后，口头经验会迅速成为瓶颈。
一个现实的接入顺序是先从高风险指标开始：收入、活跃用户、库存、余额和含个人信息的字段。把现有 dbt 测试转换成第一版规则，只在 CI 中报告而不拦截；观察一段时间后，再对确定性高的错误启用阻断。否则一次性宣称“所有 SQL 都已验证”，只会制造新的虚假安全感。
关键事实
- SQLSure 通过静态解析查询，不连接数据库，也不发送 SQL 到外部服务。
- 它检查 fan-out、chasm、可加性、连接键和敏感字段等语义问题。
- 项目宣称单次检查约 0.1 毫秒，并提供 CI、MCP 和 Python 库接入方式。
- 基准结果由项目作者提供，部署前仍应在自己的 schema 和查询集上复测。
OC 判断
AI 生成查询的生产流程不应是“生成后直接执行”，而应是“生成、确定性检查、修复、再检查、最后执行”。模型负责提出候选，规则系统负责守住可以明确表达的业务边界。
为什么重要
- 对开发者：语法正确只是最低门槛，数据产品需要语义测试和执行前门禁。
- 对企业：错误报表可能影响定价、财务和医疗决策，风险远高于一次 SQL 报错。
- 对 AI 用户：让模型检查自己的答案并不等于独立验证，最好引入不同机制的校验器。
评论
围绕这篇文章补充信息、提出问题或分享观察。