我们造了一个编译器，让你不必再赌 AI 的正确率了。不是因为模型不够准，而是行业一直让它做不该做的事。

你有没有遇到过 AI 给的 SQL 能跑、能过检查，上线后才发现边界错了一行，却不报错？

我们为什么要造编译器

我们曾经把一句需求丢给 AI，几秒就拿到一段漂亮的 CTE，窗口函数套窗口函数，review 挑不出毛病。直到对账才发现分组错了一位，兜底的那行丢了。

那一刻我们明白，行业都在卷模型更准，我们换了一条赛道：别让模型负责复杂的终态 SQL。

AI 擅长把口语拆成步骤，编译器擅长把步骤翻成 SQL。各干各的，就不用赌了。

一个跑得通但得靠祈祷的例子

需求很简单，却足够让我们捏着鼻子上线。

事件表 events 按时间排序，相邻 value 相同时属同一组，要输出每组的开始时间 effective_from 与下一组开始时间 effective_to，末组 effective_to 约定为 9999-12-31。

源数据表的 value 字段是序列 1,2,2,1,1,1,2,2,1，相邻相同并为一组：

期望结果只有 5 行：

我们把一句话需求丢给 AI，拿到的 SQL 长下面这样，6 个 CTE 还套着子查询，LAG、SUM、LEAD 全齐，还多套了一层意义不明的过滤，看起来完全正确，你敢直接上线吗？

WITH Value AS (
    SELECT id, value, timestamp FROM events
),
Value1 AS (
    SELECT Value.*, LAG(value) OVER (ORDER BY timestamp ASC) AS prev_value
    FROM Value
),
Value2 AS (
    SELECT id, value, timestamp,
        SUM(CASE WHEN value <> prev_value THEN 1 ELSE 0 END) OVER (ORDER BY timestamp ASC) AS gid
    FROM Value1
),
Grouped AS (
    SELECT gid, MIN(id) AS id, MIN(value) AS value, MIN(timestamp) AS effective_from
    FROM Value2
    GROUP BY gid
),
t_1 AS (
    SELECT gid, id, value, effective_from,
        LEAD(effective_from, 1) OVER (ORDER BY gid) AS effective_to
    FROM (
        SELECT * FROM Grouped WHERE id IN (SELECT id FROM Grouped WHERE effective_from IS NOT NULL)
    ) inner_q
),
cte_final_v2 AS (
    SELECT gid, id, value, effective_from, effective_to FROM t_1 WHERE 1 = 1
)
SELECT * FROM cte_final_v2 ORDER BY gid;

不逐组跑一遍，你能看出哪里错了吗？这类 SQL 最危险的地方不是语法，而是三处藏起来的偏差：ORDER BY 丢了空值排序分支，SUM 后漏了加 1 导致 gid 从 0 起计，LEAD 漏了默认值。其中 LEAD 这处直接让末组兜底值变成 NULL：错一行，不报错，只能祈祷；另外两处遇到边界数据同样会爆。
不是模型不够准，是交付形态错：它一次吐出终态 SQL，错了只能重写提示词整段重生成，逻辑偏差自然撤不掉。
错的正是最后一行：

期望：9 | 1 | 2023-11-18 13:00:00 | 9999-12-31 00:00:00
实际：9 | 1 | 2023-11-18 13:00:00 | NULL

我们让AI做了最不该做的事

AI 擅长规划步骤，却不擅长保证最终 SQL 一定正确。

旧范式是“提示词→AI→不确定的终态 SQL”，黑盒交付，只能让它整段重猜。

新范式应该是“提示词→AI→规范步骤→编译器→确定性 SQL”，每一步可验证。

AI writes the logic. A compiler writes the SQL.

在SQLazy里，这件事只要5步

同样的有效期逻辑（就是上面那种取每组起止时刻的逻辑），在 SQLazy 里是 5 步，每一步都能点开看中间表。

5 步干了什么，一眼看完：排正时序，按 value 变化自动切段，每段取首条，顺手带出下一组开始，最后清掉辅助列。你完全不用知道 LAG 怎么写。
还记得前面那 3 个藏起来的偏差吗？在这里它们连藏的地方都没有。想验哪步就点开哪步，分段切得对不对，看一眼 gid 列就行。

错在第 2 步就只改第 2 步，不用推倒重来。你敢改，是因为每一步都看得见。
编译后 SQL 是编译器按固定规则翻译的，可追溯，可审计：

WITH Value AS (
    SELECT id, value, timestamp FROM events
),
Value2 AS (
    SELECT gid, id AS id, value AS value, timestamp AS effective_from
    FROM (
        SELECT id, value, timestamp,
            SUM(CASE WHEN value <> col__5 THEN 1 ELSE 0 END)
                OVER (ORDER BY CASE WHEN timestamp IS NULL THEN 1 ELSE 0 END, timestamp ASC) + 1 AS gid
        FROM (
            SELECT Value.*, LAG(value) OVER (ORDER BY CASE WHEN timestamp IS NULL THEN 1 ELSE 0 END, timestamp ASC) AS col__5
            FROM Value
        ) sub__6
    ) Value1
    GROUP BY gid
)
SELECT gid, id, value, effective_from,
    LEAD(effective_from, 1, TO_DATE('9999-12-31 00:00:00', 'YYYY-MM-DD HH24:MI:SS')) OVER (ORDER BY gid) AS effective_to
FROM Value2
ORDER BY gid;

这段 SQL 没有猜的成分，是编译器把 5 步固定翻译出来的，同一 workflow 永远同一结果，不会编造字段。

简单增删改查，直接让 AI 写就行，这种分段取首尾的逻辑再用 SQLazy。

把你最可疑的那段AI SQL贴进来

你上线过最可疑的 AI SQL 是哪段？是凭空编了个不存在的字段，还是分区键漏写了，抑或聚合口径悄悄偏了？

别再陷入“重写提示词→重跑→碰运气”的循环了。把那段最不放心的 AI SQL 贴进 Playground，照着上面的样子做一遍同样可验的流程，并晒出你的案例。

在线体验与本例运行：

AI plans, compiler guarantees - zero hallucinations.