AI 时代的数开，别再靠写 SQL 吃饭了

作者：hanfengya

假期和一个工作 8 年的数开小伙伴吃饭，他半开玩笑地说：“我现在写复杂 JOIN，下意识会先让 AI 写，自己只做 review。”我整整 8 年的吃饭手艺，正在变成一个 review 别人代码的人。

一、写 SQL，曾经是怎么成为护城河的？

10 年前会写 SQL 是稀缺的。复杂 JOIN、窗口函数、CTE 嵌套——业务方写不来，资深开发月薪能比业务高 50%。

写 SQL 之所以是护城河，因为它同时考验三件事：

  • 业务理解——这个数怎么算才对？
  • 工程能力——这段 SQL 怎么写才不慢？
  • 数据敏感——这个结果合不合理？

10 年里，这三件事只有人能做。所以“会写 SQL”= 有饭吃。

二、AI 时代变了什么？

3 个变化，把这碗饭抖了一下：

① Agent 已经能写 80% 场景的 SQL

Cursor / Claude Code / GPT 起来，对绝大多数 BI 场景够用。“过去 30 天每个城市的 DAU”——5 秒，0 等待。

② 上下文窗口容得下整个数仓

Claude 1M Token、GPT-6 200 万 Token，中型数仓的全部 DDL + 业务说明 + 指标口径，一次性丢进去都装得下。模型一旦看到“全图”，写 SQL 就不再是猜字段，而是看着完整 schema 写。

③ 工具链补齐了

sqlglot 校验、dbt 管依赖、语义层强制口径一致。“AI 写 SQL”从 demo 变成了生产可用。

三、写 SQL 为什么不再是护城河？

把“写 SQL”拆成 3 件事，看 Agent 各占了多少：

维度 5 年前的人 今天的 Agent 谁更强
写复杂 JOIN/窗口函数 1 小时 30 秒，准确率 95% Agent
业务理解 凭经验 看上下文也有 80% 持平
数据敏感（结果合不合理） 凭经验 看 outlier 报告 人略胜

真相：写 SQL 这件事，80% 的工作量正在变成“打字”。数开真正值钱的部分，从来不是“打字快”，是“判断对”。

四、那数开的核心价值往哪去？

3 条新增长曲线，每一条都比“写 SQL”更值钱：

曲线 1：数据架构与治理决策

Agent 能写 SQL，但不能决定：

  • 这张表该不该建？建在哪一层？
  • 这个指标有没有口径冲突？
  • 这套数据血缘合理吗？影响面几何？

这些是判断题，不是选择题。判断题需要业务积累 + 工程经验，Agent 帮不了你。

曲线 2：让数据“被 AI 看懂”

这是个全新岗位。具体做：

  • LLM Ready 元数据——让 Agent 能理解每张表的业务用途、字段取值
  • 语义层 / 指标 registry——让 Agent 写 SQL 时不会乱用口径
  • 可召回性治理——让 RAG / AI 搜索能找到该找到的数据
  • 字段级血缘——让异常追溯从 3 小时压到 5 分钟

这些工作 5 年前根本不存在。今天它们正在变成新的核心岗位。

曲线 3：Skill / Agent 工程化

如果说前两条是“做新事”，这条是“用新方式做老事”。

让 Agent 替你写 SQL、跑、监控、告警、追溯——你的单位产出从“一段 SQL”变成“一个能跑的工作流”。杠杆从 1x 变成 10x。

具体动作：

  • 用 Claude Code Skill 把数仓开发流程模块化
  • 用 Agent 替代凌晨告警、对账、影响面排查

回报：别人需要 5 个工程师做的事，你 1 个人 + 一套 Skill 就够了。

五、给数开的 3 条行动建议

① 别再抗拒 AI 替你写 SQL

让 Agent 写 80% 的“打字活”，把节省的时间投到判断、设计、架构上。

② 主动接 1-2 个“AI 数据底座”项目

元数据系统改造、语义层、字段级血缘、可召回性治理——这些项目的简历价值，比“做了 N 张报表”高很多倍。

③ 学一两个 Agent / Skill 工具，做杠杆

Claude Code Skill / sqlglot / dbt + 语义层 / MCP——至少要会用、能 demo、能讲清楚价值。面试时拿这些出来，比讲“我熟练 SQL”加分 10 倍。

写在最后

不是 SQL 没价值了。是“只会写 SQL”没价值了。

写 SQL 这件事，5 年前是手艺，现在是工具。手艺会被工具化，工具化的手艺，价值会归零。

但判断、架构、治理、Agent 工程这些事，工具化短期内做不了。这才是数开未来的饭碗。

数开的好时代刚开始——前提是你愿意从“写 SQL 的人”升级成“让数据系统跑得起来的人”。