写在前面
过去半年，聊到 AI Coding，大家最先想到的通常是补代码、写单测、改 Bug。放到数仓研发里，最直接的用法也差不多：给 AI 一段需求，让它生成 SQL。
生成 SQL当然也很有价值。原来要写半天的 SQL，现在十几分钟就能有一个初稿。但真正把数据需求做进生产的人都知道，SQL 只是中间的一小段。前面要澄清 PRD、确认指标口径、判断资产能不能复用、设计技术方案；后面还要建表、试跑、验数、发布任务、复验调度结果，最后把交付物和风险讲清楚。中间任何一步判断错了，SQL 写得再快也没有意义。
我们最初也从 Vibe Coding 开始：把需求丢给模型，边聊边改，先把 SQL 写出来。做得多了以后，问题逐渐暴露——同一个需求换个会话就像重新开始；模型会把不确定的口径补成一个“看起来合理”的答案；工具虽然越来越多，链路仍然要靠人来回搬运上下文。
于是。我们不再只想做一个更会写 SQL 的助手，而是希望把 Agent 放进真实的数仓研发环境：它能读到可信的上下文，按固定工序推进，调用真实平台，在关键风险点停下来找人确认；即使中途失败，也能从留下的状态和证据继续。
这就是我们理解的 AI Native 数仓研发，也是 OxygenData 从 Vibe Coding 走向 Harness 的出发点。
一、Vibe Coding 很快，但接不住完整交付
Vibe Coding 最吸引人的地方是快。需求还不完整，也可以先让模型给出一个版本，人再跟着结果继续补充。用它做一次性分析、验证思路或者生成 SQL 初稿，效率很高。
但当目标从“写出一段 SQL”变成“交付一个数据需求”，它会碰到三道坎。
第一道坎是口径。PRD 里一句“看店铺化后的曝光、点击、进店和成交表现”，落到开发侧就是一串问题：曝光算 UV 还是 PV，点击包含哪些页面，进店场景如何映射，成交金额取哪个字段，统计粒度和时间口径是什么。只要这些问题没有确认，模型就可能把空白补成一个语法正确、业务错误的答案。
第二道坎是上下文。PRD 在 JoySpace，表结构和血缘在元星图，指标在 DongMetrics，脚本在开发中心，任务在 Buffalo，数据集和看板又在 BI 平台。人可以靠经验在这些系统之间切换，聊天窗口却不会自动知道哪些信息可信、哪些已经过期。
第三道坎是工程状态。一个需求经常跨几天，中间可能遇到权限不足、试跑失败、口径返工或登录态失效。只靠聊天记录，很难准确回答：用户确认过什么，平台真正返回了哪些 ID，当前卡在哪一步，下次应该从哪里继续。
所以，Vibe Coding 解决的是局部生成效率，Harness 要解决的是团队交付的稳定性。前者关注“这次能不能写出来”，后者关注“这件事能不能按同一套规则反复做对”。
这里说的 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 的整体架构
我们把整体架构归成四层。
另外两类能力横跨全链路：一类是 manifest 和阶段产物，用来保存状态、证据和续跑点；另一类是验证、门禁与授权，用来定义完成标准并约束高风险操作。
这几层不是几套各自独立的系统。知识帮助 Agent 理解和判断，Skill 约束具体工序，MCP 连接真实平台，Orchestrator 编排顺序，Pipeline 负责交付，manifest 保存现场，验证结果再决定链路能不能往下走。
3.1 总编排只管秩序，不替执行器干活
Orchestrator 不写 SQL、不建表，也不搭看板。它负责编排全局秩序：识别本次要跑哪些阶段，校验上游产物，调度白名单 Skill，在关键节点停下来确认，记录阶段状态，最后汇总交付证据。
当前总链路按下面的阶段契约推进：
整体链路不是固定把所有阶段都跑一遍，而是根据资产意图和 TRD 决定真实路径。从 PRD 到知识回流的端到端流程。
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 不会现场补一个口径继续跑，而是返回 blocked(trd_gap)
，带着证据回到 TRD 修订。这样才能说清楚：谁做了决策、用户确认的是哪个版本、验收应该按什么标准进行。
四、TRD 是链路的大脑
需求澄清解决“业务想要什么”，资产探查解决“已有东西是否存在”，但这两步还不能直接指导执行。中间需要一个具备数据架构师视角的决策层，通盘回答：整条数据链路应该怎么改，为什么这样改，各层怎样衔接，风险在哪里，最后如何验收。
在 OxygenData 里，这个角色由 TRD 承担。
我们曾经尝试过另一种做法：需求澄清后，直接让物理表、数据集和看板三个 Agent 各自设计。局部看都说得通，拼起来却未必是一条正确的链路。物理表按订单粒度设计，数据集按用户日粒度聚合；上游按支付时间分区，看板却按下单时间筛选；表是 T+1 更新，页面标题写的却是“实时”。
问题不在某个执行器能力差，而在于没有人站在全局做架构取舍。一个数据架构师型 TRD，至少要回答六类问题：
目前我们已经用固定章节、资产证据、跨层约束和确认门禁，把 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 和平台怎样接棒。
需求进来后，Agent 先把“曝光、进店、成交”等业务词翻译成需要确认的统计口径；随后查询现有指标、表、数据集和看板，给出复用证据。TRD 统一确定粒度、时间口径、加工链路、刷新周期和验收规则，用户确认后，再拆给相应 Pipeline 执行。
人在这条链路中主要处理业务取舍和高风险操作；Agent 承担高频的信息收集、执行与校验；平台返回值决定真实状态。过去散落在人脑和多个系统里的现场，现在由 Harness 串了起来。
七、知识不是附属品，而是下一次交付的起点
模型、Skill 和工具都会更新，真正能长期复用的，是在一次次交付中被验证过的业务口径、架构决策、数据模型、验证规则和故障经验。不过这些知识也不是“永远正确”的，它们有适用范围，也会随着业务和系统变化而过期。
目前我们已经接上知识闭环的两端：链路开始时，根据当前阶段获取最小必要上下文；链路结束时，从交付证据中生成知识候选，由用户选择后再回流。PRD 阶段需要的是业务概念和口径，TRD 阶段需要的是架构决策和资产关系，开发阶段需要的是 Schema、研发规范和风险提示。没有必要把整个知识库一次塞给 Agent。
当前正在探索的知识初始化框架如下。它把多源元数据、血缘和业务语义组织到一起，但这仍是需要持续优化的能力，另外我们数开个人隐性经验知识沉淀，也是比较有挑战的事情。
下一步，我们希望把知识从“能搜到、能回流”推进到“能验证、能治理”。每条知识都应保留来源、适用范围、引用记录和验证证据，并经历草稿、已验证、生产证明等状态。过期或互相冲突的知识不能继续静默影响方案。
数仓知识本来就是一张关系网：看板用了哪些指标，指标依赖哪些字段，字段来自哪张表，表由哪个任务加工，某次 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 平台
