OxygenData：从 Vibe Coding 到 Harness，我们怎样把 AI 接进数仓研发-京东云开发者社区

## 写在前面

过去半年，聊到 AI Coding，大家最先想到的通常是补代码、写单测、改 Bug。放到数仓研发里，最直接的用法也差不多：给 AI 一段需求，让它生成 SQL。

生成 SQL当然也很有价值。原来要写半天的 SQL，现在十几分钟就能有一个初稿。但真正把数据需求做进生产的人都知道，SQL 只是中间的一小段。前面要澄清 PRD、确认指标口径、判断资产能不能复用、设计技术方案；后面还要建表、试跑、验数、发布任务、复验调度结果，最后把交付物和风险讲清楚。中间任何一步判断错了，SQL 写得再快也没有意义。

我们最初也从 Vibe Coding 开始：把需求丢给模型，边聊边改，先把 SQL 写出来。做得多了以后，问题逐渐暴露——同一个需求换个会话就像重新开始；模型会把不确定的口径补成一个“看起来合理”的答案；工具虽然越来越多，链路仍然要靠人来回搬运上下文。

于是。我们不再只想做一个更会写 SQL 的助手，而是希望把 Agent 放进真实的数仓研发环境：它能读到可信的上下文，按固定工序推进，调用真实平台，在关键风险点停下来找人确认；即使中途失败，也能从留下的状态和证据继续。

这就是我们理解的 AI Native 数仓研发，也是 OxygenData 从 Vibe Coding 走向 Harness 的出发点。

![OxygenData 从 Vibe Coding 走向 Harness](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2026-08-29-18-28SMOxw958XmJUtCqe.png)

## 一、Vibe Coding 很快，但接不住完整交付

Vibe Coding 最吸引人的地方是快。需求还不完整，也可以先让模型给出一个版本，人再跟着结果继续补充。用它做一次性分析、验证思路或者生成 SQL 初稿，效率很高。

但当目标从“写出一段 SQL”变成“交付一个数据需求”，它会碰到三道坎。

第一道坎是口径。PRD 里一句“看店铺化后的曝光、点击、进店和成交表现”，落到开发侧就是一串问题：曝光算 UV 还是 PV，点击包含哪些页面，进店场景如何映射，成交金额取哪个字段，统计粒度和时间口径是什么。只要这些问题没有确认，模型就可能把空白补成一个语法正确、业务错误的答案。

第二道坎是上下文。PRD 在 JoySpace，表结构和血缘在元星图，指标在 DongMetrics，脚本在开发中心，任务在 Buffalo，数据集和看板又在 BI 平台。人可以靠经验在这些系统之间切换，聊天窗口却不会自动知道哪些信息可信、哪些已经过期。

第三道坎是工程状态。一个需求经常跨几天，中间可能遇到权限不足、试跑失败、口径返工或登录态失效。只靠聊天记录，很难准确回答：用户确认过什么，平台真正返回了哪些 ID，当前卡在哪一步，下次应该从哪里继续。

所以，Vibe Coding 解决的是局部生成效率，Harness 要解决的是团队交付的稳定性。前者关注“这次能不能写出来”，后者关注“这件事能不能按同一套规则反复做对”。

![从人驱动工具到人定义边界、Agent 推进流程](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2026-08-29-18-50q50ZoC6Uoco87DUZ.png)

这里说的 Harness 不是某个新工具，而是 Agent 的工作环境。模型负责理解和推理，Harness 给它知识、工序、工具、状态、验证方法和安全边界。没有这些东西，模型再聪明也只是一个善于对话的助手；有了这些工程约束，它才有机会参与真实交付。

## 二、我们经历的三个阶段

这套方案不是一开始就设计完整的，而是在一次次需求里逐渐补出来的。

### 2.1 第一阶段：让 AI 把 SQL 写快

最开始的做法很直接：贴需求、补表结构、让模型生成 SQL，再由开发同学手工检查和发布。它对单点开发很有效，也让我们很快看到模型在代码生成上的潜力。

问题是，质量高度依赖使用者。熟悉业务的人知道该补什么上下文、该检查哪里；经验少的人更容易接受模型给出的第一个答案。同一件事换个人做，结果差异很大。

### 2.2 第二阶段：用 Skill 和 MCP 补齐单点能力

