给AI加了3条规则，SQL翻车率降了

摘要：AI 写 SQL，语法正确率 92%，但逻辑翻车是常态。它不认识你的表结构，不知道字段叫什么，也分不清 MySQL 和 ClickHouse 的语法差异。本文分享三条 Prompt 规则：喂上下文消灭字段幻觉、定方言防止语法混搭、加验证堵住边界漏洞。每条规则配一个真实踩坑案例。

上周五下午四点半，我让 Cursor 帮我写了一个 JOIN 查询。

语法检查通过，IDE 里没有红色波浪线。我点了 Run，起身去接水。

回来的时候，查询还在跑。又等了十分钟，报错了。

不是语法问题。是 AI 把 user_name 写成了 name，MySQL 不认识这个字段。

这件事让我想起 CSDN 上的一组测试数据。

AI 写 SQL 的致命缺陷

有作者对 5 款 AI 代码助手做了 300 次 SQL 生成测试，在电商全链路数据库上跑（12 张关联表，千万行数据）。结果很说明问题：GitHub Copilot 语法正确率 92%，但逻辑正确率远低于这个数------复杂查询场景下频繁"看起来对，跑起来炸"。

（来源：CSDN，2026年5月）

用了一年 AI 辅助写 SQL 之后，我的结论就一条：AI 不是不会写 SQL，它是不认识你的数据库。

不认识你的表结构、你的字段命名、你的业务规则、你的数据库方言。

但这个事可以解决。我后来在 Prompt 里加了三件事，翻车率降了大半。

规则一：喂上下文

这是我踩得最早、也最多的坑。

有一次查用户订单，让 AI 帮忙写：

sql 复制代码

SELECT u.name, o.amount
FROM users u
JOIN orders o ON u.id = o.user_id
WHERE o.created_at > '2026-01-01'

跑起来直接报 Unknown column 'u.name'。我盯着屏幕愣了几秒------字段名明明是 user_name，AI 自作主张缩写成了 name。这个现象圈内叫"字段幻觉"，AI 会编造它认为"应该存在"的字段名。

阿里云开发者社区在 Cursor SQL 避坑指南里专门提了这个问题（来源：阿里云开发者社区，2026年3月）。解法简单到容易被忽略：把表结构喂给 AI。

在 Cursor 里用 @ 引用包含建表语句的文件，一行搞定。我用的是这个方法：项目里维护一个 schema.md，每次建新表就顺手更新，写 SQL 的时候 @schema.md。

如果你用的编辑器不支持 @ 引用，直接把建表 DDL 贴进 Prompt：

sql 复制代码

这是我的数据库表结构：
CREATE TABLE users (
  id BIGINT PRIMARY KEY,
  user_name VARCHAR(50),
  deleted_at DATETIME DEFAULT NULL,
  ...
)

核心就一条：别让 AI 猜你的字段名。猜对了是你运气好，猜错了排查半小时。

规则二：定方言

字段幻觉解决了，还会踩另一个坑：方言混搭。

去年帮数据分析项目写 ClickHouse 的物化视图，我让 AI 直接上手：

sql 复制代码

CREATE MATERIALIZED VIEW mv_daily_stats AS
SELECT date, user_id, COUNT(*) AS cnt
FROM events
GROUP BY date, user_id

ClickHouse 直接拒了。报错信息指向 GROUP BY 在物化视图里的写法不对。

排查了十几分钟才定位到原因：AI 混了 PostgreSQL 的语法进去。ClickHouse 物化视图的语法规则和 PG 是两回事，但 AI 训练数据里各种方言混在一起，它输出的东西是"最大公约数"------看起来像那么回事，一跑就炸。

此后我养成了一个习惯，Prompt 里必加一句：

复制代码

数据库是 MySQL 8.0，不是 PostgreSQL，不是 ClickHouse

如果用的 Cursor，直接写进 .cursorrules，一劳永逸：

复制代码

本项目数据库为 MySQL 8.0

别小看这一行。PostgreSQL、MySQL、ClickHouse 的方言差异大到同一个 SQL 在这边正常、在那边就直接报错。阿里云避坑指南里把这一点列在了前几条（来源：阿里云开发者社区，2026年3月）。

规则三：加验证

有了上下文，定了方言，AI 写的 SQL 就可靠了吗？

还差一步。

有一次在 MongoDB 里用聚合管道关联用户和订单，AI 写了这样一段：

javascript 复制代码

db.users.aggregate([
  { $lookup: {
    from: "orders", localField: "_id",
    foreignField: "user_id", as: "orders"
  }},
  { $unwind: "$orders" }
])

看起来没毛病。但跑了一阵发现一个诡异现象：被删除的用户，连带着订单也从结果里消失了。

排查了很久才定位到根因：$lookup 之后，已删除用户的 orders 字段是空数组，后面的 $unwind 直接把这些文档吞掉了。AI 没考虑被删用户这种边界情况。阿里云的避坑文档里也记录了这个 Case。

这个教训让我加了第三条规则：让 AI 自己解释它写的 SQL。

每次生成复杂查询后，我会加一句：

复制代码

解释一下这个查询的逻辑，特别是边界情况怎么处理的

AI 会说明它为什么选 LEFT JOIN 而不是 INNER JOIN，为什么加了 IS NULL 判断，为什么用子查询而不是 CTE。大部分逻辑错误，在 AI 自己"讲一遍"的时候就会暴露。

如果查询真的很关键，我还会让它同时生成验证 SQL：

sql 复制代码

再写一条 SQL，验证上面查询的结果是否正确

比如查一下 COUNT 能不能对上，关键字段有没有漏。跑一下验证 SQL，比肉眼 Review 靠谱得多。

一句话总结

AI 写 SQL 翻车，不是因为语法差，是因为它不认识你的数据库。

每次让 AI 写 SQL 之前，花 30 秒做三件事：

喂上下文------表结构、字段名、注释贴进去
定方言------MySQL 8.0 / PostgreSQL 15 / ClickHouse，别让 AI 猜
加验证------让它自己解释逻辑，关键查询加一条验证 SQL

30 秒多打三行 Prompt，省掉半小时排查一个"语法对但逻辑错了"的 SQL。这笔账，划算。

给AI加了3条规则，SQL翻车率降了

AI 写 SQL 的致命缺陷

规则一：喂上下文

规则二：定方言

规则三：加验证

一句话总结

延伸阅读