我构造了一个最小实验。同一批 20 笔已支付订单，来自 10 名用户，其中 5 笔售后已完结，3 笔退款通过。三条合法查询给出三个答案——按订单计算是 3/20，也就是 15%；按用户去重是 3/10，也就是 30%；只看已完结售后则是 3/5，也就是 60%。每道算术都对，却在回答不同问题。这是为验证口径而搭建的构造数据，不是线上业务数据，也不是模型厂商基准。
同一批记录，分母一换，统计问题随之改变。
统计对象决定比例含义
第一条查询统计的是“已支付订单中，有多少笔退款通过”；第二条先按用户去重，统计“已支付用户中，有多少人至少有一笔退款通过”；第三条把观察范围缩到售后已经完结的订单，统计“已完结售后中，有多少笔通过退款”。
它们都可以叫“退款率”，SQL 也都能运行。问题在于，名称相同并不代表统计对象相同。若需求只写“计算退款率”，AI 很容易从字段可得性出发，挑一张最顺手的表，顺便过滤空值，再加一个 COUNT(DISTINCT user_id) 消除重复。每一步看似合理，组合起来却可能把订单问题改成用户问题，把全部订单改成已产生结果的订单。
这正是 AI 统计分析更隐蔽的风险。它未必会把除法算错，却可能把“字段方便取”当成“业务定义成立”。百分比仍然工整，图表仍然平滑，真正被替换的是结论所描述的人口。
审核顺序应从人口开始
审查这类查询时，先不要盯小数点，也不要先讨论聚合函数。第一步应当确认谁有资格进入分母。在这个实验里，20 笔已支付订单、10 名已支付用户和 5 笔已完结售后，是三个不同的人口。只有先确定对象，3 这个分子才有可解释的意义。
同样的要求也适用于时间和去重。统计对象不仅要写“订单”或“用户”，还要固定观察起止时间、允许排除的记录以及去重键。否则两次查询即使沿用同一个指标名，也可能因为过滤条件或去重方式改变而失去可比性。
先审人口，再审公式；字段方便取，不等于业务定义成立。 公式正确只能证明计算过程没有出错，不能证明它回答了原来的业务问题。
用指标契约固定统计问题
让 AI 写 SQL 之前，先给指标附上一份简短契约，明确统计对象、观察时间、排除规则和去重键。这里的定义必须落到业务语义，不能只留下“退款率”三个字让模型自行补齐。
SQL 生成后，要求结果同时展示分子、分母和比例。单独一个 15% 很难暴露口径变化，3 / 20 则会迫使审核者确认 20 代表什么。每加一道过滤条件，还应同时输出过滤前后的记录数；人数突然下降时，必须解释被排除的是谁，而不能让筛选静默发生。
最后保存一枚“口径指纹”，记录来源表版本、时间范围、过滤条件和去重键。后续重跑先比较指纹；只要指纹发生变化，新旧百分比就不应被直接连成趋势。需要升级口径时，也应明确标记定义变更，而不是把它伪装成业务改善。
先固定业务定义，再让百分比进入比较。
AI 可以很快写出一个能跑的查询，但“能跑”只说明语法成立。判断结论是否可信，仍要回到最朴素的问题：它究竟在数谁？
作者｜随机比特
