SQL Boy 怎么可能穷途末路？

上篇面对 AI 的冲击，数据及开发领域还有哪些真正的机会？发出去以后，很多同学在跟我聊一个比较扎心的话题：

说了那么多，那我作为 SQL Boy，如何应对 AI 带来的冲击？

当然这也并非莫名焦虑，因为 AI 对大数据开发岗位的影响，已经实打实的落到日常分工和交付方式上了。

但是我还是想说先别蕉绿，这篇我们就探讨一种能完整耦合到日常工作中，不花费太多额外学习时间就能往前进阶的一种前进路线吧。

在日常开发任务里，LLM 已经进入很多具体环节：写 SQL、改 SQL、解释报错、补字段映射、看执行计划、给慢 SQL 优化建议、生成数据质量规则、根据 PRD 拆 ETL 逻辑。过去要靠熟练工慢慢磨出来的工作，现在都有了模型辅助的空间。

尤其是在语义不明、口径不清、源表质量很差、业务逻辑没有写全的时候，AI 很容易给出看起来合理、实际经不起验证的答案。

它可能把“订单金额”理解成支付金额，也可能把“有效用户”当成登录用户，还可能在宽表设计里遗漏生命周期状态、退款、撤销、补录、跨天归因这些真实业务里很麻烦的东西。

这些问题不能被忽略，但它们也不足以否定 AI 对大数据开发的提效价值。

一个普通 SQL 开发，遇到报错时让模型帮忙定位问题；遇到性能瓶颈时让模型基于执行计划给建议；遇到复杂需求时让模型先拆一版字段、口径、事实表、维表、宽表、数据质量规则，这些事情确实能提效。

提效能力越确定，对普通 SQL Boy 的冲击也越直接。

以前很多岗位的价值，来自熟练掌握某套开发八股文：会写 SQL，会拼 ETL，会按模板产出宽表，会处理常见报错，会查字段，会补文档。

现在这部分能力正在被压缩。

那本篇我尽量克制不做焦虑渲染，当然也不做“AI 替代不了你”式安慰。

两种说法都解释不了当前的数据岗位结构变化。

我更想认真讨论一个问题：

一个大数据从业者，如何从害怕被 AI 替代，走到掌握 AI，再走到用 AI 放大自己的综合能力？

只学几个 Prompt 解决不了这个问题，岗位能力本身需要重构。

一、AI 先压缩的，是低语义、低验证、低治理的重复劳动

先看岗位冲击的排序。

我不太建议一上来就讨论“SQL Boy 会不会消失”。岗位名称往往滞后于真实工作变化，先发生变化的，是每天被交付出去的那些具体任务。

AI 对大数据岗位的冲击，不会平均落在每个人身上。

最先被压缩的，往往是三类工作。

第一类是低语义 SQL。

比如根据一个明确的字段表，写查询、补条件、改语法、做简单聚合、生成常规报表 SQL。这类任务只要输入足够明确，模型已经能做得不错。

第二类是低验证开发。

比如照着一段需求生成 ETL 代码，但没有样例数据、没有口径校验、没有边界用例、没有回归测试。过去这类工作靠人肉经验兜底，现在 AI 也能生成一版。问题在于生成得快，错得也快。

第三类是低治理流程。

比如每次需求分析、数据探源、宽表设计、规则生成、发布上线都靠不同人各写各的，规范只停留在口头或文档里。AI 进来以后，这类流程如果没有结构化，很容易出现“看起来自动化了，实际错误规模化了”的情况。

很多 SQL Boy 的不安也来自这里：岗位不会在某一天突然消失，但手里越来越多“熟练工任务”已经开始被模型接走。

与其继续争论 AI 会不会写 SQL，不如直接承认：它已经能处理相当多的常规 SQL 任务。

更需要警惕的是，如果一个人的主要价值只停留在执行模板、搬字段、改报错、复制规则，这部分价值会越来越便宜。

因为 AI 把低层执行压缩以后，留下来的空位，正好是过去很多 SQL Boy 没有系统训练过的能力：需求澄清、语义建模、数据质量判断、验证设计、工程规范、流程治理、Agent 工作流搭建。

所以后面的重点，要从“证明自己比模型更会写一条 SQL”，转向补齐那些更靠近业务和工程治理的能力。

