AI 写 SQL 还是手写？3 步让报表不翻车

用自然语言问数据库，几十秒就能出一段 SQL，这是很多人今年最爽的体验；但同一套流程直接拿去交付月报，翻车也是真翻车。区别不在工具强不强，而在你有没有分清「探索」和「交付」这两种场景。

先分场景：问数和报表，本来就是两件事

临时想看一眼数据、验证一个猜测、给自己找方向——用自然语言问数最快，错了也没人受伤。

但进看板、进周报、进对外口径的数字，必须有人对结果负责。这时候手写 SQL 往往比调 AI 更省时间，因为你要的不是「跑出来」，而是「可解释、可复现、可维护」。

一句话判断标准：这个数字错了，谁会挨骂？如果有人挨骂，就别让 AI 直接生成最终 SQL。

第一步：给 AI 的不是表结构，是「口径字典」

大多数人把建表语句一贴就开始问，AI 只能靠猜。真正决定准确率的是下面四类信息：

1. 粒度：这张表一行代表什么。是订单还是订单明细？一句话说清，能消掉大部分重复计数问题。

1. 字段含义与枚举值：status=3 到底是「已支付」还是「已退款」，AI 不可能知道。

1. 时间字段选哪个：下单时间、支付时间、完成时间，口径差一天，月报可能差一个量级。

1. 常用指标定义：GMV 是否含退款、新客怎么算、活跃怎么定义。

把这些写成一份 markdown 说明贴在对话开头，或者沉淀进语义层/知识库，比反复调提示词有用得多。口径稳定的团队，值得把指标定义单独维护成一份可引用的文档。

第二步：先跑小样本，拿已知数字对账

别一上来就跑全量。让 AI 先输出「不聚合的明细 + LIMIT 100」，肉眼检查三件事：join 之后行数有没有翻倍、有没有整列为 NULL、金额有没有变成原来的几倍。

然后找一个你早就知道结果的月度数字，让 AI 生成的 SQL 跑同一口径。对上了再往下走；对不上就直接追问：

「这个数和 X 对不上，请检查 join 键是否唯一、是否有多对多导致金额翻倍。」

大模型在「被告知要检查什么」之后，往往能自己定位到问题所在。这一步花的五分钟，能省掉后面一小时的排查。

第三步：生产 SQL 人写机审，AI 只干三件事

生产环境让 AI 做辅助而不是主力，具体分工是：

• 生成骨架：把常用的 join、过滤条件、分组维度草拟出来，你再改细节。

• 代码审查：专门让它找笛卡尔积、除零、NULL 参与计算、窗口函数缺排序、时间字段不一致。

• 性能建议：分区裁剪、谓词下推、避免 SELECT *。

把 AI 当成一个随时在线的审稿人，而不是替你签字的人。

一张交付前自查清单

粒度是否说明清楚 / join 键是否唯一 / 时间口径是否统一 / 是否需要去重 / NULL 如何处理 / 是否可能除零 / 是否命中分区 / 排序是否稳定。逐条过一遍，比事后解释便宜。

小结

自然语言问数不是要替代 SQL，它把「探索」的成本降到接近零，但「交付」的责任还是要留给具体的人。用 AI 找方向、用手写保交付，中间靠口径字典和对账把两者接起来，这就是最省事的用法。