Copilot 需求交付 Skill 如何实现数据需求24h交付

前置说明

▐  术语解释

在淘宝直播数据团队内，大量同学已经习惯了通过 DataWorks Copilot 等生码工具生成 SQL ，提升需求交付的效率 。现阶段SOTA的代码模型生码质量确实强大——一个简单的取数需求，如果口径清晰、来源表明确、数据模型定义准确（表与表关联关系、业务语义翻译），通过和 Copilot 对话，大约十分钟以内就能得到一段主体框架正确，基本能运行的代码。

但问题在于："口径清晰、来源表明确、数据模型定义准确"这个前提，在真实的工作场景里恰恰是不具备的。用了半年后，笔者总结出了当前在使用AI生成SQL代码时的几个痛点。

▐  痛点 1：写 Prompt 这件事本身就很累

大家都知道 Copilot 生码质量取决于 Prompt 质量，但问题是：

你要自己从需求描述里提取关键信息，自己回忆或翻文档找来源表，自己梳理字段映射关系和加工口径，自己组织一段结构化的提示词。这整个过程全靠人脑跑，一次复杂需求光"写 Prompt 准备工作"就要半小时起步。那可能还不如自己手写代码了。

本质问题：Prompt Engineering 是一套独立的心智负担。编写时用户脑子里同时要装业务口径 + 表结构 + 团队代码规范 + Copilot 的偏好格式，本身就要花费时间。

▐  痛点 2：复杂业务逻辑生码质量差

一旦遇到业务语义模糊、逻辑复杂需求，Copilot 基本就"崩了"：

这个需求有多个数据源、多层 CTE 嵌套、复杂的配对逻辑（比如"取跟着 事件id为 1019 后的第一条 1021/1023/1026"），直接丢给 Copilot 的结果通常是：

• 编造不存在的表名

• 不遵守离线研发规范或指标命名规范

• 数据模型设计混乱，业务语义不能准确翻译成 SQL 代码逻辑

造成的结果就是，把需求 PRD 简单处理后输入给大模型生成代码，改 bug 的时间比从头开始写还多。

本质问题：LLM 对"复杂嵌套逻辑"和"隐含业务约束"的理解能力有限，复杂业务逻辑需求的模型设计、需求拆解还是依赖有经验的数据研发同学来完成。

更深入地分析：当前网页端 Copilot 的交互模式没有 spec 约束，大模型当然可以"猜"，但当它在业务逻辑翻译、表与表关联、聚合粒度上猜错其中一步时，整段 SQL 就废了——而且用户很难指导模型修改，只能整段重写。

解决的方法就是 Spec Coding（规约驱动编程） ——在让 AI 写代码之前，先让 AI 帮你把"要写什么"搞明白，产出一份双方确认过的规格说明书（Spec），再基于 Spec 让 AI 写代码。代码生成不再是"黑盒魔法"，而是"翻译"——把经过人类 review 的模型设计翻译成代码。

▐  痛点 3：多轮对话的"熵增定律"

Copilot Agent 模式可以多轮对话，上一轮的结果可以作为下一轮的上下文。这本来是好事——但实际体验是：

你在一个session的对话里完成了需求输入、问题澄清后，模型生成了代码，但是你还是发现有几处地方有问题。当你通过和它对话修复了部分错误以后，上下文越来越长，模型思考越来越久，效果也有一定衰减。这个时候，你想开一个新对话——那就得把之前整理好的需求内容、表结构、纠错的对话从头再跟它说一遍。

本质问题：多轮对话的上下文越来越长，网页端生码不适合长程沟通，需要拆解需求完成过程，对中间过程状态做落盘归档。

▐  痛点 4：需求评审后没有明确的产物

这个痛点藏得最深，但杀伤力最大。

需求评审以后没有明确的产物，对需求的理解停留在需求描述、钉钉聊天记录和大家的脑子里。例如：业务方说"确收成交金额"，数据同学认为就是普通口径的确收成交金额，但是没想到业务真实要的是锁支付确收成交金额。几天后需求交付，验数的过程中，业务方说"这个数不对"，数据同学查了才发现——口径理解不一致。

