夜雨聆风一、两层翻译，AI 接住了第二层
分析师取数这件事，本质上是两层翻译：把业务问题翻译成数据口径，再把数据口径翻译成 SQL 代码。第一层，分析师最擅长——你知道要看哪个指标、拆哪个维度、和哪段时间比。第二层，过去必须靠开发——你得把口径写成需求文档，排进迭代，等开发有空了帮你出数。
现在 AI 把第二层接过去了。
最近我们帮某日企知名母婴品牌做了一次 Data Review 取数，涉及 4 张报表、跨 6 张源表、多年份对比、渠道流转分析。分析师写好口径定义，AI 直接生成完整 SQL，全程没有让开发写一行代码，几轮对话下来就完成了交付。
这不是"AI 替代开发"，而是"分析师有了一个随时在线、秒级响应的虚拟数据开发"。
二、取数 2.0 的四个关键环节
定义层：口径写进文档，AI 直接读懂
分析师最大的优势是懂业务问题——你知道"复购率"要按首次购买品类拆分、知道"渠道流转"要区分同渠道复购和跨渠道跳转。你的瓶颈是不懂 SQL 语法。
以前这个瓶颈卡死人。现在不一样了：只要把口径写清楚，AI 就能直接出活。
以这次项目为例。时间窗口怎么定义——全量累计（LTD）、当年截至上月（YTAPR）、逐年对比（2018-2025）。品类怎么分——纸尿裤/拉拉裤归入纸品，湿巾/棉柔巾归入洗护，奶瓶/吸奶器归入喂养，推车/安全座椅归入出行。渠道怎么映射——天猫对应线上 TMALL，京东对应 JD POP&RETAIL，抖音对应 DOUYIN。配件怎么识别——替换装/辅件类商品单独标记。
这些定义写进 spec 文档，AI 自动转化为 SQL 中的公共临时表、CASE WHEN 映射、WHERE 过滤条件。定义越精确，AI 出的代码越不需要改。 模糊的定义才需要反复猜。
生成层：从 spec 到 SQL 的结构化转化
AI 出活不是"一口气从头写到尾"。它是有章法的：
公共临时表（注册与购买的合并、品类标记、前后件关联） ├── 报表一：用户规模变迁 │ ├── 总览（拥有者/购买者/商品数） │ ├── 分品类（纸品/洗护/喂养） │ └── 分新老客（新客/复购间隔<1年~>10年） ├── 报表二：复购与留存 │ ├── 表一：品牌级复购路径 │ ├── 表二：品类级复购矩阵 │ └── 表三：配件影响力 └── 报表三：渠道流转 └── 表一：消费者渠道偏好每一层是一个 CTE（公共表达式），输入和输出都清晰可查。分析师不需要看懂全部 SQL，但可以按 CTE 逐个核对中间结果——这个日期范围的用户数对不对？这个品类的商品数是不是和预期一致？
这相当于把一条"黑盒 SQL"变成了"白盒数据流水线"。
验证层：数据不自洽？AI 有"指标框架意识"
这是效率差异最大的环节。
传统模式下，数据开发拿到需求，关注的是单条 SQL 能不能跑通、语法有没有报错。至于数字合不合理、指标之间能不能互相印证——往往不在关注范围内。结果就是报表出来后，总人数不等于各品类之和，新客加老客不等于总拥有者，排查起来要翻几百行代码，半天就过去了。
AI 不一样。AI 在生成 SQL 时就理解指标间的勾稽关系：
• 总览的"拥有者/购买者人数" = 新客人数 + 老客人数 • 各品类的"新客人数"加起来应该等于全品类新客人数 • 渠道流转表中，新客 + 同渠道复购 + 跨渠道复购 = 该渠道总人数
一旦实际跑出来的数字不自洽，AI 能快速追溯到具体的 CTE 和 WHERE 条件，把口径差异直接亮出来。
某日企母婴品牌的案例中，报表二同时出现三个问题：新客加老客不等于总览、老客人数偏小、新客人数偏大。看起来是三个 bug，分析人员可能分别排查三个方向，半天无果。
AI 的排查路径是：三个症状指向同一个数据源——用户维度的"周期内首条事件"表。问题出在：一个人在同一天可能既注册又购买，按日期 JOIN 会产生重复行。一行修复，三个症状全部消失。
还有一次，报表三的总量和报表一的总量对不上。AI 追溯两个模块的 CTE，发现报表三的渠道流转表过滤掉了"配件"类事件，而报表一没有。口径差异一行代码就定位到了。
本质差异： 数据开发排查是"逐行对代码"，AI 排查是"对指标框架做差分"。前者靠经验和运气，后者靠对定义的一致性理解。效率差距不在同一个数量级。
迭代层：需求变更不再伤筋动骨
传统流程怕需求变更——改一个口径要走完整的"提需求→排期→开发→交付"循环，一个来回就是几天。
AI 协作下，变更是对话级的。
某日企母婴品牌这个项目，前后经历了至少四轮调整：
• 报表三中"配件"的复购分类，从独立一组调整为归入"无复购" • 报表三的渠道流转，全量统计口径从"每年首件"改为"以最后一件为基准看渠道变迁" • 渠道流转先排除了配件事件，后来发现与报表一口径不一致，又加了回来 • 每次变更后，定义文档同步更新
每一轮都是分析师说一句话，AI 精准定位到需要改的 CTE，改完不影响其他模块。没有重写，没有引入新 bug。
这才是迭代该有的速度。
三、什么场景做得好，什么场景仍需开发
不是所有取数都适合让分析师直接和 AI 协作。到目前为止，做得最好的场景是：
• 结构化报表取数 — 指标定义清晰、时间窗口明确、维度和分组提前确定 • 多表关联的常规分析 — 有现成的源表和口径文档可参考 • 数据一致性核查和口径排查 — AI 的"指标框架意识"恰恰是竞争力
以下场景仍然需要数据开发主导：
• 实时或准实时的数据 pipeline — 涉及调度、增量、异常处理 • 底层数仓建模 — 新表的 ETL 设计、分区策略、性能优化 • 全新的、未经定义的口径探索 — 业务方自己还没想清楚要什么
四、分析师该做什么：写好需求定义，就是学会了和 AI 协作的语言
最终，分析师能不能用好 AI，关键不在于懂不懂 SQL，而在于能不能把"自己想看什么"讲清楚。
三件事值得投入：
1. 把口径写下来，而不是靠嘴说。 时间窗口、品类分类、过滤条件、去重逻辑——越具体越好。一份好的 spec 文档就是 AI 的"需求文档"。 2. 学会看中间结果。 AI 把 SQL 拆成多个 CTE，你可以逐个验证——这个数对不对？那个维度缺不缺？不需要看懂全部代码，但要知道怎么抽查。 3. 有意识地追问数据自洽性。 拿到结果后问 AI："这几个数加起来等于那个数吗？""不同报表的同一指标口径一致吗？"这是你最该利用 AI 的地方。
当分析师不再卡在"谁来帮我写 SQL"这一步，真正释放的是对业务问题的思考时间。这才是取数 2.0 的意义。