yanxulong/AIEC_Skills
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

需求文档skill回溯专家博弈之前

Browse Source
This commit is contained in:
闫旭隆
2025-12-11 14:19:36 +08:00
parent 5f329d7b4c
commit f4314c3ede
117 changed files with 28969 additions and 3325 deletions
Download Patch File Download Diff File Expand all files Collapse all files

311
.claude/skills/requirement-generator-v1/references/phase3_interview_guide.md Normal file
View File

@ -0,0 +1,311 @@
# 阶段 3：执行访谈并收集需求 - 详细指南
本指南详细说明访谈阶段的执行流程和规范。
## 步骤 1：读取配置文件
根据项目类型读取对应的配置文件：
- **配置路径**：`D:\AA_Work\AIEC-团队开发规范Skills\.claude\skills\requirement-generator-v1\assets\{project_type}.md`
- **特殊情况**：如项目类型为"未知"，使用开放式访谈
### 从配置文件提取
- 示例问题（YAML 格式）
- 访谈策略指南
- 信息完整性要求
- 选项设计规范
---
## 步骤 2：分析用户初始描述
评估用户初始输入的信息完整度，动态决定访谈起点。
### 信息完整度评估
根据用户在阶段1的描述，判断哪些信息已经明确：
- **已明确任务/功能** → 跳过"主要任务"问题
- **已说明使用场景** → 跳过或简化"使用场景"问题
- **已提到价值/目标** → 跳过"预期价值"问题
- **已描述复杂流程/多步骤** → 主动询问 Multi-Agent 需求
- **已提及外部系统** → 深入询问数据集成细节
- **已涉及性能/安全** → 追问具体指标
---
## 步骤 3：执行动态访谈
### 访谈原则
1. **动态调整**：基于用户初始描述动态选择问题，避免机械执行
2. **工具使用**：使用 AskUserQuestion 工具进行所有提问
3. **选项设计原则**：
- **互斥性**：单选问题的选项应完全互斥，避免重叠
- **维度统一**：同一问题的选项应属于同一维度（如都是"交互方式"或都是"数据来源"）
- **边界清晰**：选项描述明确，用户能清楚判断应选哪个
- **数量要求**：单选2-6个选项，多选4-10个选项
- **multiSelect判断**：如果用户合理地可能同时需要多个选项，使用多选
4. **系统功能**：系统自动添加"Type something"选项，在 question 文本中提示用户可使用
5. **语言风格**：使用业务语言，专注业务需求而非技术实现
### 交互澄清处理流程
#### 触发交互澄清的情况（满足任一即触发）
1. **用户回答包含问号**（最高优先级）：
- 中文问号"？"或英文问号"?"
- 示例："PubMed够用吗？"、"这个选项是什么意思?"
- **规则**：只要包含问号，必须进入交互澄清
2. **用户明确请求帮助**：
- 输入"需要帮助"、"不确定"、"不清楚"、"帮我选"等
3. **用户回答包含不明确的指代或描述**（必须澄清）：
- 使用不具体的指代词："那些常见的..."、"类似的..."、"这一类..."
- 提及存在但未明确的事物："还有一些..."、"以及其他..."、"相关的..."
- 使用泛化表述："所有..."、"一般的..."、"常用的..."
- 示例："还有那些常见的精神疾病领域的文献数据库" → 需要澄清具体是哪些
4. **用户回答包含其他模糊表述**：
- 反问或转移决策："你觉得呢"、"应该选什么"
- 明确的不确定表述："不太确定"、"可能是..."、"大概..."
- 无关或过于简短的回答："随便"、"都行"、"看着办"
5. **用户对问题未作任何选择**（留空）：
- 用户跳过问题，未选择任何预设选项，也未在"其他"中输入内容
- 需要确认是遗漏、不确定、还是认为问题不适用
- 示例：多选问题返回空数组，或单选问题无选择
- **规则**：必须进入交互澄清，询问用户原因
#### 处理流程
**第1步：切换到自由对话**
向用户输出：
```markdown
您在【{问题名称}】{选择了需要帮助 / 回答较为模糊}。
原问题的选项包括：
- {选项1}：{描述}
- {选项2}：{描述}
...
请说明您的疑问或需要讨论的内容。
```
**第2步：多轮自由讨论**
- 解答用户疑问
- 提供背景知识和建议
- 每轮回复末尾必须提示："请明确您的选择，或回复'继续'返回访谈"
**第3步：判断用户是否明确选择**
**情况A：用户明确了选择**
- 用户回复如"那我选择 PubMed + PsycINFO"、"明白了，我需要..."
- 记录用户的选择
- 用户回复"继续"后，直接进入下一个问题
**情况B：用户未明确选择**
- 用户只回复"继续"、"回到访谈"等
- 恢复到**当前问题**，重新提问
- 根据讨论上下文动态生成新的选项
**示例**：
```
讨论前：您需要访问哪些数据库？
选项：PubMed、学术搜索、专业文献库
讨论后了解到是精神疾病研究，重新生成：
问题：基于您的精神疾病研究需求，需要访问哪些数据库？
选项：PubMed（生物医学）、PsycINFO（心理学）、Cochrane Library（系统评价）、其他专业数据库
```
### 访谈方式
- **工具使用**：使用 AskUserQuestion 工具，每个问题独立可答
- **节奏控制**：每轮3-4个问题，避免疲劳
- **动态调整**：根据回答动态调整后续问题和选项深度以及详细程度
- **信息分类**：只记录业务需求，用户主动提及的技术约束记录到 user_constraints
- **回答检测**（重要）：**每次用户提交回答后，立即检查是否触发澄清条件**
- **优先检查问号**：回答中包含"？"或"?"则必须进入交互澄清
- **检查是否留空**：用户未选择任何选项且未输入内容，必须进入交互澄清
- 检查是否包含"需要帮助"、"不确定"等关键词
- 检查是否包含模糊指代或描述（见上文触发条件）
- 如触发任一条件，立即进入交互澄清流程，不继续后续问题
- 只有用户回答明确具体时，才继续下一轮问题
### 信息收集范围
访谈应尽可能收集以下信息：
**业务信息**：
- 项目背景和目标
- 核心功能列表
- 目标用户和使用场景
- 预期效果和价值
**功能信息**：
- 输入输出定义
- 需要访问的外部数据和系统
- 完整交互流程
- **分阶段交付计划（必须收集）**:
- **收集方式**:
- 使用 AskUserQuestion 工具
- 将之前收集的所有功能列为选项
- **必须询问**："以下功能中,哪些必须在MVP版本中实现?"(多选)
- **必须询问**："哪些功能可以在MVP中降级实现?"
- **必须询问**："哪些功能实现难度大或依赖其他功能?"
- **判断与确认**:
- 根据用户选择综合判断阶段划分
- 生成阶段建议后与用户确认
- 阶段数量灵活:通常2-4个阶段
**约束和标准**：
- 用户明确的技术约束
- 性能和安全要求（业务层面）
- 验收标准
---
## 步骤 4：信息完整性检查
确保收集以下核心信息后可结束访谈。
### 必需信息（缺一不可）
- ✅ 项目背景和目标
- ✅ 核心功能列表（至少3个）
- ✅ 典型使用场景（至少1个）
- ✅ 基本输入输出
- ✅ 验收标准（至少3条）
- ✅ **分阶段交付计划**（MVP功能、降级功能、难度依赖）
### 可选但建议收集
- Agent架构细节（如需Multi-Agent）
- 外部系统集成需求
- 完整交互流程
- 性能和安全要求
**判断标准**：
- 如果必需信息全部收集完整，可以结束访谈
- 如果关键信息缺失，继续提问补充
- 如果用户表示"暂时没有更多信息"，可以结束访谈
---
## 步骤 5：保存访谈结果
生成结构化 JSON 并保存到 `temp/interview_result.json`。
### JSON 格式
```json
{
"project_info": {
"type": "项目类型"
},
"requirements": {
"background": "项目背景和目标",
"objectives": "预期效果和价值",
"target_users": "目标用户描述",
"core_features": ["功能1", "功能2"],
"use_cases": [
{
"scenario": "场景描述",
"trigger": "触发方式",
"steps": ["步骤1", "步骤2"],
"expected_result": "预期结果"
}
],
"input_output": {
"input": "输入信息",
"output": "输出结果"
},
"data_access": ["数据源或系统"],
"business_constraints": ["业务约束"],
"non_functional": {
"performance": "性能要求",
"security": "安全要求",
"scale": "使用规模"
},
"acceptance_criteria": ["标准1", "标准2"]
},
"delivery_plan": {
"phases": [
{
"phase_number": 1,
"goal": "阶段目标描述",
"features": ["功能1", "功能2"]
},
{
"phase_number": 2,
"goal": "阶段目标描述",
"features": ["功能3", "功能4"]
}
],
"phase_rationale": "阶段划分理由"
},
"user_constraints": {
"explicit_tech_constraints": ["用户明确提出的技术约束"]
},
"documentation": {
"recommended_template": "推荐模板路径"
}
}
```
### 保存操作
使用 Write 工具保存文件到 `temp/interview_result.json`。
**注意事项**：
- 确保 JSON 格式正确
- 所有必需字段都有值（即使为空字符串或空数组）
- user_constraints 只记录用户明确提出的技术约束
- recommended_template 根据项目类型填写对应的模板路径
---
## 访谈技巧和注意事项
### 提问技巧
1. **由浅入深**：从用户熟悉的业务问题入手，逐步深入细节
2. **具体化引导**：当用户回答笼统时，通过具体例子引导
3. **二次确认**：关键信息要通过不同角度的问题交叉验证
4. **示例激发**：通过类似项目的例子帮助用户思考
### 常见问题处理
**问题1：用户不知道如何回答**
- 提供2-3个具体例子
- 说明为什么需要这个信息
- 允许用户选择"暂时不确定"
**问题2：用户描述过于技术化**
- 引导回到业务价值："这个技术能解决什么业务问题？"
- 询问用户体验："用户会如何使用？"
- 关注目标："希望达到什么效果？"
**问题3：用户需求矛盾**
- 当场指出矛盾点
- 请用户澄清优先级
- 记录为待确认问题
### 质量控制
- ✅ 每个问题都有明确答案
- ✅ 避免引导性问题
- ✅ 确认关键术语的含义
- ✅ 记录用户的原话（特别是关键需求）
- ✅ 区分"必须有"和"最好有"
---
## 流程结束
完成保存访谈结果后，阶段3结束，进入阶段4生成需求文档。