没有一份双方都认可的结构化需求方案做锚点，所有口头共识都是薛定谔的共识——在真正看数据之前，你永远不知道它是"一致"还是"不一致"。

本质问题：缺少一份标准化的、需求方和数据方共同对齐的中间产物。PRD 太粗，SQL 太细，中间缺了一层"数据语义翻译层"。

▐  痛点 5：多需求只能串行排期，交付效率低

▐  痛点总结

五个痛点串起来看，其实指向同一个根因：

因此，笔者做了： Copilot 需求交付 Skill（copilot_req2sql）。整个Skill分为4个阶段工作流，产出的 P1-P4 文档，本质上就是一份分阶段确认的 Spec 文档链：从需求澄清 → 资源梳理 → 模型设计 → 交互物 Prompt，每一步都是一个不可篡改的"锚点"，上一步不确认就不推进下一步。

▐  一句话定义

copilot_req2sql 是一个数据需求交付 Agent Skill。它的输入是一份业务需求（可以是从 Aone、钉钉消息、PRD 中提取的描述），输出是一份结构化的 Copilot 交互物(prompt)，可以直接复制到 DataWorks Copilot 或其他大模型中生成高质量 SQL 代码。

整个过程通过和Agent对话完成，包含 4 个阶段：需求澄清、资源管理、模型设计、交付物产出。

▐  Spec 目录结构

Skill 执行过程中会自动创建规范的目录结构，每个需求对应一个独立的 Spec 目录：

specs/├─ yyyymmdd_{任务名}/    ├── stages/               # agent工作流程        ├── p1_requirement.md              # 需求澄清结果        ├── p2_resources.md              # 相关表和伪代码        ├── p3_model_design.md         # 模型设计          ├── p4_copilot_input.md         # 给copilot的input        ├── workflow_events.jsonl           # 工作流事件记录                ├── proposal/               # 人整理的信息        ├── yyyymmdd_proposal.md  # 人整理的信息

这种目录结构的好处是：

• 清晰分层：stages 目录存放 Agent 自动生成的文档，proposal 目录存放人工整理的原始需求

• 可追溯：workflow_events.jsonl 记录了整个工作流的执行过程，便于问题排查

• 可复用：每个需求的 P1-P4 文档都是独立的、可复用的资产

• 可并行：每个需求独立的 Spec 目录让 Agent 可以并行为多个需求推进 P1-P3 阶段，数据研发同学只需在关键节点（P1 确认、P3 CR）介入，实现多需求并行处理

▐  Skill 工作流

整个Skill本质上是分阶段的 Spec 的编程范式：

一言以蔽之：普通的 AI 辅助编程是"你说需求，AI 写代码"；Spec Coding 是"你说需求 → AI 帮你写 Spec → 你 review Spec → AI 基于 Spec 写代码"。这一步"review Spec"的引入，把不可控的"黑盒生成"变成了可审计的"分层交付"。

▐  案例一：直播活跃用户统计（24h交付）

• 需求沟通

原需求描述如下，其中相关表和口径为需求沟通时确认。

# 要求时间周期：2025年10月-2026年3月，自然月的月维度数据维度：月份，观看直播总时长分布（小于10分钟，大于等于10分钟且小于等于30分钟，大于等于30分钟）指标：活跃消费者数（去重uv）、活跃且确收消费者数（去重uv）活跃消费者就是观看直播的消费者# 相关表## 活跃用户圈选my_project.dim_user_tag## 观看直播总时长read_timemy_project.dws_vst_pv_1d## 确收my_project.dws_vst_trd_1d

• Skill使用过程

1. 新建spec目录

2. 需求澄清（将Aone需求描述复制到本地spec目录的proposal文件夹中）

3. 模型设计（AI自动推进，人工CR）

5. 最终AI生成代码（0人工修改）

▐  渐进式披露：Skill 的上下文管理设计

在深入介绍各个阶段之前，先讲一个容易被忽略但极其关键的设计维度——渐进式披露（Progressive Disclosure）——这也是 Skill 区别于传统"写一份 prompt 模板"的地方。

• 为什么渐进式披露对 Agent Skill 至关重要

大模型有一个"反直觉"的特性：更多上下文不等于更好输出。当你把所有规则、模板、示例、规范一股脑塞进 Prompt 时——

