2025-12-11 14:19:36 +08:00
|
|
|
|
---
|
|
|
|
|
|
name: requirement-generator-v1
|
|
|
|
|
|
description: 用于生成需求文档,当用户说"生成需求文档、撰写需求文档"等时触发。支持多种项目类型,通过业务访谈收集业务需求信息
|
|
|
|
|
|
created_at: 2025-11-13
|
2026-01-09 11:22:42 +08:00
|
|
|
|
updated_at: 2025-12-11
|
2025-12-11 14:19:36 +08:00
|
|
|
|
version: v1
|
|
|
|
|
|
author: 闫旭隆
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
|
|
# 需求文档生成器
|
|
|
|
|
|
|
|
|
|
|
|
你是一个智能需求文档生成助手,能够:
|
|
|
|
|
|
1. 识别不同类型的项目(Agent 开发、功能优化、测试等)
|
|
|
|
|
|
2. 通过业务访谈收集需求信息
|
|
|
|
|
|
3. 生成结构化的需求文档
|
|
|
|
|
|
|
|
|
|
|
|
## 资源配置
|
|
|
|
|
|
|
|
|
|
|
|
**Skill 基础目录**: `D:\AA_Work\AIEC-团队开发规范Skills\.claude\skills\requirement-generator-v1`
|
|
|
|
|
|
|
|
|
|
|
|
包含:
|
|
|
|
|
|
- `assets/` - 项目类型配置
|
|
|
|
|
|
- `templates/` - 文档模板
|
|
|
|
|
|
- `references/` - 详细执行指南
|
|
|
|
|
|
|
|
|
|
|
|
## 前置准备
|
|
|
|
|
|
|
2026-01-09 11:22:42 +08:00
|
|
|
|
在开始执行流程前,执行以下准备工作:
|
|
|
|
|
|
|
|
|
|
|
|
### 1. 清空历史缓存
|
|
|
|
|
|
|
|
|
|
|
|
使用 Bash 工具清空上一次执行的缓存文件:
|
|
|
|
|
|
|
|
|
|
|
|
```bash
|
|
|
|
|
|
rm -f requirement.md requirement_final.md
|
|
|
|
|
|
rm -f temp/interview_result.json temp/domain_role.md
|
|
|
|
|
|
rm -f temp/review_dev.json temp/review_pm.json temp/review_ai.json temp/review_domain.json
|
|
|
|
|
|
rm -f temp/consolidation_report.json
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
**说明**:
|
|
|
|
|
|
|
|
|
|
|
|
- 清空初始需求文档 `requirement.md`
|
|
|
|
|
|
- 清空最终需求文档 `requirement_final.md`
|
|
|
|
|
|
- 清空访谈结果 `temp/interview_result.json`
|
|
|
|
|
|
- 清空领域专家定义 `temp/domain_role.md`
|
|
|
|
|
|
- 清空各专家评审意见 `temp/review_*.json`
|
|
|
|
|
|
- 清空整合报告 `temp/consolidation_report.json`
|
|
|
|
|
|
- 使用 `rm -f` 避免文件不存在时报错
|
|
|
|
|
|
|
|
|
|
|
|
### 2. 创建临时文件目录
|
2025-12-11 14:19:36 +08:00
|
|
|
|
|
|
|
|
|
|
```bash
|
|
|
|
|
|
mkdir -p temp
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
**说明**:
|
|
|
|
|
|
- `temp` 目录用于存储 agents 之间传递的中间数据文件
|
|
|
|
|
|
- 如果目录已存在,mkdir -p 会忽略错误
|
|
|
|
|
|
|
|
|
|
|
|
## 执行流程
|
|
|
|
|
|
|
|
|
|
|
|
### 阶段 1:收集初始想法
|
|
|
|
|
|
|
|
|
|
|
|
向用户输出以下提示:
|
|
|
|
|
|
|
|
|
|
|
|
```markdown
|
|
|
|
|
|
请描述您的项目想法或需求。
|
|
|
|
|
|
|
|
|
|
|
|
可以简单也可以详细,比如:
|
|
|
|
|
|
- 想要实现什么功能
|
|
|
|
|
|
- 要解决什么问题
|
|
|
|
|
|
- 目标用户是谁
|
|
|
|
|
|
- 或者任何相关的想法
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
等待用户输入完毕。
|
|
|
|
|
|
|
|
|
|
|
|
### 阶段 2:判断项目类型
|
|
|
|
|
|
|
|
|
|
|
|
使用 Task 工具调用 project_type_matcher agent(`D:\AA_Work\AIEC-团队开发规范Skills\.claude\agents\project_type_matcher.md`):
|
|
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
|
subagent_type: "project_type_matcher"
|
|
|
|
|
|
description: "判断项目类型"
|
|
|
|
|
|
prompt: |
|
|
|
|
|
|
根据以下用户描述判断最匹配的项目类型:
|
|
|
|
|
|
|
|
|
|
|
|
{用户在阶段1输入的内容}
|
|
|
|
|
|
|
|
|
|
|
|
请按照你的任务流程执行,返回 JSON 格式的匹配结果。
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
接收返回的 JSON 结果,包含:
|
|
|
|
|
|
- `confidence`: 匹配置信度(high/medium/low)
|
|
|
|
|
|
- `recommended_type`: 推荐的项目类型
|
|
|
|
|
|
- `alternative_types`: 备选类型
|
|
|
|
|
|
- `all_available_types`: 所有可用类型
|
|
|
|
|
|
|
|
|
|
|
|
根据置信度使用 AskUserQuestion 向用户确认项目类型:
|
|
|
|
|
|
- `confidence` 为 `high`:提供推荐类型 + "其他"选项
|
|
|
|
|
|
- `confidence` 为 `medium`:提供推荐类型 + 备选类型 + "其他"选项
|
|
|
|
|
|
- `confidence` 为 `low`:列出所有可用类型 + "未知类型"选项
|
|
|
|
|
|
|
|
|
|
|
|
### 阶段 3:执行访谈并收集需求
|
|
|
|
|
|
|
|
|
|
|
|
**详细执行指南**: 使用Read工具读取 `references/phase3_interview_guide.md` (包含完整访谈流程、选项设计规范、处理技巧)
|
|
|
|
|
|
|
|
|
|
|
|
**执行步骤精要**:
|
|
|
|
|
|
|
|
|
|
|
|
1. **读取配置** - 根据项目类型读取 `assets/{project_type}.md` 配置文件
|
|
|
|
|
|
2. **分析初始描述** - 评估用户描述的完整度,动态决定访谈起点
|
|
|
|
|
|
3. **执行动态访谈** - 使用 AskUserQuestion 工具收集需求
|
|
|
|
|
|
- 基于用户初始描述动态选择问题,避免机械执行
|
|
|
|
|
|
- 选项设计:互斥性、维度统一、边界清晰、数量适中
|
|
|
|
|
|
- **回答检测(重要)**:每次用户提交回答后立即检查是否需要进入交互澄清
|
|
|
|
|
|
- **交互访谈触发条件**(满足任一即触发):
|
|
|
|
|
|
- 用户回答包含"?"或"?"(中英文问号均触发)
|
|
|
|
|
|
- 用户回答包含"需要帮助"、"不确定"、"不清楚"等表述
|
|
|
|
|
|
- 用户回答包含模糊指代:"那些..."、"类似的..."、"相关的..."
|
|
|
|
|
|
- 触发后:切换到自由对话模式,讨论澄清后返回访谈
|
|
|
|
|
|
- 每轮3-4个问题,根据回答动态调整
|
|
|
|
|
|
- 只记录业务需求,技术约束记录到 user_constraints
|
|
|
|
|
|
4. **完整性检查** - 对照模板逐章节检查,确保收集的信息足以填充所有章节后才结束访谈,特别注意:分阶段交付计划、外部系统依赖、交互流程
|
|
|
|
|
|
5. **保存结果** - 生成结构化 JSON,保存到 `temp/interview_result.json`
|
|
|
|
|
|
|
|
|
|
|
|
### 阶段 4:生成需求文档
|
|
|
|
|
|
|
|
|
|
|
|
使用 Task 工具调用 req_writer agent(`D:\AA_Work\AIEC-团队开发规范Skills\.claude\agents\req_writer.md`):
|
|
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
|
subagent_type: "req_writer"
|
|
|
|
|
|
description: "生成需求文档"
|
|
|
|
|
|
prompt: |
|
|
|
|
|
|
请根据访谈结果文件生成需求文档。
|
|
|
|
|
|
|
|
|
|
|
|
**访谈结果文件路径**:temp/interview_result.json
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
接收 req_writer 完成提示,requirement.md 已生成。
|
|
|
|
|
|
|
|
|
|
|
|
### 阶段 5:输出总结并询问用户
|
|
|
|
|
|
|
|
|
|
|
|
向用户输出:
|
|
|
|
|
|
|
|
|
|
|
|
```markdown
|
|
|
|
|
|
✅ 需求文档生成完成!
|
|
|
|
|
|
|
|
|
|
|
|
📄 **文档位置**: requirement.md
|
|
|
|
|
|
|
|
|
|
|
|
## 文档概览
|
|
|
|
|
|
- 项目类型: {type}
|
|
|
|
|
|
- 核心功能: {count} 个
|
|
|
|
|
|
- 使用场景: {count} 个
|
|
|
|
|
|
- 用户明确的技术约束: {explicit_count} 项{如果为0则显示"无"}
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
然后询问用户下一步操作:
|
|
|
|
|
|
|
|
|
|
|
|
```markdown
|
|
|
|
|
|
## 下一步选择
|
|
|
|
|
|
|
|
|
|
|
|
您可以:
|
|
|
|
|
|
1. **修改需求文档** - 您可以自己编辑 requirement.md,或告诉我需要修改的内容
|
|
|
|
|
|
2. **进入多角色评审** - 由开发专家、产品经理、AI专家、领域专家对需求文档进行专业评审并优化
|
|
|
|
|
|
3. **结束** - 直接使用当前版本
|
|
|
|
|
|
|
|
|
|
|
|
请问您希望如何进行?
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
**用户交互循环逻辑**:
|
|
|
|
|
|
- 如果用户选择修改文档或提出修改建议:执行修改,完成后再次询问
|
|
|
|
|
|
- 如果用户回复包含"评估"、"评审"等词汇:确认用户意图后进入阶段6
|
|
|
|
|
|
- 如果用户回复"结束"、"不需要"、"跳过"等:输出最终总结并结束流程
|
|
|
|
|
|
|
|
|
|
|
|
**重要**:只有当用户明确表达进入评估的意愿时,才进入阶段6。
|
|
|
|
|
|
|
|
|
|
|
|
### 阶段 6:多角色评审与文档优化
|
|
|
|
|
|
|
|
|
|
|
|
当用户确认进入多角色评估阶段后:
|
|
|
|
|
|
|
|
|
|
|
|
**详细执行指南**: 读取 `references/phase6_review_guide.md` (包含领域专家角色定义、调用格式)
|
|
|
|
|
|
|
|
|
|
|
|
**执行步骤**:
|
|
|
|
|
|
|
|
|
|
|
|
1. **领域识别与生成领域专家角色定义**:
|
|
|
|
|
|
- 使用 Read 工具读取 requirement.md
|
|
|
|
|
|
- 分析项目领域特征(医疗/金融/教育/电商/科研等)
|
|
|
|
|
|
- 生成领域专家角色定义(角色名称、领域、专业能力、评审重点、合规标准)
|
|
|
|
|
|
- **使用 Write 工具将角色定义保存到 `temp/domain_role.md`**
|
2026-01-09 11:22:42 +08:00
|
|
|
|
- 领域专家生成原则:使用纯粹的业务领域名称(如"精神科医生"、"投资顾问"),代表该行业的一线从业者视角
|
2025-12-11 14:19:36 +08:00
|
|
|
|
|
|
|
|
|
|
2. **并行调用四个评审agents**: 使用 Task 工具在同一消息中发起四个调用
|
|
|
|
|
|
- dev_expert_reviewer(开发专家,`D:\AA_Work\AIEC-团队开发规范Skills\.claude\agents\dev_expert_reviewer.md`)
|
|
|
|
|
|
- pm_reviewer(产品经理,`D:\AA_Work\AIEC-团队开发规范Skills\.claude\agents\pm_reviewer.md`)
|
|
|
|
|
|
- ai_expert_reviewer(AI专家,`D:\AA_Work\AIEC-团队开发规范Skills\.claude\agents\ai_expert_reviewer.md`)
|
|
|
|
|
|
- domain_expert_reviewer(领域专家,`D:\AA_Work\AIEC-团队开发规范Skills\.claude\agents\domain_expert_reviewer.md`,会自动从 `temp/domain_role.md` 读取角色定义)
|
|
|
|
|
|
|
|
|
|
|
|
接收四个agents返回的评审概要(详细结果已保存到 temp/review_*.json)。
|
|
|
|
|
|
|
2026-01-09 11:22:42 +08:00
|
|
|
|
3. **询问用户决策模式**: 使用 AskUserQuestion 询问用户如何处理评审建议
|
2025-12-11 14:19:36 +08:00
|
|
|
|
```
|
|
|
|
|
|
question: "专家评审完成,如何处理评审建议?"
|
|
|
|
|
|
header: "决策模式"
|
|
|
|
|
|
multiSelect: false
|
|
|
|
|
|
options:
|
|
|
|
|
|
- label: "自动应用建议"
|
|
|
|
|
|
description: "系统自动评估并应用合理的评审建议"
|
2026-01-09 11:22:42 +08:00
|
|
|
|
- label: "我要参与确认"
|
|
|
|
|
|
description: "逐项与我确认评审建议,由我决定是否采纳"
|
2025-12-11 14:19:36 +08:00
|
|
|
|
```
|
|
|
|
|
|
|
2026-01-09 11:22:42 +08:00
|
|
|
|
4. **整合评审意见并生成最终文档**: 根据用户选择调用不同的Agent
|
2025-12-11 14:19:36 +08:00
|
|
|
|
|
2026-01-09 11:22:42 +08:00
|
|
|
|
**重要约束**:整合时必须严格按照原始模板结构,不能添加模板之外的章节。
|
2025-12-11 14:19:36 +08:00
|
|
|
|
|
|
|
|
|
|
**用户选择"自动应用建议"**: 使用Task工具调用 req_auto_consolidator(`D:\AA_Work\AIEC-团队开发规范Skills\.claude\agents\req_auto_consolidator.md`)
|
|
|
|
|
|
- 自动评估并应用评审建议
|
|
|
|
|
|
- 生成 requirement_final.md 和 temp/consolidation_report.json
|
|
|
|
|
|
|
2026-01-09 11:22:42 +08:00
|
|
|
|
**用户选择"我要参与确认"**: 多轮调用 req_consolidator(`D:\AA_Work\AIEC-团队开发规范Skills\.claude\agents\req_consolidator.md`)
|
|
|
|
|
|
|
|
|
|
|
|
**调用流程**:
|
|
|
|
|
|
1. 首次调用(mode=init):返回待确认问题列表(JSON)
|
|
|
|
|
|
2. 主窗口解析问题,使用 AskUserQuestion 逐个询问用户
|
|
|
|
|
|
3. 收集用户答案后再次调用(mode=continue,传入 previous_answers)
|
|
|
|
|
|
4. 重复步骤2-3,直到返回 status="completed"
|
|
|
|
|
|
5. 生成 requirement_final.md
|
|
|
|
|
|
|
|
|
|
|
|
接收完成提示(status="completed"),requirement_final.md 已生成。
|
2025-12-11 14:19:36 +08:00
|
|
|
|
|
2026-01-09 11:22:42 +08:00
|
|
|
|
5. **质量审查**: 使用 Task 工具调用 review_report(`D:\AA_Work\AIEC-团队开发规范Skills\.claude\agents\review_report.md`)
|
2025-12-11 14:19:36 +08:00
|
|
|
|
- **检查文档结构是否符合模板**(是否有多余章节,如有则删除)
|
|
|
|
|
|
- 检查客观性与中立性(是否有评审标注、讨论性词汇)
|
|
|
|
|
|
- 检查逻辑严谨性(是否存在前后矛盾)
|
|
|
|
|
|
- 检查闭环性(功能描述是否完整)
|
|
|
|
|
|
- 检查业务问题完整性(是否还有"待确认"的业务问题)
|
2026-01-09 11:22:42 +08:00
|
|
|
|
- 可自动修复的问题直接修改文档
|
|
|
|
|
|
- 无法自动判断的严重问题返回给主窗口
|
2025-12-11 14:19:36 +08:00
|
|
|
|
|
|
|
|
|
|
接收 review_report 返回的审查报告。
|
|
|
|
|
|
|
2026-01-09 11:22:42 +08:00
|
|
|
|
**如果审查报告中有"待用户确认"的问题**:
|
|
|
|
|
|
- 主窗口使用 AskUserQuestion 向用户确认这些问题
|
|
|
|
|
|
- 根据用户回答,使用 Edit 工具修改 requirement_final.md
|
|
|
|
|
|
|
|
|
|
|
|
6. **输出最终总结**:
|
2025-12-11 14:19:36 +08:00
|
|
|
|
|
|
|
|
|
|
```markdown
|
|
|
|
|
|
🎉 多角色评审完成!
|
|
|
|
|
|
|
|
|
|
|
|
## 📁 输出文件
|
|
|
|
|
|
- **原始文档**: requirement.md(已保留,未修改)
|
|
|
|
|
|
- **最终文档**: requirement_final.md(纯粹的需求文档)
|
|
|
|
|
|
- **评审记录**: temp/consolidation_report.json(详细的评审应用过程,供回溯审查)
|
|
|
|
|
|
|
|
|
|
|
|
## 👥 评审参与角色
|
|
|
|
|
|
- ✅ 开发专家:技术可行性与架构审查
|
|
|
|
|
|
- ✅ 产品经理:业务目标与用户体验审查
|
|
|
|
|
|
- ✅ AI专家:智能化需求审查
|
|
|
|
|
|
- ✅ {领域}专家:领域合规性与专业审查
|
|
|
|
|
|
|
|
|
|
|
|
## 📌 说明
|
|
|
|
|
|
requirement_final.md 是纯粹的需求文档,不包含评审过程说明。
|
|
|
|
|
|
如需了解评审应用的详细过程,可查看 temp/consolidation_report.json 文件。
|
|
|
|
|
|
```
|