接下来，我们把需求澄清、元数据查询、脚本开发、任务试跑等经验拆成 Skill，再通过 MCP 接上系统平台。Agent 不再只看用户贴过来的片段，而是能够查询表结构、血缘、脚本和任务状态。

这一步解决了“会不会做”和“能不能接触真实现场”的问题，但还没有解决“谁先做、谁后做”。每个 Skill 都能完成自己的事情，跨阶段交接仍然靠人判断；一旦某一步失败，后面是继续、回退还是改方案，也缺少统一规则。

### 2.3 第三阶段：用 Harness 管住整条链路

真正的变化发生在我们把 Orchestrator、TRD、Pipeline、manifest 和门禁放到一起之后。

需求先被澄清，现有资产先被探查；TRD 站在全局做技术决策；物理表、数据集和看板分别由自己的 Pipeline 执行；每一阶段都留下产物、状态和平台证据。下游只消费已经确认的上游结论，发现方案缺口就带着证据退回，不在执行过程中临时改口径。

至此，AI 不再只是链路中的一个生成工具，而是开始在工程约束下接力工作。这也是我们从 Vibe Coding 走向 Harness 的分界线。

## 三、OxygenData Harness 的整体架构

我们把整体架构归成四层。

| 层次 | 主要组成 | 解决什么问题 |
|---|---|---|
| 知识与上下文层 | 业务口径、模型资产、指标、血缘、研发规范、历史决策 | Agent 凭什么做判断 |
| 工序层 | PRD、资产探查、TRD、开发、验证、交付等 Skill | 每一棒怎样做、做到什么程度算完成 |
| 编排与执行层 | Orchestrator、TRD、物理表/数据集/看板 Pipeline | 谁先做、谁后做，方案怎样拆解和执行 |
| 平台连接层 | JoySpace、DongDP、DongMetrics、Buffalo、BI 等 MCP 能力 | 如何读取真实事实、完成真实操作 |

另外两类能力横跨全链路：一类是 manifest 和阶段产物，用来保存状态、证据和续跑点；另一类是验证、门禁与授权，用来定义完成标准并约束高风险操作。

![AI Native 数仓研发 Harness 分层架构](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2026-08-29-21-25wxE6TYzNcMZqPdO.png)

这几层不是几套各自独立的系统。知识帮助 Agent 理解和判断，Skill 约束具体工序，MCP 连接真实平台，Orchestrator 编排顺序，Pipeline 负责交付，manifest 保存现场，验证结果再决定链路能不能往下走。

### 3.1 总编排只管秩序，不替执行器干活

Orchestrator 不写 SQL、不建表，也不搭看板。它负责编排全局秩序：识别本次要跑哪些阶段，校验上游产物，调度白名单 Skill，在关键节点停下来确认，记录阶段状态，最后汇总交付证据。

当前总链路按下面的阶段契约推进：

| 阶段 | 做什么 | 核心产物或门禁 |
|---|---|---|
| 0 编排初始化 | 建立产物目录、执行计划和主 manifest | 本次链路可追踪、可续跑 |
| 1 PRD 澄清 | 把业务语言收敛成可开发需求 | 需求状态为确认 |
| 2 资产复用探查 | 对看板、数据集、物理表、贴源层识别意图并探查现状 | 每类资产都有迭代、新建或无需操作结论 |
| 3 TRD 方案设计 | 形成物理表、数据集、看板的统一技术方案 | 用户明确“确认 TRD” |
| 4 物理表 Pipeline | 开发脚本、建改表、试跑、验数、发布任务、调度复验、按需配置 DQC | 返回真实执行结果 |
| 5 数据集 Pipeline | 完成数据准备、预览、字段处理和保存发布 | 返回真实执行结果 |
| 6 看板 Pipeline | 完成搭建、预览、修订、验收和发布 | 返回真实执行结果 |
| 7 交付汇总与知识回流 | 汇总交付证据、未完成项和可复用知识 | 交付报告与知识回流回执 |

整体链路不是固定把所有阶段都跑一遍，而是根据资产意图和 TRD 决定真实路径。从 PRD 到知识回流的端到端流程。

![从 PRD 到交付与知识回流的端到端流程](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2026-08-29-21-52w29QZ8DEuPyzq5229d.png)

### 3.2 Skill 把经验写成工序

Skill 不是一篇“教模型怎么思考”的长提示词，而是一份工序契约。它要说清楚什么时候触发、需要什么输入、输出什么产物、哪些事情不能做，以及怎样才算完成。

