用 AI 写 SQL 查询：把一句业务需求变成能跑的语句
这玩意儿到底解决啥问题
说白了，写 SQL 最费劲的不是语法，而是"我想查的东西"和"表里字段"之间的对应关系。你脑子里是"上个月每个地区的销售额"，落到数据库里可能是 orders 表、region 字段、created_at 时间范围、amount 求和。这个翻译过程，刚好是 AI 擅长的。很多刚入行的同学一看到多表关联就头大，其实就是没把这个对应关系想清楚。
我自己的用法是：先不碰数据库，把需求用大白话写清楚，让 AI 出第一版 SQL，再拿去跑。跑不通再贴报错让它改。一轮下来，比自己在那儿拼 JOIN 快太多，而且你能把精力放在"我到底想查什么"上，而不是被语法细节拖住。
先把需求说成人话
别一上来就写"SELECT * FROM"。先告诉 AI 三件事：有哪些表（把表名和关键字段贴给它）、你想得到什么粒度的结果（每行代表一个什么）、有什么过滤条件。这三样说清了，它基本不会跑偏。
比如我就直接说："我有 orders 表，字段是 id、user_id、region、amount、created_at；我要看 2026 年 9 月每个 region 的总销售额和订单数，按销售额从高到低排。"这种描述，AI 基本一次就能给出版本能跑的 GROUP BY 查询。比我自己憋十分钟强。
一个小技巧：把表结构（CREATE TABLE 或者字段清单）直接贴进去，比口头描述准得多。AI 猜字段名经常猜错，你给它看真实结构，它就不会编出不存在的列。尤其是字段名不规范的老库，这一条能省掉一堆来回。
让它把逻辑写进注释里
我习惯在 prompt 里加一句："每段逻辑用注释说明在算什么。"这样出来的 SQL 不是一堆看不懂的嵌套，而是带着中文解释的查询。以后再有人问"这行为啥这么写"，对着注释就能答，不用重新读一遍。
复杂查询让 AI 分步写：先写出最内层的子查询，确认对了再往外套。一口气要一个五层嵌套，它容易前后矛盾。分步来，每一步你都能验证，最后拼起来也稳。我一般让它先给"核心聚合"那一层，跑通了再加时间过滤和排序，层层叠加比一次成型靠谱。
结果对不对，得自己验
这是底线。AI 给的 SQL 能跑、不代表算得对。我一般做三件事：第一，用已知的几条数据手算验证，比如挑一个 region 自己加一遍，看和查询结果对不对得上；第二，看行数合不合理，比如"每个地区"应该有十来行，结果出来 200 行，多半是 JOIN 多乘了；第三，让 AI 同时给出一种更笨但更直观的写法，两种结果交叉比对。
别迷信"它能跑就是对的"。我踩过最狠的一次，是少写了 DISTINCT，去重没生效，数字虚高了一倍，汇报会上差点闹笑话。从那以后，凡是拿去汇报的数字，我都会挑一个维度手算抽查。
几个我踩过的坑
第一，时间字段的时区。created_at 到底是 UTC 还是北京时间，不问清楚，按"9 月"过滤能差出一天，整月数据就歪了。我现在一律在 prompt 里写明时区，不靠它猜。
第二，NULL 值。SUM 会忽略 NULL，但 COUNT 不一定，AI 经常忘记帮你处理"金额为空"的记录，结果和财务对不上。涉及金额汇总，我都会显式加上"忽略空值"或"空值记 0"的约束。
第三，权限和脱敏。别把含手机号、身份证的表直接贴给外部模型。内部的就走内网部署的模型，贴真实字段名没问题，但涉及个人信息一律先脱敏再问。这条不是麻烦，是底线。
进阶一点：让它能复用
顺手的做法是，让 AI 把这条查询包成一个视图或者带参数的查询模板，下次换个月份、换个维度直接改参数就能用。一次写清楚，后面几次都是改个数。我们组现在常用的那批报表查询，一半以上最初都是 AI 出的第一版，人审过改两遍就沉淀成固定资产了。
整体来说，AI 写 SQL 是把"翻译成本"压到了最低。你省下的是拼语法的功夫，换来的是把精力放在"我到底想知道什么"上。这活儿，技术员干最划算。
