聊到数据研发，大家第一反应往往是“写SQL、做报表、调优运维”。但菜鸟在深度拥抱AI之后，发现这套传统流程正在被重新定义。作为DataWorks DataAgent的首批深度共创用户，菜鸟集团结合自身在物流行业十余年的数仓建设经验，自研了一套名为SuperETL的智能体系统。这套系统通过精细化的Skill编排、生产级的安全阻断机制，以及结构化的知识沉淀，将数据研发效率直接拉高了2-3倍。在一些核心场景里，AI的自动完成率甚至超过了80%。这不仅仅是工具层面的优化，更像是一次从“工具辅助”到“智能体主导”的范式跃迁。
那么，具体是怎么做到的？我们从头拆解。
研发现状与核心痛点：为什么传统链路难以为继？
菜鸟的数据研发流程，其实跟多数企业大同小异。从需求到交付，大致可以拆成6个阶段，精力分布接近3:5:2——30%花在需求调研上，50%用于同步、建模、开发与运维，剩下的20%才是数据应用。这套链路本身并不新鲜，但真正的问题在于它横跨了多个技术栈：需求管理用Aone，离线开发用DataWorks，实时计算靠Flink，湖仓存储选Paimon，最终报表又落到FBI。链路过长，平台割裂，协同成本自然居高不下。
系统性复盘后，团队总结了三大瓶颈，直指传统模式的硬伤：
流程割裂。 多引擎架构导致链路被拆得七零八落。从需求管理到任务开发，再到流计算、湖仓和数据应用，每跳过一个平台，信息就要重新对齐一次，沟通成本远高于技术成本。
规范虚设。 物流领域沉淀下来的表命名规则、字段标准、分层架构等规范，按理说应该是指南针。但人员一流动，执行机制一缺失，这些规范就沦为了躺在文档里的字。实际执行率到底有多少？无从量化。
质量难控。 数据测试覆盖不全、DQC配置不合理、代码评审流于形式——这些问题带来的后果，直接体现在运维负担上。模型一旦发布，下游可能牵扯十层依赖、几百个任务。出了问题，修复成本是一路狂飙的指数级增长。
破局思路：结合DataWorks DataAgent构建SuperETL智能体系统
DataWorks DataAgent本身并不是一个简单的SQL生成器。它的定位是“懂业务的智能体”。覆盖数据集成、开发、运维、治理、分析全链路，能通过自然语言完成复杂的数据开发任务。关键是，它可以深度适配用户的业务逻辑，成为真正“懂行”的AI同事。
基于这个底座，菜鸟构建了SuperETL智能体系统。这个系统的核心理念，是实现三个维度的转变：
- 开发方式转变： 从“工具辅助”到“智能体驱动”。AI不再只是帮写代码的辅助角色，而是研发流程的主导者；人类专家则退居幕后，负责规则制定和质量把关。
- 业务深度融合： 注入物流领域的“行业Know-how”。包括数仓规范、表命名标准、指标口径定义等，全部通过结构化方式沉淀为AI可执行的Skills。
- 价值显著体现： 部分场景的开发效率提升2-3倍。特别是在采购领域的数据建设上，AI能自动完成大部分工作，几乎是“从需求到交付”的全流程闭环。
DataWorks DataAgent提供了完整的底座支撑。交互层支持CLI、IDE、IM、OpenAPI多入口统一负载；资源层通过Serverless Resource Group实现弹性伸缩；执行层则有Code Agent Sandbox代码沙箱、Claw运维服务、MCP/Skill Runtime工具执行。最终构成的是一个免运维、可弹性、强隔离的企业级全托管体系。
SuperETL核心架构：九大精细化Skill编排体系
SuperETL本质上是一个集成了菜鸟物流行业经验的中间层研发Skill编排体系。那么问题来了：为什么不把全链路打包进一个Skill？
原因很直接——数据规范、Checklist、运维经验构成的上下文实在是太庞大了。如果你试图把所有这些信息一股脑塞进一个Skill里，大模型很难精确控制每一步操作。参考开源Superpower模式，菜鸟的做法是把数据研发场景拆成了9个独立的Skill，再加上铁律约束。这样就能实现“意图路由→分步执行→安全拦截”的精细化管理。
九大技能体系的精细编排：
- using-superetl（元技能）： 入口路由器，负责意图识别。铁律：禁止直跳子技能。
- etl-deepresearch（检索）： 先搜后答。将行业经验沉淀为MD文档检索。铁律：先搜索后回答，禁止先问用户。
- etl-debugging（诊断）： 处理数据问题。铁律：无数据证据前绝不提修复方案。
- etl-brainstorming（需求沟通）： 压制AI幻觉。铁律：设计未确认前禁止发布。
- etl-writing-plans（计划编写）： 输出MD格式的实施计划。铁律：计划确认前禁止写SQL。
- etl-validated-coding（验证式开发）： 边探查边编写，包含单元测试。铁律：没有验证证据的SQL禁止发布。
- etl-review-and-release（评审与发布）： 人工与AI审查结合。铁律：未通过检查项禁止发布，没有例外。
- etl-dispatch-parallel（并行分派）： 处理独立任务。铁律：有依赖时禁止并行。
- etl-subagent-driven（子袋里驱动）： 独立子袋里，再加两阶段审查。
执行流程从需求接入开始，强制注入using-superetl元技能进行场景判断。如果走数据需求，就进入etl-deepresearch深度检索；如果是诊断巡检，就走etl-diagnosis；如果是数据异常，则走etl-debugging。deepresearch还有一个置信度评估机制：30%-90%置信度的，精准提问1-2个问题；低于30%的，直接进入头脑风暴；超过90%的，直接回答。之后依次经过计划编写、验证式编程、评审发布，步步为营。
六大知识资源库：
| 目录 | 内容示例 | 作用 |
|---|---|---|
| spec/ | 数仓架构、表设计、字段标准 | 提供AI检索的权威依据 |
| checklists/ | 模型设计Checklist、发布前Checklist | 强制质量卡点 |
| templates/ | DDL模板、ETL SQL模板 | 保障代码风格统一 |
| guides/ | 离线建模理论、Medallion架构 | 补充领域知识 |
| techniques/ | SQL优化、运维排障经验 | 沉淀实战Know-how |
| wiki/ | 原始业务文档、实体关系 | 构建知识图谱基座 |
Hooks机制：生产安全的核心保障
Hooks机制是整个系统的安全核心。它定义了四个触发时机：SessionStart（会话启动）、PreToolUse（工具调用前）、PostToolUse（工具调用后）、SessionEnd（会话结束）。通过hooks.json路由配置，使用matcher正则匹配来选择合适的hook脚本，由run-hook.cmd负责执行。
典型能力场景包括：会话启动时注入using-superetl、规范读取追踪、数据上报、DataWorks发布阻断、wiki整合等。其中最关键的莫过于发布阻断机制。当检测到写操作或发布命令时，Hook会直接拦截，并给出提示：“检测到发布/写操作，必须先完成发布前检查清单。”只有逐项验证通过，且命令前携带了CHECKLIST_VERIFIED=1前缀，才能放行。这个设计彻底杜绝了“带病上线”的可能性。
CLI工具与未来研发范式
为了支撑SuperETL，菜鸟构建了cn-odpscmd统一CLI工具。它覆盖了ODPS、DataWorks、元数据、FBI报表等所有核心能力。特别强调一点：工具严格区分开发环境（带_dev后缀）和生产环境。所有SQL查询，都必须在开发环境执行。
核心能力包括：权限初始化与登录、SQL查询执行（query执行SQL，query--file从脚本执行，query--output导出CSV）、DataWorks脚本管理（createnode创建、updatenode更新、deploynode发布）、元数据查询（tablemeta查表结构、tablelineage查血缘、tasklogs查日志）、FBI报表查询以及项目空间权限查询。
实战推演：物流单量汇总表新增字段
理论说完了，来看一个真实的例子。假设有个需求：为物流单量汇总表dws_lgt_order_1d新增一个“签收及时率”字段。整个流程被拆成了六步，每一步都展示了SuperETL的实战价值。
第一步：意图路由。 using-superetl读取请求“新增签收及时率字段”。匹配触发词后，路由到deepresearch。SessionStart时注入9个技能，最终输出分类结果为“新增字段需求”。Hook在SessionStart时注入skillsystem，确保using-superetl始终作为入口。
第二步：拉取检索。 etl-deepresearch检索表结构dws_lgt_order_1d，读取规范spec/02、03，再通过dataworksskills检索任务和下游。评估置信度低于90%后，将任务转交给brainstorming。Hook通过spec-tracker记录规范读取情况，track-skill-invocation记录技能调用。
第三步：明确逻辑。 etl-brainstorming明确业务逻辑：签收及时率=及时签收/总单量。确定数据类型为DECIMAL[10,4]，字段命名为sign_on_time_rate，数据来源是ods_logistics_order。最终由用户确认设计方案。Hook记录技能调用并读取DDL template。
第四步：生成计划。 etl-writing-plans编写实施计划：ALTER TABLE ADD COLUMN，修改ETL SQL增加计算，数据测试比对计算结果，制定回刷方案重算历史数据。最终输出计划到docs/plans/目录。Hook推荐checklist并将计划输出到指定位置。
第五步：验证开发。 etl-validated-coding编写DDL+ETL SQL变更。单元测试通过后，进行数据验证和SQL性能优化。最后由etl-code-reviewer Agent进行审查。Hook在PostToolUse阶段通过spec-tracker持续追踪。
第六步：安全发布。 etl-review-and-release完成功能验证（数据测试通过），准备回刷回退脚本，配置DQC+SLA监控，完善注释。在CHECKLIST_VERIFIED=1确认后，才能发布到生产环境。Hook在deploy-check时通过flag判断是否放行。
这个案例完整展示了SuperETL如何将一个看似简单的字段新增需求，通过标准化的技能编排、规范检索、交互式确认、计划编写、验证式开发、checklist审查，最终安全发布到生产环境。整个过程有条不紊，AI的角色从“执行者”变成了“流程主导者”。
展望AI时代的数据研发范式
那么，未来的研发范式会变成什么样？
不变的是数据分层架构（ODS-CDM-ADM）和维度建模方式。每个数据域依然包含ODS贴源层、CDM公共模型（DWD/DWS/DIM）、ADM分析域。这些是数据工程的基石，不会因为AI的介入而改变。
变化的是组织方式与交付物。从项目制数仓走向数据网格/数据域，按业务域拆分（比如交易、物流、LLM数据域）。知识层（WIKI/知识图谱）被空前强化，表知识定义、概念实体、指标层次关系都将作为核心资产纳入研发范式。
应用层会全面AI化。传统BI看板之外，会出现AI Skills（自然语言知识检索）、AI Reports（自动生成经营分析）和System Apps（数据驱动业务动作）。LLM数据域被显式纳入，大模型调用、成本、时效都成为数据平台治理的一部分。
交付物也从报表转向AI分析Skill、分析思路及深度分析报告。数据研发不再是“建表—出数—做报表”的循环，而是“源系统采集→域化建模→知识化沉淀→AI可用→应用自动化”的完整闭环。
总结一下：菜鸟SuperETL的实践证明，这场AI时代的数据研发升级，本质上就是将DataWorks DataAgent与行业知识、研发规范、质量标准有机结合，并系统性地转化为AI可执行的技能体系。通过九大Skill的精细编排、Hooks的安全阻断、CLI工程的支撑与知识资产的沉淀，才能最终实现从“人写代码”到“人定规则、AI执行交付”的真正跨越。这条路，可复制、可落地，值得所有在数据领域深耕的团队认真参考。