比如，需求澄清 Skill 只负责把业务描述收敛成可计算需求；资产探查 Skill 返回候选和证据，但不替用户做业务取舍；物理表设计负责形成方案，不直接建表；任务试跑只试跑已有任务，不顺手创建任务。

边界越清楚，Skill 越容易组合，也越方便定位问题。一个什么都能做的“超级 Skill”，最终往往只是另一个难维护的巨型 Prompt。

### 3.3 MCP 让判断落在真实平台事实上

MCP 把 JoySpace、DongDP、DongMetrics、Buffalo 和 BI 等平台能力封装成标准工具接口。Skill 表达“要查什么、要完成什么”，认证、参数和平台调用交给 MCP。

这一步的价值不只是省去复制粘贴。更重要的是，Agent 可以在授权范围内读取实时元数据，并以平台返回值判断状态。没有拿到真实任务 ID，就不能说任务已经创建；试跑还在运行，就不能提前宣布成功。

### 3.4 TRD 负责设计，Pipeline 负责按方案交付

物理表、数据集和看板由三条 Pipeline 分别执行。设计层与执行层之间不靠聊天记录交接，而是靠 TRD 的固定章节和统一的 `pipeline_result` 连接。

- 物理表 Pipeline 消费 TRD 的模型方案，负责脚本、表结构、试跑、两次验数、任务发布与试跑、条件 DQC 和上线交接；
- 数据集 Pipeline 消费数据集方案，负责数据准备、预览、字段处理和保存发布；
- 看板 Pipeline 消费看板方案，负责页面搭建、预览修订、验收和发布。

![TRD 向三条 Pipeline 分发方案，执行结果回到主链路](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2026-08-29-22-176toPrO0OFyt29rmk.png)

如果执行中发现 TRD 有缺口，Pipeline 不会现场补一个口径继续跑，而是返回 `blocked(trd_gap)`，带着证据回到 TRD 修订。这样才能说清楚：谁做了决策、用户确认的是哪个版本、验收应该按什么标准进行。

## 四、TRD 是链路的大脑

需求澄清解决“业务想要什么”，资产探查解决“已有东西是否存在”，但这两步还不能直接指导执行。中间需要一个具备数据架构师视角的决策层，通盘回答：整条数据链路应该怎么改，为什么这样改，各层怎样衔接，风险在哪里，最后如何验收。

在 OxygenData 里，这个角色由 TRD 承担。

我们曾经尝试过另一种做法：需求澄清后，直接让物理表、数据集和看板三个 Agent 各自设计。局部看都说得通，拼起来却未必是一条正确的链路。物理表按订单粒度设计，数据集按用户日粒度聚合；上游按支付时间分区，看板却按下单时间筛选；表是 T+1 更新，页面标题写的却是“实时”。

问题不在某个执行器能力差，而在于没有人站在全局做架构取舍。一个数据架构师型 TRD，至少要回答六类问题：

| 能力 | TRD 要回答的问题 |
|---|---|
| 需求抽象 | 业务诉求最终对应哪些交付资产，哪些只是被提及或受影响 |
| 现状诊断 | 现有表、指标、数据集和看板能复用到什么程度，差距在哪里 |
| 总体设计 | 数据从哪里来，经过哪些层，以什么粒度和时效到达消费端 |
| 跨层约束 | 物理表、数据集、指标和看板的主键、粒度、口径、刷新周期是否一致 |
| 风险权衡 | 为什么选择复用、扩维或新建，成本、性能、SLA 和影响面怎样取舍 |
| 执行验收 | 方案怎样拆给各条 Pipeline，每一层拿到什么证据才算完成 |

![TRD 作为数据架构师决策中枢](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2026-08-29-22-303wVNhiRT30K9cUOy.png)

目前我们已经用固定章节、资产证据、跨层约束和确认门禁，把 TRD 从普通说明文档变成了下游执行的唯一方案输入。下一步还要继续补两件事：一是增强跨产物一致性检查，及时发现粒度、字段、时间口径和刷新周期冲突；二是积累真实架构决策案例，让 TRD 不只会套模板，也能解释为什么这样设计更合适。

SQL、建表和发布可以不断工具化，但只有 TRD 的架构判断合理，后面的自动执行才有意义。

## 五、真正让链路稳定下来的几个设计

### 5.1 先看现状，再决定要不要新建

