SQL Copilot 最容易做成“代码补全器”：模型返回 SQL，编辑器高亮一下，用户自己运行。到了需要自动修复、自动解释或一键执行的场景，这个边界就不够了。模型写出的 SQL 往往像标准 SQL，真正交给 Flink、Spark、Hive 或 PostgreSQL 时，方言、Catalog 和执行计划都会给出不同结论。

我把验证分成三段：目标引擎 Parser 证明语句属于这个方言，Catalog/Analyzer 证明对象和类型能解析，Planner/受控执行证明计划风险和结果语义可接受。任何一段失败，都返回具体证据，而不是笼统说“SQL 可能有问题”。

NL2SQL 演示很容易做出效果：准备几张表，把 schema 放进上下文，模型很快能生成一条能跑的 SQL。真正接到企业数据平台后，问题不再是“有没有 SQL”，而是这条 SQL 为什么可信。字段名写对、语法能执行，只通过了最浅的一层检查。

我把 NL2SQL 的交付物定义为“可验证查询”，不是一段字符串。除了 SQL，还要带上所用口径、对象版本、权限范围、执行计划风险和结果断言。模型负责提出候选，平台负责决定它是否有资格执行和回答。