yanxulong/AIEC_Skills

Fork 0

Files

闫旭隆 202d1cb5ba 20260109

2026-01-09 11:22:42 +08:00

14 KiB

Raw Blame History

阶段 6：多角色评审流程指南

本指南详细说明多角色评审的完整流程和领域专家角色定义。

流程概览

6.1 领域识别与生成领域专家角色定义
  ↓
6.2 并行调用四个评审 Agents（独立评审）
  ↓
6.3 询问用户决策模式
  ↓
6.4 整合评审意见（根据用户选择调用不同Agent）
  ↓
6.5 调用 review_report 质量审查
  ↓
6.6 输出总结

6.1 领域识别与领域专家角色定义

主窗口直接分析requirement.md内容,识别项目领域特征并生成差异化的领域专家角色定义。

操作步骤

读取输入:
- 使用Read工具读取requirement.md完整内容
- 读取三个固定专家的角色定义(可选,用于确保差异化)
领域分析:
- 分析项目的业务背景、核心功能、数据类型、使用场景
- 识别项目涉及的行业领域和特征(如医疗、金融、教育、电商、科研等)
- 识别该领域可能的合规要求
- 识别领域特有的业务流程规范和风险点

生成差异化领域专家角色定义:

⚠️ 领域专家命名原则:

使用纯粹的业务领域名称，代表该行业的一线从业者/专业人士
专家应该是"使用这个系统的目标用户所在行业的资深从业者"视角

项目领域	✅ 好的命名	❌ 不好的命名
医疗精神疾病	精神科医生、精神疾病专家	医学信息学专家、医疗信息化专家
金融投资	投资顾问、基金经理	金融科技专家、金融信息化专家
法律合同	律师、法务专家	法律信息化专家
教育培训	教师、教育专家	教育信息化专家
电商零售	零售专家、品类运营专家	电商系统专家

必须确保差异化:

与开发专家区分: 不关注技术可行性，关注业务专业性和行业规范
与产品经理区分: 不关注用户体验，关注行业标准和专业流程
与AI专家区分: 不关注智能化设计，关注领域专业知识的准确性

聚焦领域特色:

站在该细分领域一线从业者的角度评审（如医学专家（精神疾病专家、内科专家）、律师（民法律师、刑法律师）、教师（数学教师、语文教师）等）
关注领域专业术语、行业标准、从业规范
评估需求是否符合该领域的实际工作流程和专业要求
识别需求中可能违反行业规范或专业常识的问题

领域专家角色定义结构

角色定义使用 Markdown 格式，必须使用 Write 工具保存到 temp/domain_role.md。

# 领域专家角色定义

## 角色名称
{领域}专家（如：精神科医生、民法律师等一线从业者角色）

## 角色身份
你是一位资深的{领域}从业者，拥有多年{领域}实践经验。你将从专业从业者的角度评审这个系统的需求文档，确保它符合{领域}的专业标准和实际工作需求。

## 领域背景
{基于requirement.md分析得出的领域特征，用该领域从业者熟悉的语言描述}

## 该领域的专业要求
- {该领域的行业标准和规范}
- {该领域的专业术语要求}
- {该领域的工作流程规范}
- {该领域的质量标准}

## 评审重点
- 需求是否符合{领域}的实际工作流程？
- 专业术语使用是否准确规范？
- 功能设计是否满足{领域}从业者的实际需求？
- 是否遗漏了{领域}工作中的关键环节？
- 输出内容是否符合{领域}的专业标准？

## 评审边界
- ✅ 关注：行业规范、专业术语、工作流程、领域专业知识
- ❌ 不关注：技术实现方案（开发专家负责）
- ❌ 不关注：界面交互体验（产品经理负责）
- ❌ 不关注：AI模型和算法设计（AI专家负责）

重要：主窗口生成角色定义后，必须使用 Write 工具写入 temp/domain_role.md，domain_expert_reviewer 会自动读取该文件。

输出识别结果

🔍 **领域识别结果**：{识别到的领域}
👤 **领域专家角色**：{具体的从业者角色名称，如"精神科医生"而非"医学信息学专家"}

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 询问用户决策模式

在整合评审意见前,询问用户是否要参与评审建议的确认过程。

使用AskUserQuestion询问

question: "专家评审完成,如何处理评审建议?"
header: "决策模式"
multiSelect: false
options:
  - label: "自动应用建议"
    description: "系统自动评估并应用合理的评审建议"
  - label: "我要参与确认"
    description: "逐项与我确认评审建议,由我决定是否采纳"

两种模式说明

模式1: 自动应用建议（默认推荐）

调用 req_auto_consolidator agent
系统自动评估评审建议
根据severity自动决定是否采纳
生成纯粹的需求文档（不含评审过程说明）
适用于大多数项目，追求效率

模式2: 我要参与确认

调用 req_consolidator agent
返回待确认建议给主窗口，由主窗口与用户交互
用户逐项确认评审建议
适用于关键项目，用户需要完全控制

6.4 整合评审意见并生成最终文档

根据用户在6.3的选择,调用不同的Agent。

Consolidator 读取文件：

temp/interview_result.json - 用户原始需求（合并决策的最高准则）
temp/review_*.json - 各专家评审意见（所有 issues/suggestions）

模式1: 自动应用建议 - 调用 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
返回简洁的完成提示给主窗口