580
.claude/skills/requirement-generator-v1/references/phase6_review_guide.md Normal file
View File

@ -0,0 +1,580 @@
# 阶段 6：多角色评审流程指南
本指南详细说明多角色评审的完整流程和领域专家角色定义。
## 流程概览
```
6.1 领域识别与生成领域专家角色定义
↓
6.2 并行调用四个评审 Agents（独立评审）
↓
6.3 博弈-评价阶段：交叉评价
↓
6.4 博弈-回应阶段：交叉回应
↓
6.5 询问用户决策模式
↓
6.6 整合评审意见（根据用户选择调用不同Agent）
↓
6.7 调用 review_report 质量审查
↓
6.8 输出总结
```
---
## 6.1 领域识别与领域专家角色定义
主窗口直接分析requirement.md内容,识别项目领域特征并生成差异化的领域专家角色定义。
### 操作步骤
1. **读取输入**:
- 使用Read工具读取requirement.md完整内容
- 读取三个固定专家的角色定义(可选,用于确保差异化)
2. **领域分析**:
- 分析项目的业务背景、核心功能、数据类型、使用场景
- 识别项目涉及的行业领域和特征(如医疗、金融、教育、电商、科研等)
- 识别该领域可能的合规要求
- 识别领域特有的业务流程规范和风险点
3. **生成差异化领域专家角色定义**:
**⚠️ 领域专家命名原则**:
- 使用**纯粹的业务领域名称**，代表该行业的一线从业者/专业人士
- 专家应该是"使用这个系统的目标用户所在行业的资深从业者"视角
| 项目领域 | ✅ 好的命名 | ❌ 不好的命名 |
|---------|------------|--------------|
| 医疗精神疾病 | 精神科医生、精神疾病专家 | 医学信息学专家、医疗信息化专家 |
| 金融投资 | 投资顾问、基金经理 | 金融科技专家、金融信息化专家 |
| 法律合同 | 律师、法务专家 | 法律信息化专家 |
| 教育培训 | 教师、教育专家 | 教育信息化专家 |
| 电商零售 | 零售专家、品类运营专家 | 电商系统专家 |
**必须确保差异化**:
- 与开发专家区分: 不关注技术可行性，关注**业务专业性和行业规范**
- 与产品经理区分: 不关注用户体验，关注**行业标准和专业流程**
- 与AI专家区分: 不关注智能化设计，关注**领域专业知识的准确性**
**聚焦领域特色**:
- 站在该细分领域一线从业者的角度评审（如医学专家（精神疾病专家、内科专家）、律师（民法律师、刑法律师）、教师（数学教师、语文教师）等）
- 关注领域专业术语、行业标准、从业规范
- 评估需求是否符合该领域的实际工作流程和专业要求
- 识别需求中可能违反行业规范或专业常识的问题
### 领域专家角色定义结构
角色定义使用 Markdown 格式，**必须使用 Write 工具保存到 `temp/domain_role.md`**。
```markdown
# 领域专家角色定义
## 角色名称
{领域}专家（如：精神科医生、民法律师等一线从业者角色）
## 角色身份
你是一位资深的{领域}从业者，拥有多年{领域}实践经验。你将从专业从业者的角度评审这个系统的需求文档，确保它符合{领域}的专业标准和实际工作需求。
## 领域背景
{基于requirement.md分析得出的领域特征，用该领域从业者熟悉的语言描述}
## 该领域的专业要求
- {该领域的行业标准和规范}
- {该领域的专业术语要求}
- {该领域的工作流程规范}
- {该领域的质量标准}
## 评审重点
- 需求是否符合{领域}的实际工作流程？
- 专业术语使用是否准确规范？
- 功能设计是否满足{领域}从业者的实际需求？
- 是否遗漏了{领域}工作中的关键环节？
- 输出内容是否符合{领域}的专业标准？
## 评审边界
- ✅ 关注：行业规范、专业术语、工作流程、领域专业知识
- ❌ 不关注：技术实现方案（开发专家负责）
- ❌ 不关注：界面交互体验（产品经理负责）
- ❌ 不关注：AI模型和算法设计（AI专家负责）
```
**重要**：主窗口生成角色定义后，必须使用 Write 工具写入 `temp/domain_role.md`，domain_expert_reviewer 会自动读取该文件。
### 输出识别结果
```markdown
🔍 **领域识别结果**：{识别到的领域}
👤 **领域专家角色**：{具体的从业者角色名称，如"精神科医生"而非"医学信息学专家"}
```
---
## 6.2 并行调用四个评审 Agents
### 重要提醒
**必须在同一个消息中发起四个 Task 调用**，以实现并行执行。
### 调用示例
```
# 在同一个消息中发起四个 Task 调用
# 调用1：开发专家
subagent_type: "dev_expert_reviewer"
description: "开发专家评审需求文档"
prompt: |
请评审项目根目录下的 requirement.md 文件。
# 调用2：产品经理
subagent_type: "pm_reviewer"
description: "产品经理评审需求文档"
prompt: |
请评审项目根目录下的 requirement.md 文件。
# 调用3：AI专家
subagent_type: "ai_expert_reviewer"
description: "AI专家评审需求文档"
prompt: |
请评审项目根目录下的 requirement.md 文件。
# 调用4：领域专家（自动读取 temp/domain_role.md）
subagent_type: "domain_expert_reviewer"
description: "{领域}专家评审需求文档"
prompt: |
请评审项目根目录下的 requirement.md 文件。
```
### Prompt 构造说明
**调用1、2、3、4（所有专家）**：
- prompt 固定简洁，只说明任务
- 评审逻辑已内置于各自的 agent 定义中
- **领域专家**会自动从 `temp/domain_role.md` 读取角色定义（6.1步骤已写入）
### 等待返回
等待所有四个 agents 返回评审概要。
**说明**：完整评审结果已保存到 temp/review_*.json，主窗口只接收概要信息。
---
## 6.3 博弈-评价阶段：交叉评价
### 流程说明
评审完成后，各专家阅读其他专家的评审意见并给出评价。每个专家会：
1. 首先加载用户原始需求（interview_result.json）作为评判基准
2. 回顾自己的评审立场（review_*.json）
3. 阅读其他3位专家的评审意见
4. 对有分歧的关键点给出评价
### 操作步骤
**在同一消息中并行调用四个专家**（传入 mode: evaluate）：
```
# 调用1：开发专家
subagent_type: "dev_expert_reviewer"
description: "开发专家交叉评价"
prompt: |
mode: evaluate
请阅读其他专家的评审意见，给出技术视角的评价。
# 调用2：产品经理
subagent_type: "pm_reviewer"
description: "产品经理交叉评价"
prompt: |
mode: evaluate
请阅读其他专家的评审意见，给出业务视角的评价。
# 调用3：AI专家
subagent_type: "ai_expert_reviewer"
description: "AI专家交叉评价"
prompt: |
mode: evaluate
请阅读其他专家的评审意见，给出智能化视角的评价。
# 调用4：领域专家
subagent_type: "domain_expert_reviewer"
description: "领域专家交叉评价"
prompt: |
mode: evaluate
请阅读其他专家的评审意见，给出领域专业视角的评价。
```
### 评价输出格式
每个专家输出 `evaluations` 数组，针对其他专家的具体条目给出评价：
```json
{
"evaluations": [
{
"target_expert": "产品经理",
"target_file": "temp/review_pm.json",
"target_item": {
"type": "issue",
"index": 0,
"brief": "对方观点摘要"
},
"stance": "disagree",
"comment": "我的评价",
"reasoning": "评价理由"
}
]
}
```
### stance 字段说明
| 值 | 含义 |
|------|------|
| `disagree` | 明确反对该观点，给出专业依据 |
| `partial` | 部分同意，指出同意和不同意的部分 |
**注意**：只评价有分歧的关键点，完全同意或无关的条目跳过不回应。
### 输出文件
- temp/evaluate_dev.json
- temp/evaluate_pm.json
- temp/evaluate_ai.json
- temp/evaluate_domain.json
---
## 6.4 博弈-回应阶段：交叉回应
### 流程说明
各专家阅读其他人对自己的评价，决定是否修正立场。每个专家会：
1. 首先加载用户原始需求（interview_result.json）作为决策基准
2. 回顾自己的原始评审（review_*.json）
3. 阅读其他专家对自己的评价（evaluate_*.json 中 target_expert 为自己的条目）
4. 基于用户需求判断是否需要修正自己的观点
### 操作步骤
**在同一消息中并行调用四个专家**（传入 mode: respond）：
```
# 调用1：开发专家
subagent_type: "dev_expert_reviewer"
description: "开发专家交叉回应"
prompt: |
mode: respond
请根据其他专家对你的评价，给出回应并确定最终立场。
# 调用2：产品经理
subagent_type: "pm_reviewer"
description: "产品经理交叉回应"
prompt: |
mode: respond
请根据其他专家对你的评价，给出回应并确定最终立场。
# 调用3：AI专家
subagent_type: "ai_expert_reviewer"
description: "AI专家交叉回应"
prompt: |
mode: respond
请根据其他专家对你的评价，给出回应并确定最终立场。
# 调用4：领域专家
subagent_type: "domain_expert_reviewer"
description: "领域专家交叉回应"
prompt: |
mode: respond
请根据其他专家对你的评价，给出回应并确定最终立场。
```
### 回应输出格式
每个专家输出 `responses_to_evaluations` 数组，明确记录对每条收到评价的回应：
```json
{
"expert_role": "开发专家",
"debate_round": 2,
"responses_to_evaluations": [
{
"from_expert": "产品经理",
"from_file": "temp/evaluate_pm.json",
"evaluation_index": 0,
"their_target": {
"my_file": "temp/review_dev.json",
"my_item_type": "issue",
"my_item_index": 0,
"my_item_content": "我的原条目内容（原文）"
},
"their_comment": "对方评价内容（原文）",
"my_decision": "accept",
"my_response": "我的回应说明",
"action": "modify",
"modification": "具体修改内容"
}
]
}
```
### 回应决策字段说明
| 字段 | 值 | 含义 |
|------|------|------|
| `my_decision` | `accept` | 完全接受，修正或撤回我的观点 |
| | `partial` | 部分接受，做有限修正 |
| | `reject` | 拒绝，坚持原观点 |
| `action` | `modify` | 修正该条目（采用 modification 内容） |
| | `withdraw` | 撤回该条目 |
| | `none` | 保持原条目不变 |
### 输出文件
- temp/response_dev.json
- temp/response_pm.json
- temp/response_ai.json
- temp/response_domain.json
### 输出博弈概要
博弈完成后，从 response_*.json 汇总统计，向用户输出概要：
```markdown
✅ 专家博弈完成
## 博弈统计
- 收到评价总数: {total_evaluations} 条
- 接受修改: {accept_count} 条
- 部分接受: {partial_count} 条
- 拒绝修改: {reject_count} 条
- 条目变更: 修改 {modify} / 撤回 {withdraw} / 保持 {none}
```
**统计来源**：从 `response_*.json` 的 `responses_to_evaluations[]` 汇总各 `my_decision` 和 `action` 字段。
---
## 6.5 询问用户决策模式
在整合评审意见前,询问用户是否要参与评审建议的确认过程。
### 使用AskUserQuestion询问
```
question: "专家评审完成,如何处理评审建议?"
header: "决策模式"
multiSelect: false
options:
- label: "我要参与确认"
description: "逐项与我确认评审建议,由我决定是否采纳"
- label: "自动应用建议"
description: "系统自动评估并应用合理的评审建议"
```
### 两种模式说明
**模式1: 我要参与确认**
- 调用 req_consolidator agent
- 使用AskUserQuestion与用户多轮交互
- 用户逐项确认评审建议
- 适用于关键项目,用户需要完全控制
**模式2: 自动应用建议**
- 调用 req_auto_consolidator agent
- 系统自动评估评审建议
- 根据severity自动决定是否采纳
- 生成纯粹的需求文档（不含评审过程说明）
- 适用于非关键项目,追求效率
---
## 6.6 整合评审意见并生成最终文档
根据用户在6.5的选择,调用不同的Agent。
**⚠️ Consolidator 读取博弈全过程文件**：
- `temp/interview_result.json` - 用户原始需求（合并决策的最高准则）
- `temp/review_*.json` - 各专家初始评审意见（所有 issues/suggestions）
- `temp/response_*.json` - 各专家交叉回应（包含 action: modify/withdraw/none）
- 根据 action 字段决定条目最终状态：撤回的不采纳，修改的采用新内容，保持的用原内容
### 模式1: 用户参与确认 - 调用 req_consolidator
#### 调用示例
```
subagent_type: "req_consolidator"
description: "整合评审意见并生成最终需求文档"
prompt: |
请整合四个评审结果并生成优化后的需求文档。
**评审结果文件**：
- temp/review_dev.json
- temp/review_pm.json
- temp/review_ai.json
- temp/review_domain.json
**模板约束**：
- 读取 temp/interview_result.json 中的 documentation.recommended_template 获取模板路径
- **严格按照模板结构生成文档，不能添加模板之外的章节**
- 评审建议的内容必须归入模板定义的现有章节中
- 如评审建议涉及新增章节（如"用户反馈机制"、"竞品对比"等），将内容整合到最相关的现有章节
**任务**：
1. 读取评审结果并汇总
2. 将评审建议转化为问题，使用AskUserQuestion工具与用户多轮确认
3. 根据用户确认生成 requirement_final.md（严格按照模板结构）
```
**说明**：
- req_consolidator会自动读取评审文件
- **会使用AskUserQuestion与用户交互确认评审建议**
- **必须严格按照模板结构生成文档，不添加额外章节**
- 只返回简洁的完成提示给主窗口
### 模式2: 自动应用建议 - 调用 req_auto_consolidator
#### 调用示例
```
subagent_type: "req_auto_consolidator"
description: "自动整合评审意见并生成最终需求文档"
prompt: |
请自动整合四个评审结果并生成优化后的需求文档。
**评审结果文件**：
- temp/review_dev.json
- temp/review_pm.json
- temp/review_ai.json
- temp/review_domain.json
**模板约束**：
- 读取 temp/interview_result.json 中的 documentation.recommended_template 获取模板路径
- **严格按照模板结构生成文档，不能添加模板之外的章节**
- 评审建议的内容必须归入模板定义的现有章节中
- 如评审建议涉及新增章节（如"用户反馈机制"、"竞品对比"等），将内容整合到最相关的现有章节
**任务**：
1. 读取评审结果并汇总
2. 自动评估评审建议的合理性和优先级
3. 自动应用合理的评审建议
4. 生成纯粹的需求文档 requirement_final.md（严格按照模板结构，不含评审过程说明）
5. 将评审应用记录保存到 temp/consolidation_report.json
```
**说明**：
- req_auto_consolidator会自动读取评审文件
- **不会与用户交互,完全自动化处理**
- **严格按照模板结构生成文档，不添加任何模板之外的章节**
- 将详细的评审应用过程记录到 temp/consolidation_report.json
- 返回简洁的完成提示给主窗口
### 等待返回
等待选中的agent返回完成提示，requirement_final.md已生成。
---
## 6.7 调用 review_report 质量审查
### 调用示例
```
subagent_type: "review_report"
description: "需求文档质量审查"
prompt: |
请对生成的需求文档进行质量审查。
**模板结构校验**（最高优先级）：
1. 读取 temp/interview_result.json 中的 documentation.recommended_template 获取模板路径
2. 检查 requirement_final.md 的章节结构是否与模板完全一致
3. 如发现多余章节（模板中没有的章节），直接删除这些章节
4. 删除时将有价值的内容迁移到最相关的模板章节中
**内容质量检查**：
1. 客观性与中立性（是否有评审标注、讨论性词汇）
2. 逻辑严谨性（是否存在前后矛盾）
3. 闭环性（功能描述是否完整）
4. 业务问题完整性（是否还有"待确认"的业务问题）
**处理方式**：
- 多余章节：直接删除，不询问用户
- 业务问题需确认：使用AskUserQuestion确认后修改
- 如果没有问题，输出通过提示
```
**说明**:
- review_report 会读取 requirement_final.md
- **首先检查文档结构是否符合模板，多余章节直接删除**
- 如发现待确认的业务问题，会使用AskUserQuestion与用户确认
- 如发现前后矛盾，会向用户询问如何处理
- 审查通过或修改完成后，返回审查报告
---
## 6.8 输出总结
### 操作步骤
整合 agent 完成后，向用户输出简洁总结。
### 输出模板
```markdown
🎉 多角色评审完成！
## 📁 输出文件
- **原始文档**: requirement.md（已保留，未修改）
- **最终文档**: requirement_final.md（纯粹的需求文档）
- **评审记录**: temp/consolidation_report.json（详细的评审应用过程，供回溯审查）
## 👥 评审参与角色
- ✅ 开发专家：技术可行性与架构审查
- ✅ 产品经理：业务目标与用户体验审查
- ✅ AI专家：智能化需求审查
- ✅ {领域}专家：领域合规性与专业审查
## 📌 说明
requirement_final.md 是纯粹的需求文档，不包含评审过程说明。
如需了解评审应用的详细过程，可查看 temp/consolidation_report.json 文件。
```
### 变量说明
| 变量 | 说明 | 来源 |
|------|------|------|
| `{领域}` | 识别的领域名称 | 6.1 领域识别结果 |
---
## 注意事项
1. **并行执行必须在同一消息中**：不要分开发送四个 Task 调用
2. **文件路径确认**：requirement.md 和 requirement_final.md 都在项目根目录
3. **不修改原文档**：requirement.md 必须保持不变
4. **领域专家角色定义**：6.1步骤必须使用Write工具将角色定义写入 `temp/domain_role.md`，domain_expert_reviewer 会自动读取
5. **⚠️ 模板结构约束**：
- 整合阶段和审查阶段必须严格按照模板结构生成文档
- 不能添加模板之外的章节（如"用户反馈与迭代机制"、"竞品对比与差异化"等）
- 评审建议的内容必须归入模板定义的现有章节中
- review_report 必须检查并删除多余章节
---
## 流程结束
完成输出总结后，**控制权交回给用户**，流程结束。