未来十年数据工程：AI如何重新定义工具操作与工程创造

未来十年的数据工程

过去十年，数据工程的主线，是Modern Data Stack对传统数仓体系的一次拆解与重组。

我们把数据采集从数据库里拆出来，形成了Data Ingestion，用FiveTran、Airbyte、Apache SeaTunnel来解决ELT/CDC/Reverse ETL；
把计算从存储里拆出来，形成了Snowflake、Databricks、Iceberg、Hive这样的云数仓和湖仓体系；
把调度从脚本里拆出来，形成了Apache Airflow、Apache DolphinScheduler这样的Orchestration；
把SQL开发、数据建模、血缘、质量、BI、AI分析，又拆成了一系列独立工具。

这套体系当然是进步，它让数据工程从“一堆脚本+Crontab”的原始阶段，走向了云原生、弹性计算、工程化治理和开放生态。

然而，Modern Data Stack最大的贡献是“拆分”，最大的副作用也是“拆分”。工具越来越多，能力越来越强，但数据工程师却被迫在更多系统之间切换：数据源在一个地方，同步配置在一个地方，任务配置在一个地方，DAG在一个地方，日志在一个地方，SQL在Git里，Snowflake/Iceberg/云数仓的执行结果又在另一个环境里。

结果是，很多数据工程师真正的时间，并没有花在数据建模、业务理解、指标口径、架构设计和成本优化上，而是花在配置数据源、设置字段映射、拖拽DAG、修改SQL、查看日志、重跑任务这些Dirty Work上。这就是Modern Data Stack给数据工程师的困扰：数据工程师被困在工具里了。

而Codex/Claude Code这类编程类AI的出现，正在改变整个编程的流程。但如何让数据工程师也可以顺利的Vibe-Coding？这正是我在探索的方向，也是本文主要讨论的内容。

我认为未来的数据工程，不会再只是“人操作工具”。而变成：Codex+Data Engineering Skill&Harness+Data Engineering SaaS+云端数仓能力。简单来讲就是过去，Modern Data Stack默认“人是操作中心”：人理解工具、人点击界面、人串联流程、人承担上下文切换。但在AI和Agentic开发时代，未来的数据工程不应该再只是“人操作一堆工具”，应该是人定义目标，Codex执行任务，平台提供边界，企业沉淀Know-how。

当Codex/Claude Code开始参与数据工程之后，是不是可以将数据工程师从各种Modern Data Stack的Dirty Work中解救出来，让数据工程重新从“工具操作”回到“工程创造”。

我认为这是在AI和Agent时代下，数据工程组织方式必然要发生的变化。

1. Modern Data Stack的问题

今天很多数据平台功能已经很完整。数据源管理、离线同步、实时CDC、SQL开发、工作流调度、实例日志、告警监控、权限审计、血缘分析，基本都可以覆盖。但功能越多，平台越复杂。菜单越来越多，配置越来越细，流程越来越长。

数据工程师不是在驾驭工具，而是在适应工具。曾经红极一时的Modern Data Stack就是让工程师学一堆东西，美其名曰Data Stack，而实际上工程师成为了“一堆工具”的奴隶，工程师应该驾驭工具，而不是一遍一遍迭代学习各种越来越多的工具。

一个看似简单的MySQL到Snowflake同步任务，背后可能涉及源端表结构、目标端database/schema/warehouse/role、字段类型转换、同步策略、工作流依赖、失败日志、下游SQL、最终报表口径，哪怕用最先进的可视化工具也需要拖拉拽好几步才可以完成整个流程。

真正消耗人的，不是某个技术点特别难，而是上下文和工具切换太多。数据源在一个地方，任务配置在一个地方，工作流定时在一个地方，日志在一个地方，SQL文件在Git或本地目录里，Snowflake的执行结果又在云端环境里。

在过去没有更好的方式，所以人只能亲自做。

但当Codex/Claude Code这类工程型AI出现后，很多判断都可以通过大模型来进行处理，细碎动作开始具备被自动拆解、自动调用、自动执行、自动反馈，这就让Data Engineering Harness工具的出现成为了可能。

2. 为什么不能让Codex直接写脚本？

很多人会想：既然Codex能写SQL、能写Python、能调用命令行，那为什么还需要Data Engineering Harness？直接让它连接MySQL和Snowflake，生成脚本跑起来不就行了吗？

这个想法在个人实验里可以成立，但在企业级数据工程里行不通。

因为企业数据工程不是和Java开发一样“把一段脚本跑通”这么简单，在企业生产环境里，数据任务必须进入一个可管理、可审计、可运维、可协作的数据工程体系。

如何在开发环境、生产环境有效限制CodeX/ClaudeCode操作，避免Agent“删库跑路”？
如何设计、运行时出现的错误让CodeX/ClaudeCode理解和重新设计运行？
如何可以快速让其它人/Agent/代码工具看懂我的Agent写的数据工程？
失败之后能不能自动恢复（重跑、补数）？可以通过重试、断点续传、失败节点重跑等机制处理；
这个表修改有没有影响下游？可以通过可视化DAG看到上下游依赖关系；
数据同步，ETL、DataMapping是否可以可视化展示？DAG如何可视化操作？
出了问题谁来审计？可以通过运行实例、操作记录、日志和告警信息回溯；

如果每次都让AI临时生成脚本，本质上只是把“人手写脚本”变成“AI生成脚本”。短期看起来快，长期会形成新的技术债：脚本风格不一、日志不统一、权限不清晰、失败不可控、运维不可追踪，让整个数据工程回到了“Shell+Crontab时代”。

所以，未来企业级AI数据工程的关键，不是让Codex裸奔，而是给Codex一个清晰的工程边界。

