为什么我不信任 AI 生成的 SQL 了，不是因为它不通，而是因为它太通——能过语法检查、能执行，却可能在不注意的地方漏洞百出。
你有没有遇到过 AI 给的 SQL 通过了语法检查、执行不报错，数据却悄悄错了一行？
能跑，不等于可信
一个看起来很简单的需求：状态流水表用字段 "NewStatus" 记录每个 ID 的状态，每个 ID 都有 "ConfirmationStarted" 和多条 "Closed"，要取 "ConfirmationStarted" 之前最近的那条 "Closed"。
期望结果:
以 ID=147 为例，在 ConfirmationStarted 之前共有三条 Closed，最后一条 06-25 才是“最近的一条”；08-25 虽也是 Closed 但已在 ConfirmationStarted 之后，不算。
期望结果只有两行："147→2022-06-25"、"1645→2023-04-29"。其他 Closed 要么太早，要么在 ConfirmationStarted 之后，都不算。
把需求丢给 AI，几秒拿到一段漂亮的 SQL，CTE 套窗口函数，review 时挑不出毛病。上线两周后对账才发现 147 取成了 05-28，数据错了一行，但 SQL 能跑。
乍一看 bug 很难发现：分段逻辑写对了，却把最后的聚合从 MAX 写成了 MIN，把“离 ConfirmationStarted 最近的一条”变成了“最早的一条”，结果在边界数据上悄悄偏了一行。
AI 给的有漏洞的 SQL 长这样:
WITH t2 AS (
SELECT CreatedAt, ID, NewStatus
, 1 + SUM(CASE WHEN NewStatus='ConfirmationStarted' THEN 1 ELSE 0 END)
OVER (PARTITION BY ID ORDER BY ID ASC, CreatedAt ASC ROWS UNBOUNDED PRECEDING) AS seg
FROM mytable
)
SELECT ID, MIN(CreatedAt) AS CreatedAt --这是几处错误之一,应为MAX，取最近的
FROM (
SELECT CreatedAt, ID, NewStatus, seg
FROM t2
WHERE NewStatus='Closed' AND seg=1
) t_3
GROUP BY ID
ORDER BY ID
这就是 AI 直接产终态 SQL 最危险的地方：你能让 AI 重写一段话，却很难让它自己发现逻辑里那一行看不见的偏差。
我们让AI做了最不该做的事
AI 很擅长把口语需求拆成步骤，却不擅长为最终 SQL 的每一个边界条件都给出 100% 保证。它是概率模型，不是编译器。
公开评测显示，即使让最先进的大模型直接把自然语言翻译成可执行 SQL，在复杂查询上的执行准确率也常在六成左右徘徊，远未达到可直接签核的程度，平均三、四次就可能错一次。
旧范式是 "提示词→AI→不确定的终态 SQL"，黑盒交付，只能让它整段重猜。
我们需要的新范式应该是 "提示词→AI→规范步骤→编译器→确定性 SQL"，每一步可验证。
“跑得通”不算数，“敢签字”才算。
SQLazy，就是这个敢签字的底气，就是规范步骤的编译器，就是新范式的落地工具。
在SQLazy里，这件事只要4步
同样的 "最近一条 Closed"，在 SQLazy 里是 4 步，关键是：每一步都能点开看中间结果。
