wx44wx/smart-data-dev-skill

Fork 0

Files

li552233 df19743ce0 Add simple sql write in main router

2026-05-12 07:43:35 +00:00

25 KiB

Raw Permalink Blame History

name, description

name	description
smart-data-developer	智能数据开发员工（v3）。支持数据开发和简单取数两种模式。数据开发模式按序调用 requirement-analyzer → model-design-generator → write-sql 三技能，结合 OV 知识库检索保障质量；简单取数模式直接调用 write-sql 生成查询SQL。当用户提到数据需求、指标需求、报表需求、SQL查询、数据开发、统计需求、ETL任务、取数、查数据时触发此技能。

name

description

smart-data-developer

智能数据开发员工（v3）。支持数据开发和简单取数两种模式。数据开发模式按序调用 requirement-analyzer → model-design-generator → write-sql 三技能，结合 OV 知识库检索保障质量；简单取数模式直接调用 write-sql 生成查询SQL。当用户提到数据需求、指标需求、报表需求、SQL查询、数据开发、统计需求、ETL任务、取数、查数据时触发此技能。

智能数据开发员工 v3

技能定位

作为协调者，根据用户需求类型选择对应流程，完成 SQL 生成。

支持两种模式：

模式	适用场景	流程
数据开发	建表、ETL、定期调度、指标报表、需要需求文档	三步走：需求分析 → 模型设计 → SQL编写
简单取数	临时查数据、单表/简单JOIN查询、一次性统计	直接调用 write-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 失败
缺乏成功案例参考 → 重复踩坑 → 代码质量差
猜测字段含义 → 口径偏差 → 业务错误
猜测处理方式 → 维护困难 → 返工成本高

注意：OV 检索仅在数据开发模式（分支A）中强制执行。简单取数模式按需检索。

强制触发时机（不可跳过，仅数据开发模式）

时机	触发点	搜索内容	强制性	检索数量
步骤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] 需求分析（+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：需求分析

调用 skill(name="requirement-analyzer")
子技能完成后，展示摘要并等待用户确认：

✅ 需求分析已完成！
📄 文件路径：{路径}

请您审核：
- 需求描述是否准确？
- 业务口径是否完整？
- 数据源是否正确？
- 输出字段是否符合预期？

回复"确认"进入步骤2，或指出需要修改的内容。

记录需求文档路径到状态中

✅ MUST：数据源匹配后 OV 深度检索

强制性说明：data-structure-fetcher 返回推荐数据源后，必须对每个推荐表进行全方位 OV 检索。

触发时机：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

③ 常用数据源判断 - 详细说明

这是数据源匹配后必须立即执行的关键检索，用于判断推荐表是否值得采用：

检索命令：

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 有多级命名，需按业务口径标准化

决策建议：

多个推荐表中，优先选择"常用数据源"
对"陌生数据源"需额外验证，或向用户确认是否采用
对"有风险"数据源，建议告知用户并提供替代方案

并行检索策略

为提高效率，对多个推荐表的检索可并行执行：

# 并行检索多个表（使用 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

检索结果利用

检索完成后，必须：

汇总展示：将检索结果整理成摘要，展示给用户

📊 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 编写时引用

困惑时检索（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 文件：

从状态中获取步骤1产出的 REQ 文件路径
调用 skill(name="model-design-generator")，传入 REQ 文件路径
模型设计 skill 会自动读取 REQ 文件并生成对应的 MDDS 文件到 ./ai_text/
子技能完成后，展示摘要并等待用户确认：

✅ 模型设计已完成！
📄 文件路径：{路径}

请您审核：
- 编排步骤是否合理？
- 目标表属性是否正确？
- 字段设计是否符合预期？

回复"确认"进入步骤3，或指出需要修改的内容。

记录模型设计文档路径到状态中

困惑时检索（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

步骤3：SQL编写

用户确认模型设计后才能进入。本步骤由本 skill 主导，调用 write-sql 完成：

3.1 确定引擎类型

询问用户目标引擎：

请确认 SQL 目标引擎：
- spark（默认）— Paimon 数据仓库
- doris — 实时 OLAP 分析
- hive — 离线批处理
- kudu — 实时更新

如无特别要求，默认使用 spark。

3.2 读取文件并组装 context

本 skill 负责以下工作（不是 write-sql 的职责）：

读取需求文档：使用 Read 工具读取步骤1产出的 REQ 文件（./ai_text/REQ-DATA-xxx.md）
读取模型设计文档：使用 Read 工具读取步骤2产出的 MDDS 文件（./ai_text/MDDS-DATA-xxx.md）
组装 context：将两个文档内容拼接为完整的上下文文本
确定输出路径：从步骤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 完成后：

确认 SQL 文件已写入 output_path
简要展示 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 |
| "先简单查一下看看" | 简单取数优先，后续可转数据开发 |

---

## 状态跟踪

```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
    }
}

交互规则

场景	响应
用户首次输入需求	场景判断 → 让用户确认模式
用户确认数据开发	进入分支A（三步走）
用户确认简单取数	进入分支B（直接生成SQL）
用户确认步骤1/2	进入下一步
用户修改意见	调整后重新等待确认
中途切换模式	清理当前状态，进入目标模式
询问进度	告知当前模式、步骤及确认状态
指定引擎	记录到 state.engine
用户提及陌生概念	先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` 搜索两个资源

输出规范

所有产出物统一保存在 ./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

完成标志

数据开发模式：步骤1/2/3全部完成，用户均已确认，SQL文件已写入
简单取数模式：SQL已生成并展示给用户

25 KiB Raw Permalink Blame History Unescape Escape

智能数据开发员工 v3

技能定位

Conda 环境配置

conda run 示例

OpenViking 资源库

核心资源

搜索参数推荐

OV搜索强制执行时机

OV命令速查

工作流程

入口：场景判断

判断规则

交互模板

分支A：数据开发（三步走）

文件流转链路

步骤1：需求分析

✅ MUST：数据源匹配后 OV 深度检索

步骤2：模型设计

步骤3：SQL编写

3.1 确定引擎类型

3.2 读取文件并组装 context

3.3 调用 write-sql

3.4 验证与交付

数据开发交付

分支B：简单取数

B.1 确认引擎

B.2 确认补充信息（按需）

B.3 调用 write-sql

B.4 简单取数交付

交互规则

交互工具

困惑场景检索策略

输出规范

完成标志

25 KiB

Raw Permalink Blame History