AI把查询写快了却没有替我们回答这个数字究竟能不能拿去做决策周一上午业务负责人发来一个问题“为什么上周新客收入下降了”如果放在以前数据分析师会先确认“新客”的定义再核对退款是否回冲、渠道归因按注册还是首购、收入看支付金额还是净收入。等口径对齐才开始写 SQL。现在很多人的第一反应变成了把问题交给 AI。几分钟后一段结构清楚的 SQL 出来了表关联正确、窗口函数漂亮、注释也很完整。结果跑出来新客收入确实下降了 12%。问题看上去已经解决。直到有人问“退款算了吗”没有。更麻烦的是这段 SQL 把“注册用户首次付费”写成了“统计周期内首次下单”把历史上买过、这周重新下单的老用户也算进了新客。代码没有报错数据也不离谱但结论是错的。这是我认为 AI 编程进入数据团队后最值得警惕的一类错误它不像语法错误那样显眼也不像任务失败那样会报警。它能顺利执行能生成图表甚至能让一套错误口径显得非常专业。作为长期和 SQL、指标口径、数据质量打交道的人我并不抗拒 AI。相反它已经成为很难放弃的效率工具。真正让我不安的不是 AI 会写 SQL而是团队可能因为它写得太快跳过了那些过去不得不认真讨论的事情。数据团队正在加速这不是想象dbt Labs 发布的《2026 State of Analytics Engineering Report》给出了一个很有代表性的信号72% 的受访者把 AI 辅助编码列为开发流程的优先事项。在管理者中超过 77% 强调通过 AI 提升生产力。这和现实体验一致。SQL、Python、YAML、测试和文档都是大模型非常擅长处理的文本结构。以前需要半小时搭好的查询骨架现在几分钟就能完成陌生仓库里的一段转换逻辑也可以先让 AI 解释数据血缘再决定从哪里修改。但同一份报告里还有一个更值得关注的数字只有 24% 的受访者优先推进 AI 辅助的管道管理包括测试、可观测性和质量控制。换句话说团队正在快速投资“生产更多数据代码”却没有用同样的速度投资“证明这些代码可信”。这种不平衡已经反映在担忧上。报告显示71% 的受访者担心幻觉或错误数据到达业务使用者41% 仍把数据所有权不清视为持续存在的问题。与此同时57% 的团队报告数据仓库和计算支出增加而团队预算增长的比例只有 36%。从数据人的角度看这几组数字连在一起非常有意思AI 让产出速度提高计算消耗和结果数量随之增加但质量责任、成本治理和数据所有权没有自动补齐。所以真正的问题不是“AI 能不能帮助数据团队”而是我们能不能在加速的同时保住对结果的解释权。AI最容易写对SQL最难写对口径数据工作和普通应用开发有一个明显区别很多错误不会导致程序崩溃只会让数字悄悄偏一点。例如计算月活用户按登录、访问核心页面还是完成关键行为结果都可以叫“月活”计算收入可以看支付额、确认收入或扣除退款后的净收入计算留存可以按自然日、24 小时窗口或首个完整周期。这些差异不是 SQL 技巧问题而是业务契约问题。AI 可以根据字段名猜测refund_amount应该被扣除却不知道财务口径要求退款在审核通过日回冲还是在原订单日重算。它可以看到user_id却不知道游客转注册后需要做身份合并。它能从代码仓库推断大部分规则但只要最关键的一条规则藏在会议纪要或某位老同事脑中结果就可能从根上偏掉。这也是为什么我不赞成用“AI 生成了多少 SQL”衡量效率。SQL 行数本来就不是数据价值生成速度更不是。一个查询真正的成本至少包括四部分写代码的时间、确认口径的时间、验证结果的时间以及错误结论被业务采用后的返工成本。AI 主要压缩的是第一部分。如果前三项没有被记录我们很容易得到一个虚假的效率故事。Stack Overflow 2025 年开发者调查也提供了类似的信任信号46% 的开发者主动不信任 AI 工具的准确性信任者为 33%高度信任者只有 3%。这并不意味着工具没有价值而是说明“使用率上升”和“结果可信”是两个不同指标。数据团队尤其应该记住这一点因为我们的代码最终会变成经营看板、实验结论、预算分配和绩效判断。普通 Bug 可能影响一个功能错误指标可能影响整个组织的判断。我们做AI数据开发试点时应该测什么如果让我设计一个两周的 AI 数据开发试点我不会先统计 token也不会比较谁写 SQL 更快。我会先选择 15 到 20 个边界清楚、能够复盘的真实任务例如新增一个渠道报表、修复一条数据质量规则、为历史模型补测试、整理一段数据血缘文档。然后把任务随机分成两组一组允许使用 AI另一组沿用现有流程。样本不大无法得出行业结论但足以发现团队内部的问题。每个任务至少记录五个指标。第一首次可运行时间。它衡量 AI 是否真的缩短了从需求到初稿的周期。第二首次可信时间。这里不是 SQL 跑通而是口径确认、结果抽样和质量检查全部完成。对数据团队来说这个指标比首次运行更重要。第三人工修改比例。把 AI 生成的代码与最终合并版本比较记录业务逻辑、性能和可维护性修改而不是只看格式调整。第四评审往返次数。若代码生成快了但评审者需要反复解释口径效率只是从作者转移到了审查者。第五发布后七天内的问题数包括数据告警、业务质疑、回滚和临时修数。这套方法的关键不是追求严谨的学术实验而是避免只挑成功案例。AI 演示最容易展示“十分钟写完一个模型”却很少展示第二天数据负责人花了多久验证它。一个可以直接复制的实践先写指标契约再让AI写SQL我们可以把需求从一句自然语言改造成一份简短的指标契约。它不需要复杂系统一段结构化文本就够了。例如计算“新客净收入”至少写清统计对象是首次完成支付的用户游客与注册账号需要合并收入按支付成功日归属退款在审核完成日冲减测试订单排除时区使用 Asia/Shanghai结果需要与财务日报在 0.5% 误差内一致。然后再让 AI 完成三件事生成查询、列出它做出的假设、生成边界测试。第三步必须由人完成选择一天的数据做分层抽样。分别检查正常订单、退款订单、跨天支付、身份合并和重复回调。不要只看总数是否接近因为两个错误可能互相抵消让总数“碰巧正确”。最后把验证通过的口径、SQL、测试和负责人一起进入版本管理。以后业务规则变化修改的是一份可追踪的契约而不是重新问 AI 一个相似问题。这套流程看起来比“直接生成 SQL”慢一点但它把最宝贵的东西留下来了口径为什么这样定义、谁确认过、如何证明它仍然正确。数据人员的价值会从写查询转向守住可信度我能理解数据从业者的焦虑。过去我们依靠熟练写 SQL、理解数仓和制作报表证明价值现在业务人员也可以直接让 AI 查询数据很多基础分析似乎不再需要专门角色。但如果回到实际工作会发现真正稀缺的能力从来不是把字段拼起来。业务提出的问题是否可以被数据回答指标定义是否稳定多个系统里的身份如何统一一次异常增长是业务变化、埋点变化还是数据延迟实验结果是否受到样本偏差影响当两个部门拿出不同数字时谁能解释差异并推动形成共同口径这些事情不会因为 AI 会写 SQL 而消失。相反当更多人可以低成本生成查询和洞察组织里会出现更多版本的“事实”数据人员维护一致性和可信度的价值会更高。dbt Labs 的报告显示受访者对数据及数据团队信任的重视程度从上一年的 66% 上升到 83%对速度的重视从 50% 上升到 71%。这说明企业同时想要更快和更可信。问题是速度可以由模型迅速放大信任却只能通过定义、验证、所有权和长期稳定的流程慢慢积累。写在最后AI 编程进入数据团队不应该被理解成“以后不用写 SQL 了”。更准确的说法是写出一段能运行的 SQL 正在变得廉价而证明它代表正确业务事实正在变得昂贵。我们当然应该使用 AI。让它生成骨架、解释遗留模型、补文档、提出测试场景、检查潜在性能问题。把机械劳动交出去没有什么可羞耻的。但有三件事不能一起交出去指标口径的决定权、结果可信度的验证权以及数据出错后的责任。作为数据人员我们不必和 AI 比谁写查询更快。我们真正需要证明的是当组织面对一堆看起来都正确的数字时我们能让它知道哪一个值得相信以及为什么。这才是 AI 时代数据团队最硬的竞争力。