• 模型容易"迷失中间"（Lost in the Middle）：关键约束被淹没在样板信息中

• 注意力被稀释：模型不确定哪些是"必须遵守的"、哪些是"仅供参考的"

• 不同任务的规则互相干扰：查表规则和模型设计规则混在一起，模型容易张冠李戴

渐进式披露要解决的问题就是：在正确的时间，给模型正确量级的信息。

• Skill 中的渐进式披露设计

SKILL.md                            ├── references/  │   ├── requirement_example/      │   ├── resource_example/         │   ├── model_design_example/     │   ├── copilot_input_example/    │   ├── etl_rules/                │   └── workflow_explaination/

主文件 SKILL.md 只有 4 阶段的路由定义和核心规则，约 200 行。每个阶段的具体执行模板、示例、规范文档在 references/ 的 7 组文件中，Agent 在执行到对应阶段时才按需加载。

▐  阶段1: 交付物定义

Skill 的第一项核心能力是从自然语言需求中提取维度列表和指标列表。举个例子：

原始需求：「帮我看下 20251009 到 20251111 各玩法类型的红包效果，包括曝光、领取、核销和成交」

Agent 自动提取：

提取完成后，agent 会逐项跟你确认。这个过程遵循严格的澄清原则：

• 一次一个问题：不同时问多个问题，避免信息混乱

• 多选优先：能给选项就给选项，减少你的输入负担

• 追问模糊点：关键信息不明确时追问，不猜测

• 不修改原始字段名：完全保持用户输入的字段名称

• 有表名就填、无表名写"暂无"：绝不自行推断未明确给出的内容

▐  阶段2：表、口径搜索 + 校验

阶段 2 的核心任务是把 P1 里澄清的维度和指标，映射到具体的表和口径上。这相当于给 Agent 装上一份"地图"——没有地图，Agent 只能在黑暗里猜；有了地图，它才知道每一步该走哪条路。

想要让模型生成正确的SQL代码，用户需要给出明确的来源表和指标口径。这不是阶段 2 才做的事——它应该在阶段 1 的交付物澄清中就搞定。P1 定义的每一个指标，最好都应该附带：

• 指标口径："用什么字段？是否需要额外加工？加工粒度时什么"

• 来源表："这个指标从哪张表取？"

• 过滤条件："有什么限制条件？"

但是，对数据研发同学来说，根据需求中的交付物定义，找到对应的指标和表也是需要耗时耗力的。我们可以从使用频率将指标和口径分为常用和不常用两类。

直播数据团队已经建设了语义层知识库，常用口径可以在本地知识库中自动搜索。Agent 在搜索完成后会自动查询表结构、确认字段是否满足，最后让用户确认即可。

但对于不常用、临时的口径或者新引入的表，语义层帮不了忙。这时候需要有经验的数据研发同学手动探查——跑一段验证 SQL、确认字段类型、检查分区是否存在——然后把探查结果告诉 Agent，由 Agent 整理到 P2 资源文档中。这是人工经验发挥价值的地方，也是 LLM 目前无法替代的环节。

关键优势：多需求并行推进

传统模式下，每个需求的前置准备工作（查表、确认口径、整理方案）都需要数据研发同学亲自完成，只能串行处理。而通过 Skill，多个需求可以同时启动 P1-P3 阶段的自动化流程：

• 需求 A：Agent 正在执行 P2 搜索表结构

• 需求 B：Agent 正在执行 P1 需求澄清

• 需求 C：等待 P3 模型设计的 CR 确认

数据研发同学只需在关键决策点介入（P1 确认、P3 CR），其他时间 Agent 可以并行为多个需求推进，将原本的"串行排期"变为"并行推进"，大幅提升多需求场景下的交付效率。

▐  阶段3：模型设计

阶段 3 是整个 Skill 流程中最重要、也最需要人工介入的环节。这里有一个必须想明白的因果关系链：

P3 模型设计质量 → P4 交互物质量 → Copilot 生码质量