二、为什么有些人用 AI 写 SQL 很爽，有些人越用越乱？

同样是接入 LLM，有些团队会觉得效率明显提升，有些团队会觉得它帮倒忙。

差异通常不在模型本身，而在输入条件。

这个问题在数据开发里尤其明显。模型并不怕 SQL 长，也不怕字段多，它更怕业务语义不完整。

如果需求写得很清楚，指标口径明确，源表含义明确，字段质量还可以，计算逻辑、过滤条件、时间边界、维度粒度、异常口径都写出来，AI 很容易产出一版可用结果。

如果需求只有一句“帮我看一下用户活跃情况”，那模型只能猜。

模型需要猜业务域，猜用户定义，猜活跃行为，猜时间范围，猜分群维度，猜统计粒度，猜口径边界。猜出来的东西再漂亮，也不应该直接进入生产。

这里有一个特别容易被忽略的点：模型通常不会主动承认“我不知道你们公司怎么定义活跃”。它会沿着最常见的语义往下补齐，然后给你一份看起来还挺完整的结果。

大数据开发里最危险的一类错误，通常不在 SQL 语法层。

语法错了，跑不通，容易发现。

更麻烦的是业务语义错了。

SQL 能跑，结果也有数，甚至看起来还挺合理，但它算偏了业务原本想问的那个问题。

比如：

• • “销售额”有没有剔除退款？
• • “新客”按注册时间算，还是首单时间算？
• • “转化率”的分母是曝光用户、点击用户，还是进入页面用户？
• • “有效订单”是否排除测试单、刷单、撤销单？
• • “昨日数据”按自然日、账务日，还是业务结算日？
• • 宽表里同一个用户多条状态记录，取最新还是取有效期内？

这些问题如果没有人问清楚，AI 仍然会给出一个答案，只是这类答案缺少生产资格。

所以大数据人用 AI 的第一层能力，应该从“帮我写 SQL”升级为“帮我更快发现需求里的语义缺口”。

这一层做不到，后面的自动化会把模糊需求放大成生产风险。

三、有些团队已经开始调整基建：把数据开发拆成 Agent 工作流

现在已经有团队开始把 AI 数据开发往工程流程里推。

他们把模型从自由问答式聊天框里拉出来，放进更结构化的数据开发流程：需求分析、模型设计、数据集选择与探查、规则生成、规则验证、发布部署上线。

这类实践最值得看的地方，在于流程本身被结构化了。

重点可以拆成四个层面。

第一，他们给 Agent 准备了很多 Skill。

这些 Skill 分别服务于需求分析、数据探源、ETL、宽表设计、开发规范等环节。这里要看的，是组织经验的固化：过去散落在资深数据开发脑子里的八股文和经验，开始变成 Agent 能执行的工作规程。

很多人看到 Skill，第一反应会觉得这不就是提示词模板吗？这个理解太轻了。能稳定复用的 Skill，应该承载一段完整的工作方法：输入是什么，输出是什么，中间必须检查什么，哪些内容不能继承，什么结果需要人工确认。

第二，他们在限制每个数开内容的继承。

限制继承处理的是一个常被忽略的问题。

很多 Agent 流程跑崩，就是因为上下文乱继承。需求分析阶段的猜测，被后面的模型设计当成事实；探源阶段的临时发现，被规则生成当成稳定结论；未确认的信息一路传下去，最后变成上线逻辑。

限制继承，本质上是在做上下文治理。

哪些内容能往下传，哪些只是候选，哪些必须等待客户确认，哪些只能作为风险提示，这些边界不先定好，Agent 会很积极地把错事做完整。

第三，他们把数据探源放在前面。

因为数据质量不好，所以先验证数据质量，再反馈给客户做治理。这一点非常现实。

很多 AI 数据开发失败，根因不在模型不会写规则，问题常常出在源数据本身没有达到可计算状态。字段名像那么回事，内容可能全是脏的；表结构看起来完整，关键字段可能大量为空；业务上说有状态流转，数据里可能缺少状态变更记录。

如果不先探源，后面所有 ETL、宽表、规则、指标都可能建立在沙地上。

第四，他们发现 PRD 越详细，Agent 开发越一致。

PRD 详细度会直接影响 Agent 开发的一致性。

