掌握“数据地图 + 关系说明 + 自然语言提问”这三步方法，再配合角色设定、输出格式约束和示例引导，就能显著提升 AI 生成 SQL 查询语句的准确率，让结果更稳定、更适合直接执行。

很多人都希望只用一句通俗的话，就让 AI 自动生成可以直接运行的 SQL 语句。但实际使用中，经常会遇到字段名写错、JOIN 条件遗漏，甚至返回大量解释说明而不是纯 SQL 代码的问题。

先喂给AI“数据地图”，再开口提问

无论是豆包AI，还是其他大模型，它都不真正了解你的数据库表结构。它不会主动判断“订单金额”究竟在 orders 表里，还是在 sales_summary 表里。如果你没有先提供表结构就直接提问，就像让一个没看过菜单的人替你点菜——最后端上来的可能完全不是你想要的内容。

第一步，先把 CREATE TABLE 语句，或者完整字段清单，原样放在对话开头。不要省略关键字段，也不要拆散分开发送。比如：
CREATE TABLE orders (id BIGINT, user_id INT, amount DECIMAL(10,2), created_at DATETIME);
CREATE TABLE users (id INT, name VARCHAR(32), city VARCHAR(20));

第二步：用一句简洁的话说明核心关联关系，比如：【user_id 是 orders 表外键，关联 users.id】

第三步：再输入你的自然语言查询需求，例如：“查询2024年下单总金额超过5000元的用户姓名和城市”。

用固定句式锁定AI角色和输出格式

如果 AI 生成的 SQL 夹杂中文解释、带注释，或者使用了你当前数据库不支持的语法，例如在 MySQL 中写出 WITH RECURSIVE，这通常说明提示词约束不够明确，AI 仍在自由发挥。

方法一：角色 + 环境 + 指令三件套
你是一名 MySQL 8.0 数据库工程师，请严格输出标准 SELECT 语句，不加任何解释、不带注释、不使用反引号包裹字段名，只返回可直接执行的 SQL 代码。

方法二：强制格式收口
要求 AI 必须用```sql开头、```结尾包裹结果，这样在复制 SQL 代码时，就不会误把多余说明一起复制进去。

方法三：字段别名一定要提前说明清楚
例如你要问“查询每个城市的订单数”，不要只写“按城市分组”这么简单。更稳妥的提示方式是直接补充：“结果中城市列命名为 city_name，订单数量列命名为 order_count”。否则，AI 很可能默认生成 COUNT(*) AS count，但很多报表系统未必接受这个字段名，后续对接时就容易出问题。

复杂查询拆成三轮对话

如果一次性提出“找出近7天复购率 TOP5 的城市，复购定义为同一用户两次下单间隔≤3天”这类复杂 SQL 查询需求，AI 很容易遗漏时间窗口计算逻辑，或者在 GROUP BY 层级上出错。更高效的方式是分步骤提问：

第一步：请列出与“用户复购行为”直接相关的所有表，以及它们对应的核心时间字段和用户标识字段。

第二步：确认 AI 返回的表清单无误后，再继续追问：基于这些表，写出计算“单个用户是否构成复购”的最小逻辑单元（例如：使用 LAG() 获取上一笔订单时间，并判断时间差是否≤3天）。

第三步：现在请生成完整 SQL，要求最终结果只包含 city 和 rebuy_rate 两列，按 rebuy_rate 降序排列，并限制返回 5 行。

加一个正确样例，AI立刻变稳

AI 对“像什么”的学习，往往比对“是什么”的理解更敏感。只要给它一组你认可的 SQL 示例映射，它通常就会按照相同风格来生成结果。

示例一（简单场景）：
Q：查所有上海用户的手机号
A：SELECT phone FROM users WHERE city = '上海';

示例二（带JOIN）：
Q：查订单金额大于1000元的用户姓名和下单时间
A：SELECT u.name, o.created_at FROM users u JOIN orders o ON u.id = o.user_id WHERE o.amount > 1000;

注意：这两个示例必须真实可执行，字段名、表名、筛选条件和写法都要与你的实际数据库保持完全一致，否则 AI 会按错误示例学习，最终生成不正确的 SQL 查询语句。