AI 很擅长生成新东西，也很容易“见需求就新建”。放在数仓里，这通常意味着重复建表、重复造指标、重复建数据集。

因此，资产探查先判断看板、数据集、物理表和贴源层是否有改动意图。有意图才继续查，没有意图就明确跳过。系统给出候选资产、相似依据和上下游影响，最终资产是否复用，由TRD技术方案评估决策。

这一步看似多走了一段，实际省掉的是后面成本更高的返工和治理。

### 5.2 人只在真正需要决策的地方出现

不是每一步都要问人。确认太多，Agent 就会变成一个不断弹窗的流程机器人，真正重要的风险反而被一堆“是否继续”淹没。

我们把人工确认集中在两类事情上：一类是模型无法可靠判断的业务取舍，比如多个相似资产到底复用哪一个；另一类是会产生外部影响的写操作，比如生产建改表、写生产分区、发布生产任务和持久化 DQC 规则。

普通阶段切换、DEV 环境写入、只读验数和结果交接默认自动推进。生产写操作则必须展示对象、环境、变更、影响和停止方式，逐项授权。一次泛化的“继续”，不能放行后面所有线上动作。

### 5.3 下游不能顺手改上游方案

Agent 在执行时很容易做局部优化：写 SQL 时发现 TRD 不够顺，顺手改一下；做看板时觉得指标名不合适，直接换一个口径。

局部看很聪明，工程上却会失控。谁改了方案、用户确认的是哪个版本、验收按什么判断，最后都说不清。

所以我们坚持产物单向流动：下游只消费已经确认的上游产物；发现问题就带证据退回，不直接改写上游结论。

### 5.4 对话不是事实源，manifest 才是

一条数据需求可能跨小时甚至跨天，也可能换会话、换人接手。聊天记录适合沟通，不适合承担工程状态。

我们使用两级 manifest 保存现场：主 manifest 记录总链路阶段、确认事件和三条 Pipeline 的结果摘要；各 Pipeline 的子 manifest 记录内部状态、平台 ID、日志证据和续跑点。

链路中断后，Agent 不需要“回忆上次聊到哪里”，而是先读 manifest，校验上游产物和版本，再从合法阶段继续。团队要共享的事实，必须落在产物和平台里，不能只存在于某段对话中。

### 5.5 交付结束后，把经验变成下一次的上下文

一次需求里真正值得沉淀的，不是某次试跑日志，而是稳定的业务口径、加工逻辑、Schema、验证规则和资产链路。

链路收尾时，知识回流 Skill 会从交付证据里生成候选知识卡片，让用户选择后再提交。下一次遇到相似需求，Agent 能从这些知识开始，而不是重新问一遍、猜一遍。

## 六、以一个典型需求为例

以“店铺化经营看板”为例，业务希望看到曝光、点击、进店和成交表现。这里不是复盘某个具体项目，而是用一个典型场景说明人、Agent 和平台怎样接棒。

![店铺化经营看板需求的端到端时序](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2026-08-29-22-537nQTi6ZmfencJVw.png)

需求进来后，Agent 先把“曝光、进店、成交”等业务词翻译成需要确认的统计口径；随后查询现有指标、表、数据集和看板，给出复用证据。TRD 统一确定粒度、时间口径、加工链路、刷新周期和验收规则，用户确认后，再拆给相应 Pipeline 执行。

人在这条链路中主要处理业务取舍和高风险操作；Agent 承担高频的信息收集、执行与校验；平台返回值决定真实状态。过去散落在人脑和多个系统里的现场，现在由 Harness 串了起来。

## 七、知识不是附属品，而是下一次交付的起点

模型、Skill 和工具都会更新，真正能长期复用的，是在一次次交付中被验证过的业务口径、架构决策、数据模型、验证规则和故障经验。不过这些知识也不是“永远正确”的，它们有适用范围，也会随着业务和系统变化而过期。

目前我们已经接上知识闭环的两端：链路开始时，根据当前阶段获取最小必要上下文；链路结束时，从交付证据中生成知识候选，由用户选择后再回流。PRD 阶段需要的是业务概念和口径，TRD 阶段需要的是架构决策和资产关系，开发阶段需要的是 Schema、研发规范和风险提示。没有必要把整个知识库一次塞给 Agent。

当前正在探索的知识初始化框架如下。它把多源元数据、血缘和业务语义组织到一起，但这仍是需要持续优化的能力，另外我们数开个人隐性经验知识沉淀，也是比较有挑战的事情。

