AI 越强，数据开发越值钱

上个月，一个做了5年数据开发的前同事给我发了条消息。

他说，最近越来越焦虑。Cursor 能写 SQL 了，Copilot 能调 ETL 了，公司新来的实习生用 AI 工具半天就能干完他以前一天的活。

"哥，你说数据开发这个岗位，还能干几年？"

我想了想，没急着回。

因为这个问题，其实不是他一个人的困惑。过去半年，我至少有七八个同行私下问过我类似的话。

今天，我想把我对这个问题的判断，认认真真写下来。

数据不会骗人：需求还在涨，但涨的不是你

先看几个事实。

根据 LinkedIn 2026 年 Q1 数据，全球数据工程师岗位同比增长了 18%。国内主流招聘平台的数据也显示，数据开发相关职位在 2026 年上半年不降反增。

但如果你仔细看 JD，会发现一个明显的变化：

三年前的招聘要求，核心是"精通 Hive/Spark/Flink，熟悉数据仓库建模"。2026 年的 JD 里，这些依然是基本功，但排在它们前面的，变成了"熟悉 AI 智能体应用开发"、"有 MLOps 经验"、"能设计数据架构而非只是执行 ETL"。

我翻了翻最近几个月的招聘数据，发现一个更扎心的趋势：2026 年大数据相关岗位中，超过六成企业明确要求应聘者具备 AI 智能体应用与落地能力，写明"大数据 + AI 智能开发"复合技能优先。

翻译成人话就是：不是没有岗位，是岗位的要求变了。

纯 ETL 开发、只会在别人设计好的框架里写 SQL 的数据开发，确实在被边缘化。但能理解业务、能设计数据架构、能把数据变成业务决策依据的人，比以往任何时候都更稀缺、更值钱。

这不是我第一次见到这种"需求结构迁移"。

2018 年，大数据最火的时候，一个会写 Spark 的工程师月薪可以轻松过 3 万。但到了 2021 年，Spark 成了标配，溢价消失。取而代之的是，懂数据建模、懂业务逻辑的数据架构师开始拿更高溢价。

每一次技术范式的变化，淘汰的都不是岗位，而是在岗位上停止进化的人。

AI 替不掉的，是那些"脏活"之外的东西

我知道你可能在想：这次不一样，AI 真的能写代码了。

你说得对，AI 确实能写 SQL，而且写得不错。它能帮你生成 ETL 脚本，能优化查询性能，甚至能根据自然语言描述自动搭建数据管道。

但我问你一个问题：一个数据开发工程师，一天真正花在"写代码"上的时间，占多少？

我自己的经验是，不超过 30%。

剩下的 70%，花在了这些事情上——

和业务方对齐需求。他们说"我想要一个用户画像"，你问他们"你说的用户画像具体指什么？包含哪些维度？用来做什么决策？"——而这些问题的答案，决定了你整个数据模型的设计。

排查数据质量问题。一个指标突然异常，你要从上游业务系统一路查到数据仓库、再从数据仓库查到报表层，定位是哪一环出了问题。这个过程考验的不是代码能力，是对整个数据链路的理解。

设计数据架构。一个新业务线要建数据仓库，你决定是 ODS-DWD-DWS-ADS 经典分层还是用宽表一步到位？选 StarRocks 还是 ClickHouse？这个决定会影响未来两年的查询性能和运维成本。

这些事，AI 干不了。

不是因为它不够聪明，而是因为这些决策依赖的是"对业务的理解"和"对系统的全局认知"。AI 能看到代码，看不到业务背景。AI 能优化 SQL，没法替代你在需求评审会上追问业务方的那十个问题。

能被替代的，是"翻译需求写代码"的机械劳动。替代不了的，是"理解业务设计架构"的判断力。

2026年，数据开发的三个进化方向

如果让我只给一个判断，我会说：数据开发这个岗位，正在经历一次"向上迁移"。

以前的数据开发，主要技能树是"数据采集清洗存储计算"。以后的数据开发，核心能力要向上迁移到三个阶段——

方向一：从"搬运工"到"架构师"

我刚做数据开发那几年，日常工作就是：上游系统抽数据、清洗、入仓、跑报表。

说白了，就是个数据搬运工。上游给我什么，我存什么。业务要什么报表，我跑什么 SQL。

但这两年我越来越意识到，真正拉开数据开发差距的，不是你写了多少行 SQL，而是你有没有能力设计整个数据链路。

举一个真实的例子。

