专栏AI 编程提效实战 30 讲标签AI编程 / SQL / 数据库 / 提示词 / 程序员效率先说结论用 AI 生成 SQL最危险的地方不是语法写错而是它在缺少上下文时“猜表、猜字段、猜业务口径”。如果你只问帮我写一条 SQL查一下最近 7 天活跃用户。AI 很可能给出一条看起来能跑、但业务口径完全不可信的 SQL。更稳的做法是在提示词里明确加上 6 类约束表结构、口径定义、时间范围、权限边界、性能限制、校验方式。这篇给你一套可直接复制的 SQL 提示词模板适合做数据查询、运营分析、排查问题和写后台统计接口时使用。为什么 AI 写 SQL 容易出问题AI 写 SQL 常见问题主要有 4 类。第一类是表名字段名靠猜。比如你只说“用户表”它可能生成users、user_info、app_user但你的库里真实表名可能是t_member_account。第二类是业务口径靠猜。比如“活跃用户”到底是登录、访问页面、下单、打开 App还是任意行为不同口径会得到完全不同的结果。第三类是时间边界不清。最近 7 天是自然日还是从当前时间往前 168 小时是否包含今天时区用哪一个第四类是性能和安全风险。AI 可能生成全表扫描、大范围LIKE、无条件更新、没有LIMIT的查询甚至在你没有强调时写出危险的DELETE或UPDATE。所以让 AI 写 SQL 前要先让它“不能自由发挥”。第 1 个约束先给表结构不让 AI 猜字段最少要给 AI 这些信息表名 orders 字段 - id订单 ID - user_id用户 ID - status订单状态paid 表示已支付cancelled 表示已取消 - pay_amount支付金额单位分 - created_at订单创建时间 - paid_at支付完成时间 索引 - idx_user_id(user_id) - idx_paid_at(paid_at) - idx_status_paid_at(status, paid_at)不要只贴一句“订单表有订单信息”。表结构越具体AI 越不容易编字段。如果你不方便贴完整建表语句也至少贴业务相关字段和索引。尤其是索引信息它会影响 SQL 的写法。第 2 个约束把业务口径写成判断条件很多 SQL 错在业务口径而不是错在语法。比如“最近 7 天付费用户数”你应该先写清楚业务口径 - 付费用户存在至少一笔 status paid 的订单 - 统计字段按 user_id 去重 - 时间范围paid_at 在最近 7 个自然日内 - 排除规则排除测试账号 user_id in (...) - 输出结果只返回一个数字字段名为 paid_user_count这一步本质上是在把一句模糊需求翻译成 SQL 条件。如果你自己都说不清口径不要急着让 AI 写 SQL。先让它反问我想统计最近 7 天付费用户数。 请先不要写 SQL。 请帮我列出生成这条 SQL 前必须确认的业务口径问题。 如果某个口径会影响结果请说明影响在哪里。第 3 个约束明确只生成 SELECT禁止写入操作只要不是明确要改数据建议默认加上安全边界安全约束 - 只允许生成 SELECT 查询 - 不允许生成 INSERT、UPDATE、DELETE、TRUNCATE、DROP - 不允许修改表结构 - 不允许使用没有 WHERE 条件的全表操作 - 如果需求必须写入数据请先说明风险不要直接给 SQL这个约束很朴素但非常有用。很多时候你只是想分析数据AI 却可能顺手给出“修复数据”的 SQL。把只读边界写清楚可以减少误操作风险。第 4 个约束加性能限制避免全表扫描生成查询类 SQL 时我通常会加这些限制性能约束 - 优先使用已给出的索引字段过滤 - 大表查询必须带明确时间范围 - 明细查询必须加 LIMIT - 避免对索引字段做函数计算 - 避免 SELECT * - 如果可能造成全表扫描请先提示风险并给出优化建议比如下面这种写法就不太好SELECT * FROM orders WHERE DATE(paid_at) 2026-06-25;更好的方向是SELECT id, user_id, pay_amount, paid_at FROM orders WHERE paid_at 2026-06-25 00:00:00 AND paid_at 2026-06-26 00:00:00 AND status paid LIMIT 100;核心区别是不要让函数包住索引字段尽量让数据库能用上范围扫描。第 5 个约束指定输出格式让结果可检查不要只让 AI 输出 SQL。让它同时输出解释和校验点输出格式 1. SQL 2. 字段说明 3. 使用到的表和字段 4. WHERE 条件对应的业务口径 5. 可能的性能风险 6. 上线前需要人工确认的点这样你不会只看到一段代码而是能检查它有没有偷偷改口径、漏字段、漏时间范围。如果是给生产库跑的 SQL我建议再加一句请给出一条用于小范围验证的 SQL例如只查一天、只查一个用户或只查 10 条样本。先小范围验证再跑完整查询。第 6 个约束要求 AI 先提问再生成对模糊需求最好的提示词不是“直接写 SQL”而是“先问问题”。你可以这样写如果下面需求缺少必要信息请先提问不要直接生成 SQL。 只有在表结构、业务口径、时间范围、输出字段和安全边界都明确后再给出 SQL。这条约束能明显降低“看起来正确”的错 SQL。AI 很擅长补全但业务 SQL 最怕补全。宁可让它多问两个问题也不要让它替你猜。可直接复制的完整提示词你现在是我的 SQL 助手。 目标基于我提供的表结构和业务口径生成可读、可检查、尽量安全的 SQL。 重要约束 1. 如果信息不足请先提问不要直接生成 SQL 2. 不允许猜表名、字段名、枚举值和业务口径 3. 默认只生成 SELECT不生成 INSERT、UPDATE、DELETE、TRUNCATE、DROP 4. 大表查询必须带明确时间范围 5. 明细查询必须加 LIMIT 6. 避免 SELECT * 7. 避免对索引字段做函数计算 8. 如果可能造成全表扫描请指出风险并给出优化建议 表结构 {粘贴表名、字段含义、索引、枚举值} 业务口径 {粘贴统计口径、过滤规则、排除规则} 查询目标 {说明你要查什么} 时间范围 {说明自然日/小时区间/是否包含今天/时区} 输出要求 1. SQL 2. 字段说明 3. 使用到的表和字段 4. WHERE 条件对应的业务口径 5. 可能的性能风险 6. 上线前需要人工确认的点 7. 小范围验证 SQL一个完整示例需求统计最近 7 个自然日每天的付费用户数和支付金额。提示词里补齐上下文后可以让 AI 生成类似这样的 SQLSELECT DATE(paid_at) AS pay_date, COUNT(DISTINCT user_id) AS paid_user_count, SUM(pay_amount) / 100.0 AS paid_amount_yuan FROM orders WHERE status paid AND paid_at 2026-06-19 00:00:00 AND paid_at 2026-06-26 00:00:00 GROUP BY DATE(paid_at) ORDER BY pay_date;这条 SQL 仍然需要你根据真实数据库确认 3 件事status paid是否就是付费成功paid_at是否为支付完成时间时区是否一致SUM(pay_amount) / 100.0是否符合金额单位AI 可以帮你提高生成效率但不能替你确认业务真相。总结用 AI 生成 SQL重点不是让它“写得快”而是让它“不能乱猜”。我建议每次至少加上 6 类约束表结构、业务口径、时间范围、安全边界、性能限制、输出校验。只要这几类信息说清楚AI 生成的 SQL 才更接近可用而不是一段看起来漂亮的风险代码。下一篇讲从 0 到 1 搭建自己的代码知识库继续给可复制的工作流。
第11讲｜用 AI 生成 SQL 时必须加的约束
发布时间：2026/6/26 13:07:04
专栏AI 编程提效实战 30 讲标签AI编程 / SQL / 数据库 / 提示词 / 程序员效率先说结论用 AI 生成 SQL最危险的地方不是语法写错而是它在缺少上下文时“猜表、猜字段、猜业务口径”。如果你只问帮我写一条 SQL查一下最近 7 天活跃用户。AI 很可能给出一条看起来能跑、但业务口径完全不可信的 SQL。更稳的做法是在提示词里明确加上 6 类约束表结构、口径定义、时间范围、权限边界、性能限制、校验方式。这篇给你一套可直接复制的 SQL 提示词模板适合做数据查询、运营分析、排查问题和写后台统计接口时使用。为什么 AI 写 SQL 容易出问题AI 写 SQL 常见问题主要有 4 类。第一类是表名字段名靠猜。比如你只说“用户表”它可能生成users、user_info、app_user但你的库里真实表名可能是t_member_account。第二类是业务口径靠猜。比如“活跃用户”到底是登录、访问页面、下单、打开 App还是任意行为不同口径会得到完全不同的结果。第三类是时间边界不清。最近 7 天是自然日还是从当前时间往前 168 小时是否包含今天时区用哪一个第四类是性能和安全风险。AI 可能生成全表扫描、大范围LIKE、无条件更新、没有LIMIT的查询甚至在你没有强调时写出危险的DELETE或UPDATE。所以让 AI 写 SQL 前要先让它“不能自由发挥”。第 1 个约束先给表结构不让 AI 猜字段最少要给 AI 这些信息表名 orders 字段 - id订单 ID - user_id用户 ID - status订单状态paid 表示已支付cancelled 表示已取消 - pay_amount支付金额单位分 - created_at订单创建时间 - paid_at支付完成时间 索引 - idx_user_id(user_id) - idx_paid_at(paid_at) - idx_status_paid_at(status, paid_at)不要只贴一句“订单表有订单信息”。表结构越具体AI 越不容易编字段。如果你不方便贴完整建表语句也至少贴业务相关字段和索引。尤其是索引信息它会影响 SQL 的写法。第 2 个约束把业务口径写成判断条件很多 SQL 错在业务口径而不是错在语法。比如“最近 7 天付费用户数”你应该先写清楚业务口径 - 付费用户存在至少一笔 status paid 的订单 - 统计字段按 user_id 去重 - 时间范围paid_at 在最近 7 个自然日内 - 排除规则排除测试账号 user_id in (...) - 输出结果只返回一个数字字段名为 paid_user_count这一步本质上是在把一句模糊需求翻译成 SQL 条件。如果你自己都说不清口径不要急着让 AI 写 SQL。先让它反问我想统计最近 7 天付费用户数。 请先不要写 SQL。 请帮我列出生成这条 SQL 前必须确认的业务口径问题。 如果某个口径会影响结果请说明影响在哪里。第 3 个约束明确只生成 SELECT禁止写入操作只要不是明确要改数据建议默认加上安全边界安全约束 - 只允许生成 SELECT 查询 - 不允许生成 INSERT、UPDATE、DELETE、TRUNCATE、DROP - 不允许修改表结构 - 不允许使用没有 WHERE 条件的全表操作 - 如果需求必须写入数据请先说明风险不要直接给 SQL这个约束很朴素但非常有用。很多时候你只是想分析数据AI 却可能顺手给出“修复数据”的 SQL。把只读边界写清楚可以减少误操作风险。第 4 个约束加性能限制避免全表扫描生成查询类 SQL 时我通常会加这些限制性能约束 - 优先使用已给出的索引字段过滤 - 大表查询必须带明确时间范围 - 明细查询必须加 LIMIT - 避免对索引字段做函数计算 - 避免 SELECT * - 如果可能造成全表扫描请先提示风险并给出优化建议比如下面这种写法就不太好SELECT * FROM orders WHERE DATE(paid_at) 2026-06-25;更好的方向是SELECT id, user_id, pay_amount, paid_at FROM orders WHERE paid_at 2026-06-25 00:00:00 AND paid_at 2026-06-26 00:00:00 AND status paid LIMIT 100;核心区别是不要让函数包住索引字段尽量让数据库能用上范围扫描。第 5 个约束指定输出格式让结果可检查不要只让 AI 输出 SQL。让它同时输出解释和校验点输出格式 1. SQL 2. 字段说明 3. 使用到的表和字段 4. WHERE 条件对应的业务口径 5. 可能的性能风险 6. 上线前需要人工确认的点这样你不会只看到一段代码而是能检查它有没有偷偷改口径、漏字段、漏时间范围。如果是给生产库跑的 SQL我建议再加一句请给出一条用于小范围验证的 SQL例如只查一天、只查一个用户或只查 10 条样本。先小范围验证再跑完整查询。第 6 个约束要求 AI 先提问再生成对模糊需求最好的提示词不是“直接写 SQL”而是“先问问题”。你可以这样写如果下面需求缺少必要信息请先提问不要直接生成 SQL。 只有在表结构、业务口径、时间范围、输出字段和安全边界都明确后再给出 SQL。这条约束能明显降低“看起来正确”的错 SQL。AI 很擅长补全但业务 SQL 最怕补全。宁可让它多问两个问题也不要让它替你猜。可直接复制的完整提示词你现在是我的 SQL 助手。 目标基于我提供的表结构和业务口径生成可读、可检查、尽量安全的 SQL。 重要约束 1. 如果信息不足请先提问不要直接生成 SQL 2. 不允许猜表名、字段名、枚举值和业务口径 3. 默认只生成 SELECT不生成 INSERT、UPDATE、DELETE、TRUNCATE、DROP 4. 大表查询必须带明确时间范围 5. 明细查询必须加 LIMIT 6. 避免 SELECT * 7. 避免对索引字段做函数计算 8. 如果可能造成全表扫描请指出风险并给出优化建议 表结构 {粘贴表名、字段含义、索引、枚举值} 业务口径 {粘贴统计口径、过滤规则、排除规则} 查询目标 {说明你要查什么} 时间范围 {说明自然日/小时区间/是否包含今天/时区} 输出要求 1. SQL 2. 字段说明 3. 使用到的表和字段 4. WHERE 条件对应的业务口径 5. 可能的性能风险 6. 上线前需要人工确认的点 7. 小范围验证 SQL一个完整示例需求统计最近 7 个自然日每天的付费用户数和支付金额。提示词里补齐上下文后可以让 AI 生成类似这样的 SQLSELECT DATE(paid_at) AS pay_date, COUNT(DISTINCT user_id) AS paid_user_count, SUM(pay_amount) / 100.0 AS paid_amount_yuan FROM orders WHERE status paid AND paid_at 2026-06-19 00:00:00 AND paid_at 2026-06-26 00:00:00 GROUP BY DATE(paid_at) ORDER BY pay_date;这条 SQL 仍然需要你根据真实数据库确认 3 件事status paid是否就是付费成功paid_at是否为支付完成时间时区是否一致SUM(pay_amount) / 100.0是否符合金额单位AI 可以帮你提高生成效率但不能替你确认业务真相。总结用 AI 生成 SQL重点不是让它“写得快”而是让它“不能乱猜”。我建议每次至少加上 6 类约束表结构、业务口径、时间范围、安全边界、性能限制、输出校验。只要这几类信息说清楚AI 生成的 SQL 才更接近可用而不是一段看起来漂亮的风险代码。下一篇讲从 0 到 1 搭建自己的代码知识库继续给可复制的工作流。
