同一个 SQL 需求我换了 5 种问法问模型，15 次里只有 5 次算对

昨晚收工前我干了件较真的事。前阵子让模型帮我写一条统计 SQL，它吐出来的结果看着挺整齐，我对了一遍手工账才发现有个城市的排名排反了。我当时没当回事，后来想想：这到底是撞大运，还是模型写 SQL 本来就这个水平？于是我搭了张两表的小库，把同一个需求换了 5 种问法各问 3 遍，一共 15 次，一条条真跑、真对账。

库很简单：一张客户表（id、姓名、城市），一张订单表（订单 id、客户 id、金额、日期），塞了 10 个客户、3 个城市、16 笔订单，其中特意埋了 1 笔去年 12 月的脏数据——它不该被算进第一季度。需求就一句：查 2026 年第一季度里每个城市消费金额排前 2 的客户，列出城市、客户名、消费总额、排名。我先把自己脑子里的正确答案算死，是 6 行：北京张三 200 / 李四 115，上海王五 250 / 赵六 90，广州孙七 200 / 郑十 140。模型用一个免费档的通用大模型，判定只有一条：不报错，且查出来的行和我这 6 行逐字对得上，才算对。

结果比我预期的两极分化还明显。15 次里，7 次直接被限流打空——免费档每秒请求卡得死，模型连 SQL 都没吐出来，这 7 次我不算它能力问题。剩下 8 次真正返回了 SQL 的：5 次结果和我的 6 行完全一致，3 次一执行就报错。按问法拆开看更说明问题：

问法                    跑通且结果对   执行报错   限流空响应
只说需求，不给表结构        1/3         2/3        0
给了建表语句              1/3          0         2/3
建表语句 + 示例行          0           1/3       2/3
建表语句 + 明确约束        3/3          0         0
先列假设再写 SQL          0           0         3/3

最扎眼的是两类失败。只丢需求的那组，模型凭空给 customers 表编出了 customer_id、customer_name 这两个根本不存在的列，sqlite 直接报 no such column。另一组给了我建表语句却没说约束，有一条 SQL 连 CTE 都没写完就被截断，报 incomplete input。反倒是我把表结构和「用 ROW_NUMBER 按城市分区、只取排名前 2」这层约束写明白的那组，3 次全对，它老老实实按我说的分区排了序。

有个点挺出乎我意料：这 8 次里没有出现「能跑但算错」的情况。5 次跑通的全对，3 次是当场崩。我原本以为最危险的是它悄悄排错序、你核对才发现，结果这次失败都很吵，反而好发现。当然这只能说明这一类「带排名的聚合查询」的失败模式偏「硬崩」，换成分页、模糊匹配、时区之类的需求未必如此，不能拿这一次推论所有 SQL。

我现在的做法改了：让模型写 SQL，一定把表结构贴给它，省得它编列名；要是涉及排名、去重、时间窗，我还会把约束直接写进提示词，不指望它自己悟。更重要的是，它吐出来的 SQL 我一定会丢进库里跑一遍、再抽两行对一下——这次 5 次「跑通且对」里，有 2 次是靠给了完整约束才稳的，剩下 3 次运气成分不小，不验证根本分不出来。

你平时让模型写查询，是连表结构都贴给它，还是甩一句需求就等结果？我以前是后者，吃过的亏够我以后都贴结构了。