我们团队之前接手过一个金融项目。原来的数据架构师离职了，留下一套跑了两年的数据管道。新人接手后，每次数据延迟都很慌——不知道为什么慢、不知道哪里是瓶颈、不敢随便动。

后来我们重新做了一遍架构梳理，画出了完整的数据血缘链路，才发现原来的设计里有一个巨大的坑：一个核心表的更新逻辑依赖上游 17 张表，其中 6 张表的更新时间和它不在同一个窗口期。这意味着数据延迟是"设计缺陷"，不是性能问题。

发现这个问题并把它修掉的人，值多少钱？

那个项目后来给客户省了每年 40 万的云资源成本。而解决这个问题的数据架构师，涨薪了 50%。

数据搬运工的价值，是"把数据搬过去"。数据架构师的价值，是"让整个数据系统更高效地运转"。这两者之间的差距，比很多人想象的大得多。

方向二：从"专注技术"到"懂业务的数据伙伴"

有一次我参加一个需求评审会。

业务方说："我们想看用户的复购率。"

一个初级数据开发听完就走了，回去写 SQL。

一个资深数据开发会追问："你说的复购率，定义是什么？同商品复购还是跨品类也算？周期是 30 天还是 90 天？要不要排除退货？"

一个有业务思维的数据开发会接着问："你们看这个指标是用来做什么决策？如果是为了优化推荐策略，那我建议加上品类维度和价格区间。如果是为了做用户分层运营，那我们可以把复购用户按频次分三档，配合 RFM 模型一起看。"

三种回答，三种段位，三种价值。

在 AI 时代，第一种回答的价值会趋近于零。因为"翻译业务需求写成 SQL"，AI 做得比你快、比你准。

但第三种回答，AI 做不了。不是技术不够，是因为它没有坐在那个会议室里，没有听到业务方在描述需求时犹豫的那两秒——那两秒意味着需求方自己也没想清楚，意味着你要帮他定义问题而不只是回答问题。

业务理解力，正在成为数据开发真正的分水岭。

方向三：从"手写一切"到"AI 增强型开发"

说到这里，你可能以为我在劝你"别学 AI 工具"。

恰恰相反。

我一个做数据平台开发的同事，花了两周时间把 AI 辅助编程工具接入自己的日常工作流。结果呢？他的效率提升了至少 40%。

不是因为他变聪明了，是因为他把那 30% 的"机械劳动"交给了 AI——写模板代码、生成 DDL、调参数、写单元测试。

省下来的时间，他用来做两件事：一是深入学习业务，每周至少参加一次业务部门的需求讨论会；二是研究数据架构，把公司几个核心数据产品的底层设计吃透了。

半年后，他从一个"写 ETL 很快的高级开发"，变成了能独立负责一个数据产品线的架构负责人。

AI 是你的工具，不是你的敌人。关键不是抗拒它，而是用它把自己从重复劳动中解放出来，把精力投入到 AI 做不到的事情上。

如果你只能做三件事

回到文章开头那个问题：数据开发还值得干吗？

我的答案很明确：值得，但只对"愿意进化的人"值得。

如果你接下来的半年只能做三件事，我建议你优先做这三件：

第一，学透一个数据平台的架构设计。 不是会用，是会设计。随便打开一个你熟悉的数据产品，问自己：如果让你从零搭建它的数据系统，你会怎么选型？怎么分层？怎么保证数据质量？能把这些问题讲清楚，你就不是"会写 SQL 的数据开发"，而是一个"能 hold 住全局的数据架构师"。

第二，找一个业务领域深入扎进去。 金融、电商、供应链、广告，选一个你感兴趣的方向，花时间理解这个领域的业务逻辑。不只是理解"数据口径是什么"，而是理解"业务为什么需要这个口径"。在这个领域积累两年，你的不可替代性会比通用型数据开发高出不止一个数量级。

第三，把 AI 工具融入日常工作流。 不要抗拒。找两个最常用的 AI 辅助工具，实实在在地用到你的开发流程里。省下来的时间，拿来学上面那两件事。

数据开发这个岗位，不会消失。

但五年前"会写 Hive SQL 就能拿高薪"的那个时代，回不去了。

它正在从一个"拼手速"的工种，变成一个"拼判断"的职业。拼的是你对数据的理解深度、对业务问题的拆解能力、对整个数据系统的设计能力。

这些东西，恰好没有捷径——只能靠实打实的项目经验和深度思考来积累。

而正是因为没有捷径，它们才构成了真正的护城河。

如果你是那个愿意进化的人，这条路比你想的要宽。