当AI编程席卷前后端开发时，数据部门却成为最后的'手工作坊'。本文作者通过实战验证AI生成SQL指标的可行性，从Claude的代码生成到元数据陷阱破解，揭示数据基建与AI协作的深层逻辑。这场技术突围不仅关乎效率提升，更在倒逼企业数据治理体系升级。

从今年1月份开始，笔者所在公司的前、后端开发们全都开启了 AI coding（通过 AI 辅助编写代码）的工作模式。除了外采供应系统的改造开发外，其他端通过 AI 编写代码的覆盖率最高甚至达到了 80% 以上。可笔者所在的数据部门，几乎所有的数仓依然“不忘初心”——通过手搓代码的方式去建表、开发指标。后来和他们交流，都清一色的回复：“等我跟 AI 讲清楚的时间，我自己早都写好了”。

一开始笔者也和大多数数仓伙伴一样，认为 AI 还替代不了数据相关的岗位，还沾沾自喜不会有裁员的风险。当每隔几周 AI 界就会出现爆炸性的突破时，笔者突然意识到如果还拿防御性的态度对待 AI 时，那将失去和 AI 产生其他可能性的机会。今天笔者就从术与道两个维度，结合指标 AI 生产的实践聊聊自己的想法，也欢迎大家在下方留言讨论。

忘掉自己的岗位属性，不确定的让 AI 来辅助你

“如果我先把这条路跑通呢？”这是笔者当时的想法，因为数据产品本身就要求了解 SQL（一种用于操作、管理关系数据库的语言），天然对数据开发有更多的了解，于是笔者决定自己上手去干。

起初笔者想在网络上找一些关于指标 AI 开发的成功经验，但几乎找不到一个可以复用的例子去模仿。后来想到 w 老师的一句话：“如果数据分析没有思路，那就先假设一个结论，按这个方向去分析”，笔者索性假定 AI 大模型能够执行这个任务，就问了大模型如下这句话：

我是想通过你帮我生成计算指标的 SQL ，我需要给你提供哪些必要信息？

经过一轮的调整对话后，豆包、Claude 分别给笔者输出了各自的方案（部分截图如下），因为 Claude 方案简洁，我优先选定了 Claude 的方案去试验。

理解 AI，给概率性思维设置目标与边界

确认了方案选型后，笔者没有立即启动，因为 AI 开发本质是对语义的理解，理解的不同就会出现各种概率性的执行方式。

这种机制对系统开发可能不会带了极端影响，系统功能解决的是用户需求，解决需求的结果也是多种多样（比如，用户登录可以邮箱、手机登录，也可以第三方或自己的域账号登录，最终结果是让用户可以访问系统）。可数据指标开发最终对应的是具体数值，且只有唯一准确的数值。所以笔者在试验方案时，选择以开发过的口径复杂的指标为切入点，最终将两段 SQL 执行的结果进行对比，验证生成代码的准确性。

在方案执行前，笔者准备了两类文档，一类是指标字典（包含指标计算口径及其计算因子对应表、字段的血缘关系），另一类是元数据信息（包含字段名称、字段说明等）和数据样本，如下图所示（数据样本略）。

第一次让 Claude 生成时，SQL 中的 where 条件多了三个笔者没有在指标字典中声明的内容。后来笔者在排查中发现了问题，因为元数据文档我直接照搬了数仓伙伴的注释，而这三个正好是唯一进行“值说明”的字段（如上图红框部分），就影响了 AI 的注意力权重。于是在调整提示词后，笔者得到了最终的代码。

AI 的价值不是替代人，而是解放人去创造价值

在最后执行两段 SQL 代码，AI 生成与数仓手搓的结果存在小数位的偏差。把两段代码提供给 Claude ，它快速定位到了不同点：数仓手搓的是按 SKU 单独算天数再取整，而 AI 生成的是先汇总所有金额再统一算天数。后来在和数仓伙伴老川对数据二次计算校验后，确认 AI 生成的计算逻辑更准确。首战告捷，笔者非常开心，结合遇到的问题，整理出最终基于大模型的 SQL 代码自动化生成方案（如下图，已在笔者部门内应用）。

温馨提示：因为每次执行都是概率性，所以一次有效的执行动作一定要保存下来。如果经常使用可以把上述过程生成 skills，这样以后任何时候对话，只要输入“/技能名称”就能调用。也可以把整个执行过程生成个文件，当下次对话时可以让 AI 访问这个文件，了解上次的成功经验。

我们再回过头来看看整个指标 AI 生产的过程，花费时间、精力最多的就是指标字典、元数据、表&字段血缘等信息的准备上，对于数仓来说确实是和 AI 对话的时间早都可以把 SQL 写完了。但这不是一锤子的买卖，这个过程既反向要求数据部门做好数据基建（规范的数仓表架构、指标字典、元数据等），又能够在其他数据应用上提供基础（比如自助分析，下篇会介绍），是一个边际成本递减、效率不断凸显的过程。

让我们成为在混乱中保持乐观并推动事情发生的人吧~