557 lines
32 KiB
Markdown
557 lines
32 KiB
Markdown
---
|
||
name: requirement-analyzer
|
||
description: 通过分模块多轮对话引导业务人员补充需求信息，自动生成符合《数据需求技术规范文档》标准格式的业务需求模板。根据业务描述智能生成输出表字段。当用户提到数据需求、指标需求、报表需求、需要新建或修改数据表、提到具体的业务指标或数据统计时，必须主动触发此技能。
|
||
---
|
||
|
||
# 需求分析 Skill
|
||
|
||
## 技能描述
|
||
|
||
通过**分模块多轮对话**引导业务人员补充需求信息，自动生成符合《数据需求技术规范文档》**标准格式**的业务需求模板。
|
||
|
||
**核心原则**：
|
||
- 模板结构固定（表格格式、章节结构严格按规范）
|
||
- 字段内容灵活（根据业务描述智能生成，不预设任何字段）
|
||
|
||
**触发场景**：当用户提到以下任何情况时，必须主动触发此技能：
|
||
- 数据需求、指标需求、报表需求、统计需求
|
||
- 需要新建或修改数据表、数据仓库、数据指标
|
||
- 提到具体的业务指标（如投诉量、受理量、用户数、销售额等）
|
||
- 提到数据统计、数据汇总、数据聚合、每日统计、增量更新
|
||
- 提到按维度统计（如按日、按部门、按地区、按产品等）
|
||
- 需求描述、需求分析、生成需求文档
|
||
|
||
**重要**：即使用户只是简单提到一个指标想法（如"统计投诉受理量"），也要主动引导用户完成完整的需求分析流程，不要直接给出技术方案。
|
||
|
||
## 工作流程总览
|
||
|
||
```
|
||
┌─────────────────────────────────────────────────────────────────────┐
|
||
│ 数据需求分析完整流程 │
|
||
├─────────────────────────────────────────────────────────────────────┤
|
||
│ │
|
||
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
|
||
│ │ 模块 1+2 │────▶│ 模块 3 │────▶│ 模块 4 │ │
|
||
│ │ 基础+详细信息 │ │ 数据源匹配 │ │ 输出表字段生成 │ │
|
||
│ │ (同时收集) │ │ (OV优先检索) │ │ (智能生成) │ │
|
||
│ └──────────────┘ └──────────────┘ └──────────────┘ │
|
||
│ │ │ │ │
|
||
│ ▼ ▼ ▼ │
|
||
│ 用户一次性提供 用户确认数据源 用户确认/修改字段 │
|
||
│ 基础+详细信息 │
|
||
│ │ │ │
|
||
│ ▼ ▼ │
|
||
│ ┌──────────────┐ ┌──────────────┐ │
|
||
│ │ 模块 5 │◀────│ 用户确认 │ │
|
||
│ │ 生成文档 │ │ 最终结果 │ │
|
||
│ │ (保存文件) │ └──────────────┘ │
|
||
│ └──────────────┘ │
|
||
│ │ │
|
||
│ ▼ │
|
||
│ 📄 需求文档已保存 │
|
||
│ ./ai_text/
|
||
│ │
|
||
└─────────────────────────────────────────────────────────────────────┘
|
||
|
||
各模块说明：
|
||
┌─────────┬─────────────────────────────────────────────────────────────┐
|
||
│ 模块 │ 内容 │
|
||
├─────────┼─────────────────────────────────────────────────────────────┤
|
||
│ 模块1+2 │ 同时收集：需求编号、描述、提出方、对接人、完成时间、 │
|
||
│ │ 需求背景、业务口径、运行频次、备注、输出表信息 │
|
||
├─────────┼─────────────────────────────────────────────────────────────┤
|
||
│ 模块3 │ 使用 OV 优先匹配数据源，推荐可用表及字段；必要时 fallback 到 legacy data-structure-fetcher │
|
||
├─────────┼─────────────────────────────────────────────────────────────┤
|
||
│ 模块4 │ 基于确认的数据源，智能生成输出表字段（严禁凭空捏造） │
|
||
├─────────┼─────────────────────────────────────────────────────────────┤
|
||
│ 模块5 │ 整合所有信息，生成标准格式文档并保存到文件 │
|
||
└─────────┴─────────────────────────────────────────────────────────────┘
|
||
|
||
需求编号规则：REQ-DATA-YYYYMMDDHHmmss-XXX
|
||
- YYYYMMDDHHmmss：当前服务器精确时间（年4位+月2位+日2位+时2位+分2位+秒2位）
|
||
- XXX：3位序号，从001开始
|
||
- 示例：REQ-DATA-20260410162709-001（2026年04月10日 16:27:09）
|
||
```
|
||
|
||
---
|
||
|
||
## 模块 1+2：需求基础信息 + 详细信息（同时收集）
|
||
|
||
**目标**：一次性收集需求基础信息和详细业务信息，减少交互轮次
|
||
|
||
**引导问题**：
|
||
```
|
||
好的，我来帮您生成标准的需求文档。为了高效完成，请您一次性提供以下信息：
|
||
|
||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||
📋 第一部分：基础信息
|
||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||
|
||
1. 需求描述（核心业务目标是什么？）
|
||
2. 需求提出方/人（哪个部门/谁提出的？）
|
||
3. 需求对接人（业务对接人和技术对接人分别是谁？）
|
||
4. 期望完成时间（YYYY-MM-DD 格式，示例：2026-04-30）
|
||
|
||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||
📋 第二部分：详细信息
|
||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||
|
||
5. 需求背景（为什么要做这个需求？业务场景说明）
|
||
6. 业务口径描述（详细的数据处理逻辑，包括统计维度、统计指标、过滤条件等）
|
||
7. 运行频次（日/周/月/准实时，示例：日）
|
||
8. 备注信息（如数据合并规则、目标表等）
|
||
|
||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||
📋 第三部分：输出表信息
|
||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||
|
||
9. 输出表中文名称（这张结果表的中文名是什么？）
|
||
10. 输出表英文名/路径（库名.表名格式）
|
||
11. 数据目录（如：上海电信/大数据中心-数据安全团队/大数据中心-数据安全团队应用层）
|
||
12. 数据源类型（paimon/hive/mysql 等）
|
||
13. 表的业务用途描述
|
||
```
|
||
|
||
**智能引导**（根据用户回答自动追问）：
|
||
- **统计维度**：确认所有分组维度（如：按日、按部门、按地区、产品类型等）
|
||
- **统计指标**：确认每个指标的计算方式（如：计数、求和、去重计数、平均值等）
|
||
- **数据更新方式**：全量覆盖 vs 增量追加（如"每日增量更新"需确认增量字段）
|
||
- **时间范围**：历史数据回溯要求、数据保留周期
|
||
- **过滤条件**：有效数据筛选规则（如：仅统计已处理的投诉、排除测试数据等）
|
||
|
||
**输出格式**：
|
||
```markdown
|
||
【模块 1+2 完成】需求基础信息 + 详细信息
|
||
|
||
### 基础信息
|
||
|
||
| 序号 | 项目 | 填写内容 | 必填标识 | 备注 |
|
||
|------|------|----------|----------|------|
|
||
| 1 | 需求编号 | REQ-DATA-{YYYYMMDDHHmmss}-{XXX} | | 唯一标识，按**服务器当前精确时间**（精确到秒）+ 序号编排 |
|
||
| 2 | 需求描述 | {value} | ★ | 简洁概括核心业务目标 |
|
||
| 3 | 需求提出方/人 | {value} | ★ | 业务归属部门/人 |
|
||
| 4 | 需求对接人 | {value} | ★ | 业务 + 技术对接责任人 |
|
||
| 5 | 期望完成时间 | {value} | | 需求落地完成时限 |
|
||
|
||
### 详细信息
|
||
|
||
| 项目 | 内容 | 必填标识 |
|
||
|------|------|----------|
|
||
| 需求背景 | {value} | ★ |
|
||
| 业务口径描述 | {value} | ★ |
|
||
| 运行频次 | {value} | ★ |
|
||
| 备注信息 | {value} | ★ |
|
||
|
||
### 输出表信息
|
||
|
||
| 输出属性 | 表中文名称 | 表英文名称（库+表） | 数据目录 | 数据源类型 | 表描述 |
|
||
|---------|-----------|---------------------|---------|-----------|--------|
|
||
| 表新建/表更新 | {表中文名称} | {库名.表名} | {数据目录} | {数据源类型} | {表描述} |
|
||
|
||
以上信息是否正确？确认后进入模块 3（OV 优先匹配数据源）。
|
||
```
|
||
|
||
**需求编号生成规则**：
|
||
- 格式：`REQ-DATA-YYYYMMDDHHmmss-XXX`（14 位日期时间 +3 位序号）
|
||
- 示例：`REQ-DATA-20260410162709-001`
|
||
- 规则：
|
||
- 日期时间：**必须获取服务器当前实际时间**（年4位+月2位+日2位+时2位+分2位+秒2位，共14位）
|
||
- 序号：3 位，从 001 开始
|
||
- 示例拆解：`20260410162709` = 2026年04月10日 16:27:09
|
||
- ⚠️ **重要**：时间必须精确到秒，不可使用估算时间或示例时间
|
||
|
||
---
|
||
|
||
## 模块 3：OV 优先匹配数据源
|
||
|
||
**目标**：使用 OV 搜索字段处理经验、表结构、历史成功 SQL 和业务语义，推荐可用数据源。`legacy-data-structure-fetcher` 只作为用户同意后的 fallback。
|
||
|
||
**调用方式**：
|
||
1. 提取模块 1+2 的业务口径描述关键词
|
||
2. 运行任何 OV 命令之前，先读取 `../references/ov-search-context.md` 了解 OV 命令用法
|
||
3. 先搜索 `field-process-memory`，用历史经验判断常用数据源、业务口径和候选方向：
|
||
- `conda run -n py13 ov find "{业务口径/核心实体}" --uri "viking://resources/field-process-memory" --threshold 0.2 --node-limit 10`
|
||
- `conda run -n py13 ov grep "{核心实体|关键词}" --uri "viking://resources/field-process-memory" --node-limit 10`
|
||
4. 再用 `table-metadata` 补充确认表结构和字段：
|
||
- `conda run -n py13 ov find "{业务口径/核心实体}" --uri "viking://resources/table-metadata" --threshold 0.2 --node-limit 10`
|
||
- `conda run -n py13 ov grep "{核心实体|关键词}" --uri "viking://resources/table-metadata" --node-limit 10`
|
||
5. 对每个推荐表按顺序执行 OV 深度检索：
|
||
- 常用数据源判断：`conda run -n py13 ov grep "{表名}" --uri "viking://resources/field-process-memory" --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" --threshold 0.2 --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`
|
||
6. 获取推荐的数据源列表（库、表、字段、技术负责人、字段类型），并给出常用数据源判断
|
||
7. 仅当 OV 命令失败、候选表不足、或用户明确要求旧方案时，先告知用户原因并获得明确同意；同意后再读取 `../references/legacy-data-structure-fetcher/SKILL.md` 并使用其中脚本补充推荐
|
||
|
||
**legacy fallback 同意模板**：
|
||
```text
|
||
OV 检索结果不足/不可用。是否同意我使用 legacy data-structure-fetcher 脚本补充搜索数据源？
|
||
```
|
||
|
||
**输出格式**：
|
||
```markdown
|
||
【模块 3】数据源匹配结果
|
||
|
||
根据您的需求描述，我先使用 OV 搜索字段处理经验和历史记忆，再补充搜索表结构与历史 SQL，推荐以下数据源：
|
||
|
||
### 推荐数据源（按综合得分排序）
|
||
|
||
| 库 | 表 | 表中文描述 | 字段 | 字段中文描述 | 技术负责人 | 字段类型 |
|
||
|----|----|------------|------|--------------|------------|----------|
|
||
| {schema} | {table} | {table_cn_name} | {column} | {column_cn} | {owner} | {type} |
|
||
| {schema} | {table} | {table_cn_name} | {column} | {column_cn} | {owner} | {type} |
|
||
|
||
请确认：
|
||
- 选择哪些表作为数据源？（回复序号或表名）
|
||
- 需要补充其他表吗？
|
||
- 技术负责人信息是否正确？
|
||
|
||
回复"数据源确认"进入模块 4（生成输出表字段）。
|
||
```
|
||
|
||
### 常用数据源判断格式
|
||
|
||
```markdown
|
||
📋 常用数据源判断结果：
|
||
|
||
【{schema}.{table}】
|
||
- 检索结果：找到 {N} 条历史使用记录
|
||
- 判断：✅ 常用数据源 / ⚠️ 偶尔使用 / ❓ 新或陌生数据源 / ⚠️ 有风险
|
||
- 历史使用场景：{场景摘要}
|
||
- 注意事项：{字段处理经验或风险}
|
||
```
|
||
|
||
---
|
||
|
||
## 模块 4：智能生成输出表字段
|
||
|
||
**目标**：基于模块 1+2 的业务描述 + 模块 3 的数据源结果，智能生成输出表字段
|
||
|
||
**⚠️ 核心约束（必须遵守）**：
|
||
1. **严禁凭空捏造字段**：输出字段的"来源表.字段"必须严格来自模块 3 用户确认的数据源表及其字段，不得编造不存在的表或字段
|
||
2. **严禁凭空调用代码**：不得假设存在某个 API、脚本或数据库连接，所有加工逻辑必须基于模块 3 已确认的源表字段
|
||
3. **字段映射必须有依据**：每个输出字段的加工逻辑必须清晰说明如何从模块 3 的源字段转换/聚合/计算得到
|
||
|
||
**智能生成逻辑**：
|
||
|
||
1. **回顾模块 3 数据源**：列出用户确认的所有数据源表及其字段清单
|
||
2. **解析业务口径**：从模块 1+2 提取统计维度、统计指标、过滤条件
|
||
3. **维度字段生成**：按统计维度生成字段，来源必须指向模块 3 确认的源表字段
|
||
- 例如：若统计维度是"投诉处理地部门"，则需找到模块 3 中哪个表的哪个字段代表部门（如 `dwd_crm_srv_complaint_rt_pos.create_org_id`）
|
||
- 若需要部门名称，需关联模块 3 中的组织架构表（如 `dwd_crm_bas_organization_ext_rt_ff.org_id` → `accnt_bureau`）
|
||
4. **指标字段生成**：按统计指标生成字段，来源必须指向模块 3 确认的源表字段
|
||
- 例如：投诉受理量 = `count(distinct dwd_crm_srv_complaint_rt_pos.complaint_id)`
|
||
5. **技术字段生成**：根据需要添加技术字段（如数据写入时间、分区字段、etl_remark 等）
|
||
- 系统函数字段（如 `etl_time`、`day_id`）来源标注为"系统函数"或"系统参数"
|
||
- 固定赋值字段（如指标编码、指标名称）来源标注为"固定值"
|
||
6. **填充加工逻辑**：根据业务口径描述生成字段加工逻辑，明确标注来源表.字段
|
||
7. **建议负责人**：从模块 1+2 的需求对接人中提取
|
||
|
||
**输出格式**：
|
||
```markdown
|
||
【模块 4】输出表字段（自动生成初稿）
|
||
|
||
根据您的业务描述和数据源匹配结果，我生成了以下输出字段：
|
||
|
||
### 输出表名
|
||
|
||
| 输出属性* | 表中文名称* | 表英文名称（库+表） | 数据目录* | 数据源类型* | 表描述 |
|
||
| ---- | ---- | ---- | ---- | ---- | ---- |
|
||
| {表新建/表更新} | {表中文名称} | {库名.表名} | {数据目录} | {数据源类型} | {表描述} |
|
||
|
||
### 输出表字段
|
||
|
||
| 排序 | 输出字段中文名* | 输出字段英文名 | 字段业务含义* | 输出字段类型 | 字段加工逻辑（多个）* | 来源表.字段（多个）* | 口径业务负责人* | 口径技术负责人* | 说明 |
|
||
| ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- |
|
||
| 1 | {字段中文名} | {field_name} | {业务含义} | {type} | {加工逻辑} | {source_table.column} | {业务负责人} | {技术负责人} | {说明} |
|
||
| 2 | {字段中文名} | {field_name} | {业务含义} | {type} | {加工逻辑} | {source_table.column} | {业务负责人} | {技术负责人} | {说明} |
|
||
| ... | ... | ... | ... | ... | ... | ... | ... | ... | ... |
|
||
|
||
请检查并修改：
|
||
- 字段是否完整？需要补充或删除哪些字段？
|
||
- 字段名称是否需要调整？
|
||
- 字段加工逻辑是否准确？来源表.字段是否正确？
|
||
- 负责人信息是否正确？
|
||
|
||
确认后可修改，回复"字段确认"进入模块 5。
|
||
```
|
||
|
||
**用户修改机制**：
|
||
- 用户可以直接指出需要修改的字段
|
||
- 用户可以补充新字段
|
||
- 用户可以删除字段
|
||
- 修改后重新生成表格供确认
|
||
|
||
**字段生成注意事项**：
|
||
- **来源表.字段必须有依据**：每个字段的"来源表.字段"列必须严格来自模块 3 用户确认的数据源，不得编造
|
||
- 对于无业务含义的扩展字段（如 x_dim01~x_dim10），加工逻辑标注为"赋值为 null"，来源表标注为"-"
|
||
- 对于固定赋值字段（如指标编码、指标名称），加工逻辑标注为"固定赋值：'xxx'"，来源表标注为"固定值"
|
||
- 对于系统函数字段（如 etl_time、day_id），加工逻辑标注为系统函数（如 now()、${day_id}），来源表标注为"系统函数"或"系统参数"
|
||
- 字段加工逻辑应清晰描述业务规则，如部门名称映射规则、统计计算方式等
|
||
- **加工逻辑示例**：
|
||
- 维度字段：`关联 dwd_crm_bas_organization_ext_rt_ff.org_id = dwd_crm_srv_complaint_rt_pos.create_org_id，取 accnt_bureau 作为部门名称`
|
||
- 指标字段：`按日期+部门分组，count(distinct dwd_crm_srv_complaint_rt_pos.complaint_id)`
|
||
|
||
---
|
||
|
||
## 模块 5：生成完整需求文档模板
|
||
|
||
**目标**：整合所有模块信息，生成标准格式的需求文档并保存到文件
|
||
|
||
**文档保存**：
|
||
- 保存路径：`./ai_text/`
|
||
- 文件命名：`REQ-DATA-{YYYYMMDDHHmmss}-{XXX}.md`（与需求编号一致）
|
||
- 时间要求：**必须使用当前实际时间**（年4位+月2位+日2位+时2位+分2位+秒2位）
|
||
- 示例：`./ai_text/REQ-DATA-20260410162709-001.md`（2026年04月10日 16:27:09）
|
||
- 保存方式：使用 write 工具将完整文档写入该路径
|
||
|
||
**文档结构**（严格按此顺序）：
|
||
1. 需求基础信息
|
||
2. 需求详细信息
|
||
3. 所用数据源及字段
|
||
4. 确认输出表名及字段
|
||
|
||
**输出格式**：
|
||
```markdown
|
||
# 数据需求技术规范文档
|
||
|
||
## 1. 需求基础信息
|
||
|
||
| 序号 | 项目 | 填写内容 | 必填标识 | 备注 |
|
||
|------|------|----------|----------|------|
|
||
| 1 | 需求编号 | REQ-DATA-{YYYYMMDDHHmmss}-{XXX} | | 唯一标识，按**当前实际时间**（精确到秒）+序号编排 |
|
||
| 2 | 需求描述 | {需求描述} | ★ | 简洁概括核心业务目标 |
|
||
| 3 | 需求提出方/人 | {需求提出方/人} | ★ | 业务归属部门/人 |
|
||
| 4 | 需求对接人 | {需求对接人} | ★ | 业务+技术对接责任人 |
|
||
| 5 | 期望完成时间 | {期望完成时间} | | 需求落地完成时限 |
|
||
|
||
---
|
||
|
||
## 2. 需求详细信息
|
||
|
||
| 项目 | 内容 | 必填标识 |
|
||
|------|------|----------|
|
||
| 需求背景 | {需求背景} | ★ |
|
||
| 业务口径描述 | {业务口径描述} | ★ |
|
||
| 运行频次 | {运行频次} | ★ |
|
||
| 备注信息 | {备注信息} | ★ |
|
||
|
||
---
|
||
|
||
## 3. 所用数据源及字段
|
||
|
||
| 库 | 表 | 表中文描述 | 字段 | 字段中文描述 | 技术负责人 | 字段类型 |
|
||
|----|----|------------|------|--------------|------------|----------|
|
||
{数据源行，每张表的每个字段一行}
|
||
|
||
---
|
||
|
||
## 4. 确认输出表名及字段
|
||
|
||
### 输出表名
|
||
|
||
| 输出属性* | 表中文名称* | 表英文名称（库+表） | 数据目录* | 数据源类型* | 表描述 |
|
||
| ---- | ---- | ---- | ---- | ---- | ---- |
|
||
| {表新建/表更新} | {表中文名称} | {库名.表名} | {数据目录} | {数据源类型} | {表描述} |
|
||
|
||
### 输出表字段
|
||
|
||
| 排序 | 输出字段中文名* | 输出字段英文名 | 字段业务含义* | 输出字段类型 | 字段加工逻辑（多个）* | 来源表.字段（多个）* | 口径业务负责人* | 口径技术负责人* | 说明 |
|
||
| ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- |
|
||
{输出表字段行}
|
||
|
||
---
|
||
```
|
||
|
||
**完成提示**：
|
||
```
|
||
✅ 需求文档已生成并保存！
|
||
|
||
📄 文件路径：./ai_text/{需求编号}.md
|
||
|
||
文档包含：
|
||
- 第 1 块：需求基础信息（5 项）
|
||
- 第 2 块：需求详细信息（4 项）+ 输出表信息
|
||
- 第 3 块：所用数据源及字段（{M}张表，{N}个字段）
|
||
- 第 4 块：确认输出表名及字段（{K}个字段）
|
||
|
||
如需修改任何内容，请指出具体模块和字段。
|
||
```
|
||
|
||
---
|
||
|
||
## 交互规则
|
||
|
||
1. **模块1+2合并引导**：基础信息和详细信息在同一轮对话中同时向用户收集，减少交互轮次
|
||
2. **分模块推进**：按 模块1+2 → 模块3 → 模块4 → 模块5 顺序执行，每模块完成后需用户确认
|
||
3. **智能校验**：检查必填项是否完整，格式是否正确
|
||
4. **数据源优先**：模块 3 先读取 OV reference，再按 `field-process-memory` → `table-metadata` → `sql_snippets` 顺序匹配数据源，模块 4 再基于数据源生成输出字段；legacy data-structure-fetcher 只在 OV 不可用、召回不足或用户指定且用户明确同意后使用
|
||
5. **文档保存**：模块 5 生成文档后，必须使用 write 工具将文档保存到 `./ai_text/{需求编号}.md`
|
||
6. **灵活跳转**：允许用户随时补充或修改之前模块的信息
|
||
7. **多轮对话记忆**：记住用户之前提供的信息，避免重复询问
|
||
8. **字段加工逻辑**：必须清晰描述业务规则，不能仅写"待确认"
|
||
9. **需求编号时间**：必须使用服务器当前精确时间（精确到秒），不可使用估算或示例时间
|
||
|
||
## 状态管理
|
||
|
||
使用以下状态变量跟踪进度：
|
||
```
|
||
state = {
|
||
"current_module": "1+2",
|
||
"module1_2_complete": false,
|
||
"module3_complete": false,
|
||
"module4_complete": false,
|
||
"module5_complete": false,
|
||
"data": {
|
||
"基础信息": {...},
|
||
"详细信息": {...},
|
||
"输出表信息": {...},
|
||
"数据源": [...],
|
||
"输出表字段": [...]
|
||
}
|
||
}
|
||
```
|
||
|
||
## 触发指令
|
||
|
||
用户输入包含以下关键词时触发：
|
||
- "数据需求"、"需求分析"、"生成需求文档"
|
||
- "指标需求"、"报表需求"、"需求描述"
|
||
- "统计 XX 量"、"按 XX 维度"
|
||
- "每日/每周/每月更新"
|
||
- "新建表"/"修改表"、"数据口径"
|
||
|
||
## 示例对话
|
||
|
||
**用户**：我有一个数据需求，要统计各投诉处理部门的投诉量
|
||
|
||
**助手**：好的，我来帮您生成标准的需求文档。为了高效完成，请您一次性提供以下信息：
|
||
|
||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||
📋 第一部分：基础信息
|
||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||
|
||
1. 需求描述（核心业务目标是什么？）
|
||
2. 需求提出方/人（哪个部门/谁提出的？）
|
||
3. 需求对接人（业务对接人和技术对接人分别是谁？）
|
||
4. 期望完成时间（YYYY-MM-DD 格式）
|
||
|
||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||
📋 第二部分：详细信息
|
||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||
|
||
5. 需求背景（为什么要做这个需求？业务场景说明）
|
||
6. 业务口径描述（详细的数据处理逻辑）
|
||
7. 运行频次（日/周/月/准实时）
|
||
8. 备注信息（如数据合并规则、目标表等）
|
||
|
||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||
📋 第三部分：输出表信息
|
||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||
|
||
9. 输出表中文名称
|
||
10. 输出表英文名/路径（库名.表名格式）
|
||
11. 数据目录
|
||
12. 数据源类型（paimon/hive/mysql 等）
|
||
13. 表的业务用途描述
|
||
|
||
**用户**：需求是监控各投诉处理部门的服务压力与绩效表现。提出方是市场部流量运营组/张三，业务对接人李四，技术对接人王五，期望 2026-04-30 完成。背景是实时监控各部门服务压力。口径是按日统计各投诉处理部门的投诉受理量，每日增量更新。备注：'市场部卡中心（投诉用）'等统一命名为"市场部"，数据插入到 db_eda_prj004_prd.prj004_ads_rpt_kfb_idx_rt。表名：投诉处理地投诉受理量表，数据目录：上海电信/大数据中心-数据安全团队/大数据中心-数据安全团队应用层，数据源类型 paimon。
|
||
|
||
**助手**：收到，确认基础信息 + 详细信息：
|
||
|
||
### 基础信息
|
||
|
||
| 序号 | 项目 | 填写内容 | 必填标识 | 备注 |
|
||
|------|------|----------|----------|------|
|
||
| 1 | 需求编号 | REQ-DATA-{当前服务器精确时间YYYYMMDDHHmmss}-{XXX} | | 唯一标识（示例：20260410162709 = 2026年04月10日 16:27:09） |
|
||
| 2 | 需求描述 | 监控各投诉处理部门的服务压力与绩效表现，统计投诉受理量 | ★ | 核心业务目标 |
|
||
| 3 | 需求提出方/人 | 市场部流量运营组/张三 | ★ | 业务归属 |
|
||
| 4 | 需求对接人 | 李四（业务）、王五（技术） | ★ | 对接责任人 |
|
||
| 5 | 期望完成时间 | 2026-04-30 | | 完成时限 |
|
||
|
||
### 详细信息
|
||
|
||
| 项目 | 内容 | 必填标识 |
|
||
|------|------|----------|
|
||
| 需求背景 | 实时监控各部门服务压力与绩效表现 | ★ |
|
||
| 业务口径描述 | 按日统计各投诉处理部门的投诉受理量，每日增量更新 | ★ |
|
||
| 运行频次 | 日 | ★ |
|
||
| 备注信息 | '市场部卡中心（投诉用）'等统一命名为"市场部"，数据插入到 db_eda_prj004_prd.prj004_ads_rpt_kfb_idx_rt | ★ |
|
||
|
||
### 输出表信息
|
||
|
||
| 输出属性 | 表中文名称 | 表英文名称（库+表） | 数据目录 | 数据源类型 | 表描述 |
|
||
|---------|-----------|---------------------|---------|-----------|--------|
|
||
| 表更新 | 投诉处理地投诉受理量表 | db_eda_prj004_prd.prj004_ads_rpt_kfb_idx_rt | 上海电信/大数据中心-数据安全团队/大数据中心-数据安全团队应用层 | paimon | 按处理地维度统计投诉受理量相关指标 |
|
||
|
||
以上信息是否正确？确认后进入模块 3。
|
||
|
||
**用户**：正确
|
||
|
||
**助手**：✅ 模块 1+2 完成
|
||
|
||
【模块 3】数据源匹配
|
||
|
||
正在使用 OV 搜索表结构、历史 SQL 和字段处理经验...
|
||
|
||
推荐以下数据源：
|
||
|
||
| 库 | 表 | 表中文描述 | 字段 | 字段中文描述 | 技术负责人 | 字段类型 |
|
||
|----|----|------------|------|--------------|------------|----------|
|
||
| db_dwd | dwd_crm_srv_complaint_rt | 投诉整合层主表 | complaint_id | 投诉ID | 蒋平川 | STRING |
|
||
| db_dwd | dwd_crm_srv_complaint_rt | 投诉整合层主表 | assist_dept_org_id | 发展组织id | 蒋平川 | STRING |
|
||
| db_dwd | dwd_crm_srv_complaint_rt | 投诉整合层主表 | create_date | 创建日期 | 蒋平川 | STRING |
|
||
| db_dim | dim_intnl_org_new | 组织架构维表 | org_id | 组织id | 范鑫鑫 | STRING |
|
||
| db_dim | dim_intnl_org_new | 组织架构维表 | org_name | 组织名称 | 范鑫鑫 | STRING |
|
||
|
||
请确认选择哪些表作为数据源？
|
||
|
||
**用户**：选择全部，数据源确认
|
||
|
||
**助手**：✅ 模块 3 完成
|
||
|
||
【模块 4】输出表字段（自动生成初稿）
|
||
|
||
根据您的业务描述和数据源匹配结果，我生成了以下输出字段：
|
||
|
||
### 输出表名
|
||
|
||
| 输出属性* | 表中文名称* | 表英文名称（库+表） | 数据目录* | 数据源类型* | 表描述 |
|
||
| ---- | ---- | ---- | ---- | ---- | ---- |
|
||
| 表更新 | 投诉处理地投诉受理量表 | db_eda_prj004_prd.prj004_ads_rpt_kfb_idx_rt | 上海电信/大数据中心-数据安全团队/大数据中心-数据安全团队应用层 | paimon | 按处理地维度统计投诉受理量相关指标 |
|
||
|
||
### 输出表字段
|
||
|
||
| 排序 | 输出字段中文名* | 输出字段英文名 | 字段业务含义* | 输出字段类型 | 字段加工逻辑（多个）* | 来源表.字段（多个）* | 口径业务负责人* | 口径技术负责人* | 说明 |
|
||
| ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- |
|
||
| 1 | 指标编码 | idx_nbr | 投诉量指标唯一编码 | string | 固定赋值：'D_DXT_00002085' | 固定值 | 李四 | 王五 | 指标唯一标识 |
|
||
| 2 | 指标名称 | idx_name | 指标中文名称 | string | 固定赋值：'投诉量' | 固定值 | 李四 | 王五 | 指标业务名称 |
|
||
| 3 | 投诉处理部门名称 | bureau_name | 标准化后的投诉处理部门名称 | string | 1. 原始部门名称为'市场部卡中心（投诉用）'、'市场部终端中心（投诉用）'、'市场部综合（投诉用）'时，统一替换为"市场部"，其他部门名称保持原值。<br>2. 关联组织架构维表（dim_intnl_org_new）获取组织名称（org_name）为投诉处理地部门 | dwd_crm_srv_complaint_rt.assist_dept_org_id; dim_intnl_org_new.org_id; dim_intnl_org_new.org_name | 李四 | 王五 | 部门名称标准化口径 |
|
||
| 4 | 投诉受理量 | idx_value | 当日单部门投诉受理总数量 | bigint | 按日期+部门分组，count(distinct complaint_id)统计投诉条数 | dwd_crm_srv_complaint_rt.complaint_id | 李四 | 王五 | 投诉总量统计 |
|
||
| 5 | 指标值类型 | idx_val_type | 指标值数据类型标识 | string | 判断idx_value是否为整数，是则赋值'整数'，否则'小数' | 计算字段idx_value | 李四 | 王五 | 本需求固定为整数 |
|
||
| 6 | 数据加工时间 | etl_time | 数据写入表的时间 | timestamp | 系统当前时间now() | 系统函数now() | - | 王五 | 数据加工追溯使用 |
|
||
| 7 | 统计日期 | day_id | 投诉数据统计日期 | string | 1. 取${day_id}转换为yyyy-MM-dd格式<br>2. 作为分区键，每日覆盖写入 | 系统参数${day_id} | 李四 | 王五 | 分区字段，格式：yyyy-MM-dd |
|
||
|
||
请检查并修改，回复"字段确认"进入模块 5。
|
||
|
||
**用户**：字段确认
|
||
|
||
**助手**：✅ 模块 4 完成
|
||
|
||
【模块 5】生成完整需求文档
|
||
|
||
正在生成标准格式的需求文档并保存到文件...
|
||
|
||
📄 已保存至：`./ai_text/REQ-DATA-20260410162709-001.md`
|
||
|
||
✅ 需求文档已生成！
|
||
|
||
文档包含：
|
||
- 第 1 块：需求基础信息（5 项）
|
||
- 第 2 块：需求详细信息（4 项）+ 输出表信息
|
||
- 第 3 块：所用数据源及字段（2 张表，5 个字段）
|
||
- 第 4 块：确认输出表名及字段（7 个字段）
|
||
|
||
如需修改任何内容，请指出具体模块和字段。
|