如果拿详细 PRD 给 Agent 做开发，效果基本一致；如果需求本身由 Agent 生成，后续开发会出现偏差，尤其是计算逻辑没有声明时。这说明 Agent 对明确规则的执行能力已经不错，但它还不适合替业务方补完所有语义细节。

第五，他们意识到知识库辅助很重要。

大数据开发里很多计算逻辑，不在当前需求里。它藏在历史口径、历史表、历史指标、历史事故、历史命名规范、历史数据质量规则里。如果没有知识库，Agent 很难知道“这个公司过去是怎么定义有效订单的”。

所以这套实践给我们的启发很清楚：

大数据团队接入 AI，更该建设的是流程、Skill、知识库、数据质量验证和发布验收，远比给 SQL 编辑器接一个模型重要。

四、SQL Boy 的第一阶段：把 AI 当成 SQL 审查和优化助手

能力升级要从离现有工作最近的环节开始。

如果一个人现在主要工作就是写 SQL、改 SQL、跑报表、做常规 ETL，那第一阶段不要急着搞复杂 Agent。

先把 AI 用在最贴近当前工作的地方。

这个阶段的目标很朴素：先让 AI 参与你每天最熟悉的工作，把低级错误、重复排查和常规优化压缩掉。你不需要一上来就设计一套完整的数据开发智能体。

第一件事，让它帮你做 SQL 错误定位。

不要只把报错贴过去问“怎么改”。更好的方式是把数据库类型、SQL、报错信息、相关表结构、字段类型、期望结果一起给它，让它输出：

• • 可能原因
• • 修复方案
• • 改动后的 SQL
• • 可能影响
• • 需要验证的样例

第二件事，让它帮你做慢 SQL 分析。

这里不要只问“帮我优化”。你需要给它执行计划、表数据量、分区信息、索引或分布键、Join 条件、过滤条件、聚合逻辑。然后要求它从几类方向看：

• • 谓词是否下推
• • 分区是否命中
• • Join 顺序是否合理
• • 大表小表关系是否清楚
• • 是否存在重复扫描
• • 是否可以预聚合
• • 是否需要拆 CTE 或物化中间结果
• • 是否存在数据倾斜

第三件事，让它帮你做 SQL Review。

你可以给自己准备一个固定检查清单：

• • 结果口径是否清楚
• • 时间范围是否明确
• • Join 是否会放大行数
• • 主键粒度是否一致
• • Null 处理是否合理
• • 去重逻辑是否有依据
• • 过滤条件是否和业务口径一致
• • 是否有小样本验证
• • 是否存在性能风险

这一阶段不要把目标放在“让 AI 替你写完所有 SQL”上。

更合适的目标，是把它变成你的第二双眼睛，让它帮你更快发现语法问题、性能问题和明显口径漏洞。

最后的生产判断仍然要由人负责。

SQL 能跑通，只能说明它通过了最低门槛。生产环境里要看的，是它算得对不对、稳不稳、能不能解释。

五、第二阶段：从 SQL 执行者升级为需求澄清者

当 AI 能帮你写一部分 SQL 后，你要主动往上游走。

这里的上游，首先是需求定义。

这一步很多人会觉得“那不是产品或者业务的事吗？”但在真实项目里，数据开发如果完全等别人把问题定义好，最后背锅的往往还是自己。

很多 SQL Boy 被困在低价值工作里，问题不在 SQL 不重要，问题在于他永远等别人把目标定义好，再去执行。

在 AI 介入执行环节后，这种位置的议价能力会下降。

因为执行环节会被模型不断压缩。更值钱的地方，会越来越靠近问题定义。

一个合格的数据需求澄清者，至少要问清楚这些东西：

• • 业务目标是什么？
• • 决策场景是什么？
• • 谁看这个数据？
• • 看完以后要做什么动作？
• • 指标名称是什么？
• • 统计对象是什么？
• • 统计粒度是什么？
• • 时间口径是什么？
• • 过滤条件是什么？
• • 分母和分子分别是什么？
• • 是否涉及排除项？
• • 是否有历史口径？
• • 是否需要和已有报表对齐？
• • 数据延迟允许到什么程度？
• • 异常值怎么处理？

你可以把这些问题做成一个需求分析 Skill。

每次拿到 PRD，先让 Agent 输出一份“需求缺口清单”，不要直接让它写 SQL。