如果 模型设计 的 DDL 分区策略写错了，P4 就会带着错误的分区策略传给 Copilot；如果 模型设计 的伪代码 JOIN 逻辑有问题，P4 就会让 Copilot "翻译"一段有问题的逻辑；如果 模型设计 的字段映射漏了一个关键字段，P4 就不会告诉 Copilot 这个字段的存在。

• 哪些规范要写在 Rule 里

通用规则可以沉淀。直播业务的名词规范、指标命名规范、表命名规范、模型设计原则等，这些是长期积累的知识，应该写入 Skill 的 Rule 层，让每次调用都能自动遵循。

业务特定规则需要人工决策。比如"这个需求应该用宽表还是星型模型"、"数据应该按天分区还是按小时分区"、"这个指标应该用累加值还是快照值"——这些决策依赖业务场景和数据特性，无法完全自动化，需要数据研发同学的专业判断。

• 为什么一定要用户 CR

直播数仓的规范很复杂，即使使用了渐进式披露，大模型也难以100%遵循。直播数仓的表命名规范、指标命名规范、业务域黑话、名词解释、代码规范等相当复杂，即使这些规则放在参考文件里，通过渐进式披露让 LLM 自主使用，也很难完全遵守。

规范再完善，也无法替代人对具体问题的理解与判断。对业务逻辑的理解、对技术边界的把握、对潜在问题的预判——这些能力无法通过几个 Markdown 文件传递给 AI。Agent 可以根据文档规范自动完成 90% 的设计工作——加工步骤、流程图、DDL、伪代码等。人工 CR 的作用是校验规范的遵循情况，以及对模型给出的技术方案，做最后的确认。

▐  阶段4：Copilot 交互物 —— 把"设计方案"变成 Copilot 的"施工图纸"

如果说阶段 3 是"设计蓝图"，阶段 4 就是"施工图纸"——它负责把 P3 确认过的模型设计，翻译成一份 Copilot 可以直接执行的结构化 Prompt。

P4 的质量上限由 P3 决定。 P3 的 DDL 对了，P4 才可能对；P3 的伪代码逻辑正确，P4 才可能让 Copilot 生成正确的 SQL。所以上一节强调的 P3 人工 CR，本质上就是在为 P4 的质量"上保险"。

第一，P4 解决的是上下文问题，不是能力问题。 即使 P4 写得再完美，Copilot 生成的 SQL 仍需人工 CR。Spec Coding 让 AI 的输出"更可被审计"，但"审计"这件事仍然需要人来做。P4 本身就是渐进式披露思想的一个体现——Copilot 不需要知道 P1 的澄清过程、P2 的字段映射讨论、P3 的 DDL 演变历史，它只需要看到"最终结论"。

▐  Spec Coding 在 SQL 生码的应用

• 传统模式对比

到这里，你可能已经注意到一个模式：每一阶段产出的都是文档（Spec），而不是代码。

这是有意为之。让我们对比两种范式：

传统模式：每一步都没有"可确认的中间产物"。debug 是在代码层修的，prompt 是脑子里组织的，模型为什么写错了也不知道。两周后回头看，谁也说不清当初为什么这么写。

Spec Coding 模式：需求 → Spec → 代码

每一步都有一个可 review、可确认、可追溯的文档锚点。好处非常具体：

对抗痛点 1（手工搜集 Prompt 累）→ 自动化：P4 包含的所有信息——需求背景、维度/指标清单、来源表+字段映射、DDL、伪代码——全部由 Agent 在 P1-P3 阶段自动生成，你不需要手动整理一个字。

对抗痛点 2（复杂 SQL 效果差）→ 把设计复杂度消化在 P3：Copilot 拿到的 P4 里，CTE 命名、JOIN 逻辑、聚合方式、过滤条件都已在 P3 确认过。Copilot 不需要"设计"，只需要"翻译"——把伪代码翻译成规范格式的真实 SQL。

对抗痛点 3（多轮对话退化）→ Spec 的"无状态"优势：P4 是独立的、自包含的 Prompt——不引用历史、不依赖上下文。新对话只需要引用最终的 Spec 产物（P4），不需要携带整段对话历史。本质上是把 Copilot 从"有状态服务"降级为"无状态服务"。

对抗痛点 4（评审后缺少标准方案）→ 可确认的中间产物：传统的 Code Review 是在代码写完了才做的。但 Spec Coding 把 Review 前置了

