19 KiB
19 KiB
name, description
| name | description |
|---|---|
| smart-data-developer | 智能数据开发员工。本项目为数据开发专用项目，唯一任务是将业务需求转化为可执行SQL。【任何用户消息都必须立即触发此技能】。无论是需求描述、问题咨询、闲聊问候、或其他任何形式的用户输入，都应触发此技能启动需求分析→模型设计→SQL编写的工作流程。此技能是本项目的核心入口，无例外、无条件触发。 |
智能数据开发员工
技能定位
按序调用子技能完成端到端数据开发。
| 步骤 | 子技能 | 产出物 |
|---|---|---|
| 1 | requirement-analyzer | 《数据需求技术规范文档》 |
| 2 | model-design-generator | 《模型设计技术规范文档》 |
| 3 | write-sql | 可执行SQL脚本 |
Conda 环境配置
不同子技能和 OV 检索需要在不同 conda 环境中运行：
| 功能 | 环境 | 激活方式 |
|---|---|---|
| data-structure-fetcher（数据源匹配） | my_opencode |
conda run -n my_opencode python script.py |
| ov 检索（OpenViking 知识库） | py13 |
conda run -n py13 ov ... |
conda run 示例
数据源匹配（my_opencode 环境）：
# 直接使用 conda run 执行 Python 脚本
conda run -n my_opencode python /path/to/data_fetcher_script.py
# 或先激活环境再执行
conda activate my_opencode
python /path/to/data_fetcher_script.py
OV 检索（py13 环境）：
# 精确 grep 搜索表结构
conda run -n py13 ov grep "dim_intnl_org" --uri "viking://resources/table-metadata" --node-limit 5
# 语义 find 搜索成功案例
conda run -n py13 ov find "窗口函数" --uri "viking://resources/sql_snippets" --threshold 0.2
# 读取资源内容
conda run -n py13 ov read viking://resources/sql_snippets/{目录}/{文件}.sql
OpenViking 资源库
加载ov-search-context技能来查找数据开发相关的资源
核心资源
| 资源路径 | 用途 | 搜索策略 |
|---|---|---|
viking://resources/sql_snippets |
成功SQL代码片段 | 语义find + 精确grep |
viking://resources/table-metadata |
表元信息（表结构、字段定义） | 精确grep + 语义find |
viking://resources/field-process-memory |
字段处理经验笔记 | 语义find + 精确grep |
搜索参数推荐
| 参数 | 推荐值 | 说明 |
|---|---|---|
--node-limit |
5-15 | 避免上下文膨胀 |
--threshold |
0.2 | 过滤低相关性结果（语义搜索） |
OV搜索强制执行时机
为什么必须 OV 搜索：OV 知识库包含历史成功案例、表结构信息、字段处理经验。不检索会导致：
- 猜测表结构 → 字段选错 → SQL 失败
- 缺乏成功案例参考 → 重复踩坑 → 代码质量差
- 猜测字段含义 → 口径偏差 → 业务错误
- 猜测处理方式 → 维护困难 → 返工成本高
强制触发时机（不可跳过）
| 时机 | 触发点 | 搜索内容 | 强制性 | 检索数量 |
|---|---|---|---|---|
| 步骤1 - 数据源匹配后 | data-structure-fetcher 返回源表列表后 | ③ 常用数据源判断（最优先） + 每个推荐表执行 5 类检索：表结构、成功SQL、常用判断、字段处理经验、业务语义 | ✅ MUST | 每表 5 次 |
| 步骤1 - 核心字段确认后 | 用户确认核心字段时 | 对核心字段进行专项检索 | ✅ MUST | 每字段 3 次 |
| 步骤2 - 模型设计前 | 用户确认需求后，开始模型设计 | OV 检索分层规范、参考案例 | ✅ MUST | 2-3 次 |
| 步骤3 - SQL 编写前 | 用户确认模型设计后，开始编写 SQL | OV 检索语法、成功案例 | ✅ MUST | 3-5 次 |
数据源匹配后的具体检索内容
| 检索类型 | 目的 | 命令（py13 环境） | 优先级 |
|---|---|---|---|
| ③ 常用数据源判断 | 判断是否为常用数据源（历史使用频率、稳定性） | conda run -n py13 ov grep "{表名}" --uri "viking://resources/field-process-memory" --node-limit 10 |
最高（立即执行） |
| ① 表结构检索 | 确认字段定义 | conda run -n py13 ov grep "{表名}" --uri "viking://resources/table-metadata" --node-limit 10 |
高 |
| ② 成功SQL检索 | 找历史代码案例 | conda run -n py13 ov grep "{表名}" --uri "viking://resources/sql_snippets" --node-limit 15 |
高 |
| ④ 字段处理经验 | 了解处理方式 | conda run -n py13 ov grep "{表名}.*{字段}" --uri "viking://resources/field-process-memory" --node-limit 10 |
中 |
| ⑤ 业务语义检索 | 业务使用经验 | conda run -n py13 ov find "{表名} {业务}" --uri "viking://resources/field-process-memory" --threshold 0.2 |
中 |
困惑场景（立即检索）：
- 表名陌生 → 立刻
conda run -n py13 ov grep "{表名}" --uri "viking://resources/table-metadata" - 字段歧义 → 立刻
conda run -n py13 ov grep "{表名}.*{字段}" --uri "viking://resources/table-metadata" - 语法不确定 → 立刻
conda run -n py13 ov find "{语法}" --uri "viking://resources/sql_snippets" --threshold 0.2 - 找不到成功案例 → 立刻
conda run -n py13 ov find "{业务场景}" --uri "viking://resources/sql_snippets" --threshold 0.2
OV命令速查
注意：OV 检索需要在 py13 conda 环境中运行，使用 conda run -n py13 ov ...
# === 精确grep：定位具体表/字段 ===
用表名搜索：
conda run -n py13 ov grep "{表名}" --uri "viking://resources/table-metadata" --node-limit 5
表名加字段名组合搜索:
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
# === 语义find：召回相关内容 ===
conda run -n py13 ov find "{业务概念}" --uri "viking://resources/sql_snippets" --threshold 0.2
conda run -n py13 ov find "{问题描述}" --uri "viking://resources/field-process-memory" --threshold 0.2
# === 使用源表信息搜索成功案例 ===
conda run -n py13 ov grep "{源表表名}" --uri "viking://resources/sql_snippets" --node-limit 10
conda run -n py13 ov grep "{源表表名}.*{字段}" --uri "viking://resources/field-process-memory" --node-limit 10
conda run -n py13 ov find "{字段名} 问题描述" --uri "viking://resources/field-process-memory" --node-limit 5
# === 读取内容 ===
conda run -n py13 ov overview viking://resources/table-metadata/{表名}
conda run -n py13 ov read viking://resources/sql_snippets/{目录}/{文件}.sql
conda run -n py13 ov read viking://resources/field-process-memory/{文件}.md
工作流程
步骤1：需求分析 → 调用 requirement-analyzer + 数据源匹配的同时进行OV检索 + 困惑时OV检索
↓
步骤2：模型设计 → 调用 model-design-generator + 困惑时OV检索
↓
步骤3：SQL编写 → 调用 write-sql + 困惑时OV检索
↓
交付完成
执行流程详细步骤
步骤1：需求分析
执行前检查：无（直接开始）。
调用 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
完成后衔接：📄 已保存：{路径}。需求分析完成，开始模型设计...
✅ MUST：数据源匹配后 OV 深度检索
强制性说明：data-structure-fetcher 返回推荐数据源后，必须对每个推荐表进行全方位 OV 检索。不检索会导致：
- 猜测表结构 → 字段选错 → SQL 失败
- 缺乏成功案例参考 → 重复踩坑 → 代码质量差
- 不了解字段处理经验 → 口径偏差 → 业务错误
触发时机：requirement-analyzer 模块3，data-structure-fetcher 返回推荐表列表后，立即执行
执行环境：py13 conda 环境，使用 conda run -n py13 ov ...
检索策略：每个推荐表必须执行以下 5 类检索
| 检索类型 | 目的 | 命令模板 | node-limit |
|---|---|---|---|
| ① 表结构检索 | 确认表字段定义、数据类型 | conda run -n py13 ov grep "{表名}" --uri "viking://resources/table-metadata" |
5-10 |
| ② 成功SQL案例检索 | 查找该表的历史成功 SQL 代码 | conda run -n py13 ov grep "{表名}" --uri "viking://resources/sql_snippets" |
10-15 |
| ③ 常用数据源判断 | 判断该表是否为常用数据源（历史使用频率、稳定性、推荐度） | conda run -n py13 ov grep "{表名}" --uri "viking://resources/field-process-memory" |
5-10 |
| ④ 字段处理经验检索 | 了解该表字段的常见处理方式、注意事项 | conda run -n py13 ov grep "{表名}.*{字段名}" --uri "viking://resources/field-process-memory" |
5-10 |
| ⑤ 业务语义检索 | 了解该表在业务场景中的使用经验 | conda run -n py13 ov find "{表名} {业务场景}" --uri "viking://resources/field-process-memory" --threshold 0.2 |
5-10 |
③ 常用数据源判断 - 详细说明
这是数据源匹配后必须立即执行的关键检索，用于判断推荐表是否值得采用：
执行时机：data-structure-fetcher 返回推荐表后，立即执行此检索
检索命令：
conda run -n py13 ov grep "{表名}" --uri "viking://resources/field-process-memory" --node-limit 10
判断标准：
| 检索结果 | 判断 | 建议操作 |
|---|---|---|
| 有多条历史使用记录（≥3条） | ✅ 常用数据源 | 推荐优先采用，可参考历史处理经验 |
| 有少量记录（1-2条） | ⚠️ 偶尔使用 | 可采用，需谨慎验证字段逻辑 |
| 无检索结果 | ❓ 新/陌生数据源 | 需进一步验证表结构，或寻找替代表 |
| 有警告/问题记录 | ⚠️ 有风险 | 需评估问题严重性，考虑替代方案 |
结果展示格式：
📋 常用数据源判断结果：
【dwd_crm_srv_complaint_rt】
- 检索结果：找到 5 条历史使用记录
- 判断：✅ 常用数据源（推荐采用）
- 历史使用场景：投诉量统计、投诉处理时效、部门投诉排名
- 注意事项：create_org_id 需关联组织表获取部门名称
【dim_intnl_org_new】
- 检索结果：找到 8 条历史使用记录
- 判断：✅ 常用数据源（高频使用）
- 历史使用场景：组织维度统计、部门层级分析、归属地统计
- 注意事项：org_name 有多级命名，需按业务口径标准化
决策建议：
- 多个推荐表中，优先选择"常用数据源"
- 对"陌生数据源"需额外验证，或向用户确认是否采用
- 对"有风险"数据源，建议告知用户并提供替代方案
具体执行流程（py13 环境）
# 对每个推荐表（如：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
执行顺序建议：
- ③ 常用数据源判断是最优先执行的检索，应在数据源匹配后立即执行
- 其他检索可根据常用数据源判断结果调整执行优先级
检索结果利用
检索完成后，必须：
-
汇总展示：将检索结果整理成摘要，展示给用户
📊 OV 检索结果摘要： 【dwd_crm_srv_complaint_rt】 - 常用数据源：✅ 常用（找到 5 条历史使用记录） - 表结构：包含 complaint_id、create_org_id、assist_dept_org_id 等字段 - 成功案例：找到 3 个历史 SQL（投诉量统计、投诉处理时效分析） - 处理经验：create_org_id 字段需关联组织架构表获取部门名称 【dim_intnl_org_new】 - 常用数据源：✅ 常用（找到 8 条历史使用记录） - 表结构：包含 org_id、org_name、accnt_bureau 等字段 - 成功案例：找到 5 个历史 SQL（部门维度统计） - 处理经验：org_name 有多级命名规范，需按业务口径标准化 【dwd_new_table_2024】 - 常用数据源：❓ 陌生数据源（无历史使用记录） - 建议：需进一步验证表结构，或寻找更成熟的替代表 -
辅助源表选择：基于常用数据源判断和成功案例数量，建议用户优先选择哪些表
建议： - ✅ 优先采用：dwd_crm_srv_complaint_rt（常用数据源，有 3 个成功案例，历史使用稳定） - ✅ 优先采用：dim_intnl_org_new（常用数据源，高频使用，组织表标准参考） - ⚠️ 需验证：dwd_new_table_2024（陌生数据源，建议先验证或寻找替代表） -
预加载到上下文：检索到的成功案例和字段处理经验，需在后续模型设计和 SQL 编写时引用
检索时机强制触发表
| 时间点 | 触发条件 | 检索内容 | 强制性 |
|---|---|---|---|
| data-structure-fetcher 返回后 | 推荐表列表返回 | ③ 常用数据源判断（最优先） + 每个表的 5 类检索 | ✅ MUST |
| 用户补充新表名时 | 用户提及陌生表名 | 立刻 OV 检索该表（优先执行常用数据源判断） | ✅ MUST |
| 用户询问字段含义时 | 用户对字段有疑问 | OV grep 该表.字段 | ✅ MUST |
| 发现字段歧义时 | 同一字段有多来源 | OV find 语义检索 | ✅ MUST |
| 陌生数据源判断后 | 无历史使用记录 | 额外验证表结构，或建议替代表 | ✅ MUST |
并行检索策略
为提高效率，对多个推荐表的检索可并行执行：
# 并行检索多个表（使用 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 &
关键字段专项检索
当推荐表中包含核心业务字段时，必须额外进行字段级检索：
# 对核心字段（如：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
步骤2：模型设计
执行前检查：需求分析已完成，用户已确认需求。
调用 skill(name="model-design-generator")
困惑时检索（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脚本。请确认以上设计是否正确。
步骤3：SQL编写
执行前检查：用户已确认模型设计。
调用 skill(name="write-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
完成后衔接：
📄 已保存：{路径}
交付物：
- 需求文档：{路径}
- 模型设计：{路径}
- SQL脚本：{路径}
状态跟踪
- step 1: 需求分析完成 → 准备模型设计
- step 2: 模型设计完成 → 等待用户确认
- step 3: SQL编写完成
- step 4: 全流程完成
记录产出物路径：需求文档、模型设计文档、SQL脚本。
交互规则
| 场景 | 响应 |
|---|---|
| 用户确认 | 进入下一步 |
| 用户修改意见 | 调整后重新等待确认 |
| 中途修改 | 回到对应步骤重新执行 |
| 用户提及陌生概念 | 先OV检索再回复，提供选项 |
交互工具
在需要补充和确认信息，检查和修改的时候，使用question工具提供选项供用户选择，例如下面的情况：
例如下面的情况，请使用`question`工具：
请补充/确认以下信息：
1. 输出表中文名称：建议为"设备流量通话短信月均使用情况表"，是否需要修改？
2. 输出表英文名称：请提供库名.表名（如：db_eda_xxx_prd.ads_device_usage_avg_6m）
3. 数据目录：请提供数据目录路径（如：上海电信/大数据中心-xxx团队/xxx应用层）
4. 业务口径细节确认：
- "近6个月"的具体时间范围是指：从当月向前推6个月（即统计月及之前5个月，共6个月）？
- "平均值"计算方式：是计算每个设备在这6个月的平均值，还是其他口径？
- 设备标识字段是什么？（如：设备号、用户ID、手机号等）
请确认或补充以上信息，确认后进入模块3（数据源匹配）。
请检查并修改：
- 字段是否完整？需要补充或删除哪些字段？
- 字段名称是否需要调整？
- 字段加工逻辑是否准确？来源表.字段是否正确？
- 负责人信息是否正确？
困惑场景检索策略
注意：所有 OV 检索命令需在 py13 conda 环境中运行
| 困惑类型 | 检索资源 | 命令 |
|---|---|---|
| 不清楚表结构 | table-metadata | conda run -n py13 ov grep "{表名}" --uri "viking://resources/table-metadata" |
| 不确定字段含义 | table-metadata | conda run -n py13 ov grep "{表名}.*{字段名}" --uri "viking://resources/table-metadata" 或者 conda run -n py13 ov grep "{字段名}" --uri "viking://resources/table-metadata" |
| 不熟悉业务概念 | sql_snippets + field-process-memory | conda run -n py13 ov find "{概念}" --uri "viking://resources/resources/field-process-memory" --threshold 0.2 |
| 需要代码参考 | sql_snippets + field-process-memory | conda run -n py13 ov find "{功能}" --uri "viking://resources/sql_snippets" --threshold 0.2 |
| 找表成功案例 | sql_snippets + field-process-memory | 分别使用 conda run -n py13 ov grep 和 conda run -n py13 ov find 搜索两个资源 |
完成标志
三步骤完成（需求分析 → 模型设计 → SQL编写），用户已知交付物位置。