这个 Skill 的输出可以固定成几块：

1. 已确认需求
2. 未确认口径
3. 可能涉及的业务对象
4. 可能涉及的指标
5. 时间与粒度要求
6. 数据源候选
7. 风险点
8. 必须向业务方确认的问题

需求缺口清单决定了后续开发是否建立在正确问题上。

一个普通 SQL 开发，拿到需求后开始写。

一个更成熟的数据工程师，拿到需求后先判断它能不能写、该不该写、缺什么信息、上线以后会不会误导业务。

AI 可以帮你更快生成检查清单，但是否问到关键问题，取决于你自己的业务敏感度。

六、第三阶段：掌握数据探源和数据质量验证

大数据开发里，有一个能力长期被低估：数据探源。

很多人以为数据开发就是建表、写 SQL、跑任务。

实际项目里，最花时间的地方，经常是搞清楚一张表到底靠不靠谱。

数据探源没有写复杂 SQL 那么有存在感，却经常决定一个需求能不能进入开发阶段。数据本身不可信，后面的自动化越快，事故传播得越快。

字段名叫 user_id，它是否真的唯一？

字段名叫 order_status，状态枚举是否完整？

字段名叫 pay_time，它是否可能为空？

业务说这张表是 T+1，实际是否每天都按时到？

某个金额字段有没有负数、极值、单位混乱？

同一个订单是否存在多条记录？

维表是否有拉链逻辑？

历史分区是否补过数据？

这些问题如果不探清楚，后面的 SQL 越自动化，事故越隐蔽。

AI 在数据探源里非常有用，但要给它正确的角色。

模型可以帮你设计探源清单，帮你生成质量规则，帮你写验证 SQL，帮你解释异常分布，帮你整理探源报告。

业务合理性的判断，不能交给模型独立完成。

你可以建立一个数据探源 Skill，让 Agent 每次围绕这些维度输出结果：

1. 表基本信息：数据量、分区、更新时间、生命周期
2. 字段画像：类型、空值率、枚举值、极值、分布
3. 主键检查：唯一性、重复样本、重复原因猜测
4. 时间检查：最早时间、最晚时间、断档情况、延迟情况
5. 关联检查：事实表与维表能否正常关联
6. 业务规则检查：金额、状态、数量、比例是否符合常识
7. 风险结论：可直接使用、需治理后使用、暂不建议使用
8. 需要反馈业务或数仓治理的问题

数据探源能力做扎实后，你就不再只是写 SQL 的人。

你开始能判断数据资产能不能支撑需求。

数据探源能力会直接影响你能否从执行岗进入方案判断岗。

因为 AI 可以帮你写一百条规则，但它不知道哪条规则在你的业务里真的重要。它可以网上搜规则模板，却不知道你们公司的“有效订单”“活跃用户”“库存可售”“收入确认”到底应该怎么定义。

业务规则的重要性排序，仍然需要人基于业务和数据经验负责。

七、第四阶段：把开发规范沉淀成 Skill，别停留在个人经验

很多公司都有数据开发规范。

但这些规范常常停在文档里。

命名规范、分层规范、调度规范、质量规范、上线规范、回滚规范、权限规范，写得很完整，落到开发时还要靠人记。

Agent 进入开发流程后，规范可以变得更可执行。

这里我建议大家不要把 Skill 理解成“写得更详细的 Prompt”。如果一个 Skill 只能让模型说得更像样，它的价值有限。能长期用的 Skill，要把规范变成一套可重复执行、可检查、可追责的动作。

你可以把规范拆成一组 Skill。

比如：

需求分析 Skill，负责把 PRD 转成结构化需求、缺口清单和确认问题。

数据探源 Skill，负责生成探源 SQL、质量规则和风险报告。

ETL 设计 Skill，负责输出源表、目标表、字段映射、转换逻辑、调度周期、依赖关系、回刷策略。

宽表设计 Skill，负责检查主题域、主键粒度、维度字段、事实字段、冗余策略、生命周期、扩展字段。

SQL Review Skill，负责检查口径、性能、可维护性、Join 风险、Null 风险、粒度风险。

发布验收 Skill，负责检查测试结果、质量规则、数据对账、任务依赖、监控告警、回滚方案。

开发规范沉淀成 Skill 的价值，在于组织经验资产化。

