把计算从存储里拆出来形成了 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/ClaudeCode 这类编程类 AI 的出现正在改变整个编程的流程。但是如何让数据工程师也可以顺利的Vibe-Coding这正是我在探索的方向也是本文主要讨论的内容。我认为未来的数据工程不会再只是“人操作工具”。而变成Codex Data Engineering Skill Harness Data Engineering SaaS云端数仓能力。简单来讲就是过去Modern Data Stack 默认“人是操作中心”人理解工具、人点击界面、人串联流程、人承担上下文切换。但在 AI 和 Agentic 开发时代未来的数据工程不应该再只是“人操作一堆工具”应该是人定义目标Codex/ClaudeCode 拆解并自动开发、调试Data Engineering Skill Harness提供工程边界并翻译给云端SaaSSnowflake/ Iceberg/ 云数据仓库承载云端计算底层调度与同步引擎保障系统稳定运行人类负责对产生的结果进行Review、治理和最终判断。当 Codex / Claude Code 开始参与数据工程之后是不是可以将数据工程师从各种 Modern Data Stack的Dirty Work中解救出来让数据工程重新从“工具操作”回到“工程创造”。我认为这是在AI和Agent时代下数据工程组织方式必然要发生的变化。1. Modern Data Stack的问题不是工具能力不够而是人被复杂工具和设置过程消耗太多今天很多数据平台功能已经很完整。数据源管理、离线同步、实时 CDC、SQL 开发、工作流调度、实例日志、告警监控、权限审计、血缘分析基本都可以覆盖。但功能越多平台越复杂。菜单越来越多配置越来越细流程越来越长。数据工程师不是在驾驭工具而是在适应工具曾经红极一时的Modern Data Stack就是让工程师学一堆东西美其名曰DataStack而实际上工程师成为了“一堆工具”的奴隶工程师应该驾驭工具而不是一遍一遍迭代学习各种越来越多的工具。一个看似简单的 MySQL 到 Snowflake 同步任务背后可能涉及源端表结构、目标端 database/ schema/ warehouse/role、字段类型转换、同步策略、工作流依赖、失败日志、下游 SQL、最终报表口径哪怕用最先进的可视化的工具也需要拖拉拽好几步才可以完成整个流程。真正消耗人的不是某个技术点特别难而是上下文和工具切换太多。数据源在一个地方任务配置在一个地方工作流定时在一个地方日志在一个地方SQL 文件在 Git 或本地目录里Snowflake 的执行结果又在云端环境里。在过去没有更好的方式所以人只能亲自做。但当 Codex/ClaudeCode 这样的工程型 AI 出现后很多判断都可以通过大模型来进行处理细碎动作开始具备被自动拆解、自动调用、自动执行、自动反馈这就让Data Engineering Harness工具的出现成为了的可能。Data Engineering Harness 本质上不是一个新的数据开发平台而是一套面向 AI 和工程型 Agent 的数据工程能力框架。它把数据源管理、数据同步、CDC、SQL 开发、任务调度、日志诊断、权限审计、运行观测、成本控制和人工接管等能力封装成 Codex/ClaudeCode 可以调用、人类可以审查、企业可以治理的工程能力。换句话说Harness 要解决的不是“让 AI 会不会写 SQL”的问题而是解决AI 写完 SQL 之后能不能安全地运行AI 创建任务之后能不能被追踪和审计AI 调用 Snowflake 之后能不能控制权限和成本AI 生成工作流之后能不能被人理解、确认和接管。所以Data Engineering Harness 的价值不是替代数据工程师也不是简单替代数据平台而是把数据工程从“人手工操作工具”升级为“人定义目标Codex 执行任务平台提供边界企业沉淀 Know-how”的新范式。2. 为什么不能让 Codex 直接写脚本很多人会想既然 Codex 能写 SQL、能写 Python、能调用命令行那为什么还需要Data Engineering Harness直接让它连接 MySQL 和 Snowflake生成脚本跑起来不就行了吗这个想法在个人实验里可以成立但在企业级数据工程里行不通。因为企业数据工程不是和Java开发一样“把一段脚本跑通”这么简单在企业生产环境里数据任务必须进入一个可管理、可审计、可运维、可协作的数据工程体系至少他可以解决如下问题:如何在开发环境、生产环境有效限制CodeX/ClaudeCode操作避免Agent“删库跑路”如何设计、运行时出现的错误让CodeX/ClaudeCode理解和重新设计运行如何可以快速让其它人/Agent/代码工具看懂我的Agent写的数据工程失败之后能不能自动恢复重跑、补数可以通过重试、断点续传、失败节点重跑等机制处理这个表修改有没有影响下游可以通过可视化 DAG 看到上下游依赖关系数据同步ETL、DataMapping是否可以可视化展示DAG如何可视化操作出了问题谁来审计可以通过运行实例、操作记录、日志和告警信息回溯如果每次都让 AI 临时生成脚本本质上只是把“人手写脚本”变成“AI 生成脚本”。短期看起来快长期会形成新的技术债脚本风格不一、日志不统一、权限不清晰、失败不可控、运维不可追踪让整个数据工程回到了“ShellCrontab时代”。所以未来企业级 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 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 的核心价值不是“让人一步步操作”而是建立高度可观测性“让人可以快速进行Reivew、微调从而对开发过程、运维情况与结果建立信任”。它要把 Codex 的执行计划、任务变更、SQL Diff、DAG 依赖、运行状态、失败日志、成本风险以人能理解的方式快速呈现出来。简单来说CLI 适合 Codex 执行。GUI 适合人类审查。Harness 负责把两者连接起来。未来最好的 UI可能不是固定页面而是围绕一次具体工程动作动态生成的审查界面SQL 转换 Diff、同步任务确认、DAG 风险检查、成本评估、上线审批。UI 会是建立一个让人类对大模型产生的信任界面让人类可以快速理解大模型产生的ETL、DataMpapingDAG让人类之间可以进行工作交接协同工作。5. 未来数据工程师从工具熟练工到工程指挥官未来数据工程师不会消失。但数据工程师会分化。一类人仍然停留在工具操作层会点平台会配任务会改 SQL会查日志会手工拖 DAG。这些能力仍然有用但会越来越容易被 Agent 自动化。另一类人会往上走能定义业务目标能设计数据模型能判断指标口径能控制云数据仓库成本能理解调度、同步、CDC 和 SQL 工作流之间的关系能把团队经验沉淀进 Harness让 Codex/ClaudeCode 在正确边界内稳定执行。未来优秀的数据工程师不一定是最会Modern Data Stack的人而是最能组织工程能力的人。他知道哪些事情可以自动化哪些事情必须人工确认哪些规则可以交给 Harness哪些判断必须留给人哪些任务可以临时生成哪些能力必须沉淀成企业资产。过去数据工程师围着工具转。未来工具、Codex/ClaudeCode 和云端能力要围着工程目标转。小结未来的数据工程不是没有人而是人终于站到了更高的位置未来只会手工操作Modern Data Stack工具的数据工程师就会像只会手工编写Java的工程师一样被淘汰。但能够理解业务、理解数据工程、理解云数仓、理解 CodeX/ClaudeCode工作方式并且能把这些能力组织成 Harness 的数据工程师会越来越重要。
