AI 生成 SQL：能帮你起草，但不能替你负责

AI 生成 SQL能帮你起草但不能替你负责AI 生成 SQL 很好用。告诉它要查什么它很快给你 SELECT、JOIN、GROUP BY甚至窗口函数都写得像模像样。但数据分析师不能把 SQL 责任交给模型。表关系、口径、分区、权限、性能这些都需要人确认。我把 AI 生成 SQL 当成“起草工具”不是“自动取数工具”。它能帮你减少重复劳动但不能替你理解业务。一、先给模型语义层不要只给自然语言如果模型不知道表结构和指标口径就只能凭字段名猜。生成出来的 SQL 可能语法对业务错。更好的方式是提供受控的数据字典和指标定义。flowchart TD A[用户问题] -- B[读取数据字典] B -- C[读取指标口径] C -- D[生成 SQL 草稿] D -- E[规则校验] E -- F[人工确认执行]AI 生成 SQL 的关键不是模型多聪明而是上下文是否可靠。为什么自然语言直接转 SQL 是数据分析的伪需求很多 AI SQL 产品的 demo 都让你相信用户说一句帮我查上周的 GMV模型就能吐出正确 SQL。但在真实数据仓库里GMV至少有三种口径下单金额、支付金额、确认收货金额上周在不同时区也是不同的时间段。没有数据字典和指标口径约束模型只能猜——猜对了是运气猜错了就是分析事故。更危险的是模型的 SQL 语法几乎总是正确的但业务含义可能完全偏离——它会自信地输出一段完美符合 SQL 规范的查询但是基于错误的假设GMV 应该就是 orders 表的 amount 求和吧。语法正确 业务错误 最隐蔽的炸弹。二、SQL 草稿要先过规则校验执行前至少校验是否带分区、是否扫描大表、是否使用禁止字段、是否存在笛卡尔积风险、是否有权限。def validate_sql(sql: str) - list[str]: errors [] lower sql.lower() if where not in lower or dt not in lower: errors.append(缺少分区过滤) if select * in lower: errors.append(禁止 select *) if cross join in lower: errors.append(存在 cross join 风险) return errors这只是非常简化的示例生产环境应使用 SQL parser而不是靠字符串判断。但即使是基础规则也比直接执行安全得多。为什么规则校验必须用 SQL Parser 而不是正则上面的示例用if where not in lower来检测分区但如果 SQL 里有一个注释-- 这里本来有 where正则就会误判。如果表名恰好包含 cross join 字样虽然不常见也会误报。SQL 的结构是上下文无关文法正则只匹配字符串模式。生产环境至少应该用 sqlparsePython、ANTLRJava或 Presto parser 这类工具把 SQL 解析成 AST抽象语法树再去检查WHERE 子句里有没有分区字段而不是字符串里有没有 where。规则校验离业务越近用正则越容易漏判和误判。三、结果解释要和 SQL 一起展示AI 不应该只返回 SQL还应解释它使用了哪些表、哪些过滤条件、指标怎么算。分析师看得懂才敢执行。{ sql: SELECT channel, COUNT(DISTINCT user_id) ..., used_tables: [dwd_user_visit_di, dwd_order_pay_di], metric_explanation: 支付转化率 支付用户数 / 访问用户数, warnings: [已限制 dt 分区, 未包含退款口径] }特别是 warnings要放在显眼位置。模型知道自己没有处理退款口径就应该提醒而不是藏起来。四、执行权限要留在人手里AI 可以生成系统可以校验但执行按钮应该由有权限的人点击。高风险 SQL 还可以走审批比如扫描超大表、导出明细、访问敏感字段。执行后也要记录谁发起、模型生成版本、最终 SQL、扫描行数、结果行数。这样出了问题能追溯。还要让 AI 学会拒绝。用户问“帮我导出所有用户手机号”模型不应该努力写 SQL而应该提示权限不足和合规风险。生成 SQL 的能力越强拒绝边界越要硬。sql_generation_guardrails: deny_columns: [phone, id_card, address] require_partition: true max_scan_rows: 10000000 require_approval_for_export: true这些规则不应该只放在 Prompt 里而要由确定性校验执行。模型负责起草规则负责守门。为什么 Prompt 里的规则不可靠必须用代码兜底Prompt 是建议性的——你可以在 System Prompt 里写禁止扫描超过 1000 万行但模型可能因为上下文超长或指令冲突而忽略。确定性代码不受模型注意力影响它 100% 执行。更关键的是哪天你换了模型从 GPT-4 切到 Claude 或 DeepSeekPrompt 的格式可能需要调整但确定性校验代码不变。信任模型的能力不信任模型的纪律——让它生成 SQL但别让它决定能不能跑。踩坑提醒坑1模型生成的 SQL 语法正确但用了错误的表— 比如用户问用户支付金额模型 JOIN 了fact_order和dim_user但实际支付金额在fact_payment表里。表级依赖关系必须在数据字典里明确不是靠字段名匹配。坑2Warnings 提示太多导致用户忽略— 如果每次生成都提示可能未考虑退款口径久而久之用户就无视了。Warnings 应该按风险等级分层必读红色、建议阅读黄色、信息灰色。坑3AI 对性能优化没有概念— 模型可能写出一条SQL 语法正确但扫了 1 亿行的查询因为它不知道哪些表大、哪些表有索引。必须在规则校验中加入max_scan_rows和分区约束。五、总结AI 生成 SQL 能提升效率但不能替分析师负责。可靠的数据字典、指标口径、规则校验、解释说明和人工确认是它进入生产取数流程的底线。SQL 写得漂亮不代表分析正确。模型可以起草责任仍然要回到人和系统规则上。