这就是Data Engineering Harness的意义，也是我设计WhaleStudio Harness Suite的目标。Harness不是限制Codex/ClaudeCode，而是让Codex/ClaudeCode的能力变得可视化、可管理、可生产化。

3. Data Engineering Harness设计理念

未来的Data Engineering Harness不再只是传统意义上“给人点”的数据开发平台，而是面向Codex/ClaudeCode和Agentic开发重新组织的数据工程Harness和Skill套件。

以我们根据这套理念制作的WhaleStudio Harness Suite来讲，下Data Engineering Harness的组成大家更容易理解：过去，Apache DolphinScheduler解决调度和Orchestration问题，Apache SeaTunnel解决多数据源数据批量同步和CDC问题，WhaleStudio把这些能力整合成all-in-one平台加上企业级功能，给企业数据工程师使用。

但在大模型和Codex/ClaudeCode时代，仅仅给人提供GUI已经不够了。

未来的数据工程系统，既要让人能看懂、能审查、能接管，也要让Codex/ClaudeCode能通过CLI、接口和工程上下文稳定调用与反馈。

这意味着，WhaleStudio要把商业版DolphinScheduler和SeaTunnel的核心能力，包括调度、同步、CDC、SQL任务、实例运行、日志诊断、权限审计、可观测性，重新设计、组织成Agent可调用与调试、人类工程师可快速审查、企业可治理的能力层。

这不是在旧的数据开发平台上加一个AI按钮或者一个聊天窗口，而是重新以Agent作为最终用户，根据AI和大模型的记忆习惯、调用能力、反馈机制重新针对软件的交互“界面”进行设计。

换句话来讲：从底层的引擎、到上层的调用、开发、调试反馈的能力，要变成AI可以理解、调用、观测和受控执行的工程系统。

未来的数据工程平台，不再只是功能集合，而会成为企业Agent数据工程Know-how的容器。

企业积累的调度规则、同步经验、SQL迁移经验、Snowflake/云数据仓库成本控制经验、发布流程、异常处理机制，都应该沉淀进Harness和其相关Memory和Skill当中，让Codex/ClaudeCode调用的不是一个裸接口，而是一套被验证过的企业工程能力。

4. UI不会消失，但会从操作入口变成可观测性与微调的窗口

有了Codex/ClaudeCode之后，很多人会觉得企业软件的UI不重要了。

我认为不是。

UI不会消失，但它的角色会变化。过去UI是操作入口。人通过UI创建数据源、配置任务、拖拽DAG、设置调度、上线工作流、查看日志。

未来，很多动作会由Codex/CluadeCode完成，但人仍然必须看清楚Agent做了什么。它创建了哪些任务？用了哪些数据源？写入了Snowflake哪个schema？哪些SQL被修改？DAG依赖是否合理？运行失败是什么原因？是否影响下游？是否需要人工接管？不同的人员之间需要协同，团队合作。

总不能让所有人都翻另一个人的Prompt聊天记录来看如何开发的吧？这就是诞生了可观测性+可微调的UI界面需求。

未来UI的核心价值不是“让人一步步操作”，而是建立高度可观测性，让人可以快速进行Review、微调，从而对开发过程、运维情况与结果建立信任。它要把Codex的执行计划、任务变更、SQL Diff、DAG依赖、运行状态、失败日志、成本风险，以人能理解的方式快速呈现出来。

简单来说：CLI适合Codex执行。GUI适合人类审查。Harness负责把两者连接起来。

未来最好的UI，可能不是固定页面，而是围绕一次具体工程动作动态生成的审查界面：SQL转换Diff、同步任务确认、DAG风险检查、成本评估、上线审批。

UI会是建立一个让人类对大模型产生的信任界面，让人类可以快速理解大模型产生的ETL、DataMapping、DAG，让人类之间可以进行工作交接，协同工作。

5. 未来数据工程师：从工具熟练工到工程指挥官

未来数据工程师不会消失。但数据工程师会分化。

一类人仍然停留在工具操作层：会点平台，会配任务，会改SQL，会查日志，会手工拖DAG。这些能力仍然有用，但会越来越容易被Agent自动化。

另一类人会往上走：能定义业务目标，能设计数据模型，能判断指标口径，能控制云数据仓库成本，能理解调度、同步、CDC和SQL工作流之间的关系，能把团队经验沉淀进Harness，让Codex/ClaudeCode在正确边界内稳定执行。

未来优秀的数据工程师，不一定是最会Modern Data Stack的人，而是最能组织工程能力的人。

他知道哪些事情可以自动化，哪些事情必须人工确认；哪些规则可以交给Harness，哪些判断必须留给人；哪些任务可以临时生成，哪些能力必须沉淀成企业资产。

过去，数据工程师围着工具转。未来，工具、Codex/ClaudeCode和云端能力要围着工程目标转。

6. 小结

未来，只会手工操作Modern Data Stack工具的数据工程师就会像只会手工编写Java的工程师一样被淘汰。但能够理解业务、理解数据工程、理解云数仓、理解CodeX/ClaudeCode工作方式，并且能把这些能力组织成Harness的数据工程师，会越来越重要。

而这不是一个遥远的设想。

在我下面的实验Demo里，我已经完成了用Codex结合WhaleStudio Harness，只需要花10分钟完成了一个从MySQL到Snowflake的数据ETL+自动化建立SQL Orchestration的工程流程：通过CLI调用能力，自动识别数据源，创建同步任务，生成可视化DAG，执行工作流，查看日志，并把SQL转换成Snowflake可运行的任务链路，并自动调试错误，修正内容。

通过这个Demo，你可以体会到，未来数据工程师是如何工作的。

数据工程的下一个十年，工具不会更多，而是AI开始深度融合工具当中，开始理解目标、服从边界，并接受人的审查，而这就是Data Engineering Harness。