1. 从写SQL到审SQL数据开发岗的真实一天被切成了两半三年前我每天的工作节奏是这样的早上到工位第一件事是打开IDE把昨天跑失败的调度任务捞出来看日志然后开始写当天的ETL脚本。一个中等复杂度的宽表从梳理业务口径、设计分层、写DDL、写加工逻辑、跑测试、对数据、提交上线顺利的话大半天就没了。那时候衡量一个数据开发靠不靠谱很大程度看他写SQL的手速和调优的直觉。现在情况变了。我所在的团队从去年开始把数仓开发链路里的相当一部分环节交给了AI Agent来处理——不是那种帮你补全一行SQL的插件而是能读懂元数据、能理解表血缘、能自己生成建模方案并落地成可执行脚本的智能体。我的一天被彻底重构了上午主要在审AI产出的东西下午在做AI暂时做不了的判断和沟通。这个转变比我想象中来得快也比我想象中更需要重新学习。这篇文章我想把AI接管数仓开发之后一个数据开发的一天到底变成什么样这件事讲透。不是泛泛谈趋势而是把每个环节里AI做了什么、人做了什么、边界在哪里、坑在哪里一条条拆开说。如果你正在做数仓、正在接触Agent类工具、或者正在犹豫要不要把AI引入自己的开发流程这篇应该能给你一些真实的参考。核心关键词就几个数仓、Agent、SQL、元数据、AI我会围绕它们把一天的完整工作流串起来。先说结论性的判断AI接管的是从需求到初版SQL这段最耗时的体力活以及从报错到定位这段最烦人的排查活人接管的是口径确认、模型取舍、质量兜底和跨团队对齐。两者不是替代关系而是把数据开发的时间结构重新分配了。2. 上午九点到十一点Agent读元数据生成建模方案我做的是挑刺2.1 Agent到底是怎么看懂数仓的很多人以为AI写SQL就是拿个大模型直接生成文本这是最大的误解。真正能用在数仓开发里的Agent第一步一定是接元数据。元数据在这里指的是描述数据的数据——表的字段名、字段类型、注释、分区信息、表之间的血缘关系、上下游依赖、更新频率、数据量级。没有这些AI生成的SQL就是空中楼阁字段名全靠猜。我参与的这套Agent的工作方式是它先通过元数据服务拉取目标表的完整schema和血缘链路然后结合我输入的业务需求描述比如要一张按天粒度的用户下单宽表包含用户基础属性、订单汇总、最近一次下单时间去匹配已有的相似表和历史建模模式最后生成一套包含ODS到DWD到DWS的分层方案和对应的建表、加工SQL。这里有个关键点元数据的质量直接决定Agent的产出质量。我们团队之前元数据管理比较随意很多表字段没有注释血缘靠人工维护还经常断。Agent上线初期生成的SQL经常引用错字段或者把不相关的表关联进来。后来我们花了大概两周时间专门补全核心表的字段注释和血缘关系Agent的准确率肉眼可见地提升了。这件事让我意识到AI接管数仓的前提是元数据要先喂饱。2.2 我审Agent方案时重点看什么Agent在十分钟内能给我一份完整的建模方案包含表结构设计、字段映射、加工逻辑、甚至分区策略建议。但这份方案我从来不会直接采纳审的时候有几个固定动作第一看粒度。Agent有时候会把不同粒度的数据混在一张表里比如把订单明细和用户日汇总放在同一层这在数仓建模里是大忌。粒度错了后面所有的聚合都会出问题。第二看口径。这是最花时间的。比如活跃用户这个指标Agent可能默认按登录算但我们业务方的定义是有下单或浏览行为。口径这种东西元数据里往往没有必须人来确认。我一般会把Agent生成的指标定义单独拉出来和业务方过一遍。第三看血缘完整性。Agent生成的加工SQL引用的上游表我会检查是否都在血缘链路里有没有引用到已经下线的表或者临时表。这个用工具能自动查但最终判断还得靠人。第四看性能和成本。Agent生成的SQL逻辑上通常没问题但可能写出全表扫描或者笛卡尔积这种在生产环境会炸的写法。我会重点看join条件和分区过滤尤其是大表之间的关联。提示审Agent方案时不要只看它生成的最终SQL一定要看它的推理过程。好的Agent会输出为什么这样设计的说明这个说明里往往藏着它的假设而假设错了就是最大的坑。2.3 一个真实的返工案例上个月Agent给我生成了一张用户行为宽表逻辑看起来没问题字段也齐全。我审的时候觉得粒度是用户天没问题就让它落地了。结果第二天业务方反馈数据对不上。排查发现Agent在处理用户最近一次下单时间这个字段时用的是全量订单表的最新时间但没有考虑订单状态过滤——已取消的订单也被算进去了。这个错误在SQL里非常隐蔽因为语法完全正确逻辑上最近一次下单字面理解也没错但业务口径里下单是不含取消的。这件事之后我养成了一个习惯凡是涉及业务口径的字段Agent生成后我一定单独标注出来逐条和业务方确认。Agent不懂业务语义它只懂数据结构和模式匹配。这个边界必须人来守。3. 中午十一点到下午两点SQL生成之后的验证环节比写SQL本身还费神3.1 数据质量校验不能省Agent生成的SQL跑通不代表数据对。我现在验证一个Agent产出的表会做几件事行数对比新表和上游表的行数关系是否符合预期。比如一张用户日汇总表行数应该等于当日活跃用户数如果突然多了或少了肯定有问题。空值检查关键字段的空值率。Agent有时候会漏掉某些关联条件导致字段大面积为空。枚举值检查状态类字段的取值范围是否符合预期。抽样比对随机抽几条记录手工用原始数据算一遍看结果是否一致。这些检查以前也做但现在做得更频繁因为Agent产出的东西看起来太对了容易让人放松警惕。我踩过的坑就是有一次Agent生成的表跑出来数据量、字段都正常我扫了一眼就上线了结果三天后才发现某个维度的数据一直是默认值因为关联条件写错了但没报错。3.2 慢SQL优化Agent的盲区Agent生成的SQL在功能上通常没问题但在性能上经常需要人介入。我遇到过几次Agent生成的SQL在生产环境跑几个小时的情况排查下来基本都是几个典型问题问题类型典型表现处理方式分区裁剪失效全表扫描扫描量巨大检查分区过滤条件是否写在子查询里导致无法下推大表join顺序错误shuffle数据量爆炸调整join顺序小表驱动大表数据倾斜个别reduce任务卡住加盐打散或改用map join重复计算同一子查询被多次执行提取公共逻辑到临时表这些问题Agent目前还很难自动识别因为它看不到实际执行计划和数据分布。我的做法是让Agent生成的SQL先在小数据集上跑看执行计划确认没问题再上生产。慢SQL优化这块人的经验还是不可替代的。3.3 元数据回写容易被忽略的一环Agent生成新表之后元数据需要同步更新——新表的字段注释、血缘关系、负责人信息都要回写到元数据系统。这件事以前人工做经常漏现在我会让Agent自动生成元数据变更脚本但回写前我会检查一遍。为什么因为如果元数据回写错了下次Agent再基于这些元数据生成方案时就会错上加错形成恶性循环。我现在的流程是Agent生成表结构和SQL → 我审核 → 执行建表 → Agent生成元数据回写脚本 → 我确认 → 回写。这个闭环里人卡了两道但值得因为元数据是Agent的记忆记忆错了后面全乱。4. 下午两点到五点人做AI做不了的事——口径对齐、模型取舍、跨团队沟通4.1 业务口径确认Agent永远跨不过去的坎下午这段时间我基本不在写代码而是在和各种人沟通。AI接管了SQL生成之后我反而有更多时间去做业务口径的确认。这件事的价值在于口径错了SQL写得再漂亮也是废的。举个例子业务方说要月度复购率这个指标至少有三种算法按订单算、按用户算、按金额算每种算法结果差异很大。Agent拿到这个需求会默认选一种通常是它训练数据里最常见的但到底用哪种必须业务方拍板。我现在会把Agent生成的指标定义整理成文档和业务方逐条过确认后再让Agent按确认的口径重新生成。这个过程听起来简单实际上很耗时。一个中等规模的数仓项目涉及几十个指标每个指标的口径确认平均要花十几分钟加起来就是好几个小时。但这是值得的因为口径确认做在前面后面的返工就少。4.2 模型取舍分层怎么分、冗余怎么设计数仓建模有很多没有标准答案的决策这张表放DWD还是DWS维度冗余到什么程度星型模型还是雪花模型这些决策Agent能给建议但最终拍板的是人。我现在的做法是让Agent给出2-3个方案每个方案附上优缺点分析然后我结合团队现状、查询模式、维护成本来选。比如Agent可能建议用雪花模型减少冗余但我们团队查询以宽表为主雪花模型会导致大量join反而降低查询性能这时候我就会选星型模型。这种取舍依赖的是对团队和业务的了解Agent没有这个上下文。它能看到数据但看不到人。4.3 跨团队对齐数据开发越来越像翻译AI接管了编码之后我发现自己的角色越来越像翻译——把业务语言翻译成数据语言再把数据结果翻译回业务语言。下午经常要参加各种对齐会和上游系统确认数据产出时间和下游应用确认字段需求和数据治理团队确认元数据标准。这些沟通工作以前也有但现在占比明显提高了。因为编码时间被压缩了腾出来的时间自然流向了沟通。我个人的感受是这对数据开发的能力要求其实更高了——你不仅要懂技术还要懂业务、懂沟通、懂协调。5. Agent在数仓开发中的能力边界哪些能交、哪些不能交5.1 可以放心交给Agent的环节经过大半年的实践我总结出几类可以比较放心交给Agent的工作标准化ETL脚本生成从ODS到DWD的清洗、去重、字段映射这类逻辑模式固定Agent做得又快又好。重复性建表任务新增一个维度的汇总表结构和已有表类似Agent能快速生成。SQL语法转换比如从一种SQL方言转到另一种Agent处理得很稳。报错初步定位SQL跑失败Agent能快速分析日志给出可能原因省去大量翻日志的时间。文档生成表说明、字段说明、血缘说明Agent生成的初稿质量已经不错。5.2 必须人把关的环节业务口径定义前面反复说了这是底线。模型架构决策分层、冗余、模型选型这些影响长期维护成本。性能优化Agent看不到执行计划和数据分布慢SQL还得人调。数据质量兜底Agent不会对数据准确性负责最终责任在人。元数据标准制定什么字段必须注释、血缘怎么维护这些规则要人定。5.3 一个判断标准我自己的判断标准很简单如果这件事错了后果是SQL要重写还是业务决策要出错前者可以交给Agent后者必须人把关。SQL重写成本可控业务决策出错可能影响真金白银。这个标准帮我划清了大部分边界。6. 踩过的坑和攒下的经验AI接管数仓后的真实教训6.1 元数据不全会让Agent胡说八道最开始我们没重视元数据Agent生成的SQL经常引用不存在的字段或者把两个名字相似但含义完全不同的表关联起来。后来补全元数据之后这个问题基本消失了。教训是上Agent之前先把元数据治理做扎实这是前提不是可选项。6.2 不要让Agent直接操作生产环境我们早期图省事让Agent生成的SQL直接在生产环境执行结果有一次Agent生成的删除语句范围写大了删了一批不该删的数据。虽然最后从备份恢复了但教训深刻。现在的流程是Agent生成 → 人工审核 → 测试环境验证 → 生产执行一步都不能少。6.3 Agent的自信是最大的风险Agent生成的东西往往看起来很自信语法正确、格式漂亮容易让人放松警惕。但实际上它可能在一个关键的口径上完全错了。我现在养成了一个习惯对Agent产出的每一个关键字段都问一句这个字段的定义是什么和业务方确认过吗。这个问题能拦住大部分隐患。6.4 人的价值在判断上不在产出上用了大半年Agent之后我最大的体会是数据开发的核心竞争力正在从能写多少SQL转向能做出多少正确判断。SQL生成这件事正在被商品化但判断口径、取舍模型、兜底质量这些能力反而更值钱了。与其焦虑被替代不如把时间花在提升判断力上。7. 一天结束时的复盘这个岗位正在变成什么样晚上收工前我习惯花十几分钟复盘当天的工作。最近这几个月的复盘记录里出现频率最高的词是确认和判断——确认口径、确认血缘、确认质量判断模型、判断优先级、判断风险。写SQL这个词出现的频率明显下降了。这个变化对数据开发这个岗位意味着什么我的观察是岗位不会消失但能力模型在重构。以前一个数据开发的核心技能是SQL熟练度加数仓理论现在这两样依然重要但权重在下降取而代之的是业务理解力、判断力和协作能力。Agent把执行层面的门槛降低了但把判断层面的门槛提高了。对刚入行的朋友我的建议是SQL和数仓基础还是要打牢因为你不懂这些就没法判断Agent产出的对错。但同时要刻意练习业务理解和沟通能力这些是Agent短期内替代不了的。对已经做了几年的朋友我的建议是主动拥抱Agent把它当成一个能力放大器而不是威胁。你越懂数仓越能驾驭Agent你越不懂越容易被Agent的错误带偏。这一天下来我大概审了Agent生成的五张表的方案改了其中两张的字段口径优化了一条慢SQL参加了两个对齐会回写了三张表的元数据。放在三年前这些工作量里有一大半是纯编码现在编码被Agent承担了我的时间流向了判断和沟通。这个转变谈不上轻松但确实让工作更有意思了——你不再是一个SQL工人而更像一个数据架构的决策者。