「把孟买和德里客户都查出来」——这句话丢给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，它生成的查询跑了多久？有没有偷偷全表扫描？
热门跟贴