![建设中的知识初始化与关系构建框架](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2026-08-30-14-12h0ovo9JGGuVJpaz.png)

下一步，我们希望把知识从“能搜到、能回流”推进到“能验证、能治理”。每条知识都应保留来源、适用范围、引用记录和验证证据，并经历草稿、已验证、生产证明等状态。过期或互相冲突的知识不能继续静默影响方案。

数仓知识本来就是一张关系网：看板用了哪些指标，指标依赖哪些字段，字段来自哪张表，表由哪个任务加工，某次 TRD 为什么选择这条链路，最后又按什么规则验收。把这些关系连起来后，Agent 给出“复用这张表”的建议时，返回的不只是一个相似名称，而是一条可以追溯的决策链。

Harness 负责把需求稳定地送到终点，知识闭环则让每次交付都为下一次积累起点。这样才是团队级AI研发真正能够复利的地方。

## 八、当前还没有解决好的问题

这套链路已经能覆盖单脚本任务的设计、开发、验证和发布，但离“稳定接住复杂数仓交付”还有明显距离。当前最需要补的是下面三件事。

### 8.1 从单脚本任务走向工作流任务

目前任务交付的主要对象还是单脚本标准任务。遇到包含多个节点、依赖关系和分支条件的工作流，链路通常只能交付到脚本，后面的节点编排、依赖配置和整体发布仍要人工完成。

这不是简单地多调用几次任务创建接口。工作流需要新的方案表达和执行契约：TRD 要描述节点拓扑、上下游依赖、运行参数和失败策略；Pipeline 要支持整图校验、局部重跑和发布前检查；manifest 也要能记录节点级状态。只有这些能力补齐，Harness 才能从“交付一个脚本”走向“交付一条生产工作流的链路”。

### 8.2 减少对话轮次，提高首轮产物质量

逐题澄清可以降低误判，但问题不分轻重地一题一题问，会把链路拖得很长。用户一旦觉得过程太啰嗦，就会绕过流程，重新回到 Vibe Coding。

我们的方向是：会改变技术路线、有前后依赖的问题继续单独确认；互相独立、风险较低的问题合并成一张结构化确认单。每个阶段结束后，把已确认事实压缩到产物和 manifest，下游只拿当前需要的最小上下文，不再反复携带整段聊天历史。

同时，需求理解、TRD 和 SQL 还存在多轮修改后才能达标的情况。下一步要补跨产物一致性检查和真实案例评估集，持续观察首轮通过率、平均修订轮次和高频错误。稳定性不能靠一句“请认真检查”，要靠结构、校验、评估和反馈闭环做出来。

### 8.3 把线上写操作纳入统一安全控制面

现在各执行 Skill 已经对生产建改表、生产分区写入、任务发布和 DQC 持久化设置了确认门，但控制仍然分散。随着可写平台和操作类型增加，只靠每个 Skill 自己维护规则，很容易出现口径不一致或授权范围过大的问题。

后续需要建设统一的线上安全控制面：默认只读和 DEV 环境；生产操作按对象、动作和环境做最小授权；执行前展示影响面，执行后保留审计事件；参数或对象发生变化时重新确认；高风险操作支持暂停、超时和人工接管。确认不是一句“是否继续”，而是一份范围明确、能够追溯的授权。

## 结语

Vibe Coding 让我们看到了模型在数仓开发里的生成效率，也帮我们快速找到最值得自动化的局部工作。但当目标从“写出一段 SQL”变成“交付一个数据需求”，问题就不再只属于代码生成：上下文从哪里来，方案由谁负责，阶段怎样接力，失败回到哪里，什么证据才算完成，线上操作怎样受控。

OxygenData 的 Harness，就是把这些过去依赖数开经验和人脑记忆的事情，逐步写进一套团队可以共享的工程系统。

Skill 约束每一棒怎么做，MCP 连接真实现场，TRD 负责全局架构决策，Orchestrator 维持链路秩序，Pipeline 交付具体资产，manifest 保存状态和证据，门禁与人工确认守住质量和安全。

这套方案还在路上。工作流任务、产物稳定性、知识治理和线上安全控制面，都需要继续完善。

最后，工具变强了，人的判断力要跟着变强。

参考材料：

- [OxygenData 平台](https://oxygen-data.jd.com/)