Sqlsure 开源：给 AI 生成的 SQL 加一道确定性护栏

一件小工具，戳中了 AI 写 SQL 的老毛病

7 月 11 日，开发者 Tejus Arora 在 GitHub 上开源了一个叫 Sqlsure 的项目，Show HN 上挂出来不到一天就冲上首页。定位很直接：给 AI 生成的 SQL 加一层"确定性语义检查"（deterministic semantic checks）。翻译成人话——大模型写的 SQL 你别急着丢进生产库跑，先让 Sqlsure 用一套确定性的规则把它体检一遍。

这事儿看着小，但凡在过去两年里用 Copilot、Cursor 或者 Claude Code 让模型写过复杂 SQL 的人，应该都被坑过：JOIN 条件漏了一个，WHERE 里少了个租户隔离字段，聚合函数忘了 GROUP BY，或者更隐蔽的——语法完全合法、explain 也能跑，但语义上就是错的。这类错误传统 linter 抓不到，单元测试也未必覆盖，而它一旦上线，后果就是脏数据、错账单、甚至跨租户数据泄漏。

Sqlsure 想解决的正是这一段：介于"能不能跑"和"跑出来对不对"之间的灰色地带。

为什么"确定性"三个字是关键

现在 SQL 校验这块，主流做法要么是 LLM 自己 review（让另一个模型看一眼），要么是跑一遍再看结果。前者是概率游戏，后者对生产环境风险太大。Sqlsure 的路子是老派的：把常见的语义错误抽象成一组规则，做静态分析，输入 SQL、输出确定的 pass/fail 加错误定位。

这套逻辑的价值在于可复现。同一段 SQL 跑一百遍，Sqlsure 给出的判断永远一样。你可以把它塞进 CI，塞进 pre-commit，塞进 agent 的工具链——不用担心今天过了明天挂。相比之下，用 GPT 去 review GPT 写的 SQL，本质是让概率检查概率，出了问题你连复盘都没法复盘。

这也是最近半年 AI 工程化领域的一个明显趋势：在 agent 越来越自主的同时，工具链反而在往"确定性"上收。前段时间有一批项目在做 typed tool call 校验、结构化输出 schema 强约束，Sqlsure 是同一股风向下的产物——LLM 负责生成，确定性工具负责兜底。

它到底在查什么

从 README 和示例来看，Sqlsure 目前覆盖的检查项大致分几类，我按重要性排一下：

1. Schema 一致性

最基础也最有用的一层。给 Sqlsure 喂一份 schema（DDL 或者从数据库里抽出来），它会检查 SQL 里引用的表名、列名、类型是不是真的存在、能不能对上。大模型经常干的事：幻觉出一个不存在的字段名，或者把 user_id 写成 userId，跑一半才报错。这类问题静态分析一秒钟就能抓。

2. JOIN 语义

这是 AI 最容易翻车的地方。Sqlsure 会检查 JOIN 的条件是否合理——比如两个表通过明显的外键关系连接，但 ON 条件里用错了字段；或者出现了笛卡尔积却没有明确的 CROSS JOIN 声明。经验丰富的 DBA 一眼能看出来的问题，模型经常视而不见。

3. 聚合与分组

SELECT 里出现了非聚合列却没进 GROUP BY，这种错在 MySQL 老版本会静默通过，在 Postgres 会直接报错，在 AI 生成的代码里出现频率高得离谱。Sqlsure 把这类语义规则硬编码进去，比数据库自己报错更早、更清晰。

4. 租户/权限字段检查（这个是亮点）

可以配置一组"必须出现在 WHERE 里"的字段，比如 tenant_id、org_id。这直接对应 SaaS 场景下最要命的一类 bug——多租户数据串了。让模型自己记得加这个字段？靠不住。让 Sqlsure 强制检查，缺了就 fail，才是正经工程做法。

5. 危险操作检测

没有 WHERE 的 UPDATE/DELETE、全表扫描的高危查询、隐式类型转换等等。这一块跟传统 SQL linter 有重叠，但结合前面几项做联合判断，能过滤掉大量误报。

用起来什么样

典型用法是把它挂在 agent 生成 SQL 之后、执行之前的那一步。伪代码大概是这样：