模式2: 用户参与确认 - 多轮调用 req_consolidator

req_consolidator 采用多轮调用模式，通过主窗口中转实现用户交互。

首次调用（mode=init）

subagent_type: "req_consolidator"
description: "整合评审意见（初始化）"
prompt: |
  请整合四个评审结果并准备用户确认。

  **mode**: init

返回示例：

{
  "status": "need_confirmation",
  "round": 1,
  "questions": [
    {
      "id": "q1",
      "question": "关于XX功能，专家建议增加YY特性，是否采纳？",
      "header": "功能增强",
      "options": [
        {"label": "采纳", "description": "增加YY特性"},
        {"label": "不采纳", "description": "保持原设计"}
      ]
    }
  ]
}

主窗口处理

解析返回的 questions 数组
对每个问题使用 AskUserQuestion 询问用户
收集用户答案

后续调用（mode=continue）

subagent_type: "req_consolidator"
description: "整合评审意见（继续）"
prompt: |
  请继续处理评审建议。

  **mode**: continue
  **previous_answers**:
  {"q1": "采纳", "q2": "不采纳"}

如果还有问题：返回 status: "need_confirmation" + 下一轮问题
如果已完成：返回 status: "completed"，requirement_final.md 已生成

完整调用流程

主窗口                              req_consolidator
   |                                      |
   |------ mode=init ------------------->|
   |<----- questions (round 1) ----------|
   |                                      |
   |-- AskUserQuestion (用户回答) ------->|
   |                                      |
   |------ mode=continue + answers ----->|
   |<----- questions (round 2) ----------|
   |                                      |
   |-- AskUserQuestion (用户回答) ------->|
   |                                      |
   |------ mode=continue + answers ----->|
   |<----- status=completed -------------|
   |                                      |

说明：

req_consolidator 不使用AskUserQuestion，通过返回JSON与主窗口交互
主窗口负责解析问题并调用AskUserQuestion
通过 previous_answers 传递用户决策
循环直到返回 status: "completed"

等待返回

等待选中的agent返回完成提示，requirement_final.md已生成。

6.5 调用 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. 业务问题完整性（是否还有"待确认"的业务问题）

  **处理方式**：
  - 可自动修复的问题：直接修改文档
  - 无法自动判断的严重问题：返回给主窗口处理

说明:

review_report 会读取 requirement_final.md
首先检查文档结构是否符合模板，多余章节直接删除
本Agent不使用AskUserQuestion，无法自动判断的问题返回给主窗口
审查通过或修改完成后，返回审查报告

主窗口处理待确认问题

如果 review_report 返回的审查报告中包含"待用户确认"的问题：

主窗口使用 AskUserQuestion 向用户确认这些问题
根据用户回答，使用 Edit 工具修改 requirement_final.md

6.6 输出总结

操作步骤

整合 agent 完成后，向用户输出简洁总结。

输出模板

🎉 多角色评审完成！

## 📁 输出文件
- **原始文档**: requirement.md（已保留，未修改）
- **最终文档**: requirement_final.md（纯粹的需求文档）
- **评审记录**: temp/consolidation_report.json（详细的评审应用过程，供回溯审查）

## 👥 评审参与角色
- ✅ 开发专家：技术可行性与架构审查
- ✅ 产品经理：业务目标与用户体验审查
- ✅ AI专家：智能化需求审查
- ✅ {领域}专家：领域合规性与专业审查

## 📌 说明

requirement_final.md 是纯粹的需求文档，不包含评审过程说明。

如需了解评审应用的详细过程，可查看 temp/consolidation_report.json 文件。

变量说明

变量	说明	来源
`{领域}`	识别的领域名称	6.1 领域识别结果

注意事项

并行执行必须在同一消息中：不要分开发送四个 Task 调用
文件路径确认：requirement.md 和 requirement_final.md 都在项目根目录
不修改原文档：requirement.md 必须保持不变
领域专家角色定义：6.1步骤必须使用Write工具将角色定义写入 temp/domain_role.md，domain_expert_reviewer 会自动读取
⚠️ 模板结构约束：
- 整合阶段和审查阶段必须严格按照模板结构生成文档
- 不能添加模板之外的章节（如"用户反馈与迭代机制"、"竞品对比与差异化"等）
- 评审建议的内容必须归入模板定义的现有章节中
- review_report 必须检查并删除多余章节

流程结束

完成输出总结后，控制权交回给用户，流程结束。

14 KiB Raw Blame History Unescape Escape

阶段 6：多角色评审流程指南

流程概览

6.1 领域识别与领域专家角色定义

操作步骤

领域专家角色定义结构

输出识别结果

6.2 并行调用四个评审 Agents

重要提醒

调用示例

Prompt 构造说明

等待返回

6.3 询问用户决策模式

使用AskUserQuestion询问

两种模式说明

6.4 整合评审意见并生成最终文档

模式1: 自动应用建议 - 调用 req_auto_consolidator（默认推荐）

调用示例

模式2: 用户参与确认 - 多轮调用 req_consolidator

首次调用（mode=init）

主窗口处理

后续调用（mode=continue）

完整调用流程

等待返回

6.5 调用 review_report 质量审查

调用示例

主窗口处理待确认问题

6.6 输出总结

操作步骤

输出模板

变量说明

注意事项

流程结束

14 KiB

Raw Blame History