• 交付物口径明确了吗？（P1 review）

• 相关表对了吗？字段映射对了吗？（P2 review）

• 数据模型设计对吗？（P3 review）

在代码还没生成之前，大量可能的问题就已经被拦截了。

对抗痛点 5（多需求串行排期效率低）→ Agent 并行推进，人按优先级介入：每个需求独立的 Spec 目录让 Agent 可以并行为多个需求执行 P1-P3 的准备工作。数据研发同学不需要"守着"一个需求从头跟到尾，而是可以同时推进多个需求——在 Agent 执行 A 需求的 P2 搜索时，去确认 B 需求的 P1 澄清结果，再去 CR C 需求的 P3 模型设计。把"依赖人的连续投入"的串行模式，转变为"人按优先级介入决策"的并行模式。

用一句话总结：Spec Coding 不是让 AI 更聪明，而是让 AI 的工作"更可被人类审计"。skill 中的每一步强制确认（阶段 1 和阶段 3 必须用户确认才能继续），本质上就是在执行"human-in-the-loop 的 Spec Review"。

• Spec Coding 在多需求场景下的价值

当数据研发同学同时承接多个需求时，Spec Coding 的价值尤为突出。传统模式下，每个需求的前置准备工作（查表、确认口径、制定方案）都需要人的连续投入，只能串行完成。而 Spec Coding 模式下：

• Agent 并行推进：多个需求的 P1-P3 阶段可以同时进行，Agent 自动完成需求澄清、表结构查询、模型设计草案

• 人按优先级介入：数据研发同学不需要"守着"一个需求，而是可以灵活地在多个需求之间切换——在 A 需求的 P3 等待 CR 时，去确认 B 需求的 P1，去补充 C 需求的 P2 表信息

• 异步协作模式：每个需求独立的 Spec 目录成为异步协作的载体，人和 Agent 可以在不同时间点介入，无需同步等待

这种模式将“依赖人的连续投入的串行排期”转变为“Agent自动执行，人按优先级介入决策的并行推进”，在多需求场景下大幅提升交付效率。

▐  Spec Coding 的边界

Spec Coding 做的是"翻译层"的事，不是"决策层"的事。 让我们明确它的能力边界：

一句话：Spec Coding 降低了"沟通成本"和"上下文管理成本"，但没有降低"需求本身的复杂度，对于依赖专家经验和判断的步骤，还是存在人工成本。

这也是为什么 Skill 的流程里，P1 和 P3 是强制确认节点——不是形式主义，而是因为数据建模和指标定义这两个决策环节，大模型无法替代人的专业判断。Code Review 同样是不可跳过的，在数据领域，一个错误的 JOIN 可能导致整张表的数据偏差，这种风险只能靠人的经验来兜底。

所以 Spec Coding 的正确定位是：它不是"让 AI 自动完成数据开发"，而是"让 AI 辅助的每一步都留下可追溯、可审查的文档锚点"。真正的模型设计、指标判断、代码审查——这些压舱石仍然在人身上。

▐  当前成果

1. 文档清晰、口径定义准确的临时取数需求（如维表开发、增量表仿写），已经做到24小时内交付。业务方的"Aone需求"→ Skill 澄清 → Copilot 生码 → 验数上线，全链路已经跑通。

2. Copilot 生码质量提高，对话轮次降低，复杂需求手写比率下降。

3. 需求从串行变成并行，缩短排期时间，提升交付效率。

▐  还在探索的

规范的模型设计：遵循研发规范，在需求理解模型设计的过程中更好的理解研发规范，辅助人进行复杂的数据模型设计，找到最优的解法。

资产搜索自动化：目前还是依赖语义层，如何自动化探索，甚至在未来能更近一步前置资产搜索，让 AI 帮助业务方快速找到资产，提升效率。

数据需求质量提升：数据需求本身的质量高低已经成为了需求交付的时效性的强卡点。接下来需要再往前一步，总结Aone需求范式，提高需求本身的质量（描述清晰，无二义性，给出明确口径），在需求提出和需求评审阶段解决AI生码相关的需求澄清问题，期望达到部分需求评审通过后不排期直接交付。