from sqlsure import Checker

checker = Checker(schema="./schema.sql", rules="./sqlsure.yaml")

sql = llm.generate(prompt)  # 让模型写 SQL
result = checker.check(sql)

if not result.ok:
    # 把错误反馈回模型，让它重写
    sql = llm.regenerate(prompt, feedback=result.errors)
else:
    db.execute(sql)

配置文件里可以声明业务规则：

required_predicates:
  - table: orders
    columns: [tenant_id]
  - table: users
    columns: [org_id]

forbidden:
  - unbounded_delete
  - unbounded_update
  - cross_join_implicit

这套接口的设计意图很清楚：做 agent 的"编译器"。LLM 相当于写代码的人，Sqlsure 是那个不容商量的类型检查器。检查失败就把结构化的错误信息喂回去让模型重写，形成一个自纠正的循环。这比让模型自我 review 靠谱得多，因为反馈本身是确定的、可解释的。

和现有方案比，位置在哪

市面上和 Sqlsure 有点像的东西不少，但都不完全重合：

• sqlfluff、sqlglot：老牌 SQL 静态分析，强在语法和格式。语义层面尤其是业务规则那块，基本不管。Sqlsure 更像是在 sqlglot 之上叠了一层"语义 + 业务规则"检查（README 里也确实提到用了 sqlglot 做 AST 解析）。
• 数据库自身的 EXPLAIN / dry-run：能抓一部分问题，但要连数据库，成本高，而且部分错误（比如租户字段缺失）它根本不认为是错。
• LLM-as-judge：让另一个模型 review，非确定性、慢、贵，前面已经吐槽过。
• PromptQL、Vanna 之类的 text-to-SQL 框架：解决的是"怎么生成"，Sqlsure 解决的是"生成完了怎么验"，两者互补。

所以 Sqlsure 的定位有点像 SQL 版的 TypeScript 类型检查器——不阻止你写代码，但阻止你把明显有问题的代码 ship 出去。

局限和值得关注的点

泼两盆冷水：

第一，规则的覆盖度决定了它能抓多少 bug。目前项目还早，规则集主要覆盖英美主流范式，中文场景下常见的一些坑（比如中文列名、跨方言函数差异）可能还需要社区补。

第二，语义正确 ≠ 业务正确。Sqlsure 能保证 SQL 在 schema 层面合理、在结构上没有致命错误，但"这条查询是否真的回答了用户的问题"这一层，它管不了，也没打算管。这块还是得靠测试和人工 review。

第三，性能和多方言支持。Postgres、MySQL、SQLite 目前看是有的，ClickHouse、BigQuery、Snowflake 这些分析型仓库的方言支持还需要观察。做 AI 数据分析 agent 的团队尤其在意这一点。

第四，规则维护成本。这类项目的宿命是——一旦社区上量，规则库会指数级膨胀，如何管理规则优先级、如何避免误报，是所有静态分析工具最终都要面对的老问题。

一点判断

Sqlsure 不炫技，甚至有点"反 AI"——它做的是把大模型的自由度压缩回一个可控的盒子里。但这正是当下 AI 编码工程化最需要的东西。过去半年，我们看到太多 agent 项目在"更自主"这条路上狂奔，然后在生产环境翻车。像 Sqlsure 这样甘心做"护栏"的工具，反而是让 AI 生成代码真正落地到严肃场景的必要拼图。

如果你在做 text-to-SQL 类产品，或者在给内部数据平台接 AI 助手，这个项目值得马上 clone 下来看看。集成成本低，收益立竿见影——尤其是把"必须包含 tenant_id"这一条打开的那一刻，你会庆幸自己没等到出事之后再来加。

顺带一提，如果你在同时对比多个模型生成 SQL 的效果——比如 GPT、Claude、DeepSeek 谁写业务 SQL 更靠谱——OpenAI Hub 一个 Key 能直接调这些主流模型，国内直连、兼容 OpenAI 格式，配合 Sqlsure 做批量评测很方便。

参考来源

• sqlsure/sqlsure - GitHub：Sqlsure 项目主仓库，包含完整文档、规则配置和 Python/CLI 使用示例。