因为它把“资深员工脑子里的经验”，变成了 Agent 可以稳定调用的流程资产。

一个刚毕业的同学，单独做需求分析可能很吃力。但如果他有一套清晰的 Skill，Agent 可以带着他一步步补齐需求、探源、设计、验证和上线。

新人依然需要学习，而且要学习这些 Skill 背后的判断逻辑。

为什么需求里必须声明计算逻辑？

为什么探源要先看主键唯一性？

为什么宽表设计要先确定粒度？

为什么质量规则不能只靠网上模板？

为什么上线前必须做数据对账？

当你能回答这些问题，你就在从 SQL 执行者，升级成数据工程流程设计者。

八、第五阶段：从使用 AI，到驾驭 AI 工作流

再往后，大数据人的能力会进入一个新层级。

这个阶段考验的重点，会从“会不会用 ChatGPT 写 SQL”、“会不会给 Agent 写提示词”，转向能不能设计一套让 Agent 稳定工作的流程。

AI 使用者和 AI 工作流设计者的差距，就从这里拉开：只会提问，最多得到一次回答；能设计流程，才有机会让模型持续参与交付。

一套稳定的 Agent 工作流，至少包含六个部分。

第一，输入治理。

需求不能直接扔给 Agent。要先拆成业务目标、指标口径、数据源候选、风险点、缺口问题。

第二，知识库治理。

历史口径、表说明、指标定义、开发规范、历史事故、质量规则，都要进入可检索、可维护的知识库。否则 Agent 每次都只能从当前 PRD 里猜。

第三，Skill 治理。

不同环节用不同 Skill，需求分析、探源、ETL、Review、发布验收不能混成一个万能提示词。

第四，上下文治理。

每个阶段只继承该继承的内容。候选信息、已确认信息、待确认信息、风险提示，要分清楚。不能让上游猜测一路污染到上线。

第五，验证治理。

每个输出都要有验证方式。SQL 要有样例验证，指标要有对账，质量规则要有命中样本，宽表要有粒度检查，发布要有回滚方案。

第六，人工签名。

关键口径、关键规则、关键上线动作，不能让 Agent 自己闭环。人要在关键节点签字确认。

把这六件事组织起来，才算进入“驾驭 AI”的层级。

普通人问模型一个问题。

进阶的人让模型帮自己做一段工作。

更成熟的人会设计一套工作流，让模型、知识库、Skill、数据质量规则、验收证据一起协作。

Agent 工作流设计能力，会成为大数据人的重要分水岭。

九、一条切实可落地的学习路径

如果你现在是一名普通 SQL 开发，我建议不要被各种宏大叙事带偏。

你可以按四个阶段推进。

这套学习路径没有速成效果，也不适合只收藏不练。更稳的做法，是把它当成一个能力台账：每个阶段都要留下自己的模板、清单、案例和复盘记录。

第一阶段：把 SQL 能力和 AI 辅助结合起来。

时间可以控制在两到三周。

这一阶段的目标，要放在建立自己的 SQL Review 工作流上，不要停在“让 AI 替你写 SQL”。

你要做几件事：

• • 收集自己日常遇到的 SQL 报错和优化案例
• • 建一个 SQL 修正 Prompt 模板
• • 建一个 SQL Review 清单
• • 学会把执行计划、表结构、分区、数据量一起提供给模型
• • 每次让模型改 SQL 后，自己做样例验证
• • 记录模型经常犯的错

这一阶段结束时，你应该拥有一个个人 SQL 助手工作流。

第二阶段：学习需求澄清和指标口径。

时间可以控制在一个月。

你要刻意训练自己从 PRD 里抽取这些东西：

• • 业务目标、指标名称、统计对象、粒度、时间口径、过滤条件、分母分子、排除项、历史口径、数据源候选、缺口问题

这一阶段可以把需求分析 Skill 做出来。以后每次拿到需求，都先跑一遍缺口清单。

如果业务方不能回答，你就不要急着开发。

成熟的数据开发，不靠猜口径推进。

第三阶段：学习数据质量和数据探源。

时间至少一个月。

你要掌握常见质量维度：

• • 完整性、唯一性、一致性、及时性、准确性、合法性、稳定性、关联完整性

然后给每个维度配上验证 SQL 和解释方式。

