AI 写 SQL 最危险的时刻，不是它写错了语法，而是它写出一条看起来很合理、能执行、却悄悄改变口径或扫过整张大表的查询。把“帮我统计一下”丢给模型，往往没有说明时间范围、去重规则、表之间的真实关系，更没有说明生产库能否执行写操作。
AI 适合帮助解释表结构、起草查询、发现遗漏的条件与生成测试用例；它不应获得生产库的自由写权限，也不应替业务负责人定义指标。下面是一套针对分析查询和报表需求的轻量流程，可使用 ChatGPT 或 Claude 完成设计与审查。
先给 AI 一份最小数据合同
不要整库导出 schema。为这次任务提供最小的只读上下文：相关表与字段、主键和关联键、字段含义、时区、数据延迟、允许的时间范围，以及已知的空值和重复规则。任何真实姓名、邮箱、电话、token、连接串和完整客户记录都不需要进入提示词。
还要写清楚输出的业务定义。例如“活跃客户”是过去 30 天登录过、过去 30 天付费过，还是本月有完成订单？“订单数”是支付成功数还是创建数？这些定义不是 SQL 技巧，不能交给模型猜。
先让 AI 提问，再让它写查询
一个好流程会要求模型列出无法判断的条件，而不是立即给出代码。常见待确认项包括：日期用 UTC 还是业务时区；取消订单是否排除；退款如何处理；用户跨设备是否去重；是否需要包含测试账户；一对多关联会不会把金额乘倍。
你是数据分析助手。根据以下最小 schema 和指标定义，先不要写 SQL。列出为得到正确结果必须确认的口径、关联风险、数据质量风险和性能风险。把问题按“阻止执行”“建议确认”“可忽略”分类。不得假设未提供的字段或表，不得要求原始个人数据。
确认问题后，再要求输出两份内容：查询草案和解释清单。解释清单应说明每个 CTE 或子查询在做什么、去重发生在哪里、过滤条件为何存在、哪些假设来自业务定义。
默认只读、限范围、先看样本
所有由 AI 起草的查询应先在只读副本、开发环境或受限制的分析仓库运行。默认禁止 INSERT、UPDATE、DELETE、MERGE、DROP、ALTER 和无条件的脚本执行。即使只是 SELECT，也要限定日期范围、返回列和行数，并用 EXPLAIN 或查询计划检查是否会全表扫描。
先看 20 到 100 行样本和聚合后的中间结果，再跑最终汇总。若结果异常，不要立刻让 AI “修一下 SQL”；先比对样本中的主键、关联次数和原始事件，弄清是数据问题还是口径问题。
基于以下已确认的指标定义，生成只读 SQL 草案。要求：只使用给出的表和字段；显式限定日期范围；将去重逻辑放在单独的 CTE；禁止任何写操作与 SELECT *；先给出一个返回不超过 100 行的抽样验证查询，再给出汇总查询。随后逐条解释关联、过滤、时区和潜在重复计数风险。
最常见的三个“结果对不上”原因
- 一对多连接：客户连接订单、订单又连接明细后，金额或人数被重复计算。先在粒度最细的表聚合，再连接。
- 日期边界：BETWEEN、时区转换和月末 23:59:59 很容易漏数据。优先使用半开区间，例如大于等于开始、小于下个周期开始。
- 状态口径：created、paid、fulfilled、refunded 是不同状态。把状态列表写进查询旁的说明，而不是只留下一个神秘 WHERE。
AI 可以列出这些风险，但只有业务负责人知道本次报表的正确口径。把最终确认写进查询注释或数据字典，下次同类需求才不会从头争论。
发布报表前的核对清单
- 指标定义、时间范围、时区和状态是否写明？
- 查询是否只读，并在受控环境测试？
- 每个 join 后的预期粒度是否可解释？
- 是否抽样核对过主键、金额和事件数？
- 是否排除了测试数据或明确说明未排除？
- 是否保存了 SQL 版本、运行时间和数据延迟说明？
AI 能让分析师更快从自然语言走到可审查的 SQL，但它不能代替数据定义、权限边界和结果验证。给它最小 schema、让它先提问、用只读样本验证，再发布结果，才能把速度变成可靠性。