Add simple sql write in main router

This commit is contained in:
li552233
2026-05-12 07:43:35 +00:00
parent a4c8b29176
commit df19743ce0

View File

@@ -1,19 +1,20 @@
---
name: smart-data-developer
description: 智能数据开发员工。本项目为数据开发专用项目唯一任务是将业务需求转化为可执行SQL。【任何用户消息都必须立即触发此技能】。无论是需求描述、问题咨询、闲聊问候、或其他任何形式的用户输入都应触发此技能启动需求分析→模型设计→SQL编写的工作流程。此技能是本项目的核心入口无例外、无条件触发
description: 智能数据开发员工v3。支持数据开发和简单取数两种模式。数据开发模式按序调用 requirement-analyzer → model-design-generator → write-sql 三技能,结合 OV 知识库检索保障质量;简单取数模式直接调用 write-sql 生成查询SQL。当用户提到数据需求、指标需求、报表需求、SQL查询、数据开发、统计需求、ETL任务、取数、查数据时触发此技能
---
# 智能数据开发员工
# 智能数据开发员工 v3
## 技能定位
按序调用子技能完成端到端数据开发
作为**协调者**,根据用户需求类型选择对应流程,完成 SQL 生成
| 步骤 | 子技能 | 产出物 |
|-----|--------|--------|
| 1 | requirement-analyzer | 《数据需求技术规范文档》 |
| 2 | model-design-generator | 《模型设计技术规范文档》 |
| 3 | write-sql | 可执行SQL脚本 |
支持两种模式:
| 模式 | 适用场景 | 流程 |
|------|----------|------|
| **数据开发** | 建表、ETL、定期调度、指标报表、需要需求文档 | 三步走:需求分析 → 模型设计 → SQL编写 |
| **简单取数** | 临时查数据、单表/简单JOIN查询、一次性统计 | 直接调用 write-sql |
---
@@ -54,7 +55,7 @@ conda run -n py13 ov read viking://resources/sql_snippets/{目录}/{文件}.sql
## OpenViking 资源库
加载`ov-search-context`技能来查找数据开发相关的资源
加载 `ov-search-context` 技能来查找数据开发相关的资源
### 核心资源
@@ -81,9 +82,11 @@ conda run -n py13 ov read viking://resources/sql_snippets/{目录}/{文件}.sql
- 猜测字段含义 → 口径偏差 → 业务错误
- 猜测处理方式 → 维护困难 → 返工成本高
**注意OV 检索仅在数据开发模式分支A中强制执行。简单取数模式按需检索。**
---
**强制触发时机(不可跳过)**
**强制触发时机(不可跳过,仅数据开发模式**
| 时机 | 触发点 | 搜索内容 | 强制性 | 检索数量 |
|-----|--------|---------|--------|---------|
@@ -127,7 +130,7 @@ conda run -n py13 ov grep "{表名}" --uri "viking://resources/table-metadata" -
conda run -n py13 ov grep "dim_intnl_org.*org_id" --uri viking://resources/table-metadata -n 5
多表名 OR 搜索:
conda run -n py13 ov grep "table1|table2|table3" --uri viking://resources/table-metadata -n 5
conda run -n py13 ov grep "table1|table2|table3" --uri "viking://resources/table-metadata" -n 5
# === 语义find召回相关内容 ===
conda run -n py13 ov find "{业务概念}" --uri "viking://resources/sql_snippets" --threshold 0.2
@@ -149,39 +152,93 @@ conda run -n py13 ov read viking://resources/field-process-memory/{文件}.md
## 工作流程
```
步骤1需求分析 → 调用 requirement-analyzer + 数据源匹配的同时进行OV检索 + 困惑时OV检索
用户输入需求
步骤2模型设计 → 调用 model-design-generator + 困惑时OV检索
[入口] 场景判断 + 用户确认
步骤3SQL编写 → 调用 write-sql + 困惑时OV检索
交付完成
├── 数据开发 → [步骤1] 需求分析(+OV检索 → 确认 → [步骤2] 模型设计(+OV检索 → 确认 → [步骤3] SQL编写+OV检索 → 交付
└── 简单取数 → [确认引擎] → 直接调用 write-sql → 交付
```
---
## 执行流程详细步骤
## 入口:场景判断
用户输入需求后,**必须先判断场景类型并让用户确认**。
### 判断规则
| 判断维度 | 数据开发特征 | 简单取数特征 |
|----------|-------------|-------------|
| 目标 | 建新表/更新表、产出报表 | 临时查看、一次性统计 |
| 调度 | 需要定期运行(日/周/月) | 不需要调度 |
| 复杂度 | 多表关联、加工逻辑复杂 | 单表或简单 JOIN |
| 关键词 | "建表"、"ETL"、"指标"、"报表"、"每日更新"、"需求" | "查一下"、"看看"、"有多少"、"帮我取"、"统计一下" |
### 交互模板
**场景有明显倾向时(推荐项标明理由)**
```
根据您的描述,我判断这是一个{数据开发/简单取数}需求。
请确认需求类型:
1. {推荐项}(推荐)← {推荐理由}
2. {另一选项}
回复 1 或 2。
```
**推荐规则**
- 涉及建表、定期调度、多步骤加工 → **推荐数据开发**
- 涉及"查一下"、"看看"、单表简单统计 → **推荐简单取数**
- 模糊场景 → **推荐数据开发**(走三步走不会出错,中途可切换)
---
## 分支A数据开发三步走
### 文件流转链路
三个步骤的产出物统一保存在 `./ai_text/` 目录下,步骤间有严格的依赖关系:
```
步骤1 产出 步骤2 产出 步骤3 产出
./ai_text/REQ-DATA-{ts}-{seq}.md → ./ai_text/MDDS-DATA-{ts}-{seq}.md → ./ai_text/SQL-DATA-{ts}-{seq}.sql
│ │ │
└──── 步骤2 读取此文件 ───────────────┘ │
└──── 步骤3 读取此文件 ──────────────┘
```
| 步骤 | 产出文件 | 命名规则 | 依赖 |
|------|---------|---------|------|
| 1 需求分析 | `REQ-DATA-{YYYYMMDDHHmmss}-{XXX}.md` | 由 requirement-analyzer 生成 | 无 |
| 2 模型设计 | `MDDS-DATA-{YYYYMMDDHHmmss}-{XXX}.md` | 从步骤1文件名转换REQ → MDDS | **必须读取步骤1的 REQ 文件** |
| 3 SQL编写 | `SQL-DATA-{YYYYMMDDHHmmss}-{XXX}.sql` | 从步骤1文件名转换REQ → SQL | **必须读取步骤1的 REQ + 步骤2的 MDDS 文件** |
### 步骤1需求分析
**执行前检查**:无(直接开始)。
1. 调用 `skill(name="requirement-analyzer")`
2. 子技能完成后,展示摘要并等待用户确认:
```
✅ 需求分析已完成!
📄 文件路径:{路径}
调用 `skill(name="requirement-analyzer")`
请您审核:
- 需求描述是否准确?
- 业务口径是否完整?
- 数据源是否正确?
- 输出字段是否符合预期?
**困惑时检索py13 环境)**
- 不熟悉业务概念 → `conda run -n py13 ov find "{概念}" --uri "viking://resources/field-process-memory" --threshold 0.2`
- 不确定指标口径 → `conda run -n py13 ov find "{指标名称} 口径" --uri "viking://resources/field-process-memory" --threshold 0.3`
**完成后衔接**`📄 已保存:{路径}。需求分析完成,开始模型设计...`
回复"确认"进入步骤2或指出需要修改的内容。
```
3. **记录需求文档路径**到状态中
#### ✅ MUST数据源匹配后 OV 深度检索
**强制性说明**data-structure-fetcher 返回推荐数据源后,**必须对每个推荐表进行全方位 OV 检索**。不检索会导致:
- 猜测表结构 → 字段选错 → SQL 失败
- 缺乏成功案例参考 → 重复踩坑 → 代码质量差
- 不了解字段处理经验 → 口径偏差 → 业务错误
---
**强制性说明**data-structure-fetcher 返回推荐数据源后,**必须对每个推荐表进行全方位 OV 检索**。
**触发时机**requirement-analyzer 模块3data-structure-fetcher 返回推荐表列表后,立即执行
@@ -205,8 +262,6 @@ conda run -n py13 ov read viking://resources/field-process-memory/{文件}.md
这是数据源匹配后**必须立即执行**的关键检索,用于判断推荐表是否值得采用:
**执行时机**data-structure-fetcher 返回推荐表后,**立即执行此检索**
**检索命令**
```bash
conda run -n py13 ov grep "{表名}" --uri "viking://resources/field-process-memory" --node-limit 10
@@ -245,30 +300,29 @@ conda run -n py13 ov grep "{表名}" --uri "viking://resources/field-process-mem
---
**具体执行流程py13 环境)**
**并行检索策略**
为提高效率,对多个推荐表的检索可并行执行:
```bash
# 对每个推荐表dwd_crm_srv_complaint_rt依次执行
# ① 表结构检索(确认字段)
conda run -n py13 ov grep "dwd_crm_srv_complaint_rt" --uri "viking://resources/table-metadata" --node-limit 10
# ② 成功SQL案例检索找历史代码
conda run -n py13 ov grep "dwd_crm_srv_complaint_rt" --uri "viking://resources/sql_snippets" --node-limit 15
# ③ 常用数据源判断(判断是否常用 - 数据源匹配后立即执行)
conda run -n py13 ov grep "dwd_crm_srv_complaint_rt" --uri "viking://resources/field-process-memory" --node-limit 10
# ④ 字段处理经验检索(找处理笔记 - 对核心字段)
conda run -n py13 ov grep "dwd_crm_srv_complaint_rt.complaint_id" --uri "viking://resources/field-process-memory" --node-limit 10
# ⑤ 业务语义检索(结合业务场景)
conda run -n py13 ov find "dwd_crm_srv_complaint_rt 投诉统计" --uri "viking://resources/field-process-memory" --threshold 0.2 --node-limit 10
# 并行检索多个表(使用 task agent 或 bash 后台)
conda run -n py13 ov grep "table1" --uri "viking://resources/table-metadata" --node-limit 10 &
conda run -n py13 ov grep "table2" --uri "viking://resources/table-metadata" --node-limit 10 &
conda run -n py13 ov grep "table3" --uri "viking://resources/table-metadata" --node-limit 10 &
```
**执行顺序建议**
- ③ 常用数据源判断是**最优先执行**的检索,应在数据源匹配后立即执行
- 其他检索可根据常用数据源判断结果调整执行优先级
---
**关键字段专项检索**
当推荐表中包含**核心业务字段**时,必须额外进行字段级检索:
```bash
# 对核心字段complaint_id、org_id进行专项检索
conda run -n py13 ov grep "dwd_crm_srv_complaint_rt.complaint_id" --uri "viking://resources/table-metadata" --node-limit 5
conda run -n py13 ov grep "complaint_id" --uri "viking://resources/field-process-memory" --node-limit 10
conda run -n py13 ov find "complaint_id 去重计数" --uri "viking://resources/sql_snippets" --threshold 0.2 --node-limit 10
```
---
@@ -309,88 +363,193 @@ conda run -n py13 ov find "dwd_crm_srv_complaint_rt 投诉统计" --uri "viking:
---
**检索时机强制触发表**
| 时间点 | 触发条件 | 检索内容 | 强制性 |
|-------|---------|---------|--------|
| data-structure-fetcher 返回后 | 推荐表列表返回 | **③ 常用数据源判断(最优先)** + 每个表的 5 类检索 | ✅ MUST |
| 用户补充新表名时 | 用户提及陌生表名 | 立刻 OV 检索该表(优先执行常用数据源判断) | ✅ MUST |
| 用户询问字段含义时 | 用户对字段有疑问 | OV grep 该表.字段 | ✅ MUST |
| 发现字段歧义时 | 同一字段有多来源 | OV find 语义检索 | ✅ MUST |
| 陌生数据源判断后 | 无历史使用记录 | 额外验证表结构,或建议替代表 | ✅ MUST |
---
**并行检索策略**
为提高效率,对多个推荐表的检索可并行执行:
```bash
# 并行检索多个表(使用 task agent 或 bash 后台)
conda run -n py13 ov grep "table1" --uri "viking://resources/table-metadata" --node-limit 10 &
conda run -n py13 ov grep "table2" --uri "viking://resources/table-metadata" --node-limit 10 &
conda run -n py13 ov grep "table3" --uri "viking://resources/table-metadata" --node-limit 10 &
```
---
**关键字段专项检索**
当推荐表中包含**核心业务字段**时,必须额外进行字段级检索:
```bash
# 对核心字段complaint_id、org_id进行专项检索
conda run -n py13 ov grep "dwd_crm_srv_complaint_rt.complaint_id" --uri "viking://resources/table-metadata" --node-limit 5
conda run -n py13 ov grep "complaint_id" --uri "viking://resources/field-process-memory" --node-limit 10
conda run -n py13 ov find "complaint_id 去重计数" --uri "viking://resources/sql_snippets" --threshold 0.2 --node-limit 10
```
---
**困惑时检索py13 环境)**
- 不熟悉业务概念 → `conda run -n py13 ov find "{概念}" --uri "viking://resources/field-process-memory" --threshold 0.2`
- 不确定指标口径 → `conda run -n py13 ov find "{指标名称} 口径" --uri "viking://resources/field-process-memory" --threshold 0.3`
### 步骤2模型设计
**执行前检查**:需求分析已完成,用户确认需求
**用户确认需求后**才能进入。本步骤**依赖步骤1的 REQ 文件**
调用 `skill(name="model-design-generator")`
1. 从状态中获取步骤1产出的 REQ 文件路径
2. 调用 `skill(name="model-design-generator")`,传入 REQ 文件路径
3. 模型设计 skill 会自动读取 REQ 文件并生成对应的 MDDS 文件到 `./ai_text/`
4. 子技能完成后,展示摘要并等待用户确认:
```
✅ 模型设计已完成!
📄 文件路径:{路径}
请您审核:
- 编排步骤是否合理?
- 目标表属性是否正确?
- 字段设计是否符合预期?
回复"确认"进入步骤3或指出需要修改的内容。
```
5. **记录模型设计文档路径**到状态中
**困惑时检索py13 环境)**
- 确认表结构 → `conda run -n py13 ov grep "{表名}" --uri "viking://resources/table-metadata"`
- 了解分层规范 → `conda run -n py13 ov find "分层架构 DWA DWM ADS" --uri "viking://resources/sql_snippets" --threshold 0.2`
**完成后衔接**`📄 已保存:{路径}。下一步将编写SQL脚本。请确认以上设计是否正确。`
---
### 步骤3SQL编写
**执行前检查**用户确认模型设计
**用户确认模型设计后**才能进入。本步骤由本 skill 主导,调用 write-sql 完成:
调用 `skill(name="write-sql")`
#### 3.1 确定引擎类型
询问用户目标引擎:
```
请确认 SQL 目标引擎:
- spark默认— Paimon 数据仓库
- doris — 实时 OLAP 分析
- hive — 离线批处理
- kudu — 实时更新
如无特别要求,默认使用 spark。
```
#### 3.2 读取文件并组装 context
本 skill 负责以下工作(**不是 write-sql 的职责**
1. **读取需求文档**:使用 Read 工具读取步骤1产出的 REQ 文件(`./ai_text/REQ-DATA-xxx.md`
2. **读取模型设计文档**:使用 Read 工具读取步骤2产出的 MDDS 文件(`./ai_text/MDDS-DATA-xxx.md`
3. **组装 context**:将两个文档内容拼接为完整的上下文文本
4. **确定输出路径**从步骤1的 REQ 文件名转换,`REQ-DATA-xxx.md` → `SQL-DATA-xxx.sql`,保存到 `./ai_text/`
```
context 内容结构:
"""
【数据需求技术规范文档】
{需求文档完整内容}
【模型设计技术规范文档】
{模型设计文档完整内容}
"""
```
#### 3.3 调用 write-sql
```
调用 write-sql 时传入以下参数:
- engine: {用户确认的引擎,默认 spark}
- context: {3.2 组装的完整上下文文本}
- output_path: ./ai_text/SQL-DATA-{从步骤1文件名提取的时间戳和序号}.sql
```
**注意**write-sql 是纯函数,不自己读文件,只接收参数生成 SQL。
**困惑时检索py13 环境)**
- SQL语法 → `conda run -n py13 ov find "{语法} 用法" --uri "viking://resources/sql_snippets" --threshold 0.2`
- 窗口函数示例 → `conda run -n py13 ov find "窗口函数 over partition" --uri "viking://resources/sql_snippets" --threshold 0.2`
**完成后衔接**
```
📄 已保存:{路径}
#### 3.4 验证与交付
交付物
write-sql 完成后
1. 确认 SQL 文件已写入 output_path
2. 简要展示 SQL 脚本概要(步骤数、目标表、源表)
### 数据开发交付
```
✅ 数据开发任务已完成!
交付物清单:
- 需求文档:{路径}
- 模型设计:{路径}
- SQL脚本{路径}
- 目标引擎:{spark/doris/hive/kudu}
```
---
## 分支B简单取数
### B.1 确认引擎
```
请确认查询引擎:
- spark默认
- doris
- hive
- kudu
如无特别要求,默认使用 spark。
```
### B.2 确认补充信息(按需)
如果用户描述中缺少关键信息,**简洁追问**不要用需求分析的13项模板
| 缺失信息 | 追问方式 |
|----------|---------|
| 表名不明 | "请确认要从哪张表查询?" |
| 时间范围不明 | "需要查哪个时间段的数据?" |
| 过滤条件不明 | "有什么筛选条件吗?" |
| 字段不明 | "需要返回哪些字段?还是全部?" |
| 聚合维度不明 | "按什么维度统计?按日/按部门/按地区?" |
**原则**:只问必要的,能推断的不问,能省略的省略。
### B.3 调用 write-sql
```
调用 write-sql 时传入以下参数:
- engine: {用户确认的引擎,默认 spark}
- context: {用户的取数描述 + 补充信息}
- output_path: 无(简单取数默认不写文件,仅在对话中展示)
```
如果用户要求保存到文件:
```
- output_path: ./ai_text/QUERY-{时间戳}.sql
```
### B.4 简单取数交付
```
✅ SQL 已生成!
引擎:{spark/doris/hive/kudu}
```sql
{生成的 SQL}
```
如需调整请告诉我。如需保存到文件,请指定路径。
```
---
## 中途切换
用户在任何时刻可以切换模式:
| 用户说 | 处理方式 |
|--------|---------|
| "这个改成正式的需求" | 简单取数 → 数据开发从步骤1开始 |
| "不用那么复杂,直接帮我查就行" | 数据开发 → 简单取数,用已有信息直接生成 SQL |
| "先简单查一下看看" | 简单取数优先,后续可转数据开发 |
---
## 状态跟踪
- step 1: 需求分析完成 → 准备模型设计
- step 2: 模型设计完成 → 等待用户确认
- step 3: SQL编写完成
- step 4: 全流程完成
记录产出物路径需求文档、模型设计文档、SQL脚本。
```python
state = {
"mode": None, # "dev"(数据开发) | "query"(简单取数) | None待确认
"step": 0, # dev模式0→1→1.5(等待)→2→2.5(等待)→3→4(完成)
# query模式0→B.1→B.2→B.3→4(完成)
"confirmed": [False, False], # dev模式[步骤1确认, 步骤2确认]
"engine": "spark", # 目标引擎
"paths": { # dev模式文件路径
"req": None,
"model": None,
"sql": None
}
}
```
---
@@ -398,9 +557,14 @@ conda run -n py13 ov find "complaint_id 去重计数" --uri "viking://resources/
| 场景 | 响应 |
|-----|------|
| 用户确认 | 进入下一步 |
| 用户首次输入需求 | 场景判断 → 让用户确认模式 |
| 用户确认数据开发 | 进入分支A三步走 |
| 用户确认简单取数 | 进入分支B直接生成SQL |
| 用户确认步骤1/2 | 进入下一步 |
| 用户修改意见 | 调整后重新等待确认 |
| 中途修改 | 回到对应步骤重新执行 |
| 中途切换模式 | 清理当前状态,进入目标模式 |
| 询问进度 | 告知当前模式、步骤及确认状态 |
| 指定引擎 | 记录到 state.engine |
| 用户提及陌生概念 | 先OV检索再回复提供选项 |
---
@@ -410,7 +574,7 @@ conda run -n py13 ov find "complaint_id 去重计数" --uri "viking://resources/
在需要补充和确认信息,检查和修改的时候,使用 `question` 工具提供选项供用户选择,例如下面的情况:
```
例如下面的情况,请使用`question`工具:
例如下面的情况,请使用 question 工具:
请补充/确认以下信息:
1. 输出表中文名称:建议为"设备流量通话短信月均使用情况表",是否需要修改?
2. 输出表英文名称:请提供库名.表名db_eda_xxx_prd.ads_device_usage_avg_6m
@@ -446,6 +610,18 @@ conda run -n py13 ov find "complaint_id 去重计数" --uri "viking://resources/
---
## 输出规范
- **所有产出物统一保存在 `./ai_text/` 目录下**
- **数据开发模式**:需求文档 + 模型设计 + SQL文件三件套文件名保持一致
- 步骤1`./ai_text/REQ-DATA-{ts}-{seq}.md`
- 步骤2`./ai_text/MDDS-DATA-{ts}-{seq}.md`REQ → MDDS
- 步骤3`./ai_text/SQL-DATA-{ts}-{seq}.sql`REQ → SQL
- **简单取数模式**:默认仅在对话中展示 SQL用户要求时写入 `./ai_text/QUERY-{时间戳}.sql`
---
## 完成标志
三步骤完成(需求分析 → 模型设计 → SQL编写用户已知交付物位置。
- **数据开发模式**步骤1/2/3全部完成用户均已确认SQL文件已写入
- **简单取数模式**SQL已生成并展示给用户