不要只在网上搜规则模板。

规则模板只是起点。规则的价值，要靠业务语义兜住。

比如金额字段非空，只是普通规则；支付成功订单金额必须大于 0 且退款后净额不能超过原支付金额，这才更接近业务规则。

第四阶段：学习 Skill 和 Agent 工作流设计。

Skill 和 Agent 工作流设计没有固定结束时间。

你要开始把自己的工作方法固化成文件。

至少准备五类 Skill：

• • 需求分析 Skill
• • 数据探源 Skill
• • ETL 设计 Skill
• • SQL Review Skill
• • 发布验收 Skill

每个 Skill 都要写清楚输入、输出、禁止事项、检查清单、验收方式。

同时要建立一个小型知识库：

• • 表说明、指标口径、历史需求、历史事故、数据质量规则、开发规范、常见 SQL 优化案例

到这个阶段，你的工作重心已经从单次调用 AI，进入到设计 AI 工作流。

你在把自己的工作经验产品化。

因为未来组织里稀缺的人，未必是单条 SQL 写得最快的人，更可能是能把一群人和一组 Agent 管进稳定流程的人。

十、几个容易踩的坑

第一，不要把 AI 生成的 SQL 直接当生产代码。

哪怕它写得再顺，也必须验证口径、粒度、样例和性能。

第二，不要在需求不清楚时强行开发。

AI 会让你更快产出一版东西，但如果计算逻辑没有声明，后面偏差会越来越大。

第三，不要把数据质量规则做成模板搬运。

网上规则很多，完整性、唯一性、一致性、及时性这些都能搜到。但规则要产生价值，必须落到业务语义上。

第四，不要让 Agent 自己继承所有上下文。

需求分析阶段的假设，不能直接变成模型设计阶段的事实。每个阶段都要区分已确认、待确认、候选和风险。

第五，不要把 Skill 当成万能魔法。

Skill 只是把流程固化下来。流程本身如果不对，Skill 会稳定地产出错误。

第六，不要忽视基础能力。

SQL、数仓分层、指标口径、调度、数据质量、性能优化、权限、安全、发布回滚，这些基础不会因为 AI 出现而消失。AI 只会让基础薄弱的人更快暴露问题。

写在最后：从害怕被替代，到成为能驾驭 AI 的数据人

接下来几年，很多大数据岗位会被重新定价。

低语义的 SQL 执行、低验证的 ETL 开发、低治理的规范复制，会被 AI 持续压缩。

大数据团队对人的需求不会消失，但会从执行量转向判断力、治理能力和流程组织能力。

企业需要的，是能把业务问题翻译成数据问题的人，能把模糊需求拆成明确口径的人，能判断数据质量能不能支撑分析的人，能设计验证闭环的人，能把开发规范固化成 Skill 的人，能把 Agent 管进稳定流程的人。

SQL Boy 的升级路线可以收束为五步。

第一步，用 AI 提升 SQL 修正、SQL Review、慢 SQL 优化效率。

第二步，往需求澄清和指标口径上走。

第三步，掌握数据探源和数据质量验证。

第四步，把开发规范沉淀成 Skill。

第五步，设计 Agent 数据开发工作流。

如果你只停在第一步，AI 对你的冲击会越来越明显。

如果你能走到第五步，AI 会成为你放大个人能力的工具。

岗位边界的变化，最终会落到一个具体问题上：

过去，一个普通数据开发的能力边界，取决于他一天能写多少 SQL。

现在，一个更强的数据工程师，能力边界会取决于他能不能把需求、语义、数据质量、开发规范、Agent、知识库和验收证据组织成一套稳定系统。

完成这五步的人，会从 SQL 执行者升级为数据工程、业务语义和 AI 工作流之间的组织者。

希望这篇文章能给大家带来一定的启发，当然不是说数据开发工程师就只有这一条路径，这条路径是建立在最小额外付出时间和成本之上的，如果还有其他的额外精力，我后续会再输出一些更多如何跨越式进阶的方法论。

看到这里了，来个“点赞”、“在看”和“转发”吧，这是我唯一的更新动力了～

而市面上很多自媒体为了流量，炒作的都是大家的情绪。我觉得这样不对，理论上应该给大家更多的视角去解决这个问题才对，所以这算落地第一篇吧。