yanxulong/AIEC_Skills

Fork 0

Files

闫旭隆 f4314c3ede 需求文档skill回溯专家博弈之前

2025-12-11 14:19:36 +08:00

18 KiB

Raw Blame History

阶段 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内容,识别项目领域特征并生成差异化的领域专家角色定义。

操作步骤

读取输入:
- 使用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 博弈-评价阶段：交叉评价

流程说明

评审完成后，各专家阅读其他专家的评审意见并给出评价。每个专家会：

首先加载用户原始需求（interview_result.json）作为评判基准
回顾自己的评审立场（review_*.json）
阅读其他3位专家的评审意见
对有分歧的关键点给出评价

操作步骤

在同一消息中并行调用四个专家（传入 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 数组，针对其他专家的具体条目给出评价：

{
  "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 博弈-回应阶段：交叉回应

流程说明

各专家阅读其他人对自己的评价，决定是否修正立场。每个专家会：

首先加载用户原始需求（interview_result.json）作为决策基准
回顾自己的原始评审（review_*.json）
阅读其他专家对自己的评价（evaluate_*.json 中 target_expert 为自己的条目）
基于用户需求判断是否需要修正自己的观点

操作步骤

在同一消息中并行调用四个专家（传入 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 数组，明确记录对每条收到评价的回应：

{
  "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 汇总统计，向用户输出概要：

✅ 专家博弈完成

## 博弈统计
- 收到评价总数: {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 完成后，向用户输出简洁总结。

输出模板

🎉 多角色评审完成！

## 📁 输出文件
- **原始文档**: 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 必须检查并删除多余章节

流程结束

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

18 KiB Raw Blame History Unescape Escape

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

流程概览

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

操作步骤

领域专家角色定义结构

输出识别结果

6.2 并行调用四个评审 Agents

重要提醒

调用示例

Prompt 构造说明

等待返回

6.3 博弈-评价阶段：交叉评价

流程说明

操作步骤

评价输出格式

stance 字段说明

输出文件

6.4 博弈-回应阶段：交叉回应

流程说明

操作步骤

回应输出格式

回应决策字段说明

输出文件

输出博弈概要

6.5 询问用户决策模式

使用AskUserQuestion询问

两种模式说明

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

模式1: 用户参与确认 - 调用 req_consolidator

调用示例

模式2: 自动应用建议 - 调用 req_auto_consolidator

调用示例

等待返回

6.7 调用 review_report 质量审查

调用示例

6.8 输出总结

操作步骤

输出模板

变量说明

注意事项

流程结束

18 KiB

Raw Blame History