不是工程师也能用 AI 写 SQL

AI 对需要从数据库拉数据的非工程师真的有变革性。PM、营销、ops、分析师,过去等工程师写 query 等几小时或几天,现在能自助。陷阱:AI 生的 SQL 错得够频繁,瞎信任会产出自信但错误的数字。错数字驱动错决策比没数据糟。

AI 对 SQL 做得好的

知道你特定 schema 的怪癖(active customers 表是哪个 — 是 customers 加 deleted_at IS NULL、还是 active_customers view?)
区分长得很像的 column(created_at vs created_at_local、revenue vs gross_revenue)
抓到两个 column 可以 JOIN 但不该(资料型别像 foreign key 但没实际关系)
知道你软删除惯例、分区规则、商业过滤要求
效能优化 — 取决于 index 跟你没告诉它的资料量

步骤一:喂 AI 你的 schema。 不要不给 context 问 SQL。给 Claude 或 GPT 你的 schema(表名、字段名、类型、每张表代表什么的简述)。几百张表的数据库,给问题相关的子集。

有用的招:先要 AI 摘要 schema。「根据这个 DDL,用 2 段摘要资料模型,标出任何看起来不寻常的。」AI 摘要错,你后续 query 就错。

步骤二:用自然语言加 context 问。 「从 orders 表 JOIN customers,给我 2025 Q3 总花费 top 10 客户,排除退款订单。花费格式化为 USD 货币。」

Context 越多 = query 越准。提到:时间范围、商业过滤(「排除测试帐号」)、输出格式要求、你在意的 edge case。

步骤三:跑之前读 query。 如果你不懂逐行,要 AI 解释。「用白话走过这个 query、每个子句做什么为什么。」有东西不符合你预期,改 prompt 重生。

步骤四:先在 sample 上跑。 加 LIMIT 100(或 WHERE date > '2025-12-01')在小切片上测试。结果合理,再扩到完整日期。

步骤五:健康检查输出。 count 符合你对商业量的预期吗?Top-N 结果有你认得的名字吗?有没 NULL 或 0 在预期外的地方?相信你的商业直觉;一个数字感觉太高或太低,挖为什么。

所有这些的修法:读 query、在 sample 上跑、健康检查。

你反复查的任何数据库,建一个 markdown 档含:

每次问 AI 那个数据库的 SQL 时把这档当 context 贴。准确度改善剧烈。

随手 one-off query,ChatGPT 或 Claude 加 schema context 够。反复工作,知道你 schema 的整合工具快得多。

影响 production 的 query。 任何写(INSERT、UPDATE、DELETE)或影响 production 性能的。让工程师审。

合规相关资料。 拉 PII、要稽核的金融资料、或任何受监管的 query。query 跟输出需要稽核轨迹;AI 生成不太对得上。

对性能敏感的 query。 Query 会跑在百万行或 hot path,需要 AI 没有的 index 意识。让工程师优化。

关键报告数字。 给高层看或用来付佣金的数字需要三重检查。AI 生 query 给初稿 OK;验证没得商量。

危险不是一次拿到错 SQL — 那很快被抓。危险是反复拿到细微错的 SQL,产出没人质疑、看似合理的数字。「客户 churn 上季 4.3%」感觉精准。Query 数错了,数字是虚构,但会被重复几个月。

培养习惯:任何驱动决策的数字都用对同一问题从不同角度跑、或问熟数据的人来验证。「这看起来对吗?」问分析师朋友 30 秒,防几个月错方向决策。