AI写SQL翻车现场：3个逻辑词让90%的提示词栽了跟头

「把孟买和德里客户都查出来」——这句话丢给AI，它可能只给你孟买客户，也可能把全印度数据都搬来。问题不在AI，在你怎么描述"和"与"或"。

自然语言里的"或"有歧义，SQL没有。这是用AI生成查询时最容易踩的坑，也是本文要拆解的核心。

数据冲击：一个"或"字引发的惨案

先看一组真实需求变形：

• 「已完成订单且金额超500」→ 需要AND

• 「孟买或德里的客户」→ 需要OR

• 「状态为处理中、已发货、已完成」→ 需要IN

这三种逻辑在SQL里是完全不同的语法结构，但用日常口语描述时，它们长得几乎一样。AI不是读心术，它只能按字面概率猜——猜错的代价是数据错漏或性能爆炸。

某数据团队曾统计，AI生成的SQL中约34%需要人工修复逻辑条件。修复原因排名第一的就是AND/OR/IN的误用或遗漏。

事件还原：从"说人话"到"说准话"

第一阶段：简单需求确实省心。

「显示已完成订单」这种单条件查询，AI几乎不会出错。自然语言描述直接映射到WHERE status = 'completed'，皆大欢喜。

第二阶段：复合条件开始埋雷。

需求变成「孟买或德里的已完成订单」。这里有两个陷阱：

1. "或"的优先级：AI可能理解为(城市=孟买 OR 城市=德里) AND 状态=已完成，也可能漏掉括号变成城市=孟买 OR (城市=德里 AND 状态=已完成)

2. "已完成"的表述：用户说"已完成"，数据库字段可能是completed、done、finished、1——AI需要猜映射关系

第三阶段：列表条件彻底翻车。

「状态为处理中、已发货、已完成的订单」——人类看到顿号自然想到"在这几个之中"，但AI可能生成三个OR条件，也可能只取第一个，还可能误解为字符串拼接。

IN运算符的存在就是为了解决这个场景，但很多人写提示词时根本想不起来要提。

关键节点：三个运算符的精确打开方式

AND：所有条件必须同时满足

错误示范：「查大单子，要完成的，孟买的」

AI可能输出：WHERE amount > 500（漏了城市和状态）

正确姿势：「订单需同时满足：状态为'completed'、城市为'Mumbai'、金额大于500」

关键技巧：用"同时满足""并且""所有"等词明确触发AND逻辑

OR：任一条件满足即可

错误示范：「孟买或德里客户」

风险：AI可能只返回孟买客户（把"或"当语气词），也可能返回全量数据（把"或"当AND）

正确姿势：「客户城市为'Mumbai'或'Delhi'，满足任一即可」

关键技巧：显式列出可选值，用"满足任一""或...或...""之一"强化OR语义

IN：值在指定集合中

错误示范：「状态是处理中、已发货、已完成的」

AI常见翻车：生成status = '处理中、已发货、已完成'（字符串匹配）或只取第一个值

正确姿势：「状态字段值属于以下集合：'processing', 'shipped', 'completed'」

关键技巧：用"属于""在...之中""集合""列表"等词触发IN，直接给出具体值

启示：提示词工程的本质是接口设计

写SQL提示词和写代码注释有个共同点：你以为自己在描述意图，实际上是在设计接口。

接口需要精确、无歧义、可验证。自然语言天生模糊，所以好的SQL提示词要自带"类型系统"：

• 字段名用引号或代码格式标注

• 逻辑关系用结构化表述（"条件A且条件B"而非"要A的B的"）

• 枚举值显式列出，不用口语省略

• 优先级用括号或缩进暗示

一个实用模板：

「查询[表名]，返回满足以下[全部/任一]条件的记录：

1. [字段名] [运算符] [值]

结果需包含字段：A, B, C」

这个模板把自然语言需求翻译成AI能稳定解析的结构，减少自由发挥空间。

最后留个开放问题：你最近一次用AI写SQL，它生成的查询跑了多久？有没有偷偷全表扫描？