需求文档skill回溯专家博弈之前
This commit is contained in:
闫旭隆
282
.claude/skills/requirement-generator-v1/SKILL.md
Normal file
282
.claude/skills/requirement-generator-v1/SKILL.md
Normal file
@ -0,0 +1,282 @@
|
||||
---
|
||||
name: requirement-generator-v1
|
||||
description: 用于生成需求文档，当用户说"生成需求文档、撰写需求文档"等时触发。支持多种项目类型，通过业务访谈收集业务需求信息
|
||||
created_at: 2025-11-13
|
||||
updated_at: 2025-12-03
|
||||
version: v1
|
||||
author: 闫旭隆
|
||||
---
|
||||
|
||||
# 需求文档生成器
|
||||
|
||||
你是一个智能需求文档生成助手，能够：
|
||||
1. 识别不同类型的项目（Agent 开发、功能优化、测试等）
|
||||
2. 通过业务访谈收集需求信息
|
||||
3. 生成结构化的需求文档
|
||||
|
||||
## 资源配置
|
||||
|
||||
**Skill 基础目录**: `D:\AA_Work\AIEC-团队开发规范Skills\.claude\skills\requirement-generator-v1`
|
||||
|
||||
包含:
|
||||
- `assets/` - 项目类型配置
|
||||
- `templates/` - 文档模板
|
||||
- `references/` - 详细执行指南
|
||||
|
||||
## 前置准备
|
||||
|
||||
在开始执行流程前，使用 Bash 工具创建临时文件目录：
|
||||
|
||||
```bash
|
||||
mkdir -p temp
|
||||
```
|
||||
|
||||
**说明**：
|
||||
- `temp` 目录用于存储 agents 之间传递的中间数据文件
|
||||
- 如果目录已存在，mkdir -p 会忽略错误
|
||||
- 该目录将用于存储访谈结果 JSON 文件
|
||||
|
||||
## 执行流程
|
||||
|
||||
### 阶段 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`**
|
||||
- ⚠️ 领域专家生成原则：使用纯粹的业务领域名称（如"精神科医生"、"投资顾问"），代表该行业的一线从业者视角
|
||||
|
||||
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）。
|
||||
|
||||
3. **博弈-评价阶段：交叉评价**
|
||||
|
||||
使用Task工具并行调用四个专家（agents 路径同上），传入评价模式：
|
||||
```
|
||||
subagent_type: "dev_expert_reviewer"
|
||||
description: "开发专家交叉评价"
|
||||
prompt: |
|
||||
mode: evaluate
|
||||
|
||||
请阅读其他专家的评审意见，给出你基于开发专家视角的评价。
|
||||
|
||||
# 每个专家的 prompt 都需要包含 mode: evaluate
|
||||
```
|
||||
|
||||
接收四个agents返回的评价概要（结果已保存到 temp/evaluate_*.json）。
|
||||
|
||||
4. **博弈-回应阶段：交叉回应**
|
||||
|
||||
使用Task工具并行调用四个专家（agents 路径同上），传入回应模式：
|
||||
```
|
||||
subagent_type: "dev_expert_reviewer"
|
||||
description: "开发专家交叉回应"
|
||||
prompt: |
|
||||
mode: respond
|
||||
|
||||
请根据其他专家对你的评价，给出回应并确定最终立场。
|
||||
|
||||
# 每个专家的 prompt 都需要包含 mode: respond
|
||||
```
|
||||
|
||||
接收四个agents返回的回应概要（结果已保存到 temp/response_*.json）。
|
||||
|
||||
**输出博弈概要**（从 response_*.json 汇总统计）：
|
||||
```markdown
|
||||
✅ 专家博弈完成
|
||||
|
||||
## 博弈统计
|
||||
- 收到评价总数: {total_evaluations} 条
|
||||
- 接受修改: {accept_count} 条
|
||||
- 部分接受: {partial_count} 条
|
||||
- 拒绝修改: {reject_count} 条
|
||||
- 条目变更: 修改 {modify} / 撤回 {withdraw} / 保持 {none}
|
||||
```
|
||||
|
||||
5. **询问用户决策模式**: 使用 AskUserQuestion 询问用户如何处理评审建议
|
||||
```
|
||||
question: "专家评审完成,如何处理评审建议?"
|
||||
header: "决策模式"
|
||||
multiSelect: false
|
||||
options:
|
||||
- label: "我要参与确认"
|
||||
description: "逐项与我确认评审建议,由我决定是否采纳"
|
||||
- label: "自动应用建议"
|
||||
description: "系统自动评估并应用合理的评审建议"
|
||||
```
|
||||
|
||||
6. **整合评审意见并生成最终文档**: 根据用户选择调用不同的Agent
|
||||
|
||||
**⚠️ 重要约束**：整合时必须严格按照原始模板结构，不能添加模板之外的章节。
|
||||
|
||||
**用户选择"我要参与确认"**: 使用Task工具调用 req_consolidator（`D:\AA_Work\AIEC-团队开发规范Skills\.claude\agents\req_consolidator.md`）
|
||||
- 与用户多轮确认评审建议
|
||||
- 生成 requirement_final.md
|
||||
|
||||
**用户选择"自动应用建议"**: 使用Task工具调用 req_auto_consolidator（`D:\AA_Work\AIEC-团队开发规范Skills\.claude\agents\req_auto_consolidator.md`）
|
||||
- 自动评估并应用评审建议
|
||||
- 生成 requirement_final.md 和 temp/consolidation_report.json
|
||||
|
||||
接收完成提示，requirement_final.md 已生成。
|
||||
|
||||
7. **质量审查**: 使用 Task 工具调用 review_report（`D:\AA_Work\AIEC-团队开发规范Skills\.claude\agents\review_report.md`）
|
||||
- **检查文档结构是否符合模板**（是否有多余章节，如有则删除）
|
||||
- 检查客观性与中立性（是否有评审标注、讨论性词汇）
|
||||
- 检查逻辑严谨性（是否存在前后矛盾）
|
||||
- 检查闭环性（功能描述是否完整）
|
||||
- 检查业务问题完整性（是否还有"待确认"的业务问题）
|
||||
- 如发现问题（包括多余章节），直接修改文档；如有业务问题需确认，使用AskUserQuestion确认后修改
|
||||
|
||||
接收 review_report 返回的审查报告。
|
||||
|
||||
8. **输出最终总结**:
|
||||
|
||||
```markdown
|
||||
🎉 多角色评审完成！
|
||||
|
||||
## 📁 输出文件
|
||||
- **原始文档**: requirement.md（已保留，未修改）
|
||||
- **最终文档**: requirement_final.md（纯粹的需求文档）
|
||||
- **评审记录**: temp/consolidation_report.json（详细的评审应用过程，供回溯审查）
|
||||
|
||||
## 👥 评审参与角色
|
||||
- ✅ 开发专家：技术可行性与架构审查
|
||||
- ✅ 产品经理：业务目标与用户体验审查
|
||||
- ✅ AI专家：智能化需求审查
|
||||
- ✅ {领域}专家：领域合规性与专业审查
|
||||
|
||||
## 📌 说明
|
||||
requirement_final.md 是纯粹的需求文档，不包含评审过程说明。
|
||||
如需了解评审应用的详细过程，可查看 temp/consolidation_report.json 文件。
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
**流程结束**。
|
||||
393
.claude/skills/requirement-generator-v1/assets/agent_dev.md
Normal file
393
.claude/skills/requirement-generator-v1/assets/agent_dev.md
Normal file
@ -0,0 +1,393 @@
|
||||
---
|
||||
type: agent_dev
|
||||
keywords: [agent, skill, 自动化, 智能助手, 助手, langchain, langgraph, 机器人, bot, 对话, workflow, 工作流, multi-agent]
|
||||
priority: high
|
||||
---
|
||||
|
||||
# Agent 开发项目配置
|
||||
|
||||
本配置用于端到端的 Agent 开发项目，包括但不限于：
|
||||
- Claude Code Skill/Agent
|
||||
- LangChain Agent
|
||||
- LangGraph Workflow
|
||||
- Multi-Agent 系统
|
||||
- 其他 AI Agent 框架
|
||||
|
||||
## 模板路径
|
||||
templates/agent_dev_template.md
|
||||
|
||||
## 启动问题示例
|
||||
|
||||
以下问题仅作为参考，根据用户初始描述的详细程度和信息完整度动态选择和调整。
|
||||
|
||||
### 示例问题：主要任务
|
||||
|
||||
```yaml
|
||||
question: "这个智能助手主要帮助用户完成什么任务？（可多选，或在'其他'中详细描述；需要帮助请输入'需要帮助'）"
|
||||
options:
|
||||
- label: "信息查询和检索"
|
||||
description: "帮助用户查找、搜索、整理信息"
|
||||
- label: "数据处理和分析"
|
||||
description: "对数据进行清洗、转换、分析"
|
||||
- label: "自动化任务执行"
|
||||
description: "自动完成重复性工作或流程"
|
||||
- label: "辅助决策支持"
|
||||
description: "提供建议、分析、推荐"
|
||||
multiSelect: true
|
||||
```
|
||||
|
||||
**使用时机**：用户初始描述未明确说明具体任务时使用。如已明确，跳过此问题。
|
||||
|
||||
---
|
||||
|
||||
### 示例问题：预期价值
|
||||
|
||||
```yaml
|
||||
question: "预期带来什么价值？（可多选，或在'其他'中详细描述；需要帮助请输入'需要帮助'）"
|
||||
options:
|
||||
- label: "提高效率"
|
||||
description: "节省时间，加快处理速度"
|
||||
- label: "降低成本"
|
||||
description: "减少人力投入，降低运营成本"
|
||||
- label: "提升质量"
|
||||
description: "提高准确性，减少错误"
|
||||
- label: "增强用户体验"
|
||||
description: "简化操作，提升满意度"
|
||||
multiSelect: true
|
||||
```
|
||||
|
||||
**使用时机**：用户初始描述未说明价值或目标时使用。可与其他问题合并。
|
||||
|
||||
---
|
||||
|
||||
### 示例问题：使用场景
|
||||
|
||||
```yaml
|
||||
question: "用户在什么情况下会需要使用这个助手？（可多选，或在'其他'中描述具体场景；需要帮助请输入'需要帮助'）"
|
||||
options:
|
||||
- label: "定期自动执行"
|
||||
description: "按时间表自动运行，如每天早上、每周等"
|
||||
- label: "用户主动调用"
|
||||
description: "用户有需求时手动触发"
|
||||
- label: "事件触发"
|
||||
description: "特定事件发生时自动执行，如文件变化、消息到达等"
|
||||
multiSelect: true
|
||||
```
|
||||
|
||||
**使用时机**：了解基本任务后询问。根据回答深入询问具体触发条件、频率等细节。
|
||||
|
||||
---
|
||||
|
||||
### 示例问题：架构复杂度
|
||||
|
||||
```yaml
|
||||
question: "任务是否需要多个专门的助手配合完成？（或在'其他'中描述；需要帮助请输入'需要帮助'）"
|
||||
options:
|
||||
- label: "不需要，单个助手就能完成"
|
||||
description: "任务相对简单，流程单一"
|
||||
- label: "需要，任务复杂，需要多个助手协作"
|
||||
description: "需要将任务拆分给不同的专门助手"
|
||||
multiSelect: false
|
||||
```
|
||||
|
||||
**使用时机**：用户描述涉及多步骤、复杂流程时询问。如选择Multi-Agent，后续深入询问各Agent职能和协作方式。
|
||||
|
||||
---
|
||||
|
||||
## 访谈启动策略
|
||||
|
||||
### 分析用户初始描述
|
||||
|
||||
访谈前先分析用户初始输入的信息完整度：
|
||||
|
||||
**信息完整度检查**
|
||||
|
||||
识别用户初始描述中已包含的信息：
|
||||
|
||||
- ✓ 明确任务/功能 → 跳过"主要任务"问题
|
||||
- ✓ 说明使用场景 → 跳过或简化"使用场景"问题
|
||||
- ✓ 提到价值/目标 → 跳过"预期价值"问题
|
||||
- ✓ 描述复杂流程/多步骤 → 主动询问Multi-Agent需求
|
||||
- ✓ 提及外部系统 → 深入询问数据集成细节
|
||||
- ✓ 涉及性能/安全 → 追问具体指标
|
||||
|
||||
**动态起始点选择**
|
||||
|
||||
| 用户描述情况 | 起始策略 | 示例 |
|
||||
|------------|---------|------|
|
||||
| 详细完整 | 直接补充细节 | "如何定义'重要联系人'？" |
|
||||
| 基本清晰 | 从1-2个示例问题开始 | "使用场景"+"预期价值" |
|
||||
| 模糊简略 | 依次使用示例问题 | "主要任务"→"使用场景"→... |
|
||||
| 技术导向 | 引导到业务需求 | "这个功能主要帮用户解决什么问题？" |
|
||||
|
||||
### 启动原则
|
||||
|
||||
1. **先分析，后提问**
|
||||
- 仔细阅读用户初始描述
|
||||
- 识别已有信息和缺失信息
|
||||
- 避免询问已明确的内容
|
||||
|
||||
2. **避免机械执行**
|
||||
- 示例问题不是固定流程
|
||||
- 根据实际情况选择和调整
|
||||
- 灵活组合或跳过问题
|
||||
|
||||
3. **动态调整深度**
|
||||
- 用户回答内容丰富 → 快速推进
|
||||
- 用户回答简短模糊 → 追问细节
|
||||
- 用户不确定 → 提供更多选项或示例
|
||||
|
||||
4. **保持对话自然**
|
||||
- 基于上一轮回答提出下一个问题
|
||||
- 合并相关信息的询问
|
||||
- 避免突兀的话题跳转
|
||||
|
||||
## 访谈策略指南
|
||||
|
||||
### 访谈目标
|
||||
|
||||
收集完整的业务需求信息，用于生成结构化需求文档。
|
||||
|
||||
### 访谈方式
|
||||
|
||||
- 使用 AskUserQuestion 工具进行所有提问
|
||||
- 每个问题独立、可单独回答
|
||||
- 提供2-4个常见选项
|
||||
- 在question中明确提示"可在'其他'中详细描述"或类似说明
|
||||
- 系统自动添加"其他"选项
|
||||
- 使用业务语言，避免技术术语
|
||||
|
||||
### 信息收集范围
|
||||
|
||||
**基础信息**：
|
||||
- 项目背景和目标
|
||||
- 核心功能列表
|
||||
- 目标用户和使用场景
|
||||
- 使用入口和触发方式
|
||||
|
||||
**架构信息**（如需Multi-Agent）：
|
||||
- Agent角色划分和职能
|
||||
- Agent能力边界
|
||||
- Agent间协作关系和数据传递
|
||||
|
||||
**功能细节**：
|
||||
- 输入输出定义
|
||||
- 需要访问的外部数据和系统
|
||||
- 完整的交互流程
|
||||
- 异常和分支处理
|
||||
|
||||
**交付规划**：
|
||||
- MVP核心功能
|
||||
- 后续优化和高级功能
|
||||
- 分阶段目标
|
||||
|
||||
**非功能需求**：
|
||||
- 用户明确的技术约束
|
||||
- 性能要求（用户数、响应时间等业务指标）
|
||||
- 安全和隐私要求（业务层面）
|
||||
- 其他特殊需求
|
||||
|
||||
**验收标准**：
|
||||
- 功能验收条件
|
||||
- 非功能验收条件
|
||||
|
||||
### 动态访谈原则
|
||||
|
||||
1. **基于回答识别缺口**
|
||||
- 分析每轮回答获得的信息
|
||||
- 识别仍缺失的领域
|
||||
- 确定后续提问方向
|
||||
|
||||
2. **适应项目复杂度**
|
||||
- 简单项目：快速收集核心信息即可
|
||||
- 复杂项目：深入询问架构、流程、分阶段等
|
||||
- Multi-Agent项目：详细了解各Agent职能和协作
|
||||
|
||||
3. **聚焦关键特征**
|
||||
- 如涉及高性能：追问具体性能指标
|
||||
- 如涉及高安全：追问敏感数据处理
|
||||
- 如需集成外部系统：追问数据流转细节
|
||||
- 如涉及复杂流程：询问异常和分支处理
|
||||
|
||||
4. **避免重复和冗余**
|
||||
- 不重复提问已获取的信息
|
||||
- 合并相关信息的提问
|
||||
- 综合考虑用户回答的详细程度
|
||||
|
||||
5. **灵活调整问题深度**
|
||||
- 用户回答简短模糊：追问细节
|
||||
- 用户回答内容丰富：快速推进其他信息
|
||||
- 用户不确定：提供更具体的选项或示例
|
||||
|
||||
### 完整性检查
|
||||
|
||||
每轮访谈后评估已收集信息的完整性，当以下核心信息都已获取时，可结束访谈：
|
||||
|
||||
**必需信息**：
|
||||
- 项目背景和目标
|
||||
- 核心功能列表（至少3个）
|
||||
- 典型使用场景（至少1个）
|
||||
- 基本输入输出
|
||||
- 验收标准（至少3条）
|
||||
- **分阶段交付计划**（MVP功能、降级功能、难度依赖）
|
||||
|
||||
**可选但建议收集**：
|
||||
- Agent架构细节（如需Multi-Agent）
|
||||
- 外部系统集成需求
|
||||
- 完整交互流程
|
||||
- 性能和安全要求
|
||||
|
||||
### 问题生成规范
|
||||
|
||||
**语言风格**：
|
||||
- 使用业务语言
|
||||
- 问题清晰具体
|
||||
- 避免技术术语
|
||||
|
||||
**question文本**：
|
||||
- 在问题中明确提示用户可以使用"其他"选项
|
||||
- 示例："（可多选，或在'其他'中详细描述）"
|
||||
- 示例："（或在'其他'中说明您的具体情况）"
|
||||
|
||||
**选项设计**：
|
||||
- 尽可能从不同角度覆盖，边界明晰简洁，10个以内
|
||||
- 选项描述简洁明确
|
||||
- 覆盖主要情况，不穷尽所有可能
|
||||
|
||||
**选项设计规范**：
|
||||
|
||||
#### 互斥性原则
|
||||
|
||||
**单选问题**（multiSelect: false）：
|
||||
- ✅ 选项应完全互斥，无重叠
|
||||
- ✅ 边界清晰，用户能明确判断属于哪一个
|
||||
- ❌ 避免数量范围重叠（如"1-10人"和"5-20人"）
|
||||
- ❌ 避免概念包含关系（如"Web界面"和"移动端界面"同时出现在"访问方式"问题中）
|
||||
|
||||
**多选问题**（multiSelect: true）：
|
||||
- ✅ 选项可从不同角度切分，允许合理组合
|
||||
- ✅ 每个选项应代表独立的需求维度
|
||||
- ❌ 避免选项之间有逻辑依赖（如"数据收集"和"基于收集的数据分析"）
|
||||
|
||||
#### 维度统一原则
|
||||
|
||||
**同一问题的所有选项应属于同一分类维度**
|
||||
|
||||
❌ **错误示例**（维度混乱）：
|
||||
```yaml
|
||||
question: "用户如何使用这个工具?"
|
||||
options:
|
||||
- 输入问题主动调用 # 维度：触发方式
|
||||
- 命令行/编程接口 # 维度：交互界面
|
||||
- Web界面 # 维度：交互界面
|
||||
multiSelect: false
|
||||
```
|
||||
问题：第1个选项是"触发方式"，第2、3个是"交互界面"，维度不统一
|
||||
|
||||
✅ **正确示例**（维度统一）：
|
||||
```yaml
|
||||
question: "用户通过什么方式访问工具?"
|
||||
options:
|
||||
- 命令行接口
|
||||
- Web界面
|
||||
- 桌面应用
|
||||
multiSelect: false
|
||||
```
|
||||
|
||||
或者拆分为两个问题：
|
||||
```yaml
|
||||
question: "工具的触发方式?"
|
||||
options:
|
||||
- 用户主动输入问题调用
|
||||
- 定时自动执行
|
||||
- 事件触发（如文献更新）
|
||||
multiSelect: true
|
||||
---
|
||||
question: "工具的交互界面?"
|
||||
options:
|
||||
- 命令行/API接口
|
||||
- Web浏览器界面
|
||||
- 桌面客户端
|
||||
multiSelect: false
|
||||
```
|
||||
|
||||
#### 边界清晰原则
|
||||
|
||||
**数量范围选项**：
|
||||
```yaml
|
||||
# ❌ 边界重叠
|
||||
- 1-10人
|
||||
- 5-20人
|
||||
|
||||
# ✅ 边界清晰
|
||||
- 个人使用（1-5人）
|
||||
- 小团队（6-50人）
|
||||
- 中大型（50人以上）
|
||||
```
|
||||
|
||||
**概念分类选项**：
|
||||
```yaml
|
||||
# ❌ 包含关系
|
||||
- 医疗数据
|
||||
- 患者健康记录 # 属于医疗数据的子集
|
||||
|
||||
# ✅ 平级分类
|
||||
- 患者健康记录
|
||||
- 医学影像数据
|
||||
- 临床试验数据
|
||||
```
|
||||
|
||||
#### 完备性检查
|
||||
|
||||
- 2-4个选项应覆盖**80%的常见场景**
|
||||
- 如果某个场景>10%用户可能选择，应作为预设选项
|
||||
- 剩余<20%的长尾场景通过"其他"覆盖
|
||||
- 当不确定时，优先设计偏通用的选项+依赖"其他"
|
||||
|
||||
**multiSelect设置**：
|
||||
- 核心功能、使用场景、数据访问、触发方式、预期价值 → true
|
||||
- 规模量级、架构复杂度、二选一决策 → false
|
||||
|
||||
**上下文关联**：
|
||||
- 基于之前的回答调整问题
|
||||
- 识别项目特点后深入相关领域
|
||||
- 根据项目复杂度调整问题数量
|
||||
|
||||
### 访谈示例场景
|
||||
|
||||
**场景1：详细完整的描述**
|
||||
|
||||
用户输入：
|
||||
```
|
||||
我想做一个邮件助手，每天早上7点自动扫描我的工作邮箱，
|
||||
提取来自重要联系人的邮件，总结关键内容，生成一份摘要报告
|
||||
发送到企业微信。主要是为了节省每天30分钟的邮件筛选时间。
|
||||
```
|
||||
|
||||
应对策略：
|
||||
- 已包含：任务（邮件整理）、场景（每天早上7点）、价值（节省30分钟）、触发方式（定时）
|
||||
- 缺失：重要联系人定义、摘要格式、异常处理、输入输出细节
|
||||
- 起始问题："如何判断'重要联系人'？是基于发件人列表，还是其他规则？"
|
||||
|
||||
**场景2：基本清晰的描述**
|
||||
|
||||
用户输入：
|
||||
```
|
||||
我想开发一个智能客服助手，帮助回答用户常见问题。
|
||||
```
|
||||
|
||||
应对策略：
|
||||
- 已包含：任务类型（辅助决策/信息查询）
|
||||
- 缺失：使用场景、触发方式、价值、数据来源
|
||||
- 起始问题：从示例问题"使用场景"开始，然后询问知识来源
|
||||
|
||||
**场景3：模糊简略的描述**
|
||||
|
||||
用户输入：
|
||||
```
|
||||
想做一个自动化工具。
|
||||
```
|
||||
|
||||
应对策略：
|
||||
- 信息极少
|
||||
- 从示例问题"主要任务"开始，依次引导
|
||||
291
.claude/skills/requirement-generator-v1/assets/feature_update.md
Normal file
291
.claude/skills/requirement-generator-v1/assets/feature_update.md
Normal file
@ -0,0 +1,291 @@
|
||||
---
|
||||
type: feature_update
|
||||
keywords: [优化, 改进, 迭代, 更新, bug, 修复, 重构, 升级, 增强, enhance, improve, refactor]
|
||||
priority: high
|
||||
---
|
||||
|
||||
# 功能优化/更新项目配置
|
||||
|
||||
本配置用于已有项目的功能优化、更新迭代、bug 修复等场景。
|
||||
|
||||
## 模板路径
|
||||
templates/feature_update_template.md
|
||||
|
||||
## 核心问题配置
|
||||
|
||||
### 问题 1：当前问题识别
|
||||
|
||||
```yaml
|
||||
question: "请描述当前功能存在什么问题或不足？"
|
||||
type: "text"
|
||||
prompt: |
|
||||
比如：
|
||||
- 功能不完善，缺少某些能力
|
||||
- 性能不好，速度慢
|
||||
- 用户体验差，操作复杂
|
||||
- 经常出错
|
||||
- 维护困难
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 问题 2：优化目标
|
||||
|
||||
```yaml
|
||||
question: "优化后，您希望达到什么效果？"
|
||||
type: "text"
|
||||
prompt: |
|
||||
请尽可能具体地描述，比如：
|
||||
- "查询速度从 3 秒缩短到 1 秒以内"
|
||||
- "增加批量导入功能"
|
||||
- "优化操作流程，减少点击次数"
|
||||
- "降低出错率"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 问题 3：影响范围
|
||||
|
||||
```yaml
|
||||
question: "这次优化会影响哪些功能或用户？（或在'其他'中描述；需要帮助请输入'需要帮助'）"
|
||||
options:
|
||||
- label: "只影响这一个功能"
|
||||
description: "局部优化，不影响其他功能"
|
||||
- label: "会影响相关的几个功能"
|
||||
description: "需要同步调整其他功能"
|
||||
- label: "会影响整个系统"
|
||||
description: "架构或核心功能的调整"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 问题 4：兼容性要求
|
||||
|
||||
```yaml
|
||||
question: "优化后，原有的功能和数据是否需要保持兼容？（或在'其他'中描述；需要帮助请输入'需要帮助'）"
|
||||
options:
|
||||
- label: "必须完全兼容，不能影响现有用户"
|
||||
description: "向后兼容，不需要数据迁移"
|
||||
- label: "可以有小的调整，但要保证数据不丢失"
|
||||
description: "需要数据迁移，但应该简单"
|
||||
- label: "可以重新设计，旧数据可以手动迁移"
|
||||
description: "不保证兼容，手动或复杂迁移"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 问题 5：性能指标（如涉及性能优化）
|
||||
|
||||
```yaml
|
||||
question: "如果涉及性能优化，请描述当前速度和期望速度。"
|
||||
type: "text"
|
||||
prompt: |
|
||||
比如：
|
||||
- "现在加载需要 10 秒，希望 2 秒以内"
|
||||
- "现在只能处理 100 条数据，希望能处理 10000 条"
|
||||
- "高峰期经常卡顿，希望流畅运行"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 问题 6：测试与验收
|
||||
|
||||
```yaml
|
||||
question: "如何验证优化是成功的？"
|
||||
type: "text"
|
||||
prompt: |
|
||||
请列出具体的验收标准，比如：
|
||||
- "查询 1000 条数据在 1 秒内返回"
|
||||
- "批量导入 10000 条数据无报错"
|
||||
- "用户操作减少到 3 步"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 通用映射规则
|
||||
|
||||
```yaml
|
||||
# 问题类型 → 优化重点
|
||||
issue_type_mapping:
|
||||
"速度慢|性能差|加载时间长":
|
||||
focus: "性能优化"
|
||||
metrics: "响应时间、吞吐量"
|
||||
approaches: ["缓存", "索引优化", "异步处理", "数据库优化"]
|
||||
|
||||
"功能不完善|缺少能力|用户需求":
|
||||
focus: "功能增强"
|
||||
metrics: "功能完整度、用户满意度"
|
||||
approaches: ["需求分析", "功能设计", "API 扩展"]
|
||||
|
||||
"操作复杂|体验差|难用":
|
||||
focus: "用户体验优化"
|
||||
metrics: "操作步骤、用户反馈"
|
||||
approaches: ["交互优化", "流程简化", "UI 改进"]
|
||||
|
||||
"经常出错|不稳定|bug":
|
||||
focus: "稳定性提升"
|
||||
metrics: "错误率、可用性"
|
||||
approaches: ["异常处理", "边界检查", "测试覆盖"]
|
||||
|
||||
"代码混乱|难维护":
|
||||
focus: "代码重构"
|
||||
metrics: "代码质量、可维护性"
|
||||
approaches: ["架构优化", "代码清理", "文档完善"]
|
||||
|
||||
# 影响范围 → 测试策略
|
||||
scope_mapping:
|
||||
"局部优化":
|
||||
testing: "单元测试 + 功能测试"
|
||||
risk: "low"
|
||||
rollout: "直接发布"
|
||||
|
||||
"中等范围":
|
||||
testing: "集成测试 + 回归测试"
|
||||
risk: "medium"
|
||||
rollout: "分阶段发布"
|
||||
|
||||
"大范围":
|
||||
testing: "全面测试 + 压力测试"
|
||||
risk: "high"
|
||||
rollout: "灰度发布 + 回滚预案"
|
||||
|
||||
# 兼容性要求 → 实现策略
|
||||
compatibility_mapping:
|
||||
"完全兼容":
|
||||
strategy: "增量优化"
|
||||
migration: "不需要"
|
||||
risk: "low"
|
||||
|
||||
"需要迁移":
|
||||
strategy: "版本升级 + 迁移脚本"
|
||||
migration: "自动迁移"
|
||||
risk: "medium"
|
||||
|
||||
"不保证兼容":
|
||||
strategy: "重新设计"
|
||||
migration: "手动迁移或弃用旧数据"
|
||||
risk: "high"
|
||||
```
|
||||
|
||||
## 文档结构建议
|
||||
|
||||
```markdown
|
||||
# {功能名称}优化 - 需求文档
|
||||
|
||||
## 1. 现状分析
|
||||
- 当前问题描述
|
||||
- 问题影响和严重程度
|
||||
- 问题根因（如已知）
|
||||
|
||||
## 2. 优化目标
|
||||
- 功能目标
|
||||
- 性能目标
|
||||
- 质量目标
|
||||
- 优先级
|
||||
|
||||
## 3. 优化方案概述
|
||||
- 主要优化方向
|
||||
- 技术方案（如已明确）
|
||||
- 预期效果
|
||||
|
||||
## 4. 功能变更
|
||||
- 新增功能
|
||||
- 修改功能
|
||||
- 废弃功能
|
||||
|
||||
## 5. 技术变更
|
||||
- 架构调整
|
||||
- 数据库变更
|
||||
- API 变更
|
||||
- 依赖更新
|
||||
|
||||
## 6. 兼容性与迁移
|
||||
- 向后兼容性
|
||||
- 数据迁移方案
|
||||
- 回滚策略
|
||||
|
||||
## 7. 影响范围
|
||||
- 受影响的模块
|
||||
- 受影响的用户
|
||||
- 风险评估
|
||||
|
||||
## 8. 测试策略
|
||||
- 测试范围
|
||||
- 测试用例
|
||||
- 性能测试（如需要）
|
||||
|
||||
## 9. 发布计划
|
||||
- 发布方式（灰度/全量）
|
||||
- 发布步骤
|
||||
- 监控指标
|
||||
|
||||
## 10. 验收标准
|
||||
- 功能验收
|
||||
- 性能验收
|
||||
- 稳定性验收
|
||||
```
|
||||
|
||||
## 特殊场景处理
|
||||
|
||||
### 性能优化项目
|
||||
额外关注：
|
||||
- 性能基线测试
|
||||
- 瓶颈分析
|
||||
- 优化前后对比
|
||||
- 性能监控方案
|
||||
|
||||
### 架构重构项目
|
||||
额外关注：
|
||||
- 架构演进路径
|
||||
- 服务拆分/合并
|
||||
- 技术债务清理
|
||||
- 团队能力评估
|
||||
|
||||
### 紧急 Bug 修复
|
||||
额外关注：
|
||||
- 问题复现步骤
|
||||
- 临时解决方案
|
||||
- 根因分析
|
||||
- 防止复发措施
|
||||
|
||||
## 选项设计规范
|
||||
|
||||
### 互斥性原则
|
||||
|
||||
**单选问题**（multiSelect: false）：
|
||||
- ✅ 选项应完全互斥，无重叠
|
||||
- ✅ 边界清晰，用户能明确判断属于哪一个
|
||||
- ❌ 避免数量范围重叠（如"1-10人"和"5-20人"）
|
||||
- ❌ 避免概念包含关系
|
||||
|
||||
**多选问题**（multiSelect: true）：
|
||||
- ✅ 选项可从不同角度切分，允许合理组合
|
||||
- ✅ 每个选项应代表独立的需求维度
|
||||
- ❌ 避免选项之间有逻辑依赖
|
||||
|
||||
### 维度统一原则
|
||||
|
||||
同一问题的所有选项应属于同一分类维度。
|
||||
|
||||
❌ **错误示例**（维度混乱）：
|
||||
```yaml
|
||||
question: "用户如何使用这个工具?"
|
||||
options:
|
||||
- 输入问题主动调用 # 维度：触发方式
|
||||
- 命令行/编程接口 # 维度：交互界面
|
||||
- Web界面 # 维度：交互界面
|
||||
multiSelect: false
|
||||
```
|
||||
|
||||
✅ **正确做法**：拆分为两个问题，或统一到同一维度
|
||||
|
||||
### 边界清晰原则
|
||||
|
||||
**数量范围**：避免重叠，如"个人使用（1-5人）"、"小团队（6-50人）"
|
||||
**概念分类**：确保平级，避免包含关系
|
||||
|
||||
### 完备性检查
|
||||
|
||||
- 2-4个选项应覆盖**80%的常见场景**
|
||||
- 长尾场景通过"其他"覆盖
|
||||
- 当不确定时，优先设计偏通用的选项+依赖"其他"
|
||||
325
.claude/skills/requirement-generator-v1/assets/testing.md
Normal file
325
.claude/skills/requirement-generator-v1/assets/testing.md
Normal file
@ -0,0 +1,325 @@
|
||||
---
|
||||
type: testing
|
||||
keywords: [测试, 验证, 检验, test, 质量保证, qa, 单元测试, 集成测试, 性能测试, 自动化测试]
|
||||
priority: medium
|
||||
---
|
||||
|
||||
# 测试项目配置
|
||||
|
||||
本配置用于各类测试项目，包括功能测试、性能测试、安全测试等。
|
||||
|
||||
## 模板路径
|
||||
templates/testing_template.md
|
||||
|
||||
## 核心问题配置
|
||||
|
||||
### 问题 1：测试对象
|
||||
|
||||
```yaml
|
||||
question: "需要测试哪个功能或系统？"
|
||||
type: "text"
|
||||
prompt: "请描述测试对象，包括功能名称、版本等"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 问题 2：测试类型
|
||||
|
||||
```yaml
|
||||
question: "主要测试什么方面？（可多选，或在'其他'中详细描述；需要帮助请输入'需要帮助'）"
|
||||
options:
|
||||
- label: "功能是否正常工作"
|
||||
description: "验证功能符合预期"
|
||||
- label: "系统性能和速度"
|
||||
description: "检查响应时间、承载能力"
|
||||
- label: "安全性和数据保护"
|
||||
description: "检查是否有安全漏洞"
|
||||
- label: "多个功能协同工作"
|
||||
description: "验证各模块集成后的表现"
|
||||
multiSelect: true
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 问题 3：测试范围
|
||||
|
||||
```yaml
|
||||
question: "需要测试哪些具体场景？"
|
||||
type: "text"
|
||||
prompt: |
|
||||
请列出关键的测试场景，比如：
|
||||
- 用户登录
|
||||
- 创建订单
|
||||
- 查询历史记录
|
||||
- 边界情况（极端输入）
|
||||
- 异常情况（网络中断、数据错误等）
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 问题 4：测试数据
|
||||
|
||||
```yaml
|
||||
question: "测试时需要使用什么数据？（或在'其他'中描述；需要帮助请输入'需要帮助'）"
|
||||
options:
|
||||
- label: "使用真实数据"
|
||||
description: "从生产环境或实际业务获取"
|
||||
- label: "使用模拟数据"
|
||||
description: "自己构造测试数据"
|
||||
- label: "两者都需要"
|
||||
description: "生产数据 + 模拟数据"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 问题 5：测试方式
|
||||
|
||||
```yaml
|
||||
question: "测试是手动进行还是自动化？（或在'其他'中描述；需要帮助请输入'需要帮助'）"
|
||||
options:
|
||||
- label: "手动测试就够了"
|
||||
description: "人工操作和检查"
|
||||
- label: "希望自动化执行"
|
||||
description: "写脚本自动运行测试"
|
||||
- label: "部分自动化，部分手动"
|
||||
description: "混合模式"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 问题 6：性能指标（如涉及性能测试）
|
||||
|
||||
```yaml
|
||||
question: "如果测试性能，什么样的表现算合格？"
|
||||
type: "text"
|
||||
prompt: |
|
||||
比如：
|
||||
- "页面加载时间不超过 2 秒"
|
||||
- "支持 100 人同时使用不卡顿"
|
||||
- "处理 10000 条数据在 1 分钟内完成"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 问题 7：验收标准
|
||||
|
||||
```yaml
|
||||
question: "怎样才算测试通过？"
|
||||
type: "text"
|
||||
prompt: |
|
||||
请列出具体的通过标准，比如：
|
||||
- "所有核心功能无报错"
|
||||
- "性能指标达标"
|
||||
- "安全扫描无高危漏洞"
|
||||
- "覆盖率达到 80%"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 问题 8：测试环境
|
||||
|
||||
```yaml
|
||||
question: "在什么环境下进行测试？（或在'其他'中描述；需要帮助请输入'需要帮助'）"
|
||||
options:
|
||||
- label: "开发环境（自己电脑）"
|
||||
description: "本地开发环境"
|
||||
- label: "专门的测试环境"
|
||||
description: "独立测试环境"
|
||||
- label: "接近真实的生产环境"
|
||||
description: "预生产环境"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 通用映射规则
|
||||
|
||||
```yaml
|
||||
# 测试类型 → 测试策略
|
||||
test_type_mapping:
|
||||
"功能测试":
|
||||
approach: "测试用例设计"
|
||||
tools: ["手动测试", "Selenium", "Cypress", "Playwright"]
|
||||
metrics: ["功能覆盖率", "缺陷密度"]
|
||||
|
||||
"性能测试":
|
||||
approach: "压力测试 + 监控"
|
||||
tools: ["JMeter", "Locust", "k6"]
|
||||
metrics: ["响应时间", "吞吐量", "资源占用"]
|
||||
|
||||
"安全测试":
|
||||
approach: "漏洞扫描 + 渗透测试"
|
||||
tools: ["OWASP ZAP", "Burp Suite", "SonarQube"]
|
||||
metrics: ["漏洞数量", "安全评级"]
|
||||
|
||||
"集成测试":
|
||||
approach: "接口测试 + 数据验证"
|
||||
tools: ["Postman", "pytest", "Jest"]
|
||||
metrics: ["接口覆盖率", "数据一致性"]
|
||||
|
||||
# 自动化程度 → 实现方式
|
||||
automation_mapping:
|
||||
"手动测试":
|
||||
tools: "测试用例文档"
|
||||
efficiency: "low"
|
||||
cost: "人力成本高"
|
||||
|
||||
"自动化测试":
|
||||
tools: "测试框架 + CI/CD"
|
||||
efficiency: "high"
|
||||
cost: "初期投入高，长期收益大"
|
||||
|
||||
"混合模式":
|
||||
tools: "自动化框架 + 手动补充"
|
||||
efficiency: "medium"
|
||||
best_for: "核心流程自动化，边界场景手动"
|
||||
|
||||
# 测试环境 → 准备工作
|
||||
environment_mapping:
|
||||
"本地开发环境":
|
||||
setup: "最简单"
|
||||
reality: "与生产差异大"
|
||||
suitable_for: "单元测试、快速验证"
|
||||
|
||||
"独立测试环境":
|
||||
setup: "中等复杂度"
|
||||
reality: "接近生产"
|
||||
suitable_for: "集成测试、功能测试"
|
||||
|
||||
"预生产环境":
|
||||
setup: "复杂"
|
||||
reality: "几乎等同生产"
|
||||
suitable_for: "性能测试、上线前验证"
|
||||
```
|
||||
|
||||
## 文档结构建议
|
||||
|
||||
```markdown
|
||||
# {功能/系统名称}测试 - 需求文档
|
||||
|
||||
## 1. 测试概述
|
||||
- 测试对象
|
||||
- 测试背景
|
||||
- 测试目标
|
||||
|
||||
## 2. 测试类型与范围
|
||||
- 测试类型（功能/性能/安全/集成等）
|
||||
- 测试范围（包含和排除的部分）
|
||||
- 测试深度
|
||||
|
||||
## 3. 测试场景
|
||||
- 正常场景
|
||||
- 异常场景
|
||||
- 边界场景
|
||||
- 用户故事/测试用例
|
||||
|
||||
## 4. 测试数据
|
||||
- 数据来源
|
||||
- 数据量级
|
||||
- 数据准备方式
|
||||
- 隐私保护要求
|
||||
|
||||
## 5. 测试环境
|
||||
- 环境配置
|
||||
- 依赖服务
|
||||
- 测试工具
|
||||
|
||||
## 6. 测试方式
|
||||
- 自动化策略
|
||||
- 测试框架和工具
|
||||
- CI/CD 集成
|
||||
|
||||
## 7. 性能指标（如适用）
|
||||
- 响应时间要求
|
||||
- 吞吐量要求
|
||||
- 并发要求
|
||||
- 资源限制
|
||||
|
||||
## 8. 验收标准
|
||||
- 通过标准
|
||||
- 覆盖率要求
|
||||
- 缺陷标准
|
||||
- 性能基线
|
||||
|
||||
## 9. 测试计划
|
||||
- 测试阶段
|
||||
- 时间安排
|
||||
- 人员分工
|
||||
|
||||
## 10. 交付物
|
||||
- 测试报告
|
||||
- 测试用例
|
||||
- 自动化脚本
|
||||
- 缺陷列表
|
||||
```
|
||||
|
||||
## 特殊场景处理
|
||||
|
||||
### 性能测试项目
|
||||
额外关注：
|
||||
- 性能基线建立
|
||||
- 压力测试策略（阶梯式/持续/峰值）
|
||||
- 瓶颈分析工具
|
||||
- 监控和报警
|
||||
|
||||
### 安全测试项目
|
||||
额外关注：
|
||||
- OWASP Top 10
|
||||
- 常见漏洞类型
|
||||
- 合规要求（等保、PCI-DSS 等）
|
||||
- 渗透测试授权
|
||||
|
||||
### 自动化测试项目
|
||||
额外关注：
|
||||
- 测试框架选择
|
||||
- 测试代码架构
|
||||
- CI/CD 集成
|
||||
- 维护成本
|
||||
|
||||
### 兼容性测试项目
|
||||
额外关注：
|
||||
- 浏览器/设备矩阵
|
||||
- 操作系统版本
|
||||
- 第三方依赖版本
|
||||
- 向后兼容性
|
||||
|
||||
## 选项设计规范
|
||||
|
||||
### 互斥性原则
|
||||
|
||||
**单选问题**（multiSelect: false）：
|
||||
- ✅ 选项应完全互斥，无重叠
|
||||
- ✅ 边界清晰，用户能明确判断属于哪一个
|
||||
- ❌ 避免数量范围重叠（如"1-10人"和"5-20人"）
|
||||
- ❌ 避免概念包含关系
|
||||
|
||||
**多选问题**（multiSelect: true）：
|
||||
- ✅ 选项可从不同角度切分，允许合理组合
|
||||
- ✅ 每个选项应代表独立的需求维度
|
||||
- ❌ 避免选项之间有逻辑依赖
|
||||
|
||||
### 维度统一原则
|
||||
|
||||
同一问题的所有选项应属于同一分类维度。
|
||||
|
||||
❌ **错误示例**（维度混乱）：
|
||||
```yaml
|
||||
question: "用户如何使用这个工具?"
|
||||
options:
|
||||
- 输入问题主动调用 # 维度：触发方式
|
||||
- 命令行/编程接口 # 维度：交互界面
|
||||
- Web界面 # 维度：交互界面
|
||||
multiSelect: false
|
||||
```
|
||||
|
||||
✅ **正确做法**：拆分为两个问题，或统一到同一维度
|
||||
|
||||
### 边界清晰原则
|
||||
|
||||
**数量范围**：避免重叠，如"个人使用（1-5人）"、"小团队（6-50人）"
|
||||
**概念分类**：确保平级，避免包含关系
|
||||
|
||||
### 完备性检查
|
||||
|
||||
- 2-4个选项应覆盖**80%的常见场景**
|
||||
- 长尾场景通过"其他"覆盖
|
||||
- 当不确定时，优先设计偏通用的选项+依赖"其他"
|
||||
@ -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生成需求文档。
|
||||
@ -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 必须检查并删除多余章节
|
||||
|
||||
---
|
||||
|
||||
## 流程结束
|
||||
|
||||
完成输出总结后，**控制权交回给用户**，流程结束。
|
||||
313
.claude/skills/requirement-generator-v1/requirement.md
Normal file
313
.claude/skills/requirement-generator-v1/requirement.md
Normal file
@ -0,0 +1,313 @@
|
||||
# 医疗精神疾病深度研究助手 (DeepResearch Assistant) - 需求文档
|
||||
|
||||
**文档版本**: 1.0
|
||||
**创建时间**: 2025-12-07
|
||||
**生成方式**: Claude Code 智能需求生成器
|
||||
**项目类型**: Agent 开发
|
||||
|
||||
---
|
||||
|
||||
## 1. 背景与目标
|
||||
|
||||
### 1.1 项目背景
|
||||
|
||||
开发一个面向医疗精神疾病领域的深度研究助手（DeepResearch Assistant），帮助科研人员、医学生和医疗信息分析师进行系统性文献调研。该助手能够根据用户提出的研究问题，自动执行多数据源并行搜索，对搜索到的文献进行智能分析，最终生成高质量、结构化的研究报告，确保引用准确、逻辑清晰。
|
||||
|
||||
### 1.2 目标与价值
|
||||
|
||||
**核心目标**：
|
||||
1. **提高文献调研效率**：将传统需要数天的文献调研工作压缩到小时级别完成
|
||||
2. **提升研究质量**：确保文献覆盖全面、引用准确可追溯、分析逻辑严谨
|
||||
3. **构建长期知识库**：通过知识图谱积累领域知识，支持持续研究和知识发现
|
||||
|
||||
**目标用户**：
|
||||
1. **科研人员/学者**：进行精神疾病领域的学术研究
|
||||
2. **医学生/规培医生**：学习精神科知识，辅助学业
|
||||
3. **医疗信息分析师**：处理大量文献数据，支持机构决策
|
||||
|
||||
---
|
||||
|
||||
## 2. 使用场景与触发方式
|
||||
|
||||
### 2.1 典型使用场景
|
||||
|
||||
#### 场景一：文献综述撰写
|
||||
|
||||
**触发条件**：用户输入研究问题，如"近5年精神分裂症认知功能障碍的非药物治疗进展"
|
||||
|
||||
**操作步骤**：
|
||||
1. 用户输入研究问题
|
||||
2. 系统展示Multi-Agent执行进度：解析问题 -> 制定搜索策略
|
||||
3. 并行搜索多个数据源，实时显示"正在搜索PubMed..."、"已找到X篇文献"
|
||||
4. 对文献进行智能分析和综合
|
||||
5. 将新文献动态加入知识图谱，执行去重
|
||||
6. 生成结构化研究报告
|
||||
|
||||
**预期结果**：获得一份包含背景概述、核心文献分析、证据等级评估、研究结论与知识空白、标准格式引用的完整中文研究报告
|
||||
|
||||
#### 场景二：研究题目探索
|
||||
|
||||
**触发条件**：用户希望了解某个新研究方向的进展和空白
|
||||
|
||||
**操作步骤**：
|
||||
1. 用户输入探索性问题
|
||||
2. 系统搜索相关文献并分析研究现状
|
||||
3. 识别该领域的知识空白和潜在研究方向
|
||||
4. 生成研究现状与机会分析报告
|
||||
|
||||
**预期结果**：了解该方向的研究现状、主要发现、知识空白和潜在研究机会
|
||||
|
||||
### 2.2 使用入口与触发方式
|
||||
|
||||
- **主要入口**：通过对话界面以自然语言输入研究问题
|
||||
- **触发方式**：用户输入研究问题后，系统自动启动Multi-Agent协作流程
|
||||
- **语言支持**：支持中英文提问
|
||||
|
||||
---
|
||||
|
||||
## 3. 输入输出定义
|
||||
|
||||
### 3.1 输入
|
||||
|
||||
| 输入项 | 描述 | 格式 | 必填 |
|
||||
|-------|------|------|------|
|
||||
| 研究问题 | 用户以自然语言描述的研究问题 | 自然语言文本（中/英文） | 是 |
|
||||
|
||||
**输入示例**：
|
||||
- "近5年精神分裂症认知功能障碍的非药物治疗进展"
|
||||
- "抑郁症与肠道菌群的关系研究现状"
|
||||
- "What are the recent advances in cognitive behavioral therapy for PTSD?"
|
||||
|
||||
### 3.2 输出
|
||||
|
||||
**输出格式**：结构化中文研究报告
|
||||
|
||||
**报告结构**：
|
||||
| 章节 | 内容描述 |
|
||||
|-----|---------|
|
||||
| 研究背景与现状概述 | 对研究问题的背景介绍和领域概况 |
|
||||
| 核心文献摘要与分析 | 重要文献的摘要提取和关键发现对比分析 |
|
||||
| 研究方法与证据等级 | 文献的研究方法分类和证据等级评估 |
|
||||
| 研究结论与知识空白 | 综合结论和领域内尚待研究的问题 |
|
||||
| 文献引用列表 | 标准格式的完整引用列表 |
|
||||
|
||||
---
|
||||
|
||||
## 4. 交互流程说明
|
||||
|
||||
### 4.1 典型主流程
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
Start([用户输入研究问题]) --> Parse[解析问题/制定搜索策略]
|
||||
Parse --> Search[并行搜索多数据源]
|
||||
Search --> Progress[实时展示搜索进度]
|
||||
Progress --> Analyze[智能文献分析与综合]
|
||||
Analyze --> KG[知识图谱更新与去重]
|
||||
KG --> Generate[生成结构化报告]
|
||||
Generate --> Output([输出研究报告])
|
||||
```
|
||||
|
||||
**流程说明**：
|
||||
1. **问题解析**：理解用户研究问题，提取关键词，制定多数据源搜索策略
|
||||
2. **并行搜索**：同时向多个学术数据源发起检索请求
|
||||
3. **进度展示**：实时向用户反馈各数据源搜索状态和已找到的文献数量
|
||||
4. **文献分析**：对检索到的文献进行摘要提取、证据等级评估、关键发现对比
|
||||
5. **知识图谱更新**：将新文献信息存入知识图谱，执行多级去重
|
||||
6. **报告生成**：综合分析结果，生成结构化研究报告
|
||||
|
||||
### 4.2 异常与分支流程
|
||||
|
||||
| 异常场景 | 处理方式 |
|
||||
|---------|---------|
|
||||
| 某数据源访问失败 | 记录失败原因，继续使用其他数据源，在报告中注明 |
|
||||
| 搜索结果为空 | 建议用户调整研究问题或扩大搜索范围 |
|
||||
| 文献数量过多 | 按相关性和证据等级排序，优先处理高价值文献 |
|
||||
| 重复文献识别 | 通过知识图谱去重机制自动合并 |
|
||||
|
||||
---
|
||||
|
||||
## 5. 外部系统与数据依赖
|
||||
|
||||
### 5.1 外部数据源需求
|
||||
|
||||
| 数据源 | 类型 | 用途 | 优先级 |
|
||||
|-------|------|------|--------|
|
||||
| PubMed/MEDLINE | 生物医学文献数据库 | 获取生物医学研究文献 | 核心 |
|
||||
| PsycINFO | 心理学专业数据库 | 获取心理学/精神科专业文献 | 核心 |
|
||||
| Embase | 欧洲文献数据库 | 获取欧洲文献及药物研究 | 核心 |
|
||||
| Cochrane Library | 循证医学数据库 | 获取系统评价和Meta分析 | 扩展 |
|
||||
| CNKI | 中国知网 | 获取中文学术文献 | 扩展 |
|
||||
| 万方数据 | 中文文献数据库 | 补充中文文献来源 | 扩展 |
|
||||
| bioRxiv/medRxiv | 预印本平台 | 获取最新未发表研究 | 扩展 |
|
||||
| Google Scholar | 综合学术搜索 | 补充其他来源遗漏文献 | 扩展 |
|
||||
|
||||
### 5.2 系统集成需求
|
||||
|
||||
- **知识图谱存储系统**：用于持久化存储文献、概念、作者、研究时间线等实体及其关系
|
||||
- **文献全文获取服务**：用于获取文献全文内容（可选）
|
||||
|
||||
### 5.3 数据交互时序
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant U as 用户
|
||||
participant O as 调度Agent
|
||||
participant S1 as 搜索Agent-PubMed
|
||||
participant S2 as 搜索Agent-PsycINFO
|
||||
participant S3 as 搜索Agent-Embase
|
||||
participant A as 分析Agent
|
||||
participant KG as 知识图谱
|
||||
participant R as 报告生成Agent
|
||||
|
||||
U->>O: 输入研究问题
|
||||
O->>O: 解析问题/制定策略
|
||||
|
||||
par 并行搜索
|
||||
O->>S1: 搜索PubMed
|
||||
O->>S2: 搜索PsycINFO
|
||||
O->>S3: 搜索Embase
|
||||
S1-->>O: 返回文献列表
|
||||
S2-->>O: 返回文献列表
|
||||
S3-->>O: 返回文献列表
|
||||
end
|
||||
|
||||
O->>A: 提交文献进行分析
|
||||
A->>KG: 查询已有知识
|
||||
KG-->>A: 返回相关知识
|
||||
A->>KG: 更新新知识(含去重)
|
||||
A-->>O: 返回分析结果
|
||||
|
||||
O->>R: 生成研究报告
|
||||
R-->>U: 输出结构化报告
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 6. 系统模块与Agent角色定义
|
||||
|
||||
### 6.1 Agent列表与核心职能
|
||||
|
||||
| Agent名称 | 核心职能 | 主要能力 |
|
||||
|----------|---------|---------|
|
||||
| 调度Agent | 任务分解与协调 | 解析研究问题、制定搜索策略、协调各Agent工作、汇总结果 |
|
||||
| 搜索Agent(多实例) | 数据源检索 | 连接特定数据源、执行检索、返回文献元数据 |
|
||||
| 分析Agent | 文献智能分析 | 摘要提取、证据等级评估、关键发现对比、知识图谱交互 |
|
||||
| 报告生成Agent | 报告撰写 | 综合分析结果、生成结构化报告、格式化引用 |
|
||||
| 去重Agent | 知识图谱去重 | 文献ID去重、实体语义去重、关系级去重 |
|
||||
|
||||
### 6.2 Agent能力边界
|
||||
|
||||
| Agent | 能做 | 不能做 |
|
||||
|-------|-----|-------|
|
||||
| 调度Agent | 任务分解、进度跟踪、结果汇总 | 直接访问数据源、执行深度分析 |
|
||||
| 搜索Agent | 连接数据源、执行检索 | 分析文献内容、生成报告 |
|
||||
| 分析Agent | 理解文献内容、评估证据等级 | 直接访问数据源、格式化输出 |
|
||||
| 报告生成Agent | 组织报告结构、生成标准引用 | 搜索文献、分析文献内容 |
|
||||
| 去重Agent | 识别重复实体和关系、合并同义词 | 搜索文献、分析文献内容 |
|
||||
|
||||
### 6.3 Agent间协作关系
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
Orchestrator[调度Agent] --> Search1[搜索Agent-PubMed]
|
||||
Orchestrator --> Search2[搜索Agent-PsycINFO]
|
||||
Orchestrator --> Search3[搜索Agent-其他数据源]
|
||||
Orchestrator --> Analyzer[分析Agent]
|
||||
Analyzer <--> KG[(知识图谱)]
|
||||
Analyzer <--> Dedup[去重Agent]
|
||||
Orchestrator --> Reporter[报告生成Agent]
|
||||
|
||||
subgraph 并行执行
|
||||
Search1
|
||||
Search2
|
||||
Search3
|
||||
end
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 7. 分阶段交付计划
|
||||
|
||||
### 7.1 阶段1：MVP版本 - 实现核心搜索和报告生成能力
|
||||
|
||||
**阶段目标**: 验证核心价值，实现基本的多数据源搜索和结构化报告生成能力
|
||||
|
||||
**功能清单**:
|
||||
- 3个核心数据源并行搜索（PubMed、PsycINFO、Embase）
|
||||
- 结构化报告生成（固定模板）
|
||||
- Multi-Agent执行进度展示
|
||||
- 文字形式存储搜索结果（暂不使用知识图谱）
|
||||
|
||||
### 7.2 阶段2：完善版本 - 扩展数据源，引入知识图谱与完整去重
|
||||
|
||||
**阶段目标**: 扩展全部数据源，引入知识图谱存储与完整的去重机制，提升研究深度
|
||||
|
||||
**功能清单**:
|
||||
- 扩展全部数据源（Cochrane、CNKI、万方、预印本、Google Scholar）
|
||||
- 知识图谱存储（文献引用关系、概念/实体关系、作者合作关系、研究时间线）
|
||||
- 完整去重机制（文献ID去重、实体语义去重、关系级去重）
|
||||
- 基于知识图谱的推理与充分性检查
|
||||
- 报告格式动态调整（根据问题类型灵活调整报告结构）
|
||||
|
||||
**阶段划分说明**: MVP阶段聚焦核心价值验证（搜索+报告生成），知识图谱及其相关功能（去重、推理）作为整体在第二阶段一起引入，避免功能割裂
|
||||
|
||||
---
|
||||
|
||||
## 8. 技术约束与非功能性需求
|
||||
|
||||
### 8.1 技术约束
|
||||
|
||||
以下为用户明确要求的技术约束：
|
||||
|
||||
**知识图谱存储**
|
||||
> 使用知识图谱进行文献存储与动态更新
|
||||
|
||||
**全图去重机制**
|
||||
> 建立全图去重机制（文献ID去重+实体语义去重+关系级去重）
|
||||
|
||||
**Multi-Agent架构**
|
||||
> 采用Multi-Agent架构实现并行处理和进度展示
|
||||
|
||||
### 8.2 性能要求
|
||||
|
||||
| 指标 | 要求 | 说明 |
|
||||
|-----|------|------|
|
||||
| 响应时间 | 允许小时级执行 | 追求全面深入的研究结果而非快速响应 |
|
||||
| 进度反馈 | 实时 | Multi-Agent执行过程需实时展示进度 |
|
||||
|
||||
### 8.3 安全要求
|
||||
|
||||
- 无特殊安全要求，主要处理公开学术文献
|
||||
- 无需用户认证或敏感数据加密
|
||||
|
||||
### 8.4 其他非功能性要求
|
||||
|
||||
| 类别 | 要求 |
|
||||
|-----|------|
|
||||
| 使用规模 | 个人/小团队使用（1-10人） |
|
||||
| 日均查询量 | 10-50次 |
|
||||
| 输出语言 | 报告输出为中文 |
|
||||
| 文献处理 | 支持中英文文献处理 |
|
||||
|
||||
---
|
||||
|
||||
## 9. 验收标准
|
||||
|
||||
### 9.1 功能验收标准
|
||||
|
||||
| 验收项 | 验收标准 | 验证方式 |
|
||||
|-------|---------|---------|
|
||||
| 引用准确性 | 报告中引用的每篇文献都能在对应数据源中找到原文 | 人工抽查验证 |
|
||||
| 报告完整性 | 包含背景、文献分析、证据等级、结论、引用等必要章节 | 结构检查 |
|
||||
| 进度展示 | Multi-Agent执行过程可视化展示，用户能了解当前进度 | 用户体验测试 |
|
||||
| 复杂问题处理 | 能处理多维度、跨领域的精神疾病研究问题 | 复杂问题测试 |
|
||||
| 去重有效性 | 同一文献不重复入库，同义实体能识别合并，关系边不重复 | 知识图谱检查 |
|
||||
|
||||
### 9.2 非功能验收标准
|
||||
|
||||
| 验收项 | 验收标准 |
|
||||
|-------|---------|
|
||||
| 执行时间 | 完整研究报告生成在合理时间内完成（允许小时级） |
|
||||
| 并发支持 | 支持小团队（1-10人）同时使用 |
|
||||
| 中英文支持 | 能正确处理中英文混合的研究问题和文献 |
|
||||
351
.claude/skills/requirement-generator-v1/requirement_final.md
Normal file
351
.claude/skills/requirement-generator-v1/requirement_final.md
Normal file
@ -0,0 +1,351 @@
|
||||
# 医疗精神疾病深度研究助手 (DeepResearch Assistant) - 需求文档
|
||||
|
||||
**文档版本**: 1.1
|
||||
**创建时间**: 2025-12-07
|
||||
**生成方式**: Claude Code 智能需求生成器
|
||||
**项目类型**: Agent 开发
|
||||
|
||||
---
|
||||
|
||||
## 1. 背景与目标
|
||||
|
||||
### 1.1 项目背景
|
||||
|
||||
开发一个面向医疗精神疾病领域的深度研究助手（DeepResearch Assistant），帮助科研人员、医学生和医疗信息分析师进行系统性文献调研。该助手能够根据用户提出的研究问题，自动执行多数据源并行搜索，对搜索到的文献进行智能分析，最终生成高质量、结构化的研究报告，确保引用准确、逻辑清晰。
|
||||
|
||||
### 1.2 目标与价值
|
||||
|
||||
**核心目标**：
|
||||
1. **提高文献调研效率**：将传统需要数天的文献调研工作压缩到小时级别完成
|
||||
2. **提升研究质量**：确保文献覆盖全面、引用准确可追溯、分析逻辑严谨
|
||||
3. **构建长期知识库**：通过知识图谱积累领域知识，支持持续研究和知识发现
|
||||
|
||||
**目标用户**：
|
||||
1. **科研人员/学者**：进行精神疾病领域的学术研究
|
||||
2. **医学生/规培医生**：学习精神科知识，辅助学业
|
||||
3. **医疗信息分析师**：处理大量文献数据，支持机构决策
|
||||
|
||||
---
|
||||
|
||||
## 2. 使用场景与触发方式
|
||||
|
||||
### 2.1 典型使用场景
|
||||
|
||||
#### 场景一：文献综述撰写
|
||||
|
||||
**触发条件**：用户输入研究问题，如"近5年精神分裂症认知功能障碍的非药物治疗进展"
|
||||
|
||||
**操作步骤**：
|
||||
1. 用户输入研究问题
|
||||
2. 系统展示Multi-Agent执行进度：解析问题 -> 制定搜索策略
|
||||
3. 并行搜索多个数据源，实时显示"正在搜索PubMed..."、"已找到X篇文献"
|
||||
4. 对文献进行智能分析和综合
|
||||
5. 将新文献动态加入知识图谱，执行去重
|
||||
6. 生成结构化研究报告
|
||||
|
||||
**预期结果**：获得一份包含背景概述、核心文献分析、研究类型分布、研究结论与知识空白、标准格式引用的完整中文研究报告
|
||||
|
||||
#### 场景二：研究题目探索
|
||||
|
||||
**触发条件**：用户希望了解某个新研究方向的进展和空白
|
||||
|
||||
**操作步骤**：
|
||||
1. 用户输入探索性问题
|
||||
2. 系统搜索相关文献并分析研究现状
|
||||
3. 识别该领域的知识空白和潜在研究方向
|
||||
4. 生成研究现状与机会分析报告
|
||||
|
||||
**预期结果**：了解该方向的研究现状、主要发现、知识空白和潜在研究机会
|
||||
|
||||
### 2.2 使用入口与触发方式
|
||||
|
||||
- **主要入口**：通过对话界面以自然语言输入研究问题
|
||||
- **触发方式**：用户输入研究问题后，系统自动启动Multi-Agent协作流程
|
||||
- **语言支持**：支持中英文提问
|
||||
- **搜索策略控制**：默认自动执行搜索；高级用户可开启搜索策略预览与调整模式；在结果页面提供调整搜索范围后重新生成的入口
|
||||
|
||||
---
|
||||
|
||||
## 3. 输入输出定义
|
||||
|
||||
### 3.1 输入
|
||||
|
||||
| 输入项 | 描述 | 格式 | 必填 |
|
||||
|-------|------|------|------|
|
||||
| 研究问题 | 用户以自然语言描述的研究问题 | 自然语言文本（中/英文） | 是 |
|
||||
|
||||
**输入示例**：
|
||||
- "近5年精神分裂症认知功能障碍的非药物治疗进展"
|
||||
- "抑郁症与肠道菌群的关系研究现状"
|
||||
- "治疗抵抗性抑郁症的增效治疗策略"
|
||||
- "首发精神分裂症的早期干预证据"
|
||||
|
||||
**术语规范化处理**：系统基于DSM-5/ICD-11术语库，自动识别用户输入的非标准术语并映射到标准术语进行搜索。
|
||||
|
||||
### 3.2 输出
|
||||
|
||||
**输出格式**：结构化中文研究报告（Markdown格式，用户可自行转换为其他格式）
|
||||
|
||||
**报告结构**：
|
||||
| 章节 | 内容描述 |
|
||||
|-----|---------|
|
||||
| 研究背景与现状概述 | 对研究问题的背景介绍和领域概况 |
|
||||
| 核心文献摘要与分析 | 重要文献的摘要提取和关键发现对比分析，每条结论标注证据来源链接 |
|
||||
| 研究类型分布 | 纳入文献的研究类型分类（系统评价/Meta分析、RCT、队列研究、病例对照、病例报告等） |
|
||||
| 研究方法学注意事项 | 诊断标准差异提醒、评估量表说明、方法学局限性说明 |
|
||||
| 研究结论与知识空白 | 综合结论和领域内尚待研究的问题 |
|
||||
| 文献引用列表 | 标准格式的完整引用列表，所有引用均经过来源验证 |
|
||||
|
||||
**报告透明性说明**：
|
||||
- 显示研究类型分布（如：包含3项RCT、5项队列研究等）
|
||||
- 展示文献筛选逻辑（如：搜索到200篇，相关性筛选后纳入50篇）
|
||||
- 对核心专业术语提供悬浮解释或脚注
|
||||
- 明确标注"研究类型分类由AI提供，完整的证据等级评估需专业人员判断"
|
||||
|
||||
---
|
||||
|
||||
## 4. 交互流程说明
|
||||
|
||||
### 4.1 典型主流程
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
Start([用户输入研究问题]) --> Parse[解析问题/制定搜索策略]
|
||||
Parse --> Search[并行搜索多数据源]
|
||||
Search --> Progress[实时展示搜索进度]
|
||||
Progress --> Analyze[智能文献分析与综合]
|
||||
Analyze --> KG[知识图谱更新与去重]
|
||||
KG --> Generate[生成结构化报告]
|
||||
Generate --> Output([输出研究报告])
|
||||
```
|
||||
|
||||
**流程说明**：
|
||||
1. **问题解析**：理解用户研究问题，进行术语规范化转换，提取关键词，制定多数据源搜索策略
|
||||
2. **并行搜索**：同时向多个学术数据源发起检索请求
|
||||
3. **进度展示**：实时向用户反馈各数据源搜索状态和已找到的文献数量，展示预估完成时间
|
||||
4. **文献分析**：对检索到的文献进行摘要提取、研究类型分类、关键发现对比
|
||||
5. **知识图谱更新**：将新文献信息存入知识图谱，执行多级去重
|
||||
6. **报告生成**：综合分析结果，生成结构化研究报告
|
||||
|
||||
### 4.2 异常与分支流程
|
||||
|
||||
| 异常场景 | 处理方式 |
|
||||
|---------|---------|
|
||||
| 某数据源访问失败 | 记录失败原因，继续使用其他数据源，在报告中注明数据源覆盖情况 |
|
||||
| 搜索结果为空 | 建议用户调整研究问题或扩大搜索范围 |
|
||||
| 文献数量过多 | 采用分层处理策略：第一轮粗筛可处理200篇（相关性排序），第二轮精读分析处理Top 50-80篇核心文献，明确告知用户已分析文献范围 |
|
||||
| 重复文献识别 | 通过知识图谱多级去重机制自动合并 |
|
||||
| 用户问题模糊 | 提供问题澄清引导，帮助用户明确研究范围 |
|
||||
|
||||
---
|
||||
|
||||
## 5. 外部系统与数据依赖
|
||||
|
||||
### 5.1 外部数据源需求
|
||||
|
||||
| 数据源 | 类型 | 用途 | 优先级 | 授权方式 |
|
||||
|-------|------|------|--------|----------|
|
||||
| PubMed/MEDLINE | 生物医学文献数据库 | 获取生物医学研究文献 | 核心（MVP） | 免费开放API（E-utilities） |
|
||||
| PsycINFO | 心理学专业数据库 | 获取心理学/精神科专业文献 | 核心 | 需机构订阅，支持用户自带机构账号模式 |
|
||||
| Embase | 欧洲文献数据库 | 获取欧洲文献及药物研究 | 核心 | 需机构订阅，支持用户自带机构账号模式 |
|
||||
| Cochrane Library | 循证医学数据库 | 获取系统评价和Meta分析 | 扩展 | 需机构订阅 |
|
||||
| CNKI | 中国知网 | 获取中文学术文献 | 扩展 | 需机构订阅 |
|
||||
| 万方数据 | 中文文献数据库 | 补充中文文献来源 | 扩展 | 需机构订阅 |
|
||||
| bioRxiv/medRxiv | 预印本平台 | 获取最新未发表研究 | 扩展（MVP） | 免费开放API |
|
||||
| Google Scholar | 综合学术搜索 | 补充其他来源遗漏文献 | 扩展 | 需评估访问限制 |
|
||||
| ClinicalTrials.gov | 临床试验注册库 | 获取在研试验信息，评估发表偏倚 | 扩展（Phase 2） | 免费开放API |
|
||||
|
||||
**预印本来源说明**：对预印本来源的文献进行明确标注和风险提示，说明其未经同行评审的局限性，并降低其在证据综合中的权重。
|
||||
|
||||
### 5.2 系统集成需求
|
||||
|
||||
- **知识图谱存储系统**：用于持久化存储文献、概念、作者、研究时间线等实体及其关系
|
||||
- **医学术语标准化组件**：必须集成ICD-11、DSM-5术语库、MeSH/UMLS，作为搜索和去重的基础能力
|
||||
- **文献全文获取服务**（可选）：用于获取文献全文内容，可考虑使用Unpaywall等开放全文获取渠道
|
||||
|
||||
### 5.3 数据交互时序
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant U as 用户
|
||||
participant O as 调度Agent
|
||||
participant S1 as 搜索Agent-PubMed
|
||||
participant S2 as 搜索Agent-PsycINFO
|
||||
participant S3 as 搜索Agent-Embase
|
||||
participant A as 分析Agent
|
||||
participant KG as 知识图谱
|
||||
participant R as 报告生成Agent
|
||||
|
||||
U->>O: 输入研究问题
|
||||
O->>O: 解析问题/术语规范化/制定策略
|
||||
|
||||
par 并行搜索
|
||||
O->>S1: 搜索PubMed
|
||||
O->>S2: 搜索PsycINFO
|
||||
O->>S3: 搜索Embase
|
||||
S1-->>O: 返回文献列表
|
||||
S2-->>O: 返回文献列表
|
||||
S3-->>O: 返回文献列表
|
||||
end
|
||||
|
||||
O->>A: 提交文献进行分析
|
||||
A->>KG: 查询已有知识
|
||||
KG-->>A: 返回相关知识
|
||||
A->>KG: 更新新知识(含去重)
|
||||
A-->>O: 返回分析结果
|
||||
|
||||
O->>R: 生成研究报告
|
||||
R-->>U: 输出结构化报告
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 6. 系统模块与Agent角色定义
|
||||
|
||||
### 6.1 Agent列表与核心职能
|
||||
|
||||
| Agent名称 | 核心职能 | 主要能力 |
|
||||
|----------|---------|---------|
|
||||
| 调度Agent | 任务分解与协调 | 解析研究问题、术语规范化、制定搜索策略、协调各Agent工作、汇总结果 |
|
||||
| 搜索Agent(多实例) | 数据源检索 | 连接特定数据源、执行检索、返回文献元数据、将源格式转换为统一格式 |
|
||||
| 分析Agent | 文献智能分析 | 摘要提取、研究类型分类、关键发现对比、评估量表识别、知识图谱交互 |
|
||||
| 报告生成Agent | 报告撰写 | 综合分析结果、生成结构化报告、格式化引用、引用来源校验 |
|
||||
| 去重Agent | 知识图谱去重 | 文献ID去重、基于UMLS/MeSH的跨语言术语对齐、关系级去重 |
|
||||
|
||||
### 6.2 Agent能力边界
|
||||
|
||||
| Agent | 能做 | 不能做 |
|
||||
|-------|-----|-------|
|
||||
| 调度Agent | 任务分解、进度跟踪、结果汇总、术语规范化 | 直接访问数据源、执行深度分析 |
|
||||
| 搜索Agent | 连接数据源、执行检索、格式转换 | 分析文献内容、生成报告 |
|
||||
| 分析Agent | 理解文献内容、研究类型分类、量表名称识别 | 直接访问数据源、格式化输出、完整GRADE证据等级评估 |
|
||||
| 报告生成Agent | 组织报告结构、生成标准引用、引用ID校验 | 搜索文献、分析文献内容、自行补充引用 |
|
||||
| 去重Agent | 识别重复实体和关系、跨语言术语对齐 | 搜索文献、分析文献内容 |
|
||||
|
||||
### 6.3 Agent间协作关系
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
Orchestrator[调度Agent] --> Search1[搜索Agent-PubMed]
|
||||
Orchestrator --> Search2[搜索Agent-PsycINFO]
|
||||
Orchestrator --> Search3[搜索Agent-其他数据源]
|
||||
Orchestrator --> Analyzer[分析Agent]
|
||||
Analyzer <--> KG[(知识图谱)]
|
||||
Analyzer <--> Dedup[去重Agent]
|
||||
Orchestrator --> Reporter[报告生成Agent]
|
||||
|
||||
subgraph 并行执行
|
||||
Search1
|
||||
Search2
|
||||
Search3
|
||||
end
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 7. 分阶段交付计划
|
||||
|
||||
### 7.1 阶段1：MVP版本 - 实现核心搜索和报告生成能力
|
||||
|
||||
**阶段目标**: 验证核心价值，实现基本的多数据源搜索和结构化报告生成能力
|
||||
|
||||
**功能清单**:
|
||||
- 3个核心数据源并行搜索（PubMed、bioRxiv/medRxiv为MVP必选，PsycINFO/Embase支持用户自带机构账号）
|
||||
- 结构化报告生成（Markdown格式）
|
||||
- Multi-Agent执行进度展示
|
||||
- 基于DOI/PMID的精确匹配去重
|
||||
- 研究类型分类（系统评价/Meta分析、RCT、队列研究、病例对照、病例报告等）
|
||||
- 诊断标准关键词识别与标注（识别文献中出现的DSM-5、ICD-11等关键词）
|
||||
- 常用精神科量表名称识别（PANSS、HAM-D、MADRS、CGI等）
|
||||
- 研究方法学注意事项提醒章节
|
||||
- 引用幻觉防范机制：结构化输出+引用ID校验
|
||||
|
||||
### 7.2 阶段2：完善版本 - 扩展数据源，引入知识图谱与完整去重
|
||||
|
||||
**阶段目标**: 扩展全部数据源，引入知识图谱存储与完整的去重机制，提升研究深度
|
||||
|
||||
**功能清单**:
|
||||
- 扩展全部数据源（Cochrane、CNKI、万方、Google Scholar）
|
||||
- 整合ClinicalTrials.gov临床试验注册库
|
||||
- 知识图谱存储（文献引用关系、概念/实体关系、作者合作关系、研究时间线）
|
||||
- 完整去重机制（文献ID去重、基于UMLS/MeSH CUI的跨语言术语对齐、关系级去重）
|
||||
- 基于知识图谱的推理与充分性检查
|
||||
- 报告格式动态调整（根据问题类型灵活调整报告结构）
|
||||
- 直接导出Word/PDF功能
|
||||
- 偏倚风险初筛（基于Cochrane偏倚风险评估工具框架）
|
||||
- 量表评分结果提取
|
||||
- 诊断标准版本自动识别与标注
|
||||
|
||||
**阶段划分说明**: MVP阶段聚焦核心价值验证（搜索+报告生成+基本专业功能），知识图谱及其相关功能（完整去重、推理）作为整体在第二阶段一起引入，避免功能割裂
|
||||
|
||||
---
|
||||
|
||||
## 8. 技术约束与非功能性需求
|
||||
|
||||
### 8.1 技术约束
|
||||
|
||||
以下为用户明确要求的技术约束：
|
||||
|
||||
**知识图谱存储**
|
||||
> 使用知识图谱进行文献存储与动态更新
|
||||
|
||||
**全图去重机制**
|
||||
> 建立全图去重机制（文献ID去重+基于UMLS/MeSH的跨语言术语对齐+关系级去重）
|
||||
|
||||
**Multi-Agent架构**
|
||||
> 采用Multi-Agent架构实现并行处理和进度展示
|
||||
|
||||
**医学术语标准化组件**
|
||||
> 必须集成ICD-11、DSM-5术语库、MeSH/UMLS，作为搜索和去重的基础能力
|
||||
|
||||
**引用幻觉防范**
|
||||
> 报告生成Agent的引用必须且只能来自搜索Agent返回的文献列表，采用结构化输出格式，后处理阶段校验所有引用ID是否存在于原始搜索结果中
|
||||
|
||||
### 8.2 性能要求
|
||||
|
||||
| 指标 | 要求 | 说明 |
|
||||
|-----|------|------|
|
||||
| 响应时间 | 允许小时级执行 | 追求全面深入的研究结果而非快速响应 |
|
||||
| 进度反馈 | 实时 | Multi-Agent执行过程需实时展示进度，包含预估完成时间 |
|
||||
| 后台执行 | 支持 | 支持后台执行+完成通知，用户无需持续等待 |
|
||||
| 文献处理能力 | 分层处理 | 第一轮粗筛可处理200篇，第二轮精读分析处理Top 50-80篇核心文献 |
|
||||
|
||||
### 8.3 安全要求
|
||||
|
||||
- 无特殊安全要求，主要处理公开学术文献
|
||||
- 无需用户认证或敏感数据加密
|
||||
- 用户机构账号信息（如用于PsycINFO访问）需安全存储
|
||||
|
||||
### 8.4 其他非功能性要求
|
||||
|
||||
| 类别 | 要求 |
|
||||
|-----|------|
|
||||
| 使用规模 | 个人/小团队使用（1-10人） |
|
||||
| 日均查询量 | 10-50次 |
|
||||
| 输出语言 | 报告输出为中文 |
|
||||
| 文献处理 | 支持中英文文献处理 |
|
||||
|
||||
---
|
||||
|
||||
## 9. 验收标准
|
||||
|
||||
### 9.1 功能验收标准
|
||||
|
||||
| 验收项 | 验收标准 | 验证方式 |
|
||||
|-------|---------|---------|
|
||||
| 引用来源可追溯率 | =100%（刚性约束，所有引用必须来自搜索返回结果，禁止AI自行生成） | 自动化校验+人工抽查 |
|
||||
| 引用格式准确率 | >=95%（DOI、作者、标题等信息与原始数据一致） | 人工抽查验证 |
|
||||
| 报告完整性 | 包含背景、文献分析、研究类型分布、方法学注意事项、结论、引用等必要章节 | 结构检查 |
|
||||
| 进度展示 | Multi-Agent执行过程可视化展示，用户能了解当前进度和预估完成时间 | 用户体验测试 |
|
||||
| 复杂问题处理 | 能处理涉及多种疾病类型、多种治疗方法的跨领域研究问题 | 复杂问题测试用例验证 |
|
||||
| 去重准确率 | >=90%（允许边界情况保留两者） | 知识图谱检查 |
|
||||
| 研究类型分类准确率 | >=85%（系统评价/RCT/队列研究/病例报告等基本分类） | 人工抽查验证 |
|
||||
|
||||
### 9.2 非功能验收标准
|
||||
|
||||
| 验收项 | 验收标准 |
|
||||
|-------|---------|
|
||||
| 执行时间 | 完整研究报告生成在合理时间内完成（简单问题30分钟内，复杂问题2小时内） |
|
||||
| 并发支持 | 支持小团队（1-10人）同时使用 |
|
||||
| 中英文支持 | 能正确处理中英文混合的研究问题和文献 |
|
||||
| 术语规范化 | 能正确识别并处理精神科领域的非标准术语输入 |
|
||||
File diff suppressed because it is too large
Load Diff
@ -0,0 +1,516 @@
|
||||
{
|
||||
"consolidation_date": "2025-12-07",
|
||||
"statistics": {
|
||||
"total_issues": 27,
|
||||
"total_suggestions": 18,
|
||||
"total_missing_items": 16,
|
||||
"applied": 31,
|
||||
"modified": 19,
|
||||
"withdrawn": 1,
|
||||
"rejected": 10
|
||||
},
|
||||
"applied_items": [
|
||||
{
|
||||
"source_expert": "开发专家",
|
||||
"item_type": "issue",
|
||||
"item_index": 0,
|
||||
"severity": "high",
|
||||
"description": "外部数据源API访问可行性未验证",
|
||||
"status": "applied",
|
||||
"applied_content": "明确标注各数据源的授权方式，MVP阶段优先使用免费开放API（PubMed、bioRxiv），支持用户自带机构账号模式",
|
||||
"reason": "开发专家与产品经理达成共识，采用修改后方案"
|
||||
},
|
||||
{
|
||||
"source_expert": "开发专家",
|
||||
"item_type": "issue",
|
||||
"item_index": 2,
|
||||
"severity": "high",
|
||||
"description": "实时进度展示的技术实现方式不明确",
|
||||
"status": "applied",
|
||||
"applied_content": "在性能要求中增加进度反馈机制描述，包含预估完成时间和后台执行支持",
|
||||
"reason": "无争议，直接采纳"
|
||||
},
|
||||
{
|
||||
"source_expert": "开发专家",
|
||||
"item_type": "issue",
|
||||
"item_index": 4,
|
||||
"severity": "medium",
|
||||
"description": "'合理时间内完成'表述模糊",
|
||||
"status": "applied",
|
||||
"applied_content": "在验收标准中明确时间预期：简单问题30分钟内，复杂问题2小时内",
|
||||
"reason": "无争议，直接采纳"
|
||||
},
|
||||
{
|
||||
"source_expert": "开发专家",
|
||||
"item_type": "issue",
|
||||
"item_index": 7,
|
||||
"severity": "low",
|
||||
"description": "多数据源返回结果的格式标准化未考虑",
|
||||
"status": "applied",
|
||||
"applied_content": "在Agent能力定义中明确搜索Agent负责格式转换",
|
||||
"reason": "无争议，直接采纳"
|
||||
},
|
||||
{
|
||||
"source_expert": "开发专家",
|
||||
"item_type": "missing_item",
|
||||
"item_index": 2,
|
||||
"severity": "medium",
|
||||
"description": "缺少错误恢复机制说明",
|
||||
"status": "applied",
|
||||
"applied_content": "在性能要求中增加后台执行+完成通知支持",
|
||||
"reason": "无争议，直接采纳"
|
||||
},
|
||||
{
|
||||
"source_expert": "产品经理",
|
||||
"item_type": "issue",
|
||||
"item_index": 3,
|
||||
"severity": "medium",
|
||||
"description": "进度反馈机制描述不够具体",
|
||||
"status": "applied",
|
||||
"applied_content": "增加预估完成时间展示、后台执行+完成通知功能",
|
||||
"reason": "无争议，直接采纳"
|
||||
},
|
||||
{
|
||||
"source_expert": "产品经理",
|
||||
"item_type": "issue",
|
||||
"item_index": 5,
|
||||
"severity": "medium",
|
||||
"description": "边缘场景覆盖不足",
|
||||
"status": "applied",
|
||||
"applied_content": "在异常处理中增加用户问题模糊时的引导澄清机制",
|
||||
"reason": "无争议，直接采纳"
|
||||
},
|
||||
{
|
||||
"source_expert": "产品经理",
|
||||
"item_type": "issue",
|
||||
"item_index": 6,
|
||||
"severity": "medium",
|
||||
"description": "部分验收标准不够具体可测",
|
||||
"status": "applied",
|
||||
"applied_content": "在验收标准中明确复杂问题的定义和时间范围",
|
||||
"reason": "无争议，直接采纳"
|
||||
},
|
||||
{
|
||||
"source_expert": "产品经理",
|
||||
"item_type": "user_experience_concern",
|
||||
"item_index": 0,
|
||||
"severity": "medium",
|
||||
"description": "长时间等待的用户体验",
|
||||
"status": "applied",
|
||||
"applied_content": "增加预估完成时间、后台执行+完成通知功能",
|
||||
"reason": "无争议，直接采纳"
|
||||
},
|
||||
{
|
||||
"source_expert": "AI专家",
|
||||
"item_type": "issue",
|
||||
"item_index": 0,
|
||||
"severity": "high",
|
||||
"description": "引用准确性验收标准缺乏量化指标",
|
||||
"status": "applied",
|
||||
"applied_content": "分层定义验收指标：引用来源可追溯率=100%（刚性约束），引用格式准确率>=95%",
|
||||
"reason": "AI专家与开发专家达成共识"
|
||||
},
|
||||
{
|
||||
"source_expert": "AI专家",
|
||||
"item_type": "issue",
|
||||
"item_index": 4,
|
||||
"severity": "medium",
|
||||
"description": "'复杂问题处理'验收标准过于模糊",
|
||||
"status": "applied",
|
||||
"applied_content": "明确复杂问题的定义：涉及多种疾病类型、多种治疗方法的跨领域研究问题",
|
||||
"reason": "无争议，直接采纳"
|
||||
},
|
||||
{
|
||||
"source_expert": "AI专家",
|
||||
"item_type": "ai_risk",
|
||||
"item_index": 0,
|
||||
"severity": "high",
|
||||
"description": "引用幻觉风险",
|
||||
"status": "applied",
|
||||
"applied_content": "通过架构设计防范：报告生成Agent引用只能来自搜索返回列表，采用结构化输出+ID校验机制",
|
||||
"reason": "AI专家接受开发专家的简化方案"
|
||||
},
|
||||
{
|
||||
"source_expert": "AI专家",
|
||||
"item_type": "missing_item",
|
||||
"item_index": 2,
|
||||
"severity": "medium",
|
||||
"description": "未定义分析Agent处理单次任务的文献数量上限",
|
||||
"status": "applied",
|
||||
"applied_content": "采用分层处理策略：第一轮粗筛200篇，第二轮精读50-80篇核心文献",
|
||||
"reason": "AI专家接受开发专家的动态配置方案"
|
||||
},
|
||||
{
|
||||
"source_expert": "领域专家",
|
||||
"item_type": "issue",
|
||||
"item_index": 3,
|
||||
"severity": "medium",
|
||||
"description": "缺少专业术语规范化处理",
|
||||
"status": "applied",
|
||||
"applied_content": "建立精神科标准术语库（基于DSM-5/ICD-11），在问题解析阶段自动映射到标准术语",
|
||||
"reason": "无争议，直接采纳"
|
||||
},
|
||||
{
|
||||
"source_expert": "领域专家",
|
||||
"item_type": "issue",
|
||||
"item_index": 7,
|
||||
"severity": "low",
|
||||
"description": "输入示例可进一步优化",
|
||||
"status": "applied",
|
||||
"applied_content": "增加更专业的输入示例",
|
||||
"reason": "无争议，直接采纳"
|
||||
},
|
||||
{
|
||||
"source_expert": "领域专家",
|
||||
"item_type": "issue",
|
||||
"item_index": 8,
|
||||
"severity": "low",
|
||||
"description": "未明确处理预印本文献的风险提示",
|
||||
"status": "applied",
|
||||
"applied_content": "在数据源说明中增加预印本风险提示",
|
||||
"reason": "无争议，直接采纳"
|
||||
},
|
||||
{
|
||||
"source_expert": "领域专家",
|
||||
"item_type": "missing_item",
|
||||
"item_index": 0,
|
||||
"severity": "medium",
|
||||
"description": "缺少量表和评估工具识别功能",
|
||||
"status": "applied",
|
||||
"applied_content": "MVP阶段实现量表名称识别，Phase 2实现评分结果提取",
|
||||
"reason": "领域专家接受AI专家的分层实现建议"
|
||||
}
|
||||
],
|
||||
"modified_items": [
|
||||
{
|
||||
"source_expert": "开发专家",
|
||||
"item_type": "suggestion",
|
||||
"item_index": 0,
|
||||
"severity": "medium",
|
||||
"original": "建议增加技术选型章节：明确开发语言（Python推荐）、Agent框架等核心技术决策",
|
||||
"modified": "建议在需求文档中明确技术约束（知识图谱存储能力、并行任务调度、实时进度反馈、医学术语标准化组件），具体技术选型留待技术设计阶段",
|
||||
"modifier": "产品经理+领域专家",
|
||||
"reason": "产品经理指出需求文档应保持技术中立，领域专家补充了医学术语标准化组件的必要性"
|
||||
},
|
||||
{
|
||||
"source_expert": "开发专家",
|
||||
"item_type": "issue",
|
||||
"item_index": 5,
|
||||
"severity": "medium",
|
||||
"original": "证据等级评估的实现复杂度被低估，建议结合文献元数据进行规则化判断",
|
||||
"modified": "采用分层策略：Phase 1做研究类型分类+规则化信息提取，Phase 2引入偏倚风险初筛；采用Cochrane偏倚风险评估工具框架，AI任务定位为信息提取而非判断",
|
||||
"modifier": "AI专家+领域专家",
|
||||
"reason": "AI专家和领域专家均指出完整GRADE评估超出AI能力边界，但研究类型分类是核心功能不可放弃"
|
||||
},
|
||||
{
|
||||
"source_expert": "开发专家",
|
||||
"item_type": "suggestion",
|
||||
"item_index": 2,
|
||||
"severity": "medium",
|
||||
"original": "建议细化MVP验收标准：增加定量指标如'引用准确率>=95%'、'去重准确率>=90%'",
|
||||
"modified": "分层定义验收指标：引用来源可追溯率=100%（刚性约束），引用格式准确率>=95%，去重准确率>=90%",
|
||||
"modifier": "AI专家",
|
||||
"reason": "AI专家提出将可追溯性与格式准确性分开定义更精准"
|
||||
},
|
||||
{
|
||||
"source_expert": "开发专家",
|
||||
"item_type": "tech_risk",
|
||||
"item_index": 1,
|
||||
"severity": "high",
|
||||
"original": "知识图谱去重准确性风险：分层去重方案",
|
||||
"modified": "分层去重：先DOI/PMID精确匹配，再UMLS/MeSH CUI映射实现跨语言术语对齐，最后标题相似度匹配；对无法匹配的实体采用保守策略",
|
||||
"modifier": "AI专家+领域专家",
|
||||
"reason": "两位专家均指出现有标准术语库可有效支持跨语言术语对齐"
|
||||
},
|
||||
{
|
||||
"source_expert": "产品经理",
|
||||
"item_type": "suggestion",
|
||||
"item_index": 2,
|
||||
"severity": "low",
|
||||
"original": "建议细化用户故事",
|
||||
"modified": "建议在验收标准部分增加基于用户视角的测试用例描述",
|
||||
"modifier": "开发专家",
|
||||
"reason": "开发专家指出当前场景描述已足够详细"
|
||||
},
|
||||
{
|
||||
"source_expert": "产品经理",
|
||||
"item_type": "issue",
|
||||
"item_index": 4,
|
||||
"severity": "medium",
|
||||
"original": "报告输出形式单一",
|
||||
"modified": "MVP阶段输出Markdown格式，Phase 2增加直接导出Word/PDF功能，英文报告作为后续版本考虑",
|
||||
"modifier": "开发专家+AI专家",
|
||||
"reason": "开发专家和AI专家均指出应分阶段实现"
|
||||
},
|
||||
{
|
||||
"source_expert": "产品经理",
|
||||
"item_type": "user_experience_concern",
|
||||
"item_index": 1,
|
||||
"severity": "medium",
|
||||
"original": "报告质量的可信度建立：显示证据强度评分",
|
||||
"modified": "显示研究类型分布（如包含3项RCT、5项队列研究等）替代AI直接评分，展示文献筛选逻辑",
|
||||
"modifier": "AI专家",
|
||||
"reason": "AI专家指出证据强度评分可能给用户造成虚假的专业感"
|
||||
},
|
||||
{
|
||||
"source_expert": "产品经理",
|
||||
"item_type": "issue",
|
||||
"item_index": 2,
|
||||
"severity": "high",
|
||||
"original": "缺少关键使用场景：医学生临床问题查证场景等",
|
||||
"modified": "MVP阶段聚焦学术研究场景，临床决策支持场景（诊断鉴别、治疗方案选择等）作为Phase 2扩展",
|
||||
"modifier": "领域专家",
|
||||
"reason": "领域专家指出临床决策支持与学术研究有本质区别，需差异化设计"
|
||||
},
|
||||
{
|
||||
"source_expert": "产品经理",
|
||||
"item_type": "user_experience_concern",
|
||||
"item_index": 2,
|
||||
"severity": "low",
|
||||
"original": "专业术语理解门槛：根据用户角色调整报告语言复杂度",
|
||||
"modified": "采用保持专业术语+增加解释注释的方式，不直接简化术语以避免损失专业精确性",
|
||||
"modifier": "领域专家",
|
||||
"reason": "领域专家指出精神科术语简化可能导致专业准确性损失"
|
||||
},
|
||||
{
|
||||
"source_expert": "AI专家",
|
||||
"item_type": "suggestion",
|
||||
"item_index": 0,
|
||||
"severity": "medium",
|
||||
"original": "增加引用验证Agent角色",
|
||||
"modified": "通过架构设计防范引用幻觉：结构化输出+ID校验，作为报告生成Agent的内置功能",
|
||||
"modifier": "开发专家",
|
||||
"reason": "开发专家指出独立Agent过度设计，架构约束即可解决"
|
||||
},
|
||||
{
|
||||
"source_expert": "AI专家",
|
||||
"item_type": "suggestion",
|
||||
"item_index": 3,
|
||||
"severity": "medium",
|
||||
"original": "MVP阶段先实现用户对搜索策略的确认功能",
|
||||
"modified": "提供搜索策略确认的可选功能：默认自动执行，高级用户可开启策略预览，结果页面提供调整后重新生成入口",
|
||||
"modifier": "产品经理",
|
||||
"reason": "产品经理指出强制确认会打断用户流程，采用可选模式"
|
||||
},
|
||||
{
|
||||
"source_expert": "AI专家",
|
||||
"item_type": "suggestion",
|
||||
"item_index": 5,
|
||||
"severity": "low",
|
||||
"original": "明确定义单次任务的文献处理上限（如50篇）",
|
||||
"modified": "采用分层处理策略（粗筛200篇+精读50-80篇）+动态配置，而非固定数值",
|
||||
"modifier": "开发专家+产品经理",
|
||||
"reason": "开发专家指出50篇过于保守，产品经理建议用户可选范围"
|
||||
},
|
||||
{
|
||||
"source_expert": "AI专家",
|
||||
"item_type": "issue",
|
||||
"item_index": 2,
|
||||
"severity": "high",
|
||||
"original": "知识图谱的实体语义去重能力要求过高",
|
||||
"modified": "跨语言术语对齐可通过整合现有标准术语库（ICD-11、UMLS、MeSH）实现，技术难度低于从零构建",
|
||||
"modifier": "领域专家",
|
||||
"reason": "领域专家指出现有医学术语标准化资源成熟度被低估"
|
||||
},
|
||||
{
|
||||
"source_expert": "AI专家",
|
||||
"item_type": "ai_risk",
|
||||
"item_index": 1,
|
||||
"severity": "high",
|
||||
"original": "证据等级评估不可靠风险，建议MVP阶段简化为研究类型分类",
|
||||
"modified": "采用Cochrane偏倚风险评估工具框架，AI任务定位为从文献中提取信息填充清单，基于清单结果进行规则化判断",
|
||||
"modifier": "领域专家",
|
||||
"reason": "领域专家提供了现有评估框架可转化为结构化检查清单的方案"
|
||||
},
|
||||
{
|
||||
"source_expert": "领域专家",
|
||||
"item_type": "issue",
|
||||
"item_index": 0,
|
||||
"severity": "high",
|
||||
"original": "缺少诊断标准版本标注功能，自动识别并标注每篇文献的诊断标准版本",
|
||||
"modified": "MVP阶段增加诊断标准注意事项提醒章节+关键词识别，Phase 2尝试自动识别",
|
||||
"modifier": "开发专家+产品经理",
|
||||
"reason": "开发专家指出自动识别技术实现有挑战，应分阶段实现"
|
||||
},
|
||||
{
|
||||
"source_expert": "领域专家",
|
||||
"item_type": "issue",
|
||||
"item_index": 1,
|
||||
"severity": "high",
|
||||
"original": "证据等级评估方法未明确，建议建立自动识别和分级逻辑",
|
||||
"modified": "MVP阶段实现研究类型分类，Phase 2尝试偏倚风险初筛，完整GRADE评估定位为人工任务",
|
||||
"modifier": "AI专家",
|
||||
"reason": "AI专家指出GRADE完整评估超出AI可靠能力边界"
|
||||
},
|
||||
{
|
||||
"source_expert": "领域专家",
|
||||
"item_type": "issue",
|
||||
"item_index": 2,
|
||||
"severity": "high",
|
||||
"original": "未涵盖临床试验注册库",
|
||||
"modified": "ClinicalTrials.gov列入Phase 2扩展数据源，WHO ICTRP根据技术条件评估后决定",
|
||||
"modifier": "开发专家+产品经理",
|
||||
"reason": "开发专家指出WHO ICTRP缺乏稳定公开API，产品经理建议控制MVP范围"
|
||||
},
|
||||
{
|
||||
"source_expert": "领域专家",
|
||||
"item_type": "suggestion",
|
||||
"item_index": 7,
|
||||
"severity": "medium",
|
||||
"original": "MVP阶段也应包含诊断标准版本标注和基本的证据等级评估",
|
||||
"modified": "MVP阶段实现诊断标准关键词识别+研究类型分类，标注为AI初步分类，完整循证医学评估功能在Phase 2完善",
|
||||
"modifier": "开发专家+产品经理+AI专家",
|
||||
"reason": "多位专家指出原建议对MVP范围定义过于激进"
|
||||
},
|
||||
{
|
||||
"source_expert": "AI专家",
|
||||
"item_type": "suggestion",
|
||||
"item_index": 1,
|
||||
"severity": "high",
|
||||
"original": "将证据等级评估任务降级为研究类型分类",
|
||||
"modified": "保留证据等级评估功能，采用结构化规则评估方式：基于研究类型、样本量、盲法等客观元数据进行规则化判断，标注AI局限性",
|
||||
"modifier": "开发专家+产品经理+领域专家",
|
||||
"reason": "三位专家均指出完全降级会损害产品核心价值"
|
||||
}
|
||||
],
|
||||
"rejected_items": [
|
||||
{
|
||||
"source_expert": "开发专家",
|
||||
"item_type": "issue",
|
||||
"item_index": 1,
|
||||
"severity": "high",
|
||||
"description": "知识图谱技术选型和存储方案未明确",
|
||||
"status": "rejected",
|
||||
"reason": "属于技术设计阶段内容，需求文档应保持技术中立"
|
||||
},
|
||||
{
|
||||
"source_expert": "开发专家",
|
||||
"item_type": "issue",
|
||||
"item_index": 3,
|
||||
"severity": "medium",
|
||||
"description": "Agent通信机制未定义",
|
||||
"status": "rejected",
|
||||
"reason": "属于技术设计阶段内容，需求文档应保持技术中立"
|
||||
},
|
||||
{
|
||||
"source_expert": "开发专家",
|
||||
"item_type": "missing_item",
|
||||
"item_index": 0,
|
||||
"severity": "medium",
|
||||
"description": "缺少技术栈选型说明",
|
||||
"status": "rejected",
|
||||
"reason": "属于技术设计阶段内容"
|
||||
},
|
||||
{
|
||||
"source_expert": "开发专家",
|
||||
"item_type": "missing_item",
|
||||
"item_index": 1,
|
||||
"severity": "medium",
|
||||
"description": "缺少LLM模型选型和调用方式",
|
||||
"status": "rejected",
|
||||
"reason": "属于技术设计阶段内容"
|
||||
},
|
||||
{
|
||||
"source_expert": "开发专家",
|
||||
"item_type": "missing_item",
|
||||
"item_index": 5,
|
||||
"severity": "low",
|
||||
"description": "缺少监控和日志方案",
|
||||
"status": "rejected",
|
||||
"reason": "属于技术设计阶段内容"
|
||||
},
|
||||
{
|
||||
"source_expert": "产品经理",
|
||||
"item_type": "missing_item",
|
||||
"item_index": 0,
|
||||
"severity": "low",
|
||||
"description": "竞品分析",
|
||||
"status": "rejected",
|
||||
"reason": "属于产品规划阶段内容，非需求文档范畴"
|
||||
},
|
||||
{
|
||||
"source_expert": "产品经理",
|
||||
"item_type": "missing_item",
|
||||
"item_index": 1,
|
||||
"severity": "low",
|
||||
"description": "用户旅程地图",
|
||||
"status": "rejected",
|
||||
"reason": "当前场景描述已足够详细"
|
||||
},
|
||||
{
|
||||
"source_expert": "产品经理",
|
||||
"item_type": "missing_item",
|
||||
"item_index": 5,
|
||||
"severity": "low",
|
||||
"description": "数据导出与集成（Zotero、EndNote等）",
|
||||
"status": "rejected",
|
||||
"reason": "超出用户原始需求范围，可作为后续版本考虑"
|
||||
},
|
||||
{
|
||||
"source_expert": "领域专家",
|
||||
"item_type": "issue",
|
||||
"item_index": 4,
|
||||
"severity": "medium",
|
||||
"description": "未区分药物治疗与非药物治疗的文献分析逻辑",
|
||||
"status": "rejected",
|
||||
"reason": "过于细化的领域逻辑，可在技术设计阶段考虑"
|
||||
},
|
||||
{
|
||||
"source_expert": "领域专家",
|
||||
"item_type": "issue",
|
||||
"item_index": 6,
|
||||
"severity": "medium",
|
||||
"description": "未提及临床实践指南的整合",
|
||||
"status": "rejected",
|
||||
"reason": "超出用户原始需求范围，指南整合复杂度高，可作为后续版本考虑"
|
||||
}
|
||||
],
|
||||
"withdrawn_items": [
|
||||
{
|
||||
"source_expert": "产品经理",
|
||||
"item_type": "missing_item",
|
||||
"item_index": 4,
|
||||
"description": "移动端适配",
|
||||
"withdrawn_by": "产品经理",
|
||||
"reason": "开发专家指出目标用户的核心使用场景是桌面端长时间研究工作，移动端投入产出比低"
|
||||
}
|
||||
],
|
||||
"conflict_resolutions": [
|
||||
{
|
||||
"topic": "证据等级评估功能范围",
|
||||
"conflicting_parties": ["AI专家（建议降级为研究类型分类）", "领域专家（坚持证据等级是核心价值）", "产品经理（强调用户核心需求）"],
|
||||
"resolution": "保留证据等级评估功能，但采用结构化规则评估方式降低AI风险",
|
||||
"reason": "按用户价值优先原则裁决，证据等级评估是用户明确需求，但采纳AI专家关于风险控制的建议"
|
||||
},
|
||||
{
|
||||
"topic": "MVP阶段专业功能范围",
|
||||
"conflicting_parties": ["领域专家（要求诊断标准自动识别+完整证据评估）", "开发专家+产品经理（控制MVP范围）"],
|
||||
"resolution": "MVP阶段实现诊断标准关键词识别+研究类型分类，完整功能留待Phase 2",
|
||||
"reason": "按技术可行性优先原则裁决，同时保留核心专业价值"
|
||||
},
|
||||
{
|
||||
"topic": "引用幻觉防范机制",
|
||||
"conflicting_parties": ["AI专家（建议增加引用验证Agent）", "开发专家（架构设计即可解决）"],
|
||||
"resolution": "采用开发专家方案：结构化输出+ID校验作为报告生成Agent内置功能",
|
||||
"reason": "按技术可行性优先原则裁决，更简洁的架构方案同样有效"
|
||||
},
|
||||
{
|
||||
"topic": "文献处理数量上限",
|
||||
"conflicting_parties": ["AI专家（建议50篇固定上限）", "开发专家+产品经理（动态配置+分层处理）"],
|
||||
"resolution": "采用分层处理策略：粗筛200篇+精读50-80篇，上限动态可配置",
|
||||
"reason": "按技术可行性优先原则裁决，分层策略更符合实际工程需求"
|
||||
}
|
||||
],
|
||||
"key_improvements_summary": [
|
||||
"明确了外部数据源的授权方式和优先级，MVP阶段聚焦免费开放API数据源",
|
||||
"增加了术语规范化处理能力（基于DSM-5/ICD-11/MeSH/UMLS）",
|
||||
"细化了验收标准：引用来源可追溯率100%（刚性约束），引用格式准确率>=95%，去重准确率>=90%",
|
||||
"建立了分层文献处理策略（粗筛200篇+精读50-80篇）",
|
||||
"增加了引用幻觉防范机制（结构化输出+ID校验）",
|
||||
"明确了证据等级评估的分阶段实现路径（MVP研究类型分类，Phase 2偏倚风险初筛）",
|
||||
"增加了进度反馈机制的具体描述（预估完成时间、后台执行+通知）",
|
||||
"增加了精神科专业功能（量表名称识别、诊断标准关键词识别、方法学注意事项章节）",
|
||||
"增加了预印本来源的风险提示",
|
||||
"明确了报告透明性要求（研究类型分布、文献筛选逻辑、AI局限性说明）"
|
||||
]
|
||||
}
|
||||
35
.claude/skills/requirement-generator-v1/temp/domain_role.md
Normal file
35
.claude/skills/requirement-generator-v1/temp/domain_role.md
Normal file
@ -0,0 +1,35 @@
|
||||
# 领域专家角色定义
|
||||
|
||||
## 角色名称
|
||||
精神科医生
|
||||
|
||||
## 角色身份
|
||||
你是一位资深的精神科医生，拥有15年以上精神疾病临床诊疗和学术研究经验。你将从精神科临床医生的角度评审这个深度研究助手的需求文档，确保它符合精神医学的专业标准和临床实际需求。
|
||||
|
||||
## 领域背景
|
||||
精神疾病领域涉及精神分裂症、抑郁症、双相障碍、焦虑症、PTSD等多种疾病的诊断、治疗和研究。该领域的文献研究需要：
|
||||
- 涵盖临床试验、流行病学、病因学、治疗方法等多个维度
|
||||
- 区分药物治疗与非药物治疗（心理治疗、物理治疗等）的研究证据
|
||||
- 关注证据等级和临床指南的更新
|
||||
- 了解DSM-5/ICD-11诊断标准的演变
|
||||
|
||||
## 该领域的专业要求
|
||||
- **诊断标准规范**：精神疾病的诊断必须遵循DSM-5或ICD-11标准，文献分析需注意诊断标准版本
|
||||
- **证据等级体系**：精神科遵循循证医学原则，RCT和系统评价/Meta分析具有最高证据等级
|
||||
- **治疗指南遵循**：需关注APA、NICE、WFSBP等权威机构发布的临床实践指南
|
||||
- **专业术语规范**：精神科术语需准确使用，如"精神分裂症"而非"精神病"、"抑郁发作"而非"抑郁"等
|
||||
- **伦理与隐私**：精神疾病研究涉及敏感患者信息，需注意研究伦理规范
|
||||
|
||||
## 评审重点
|
||||
- 需求是否符合精神科临床医生和研究者的实际工作流程？
|
||||
- 专业术语使用是否准确规范（如疾病名称、治疗方法、量表名称）？
|
||||
- 文献来源和数据库选择是否覆盖精神医学核心期刊和数据库？
|
||||
- 证据等级评估方法是否符合循证医学标准？
|
||||
- 报告结构是否满足临床和学术研究的需求？
|
||||
- 是否遗漏了精神科研究中的关键环节（如安全性数据、长期随访结果）？
|
||||
|
||||
## 评审边界
|
||||
- 关注：精神医学专业规范、临床术语准确性、研究方法学标准、文献来源权威性
|
||||
- 不关注：技术实现方案（开发专家负责）
|
||||
- 不关注：界面交互体验（产品经理负责）
|
||||
- 不关注：AI模型和算法设计（AI专家负责）
|
||||
116
.claude/skills/requirement-generator-v1/temp/evaluate_ai.json
Normal file
116
.claude/skills/requirement-generator-v1/temp/evaluate_ai.json
Normal file
@ -0,0 +1,116 @@
|
||||
{
|
||||
"expert_role": "AI专家",
|
||||
"debate_phase": "evaluate",
|
||||
|
||||
"evaluations": [
|
||||
{
|
||||
"target_expert": "开发专家",
|
||||
"target_file": "temp/review_dev.json",
|
||||
"target_item": {
|
||||
"type": "issue",
|
||||
"index": 5,
|
||||
"content": "证据等级评估的实现复杂度被低估：医学领域的证据等级评估（如GRADE标准）需要专业知识和结构化判断，仅依靠LLM分析可能准确性不足"
|
||||
},
|
||||
"stance": "partial",
|
||||
"comment": "开发专家的技术实现视角正确，但建议方案'结合文献元数据进行规则化判断'过于乐观。当前LLM对证据等级评估的可靠性问题不仅是实现复杂度问题，更是AI能力边界问题。元数据（研究类型、样本量）仅能支持粗粒度分类，无法实现真正的GRADE评估（需理解偏倚风险、结果一致性、精确性等）。",
|
||||
"reasoning": "从AI能力视角，证据等级评估涉及多维度专业判断（研究设计识别、偏倚评估、证据一致性分析），当前LLM在此类任务上的准确率缺乏可靠基准。建议将此任务定位为'AI辅助的研究类型分类'而非'证据等级评估'，降低用户预期和误用风险。"
|
||||
},
|
||||
{
|
||||
"target_expert": "开发专家",
|
||||
"target_file": "temp/review_dev.json",
|
||||
"target_item": {
|
||||
"type": "suggestion",
|
||||
"index": 2,
|
||||
"content": "建议细化MVP验收标准：当前验收标准偏定性，建议增加定量指标如'引用准确率>=95%'、'去重准确率>=90%'"
|
||||
},
|
||||
"stance": "partial",
|
||||
"comment": "定量指标方向正确，但95%引用准确率的可行性需要验证。当前LLM在学术引用任务上的幻觉率报告差异较大（3%-15%），95%准确率对应5%错误率，处于较乐观水平。",
|
||||
"reasoning": "建议分层设定：(1)引用来源可追溯率100%（所有引用必须来自搜索返回结果，禁止AI自行生成）；(2)引用格式准确率>=95%（DOI、作者、标题等信息与原始数据一致）。将'可追溯性'与'格式准确性'分开定义，前者是刚性约束，后者允许容错。"
|
||||
},
|
||||
{
|
||||
"target_expert": "开发专家",
|
||||
"target_file": "temp/review_dev.json",
|
||||
"target_item": {
|
||||
"type": "tech_risk",
|
||||
"index": 1,
|
||||
"content": "知识图谱去重准确性风险：'语义去重'依赖NLP/向量匹配，可能出现误判（重复未识别或错误合并），影响报告质量"
|
||||
},
|
||||
"stance": "partial",
|
||||
"comment": "风险识别准确，但缓解措施'分层去重'未充分考虑跨语言场景。中英文医学术语的语义对齐（如'精神分裂症'与'Schizophrenia'）不能仅靠向量相似度，需要依赖标准术语库。",
|
||||
"reasoning": "从AI能力视角，跨语言语义对齐是NLP领域的已知难题。向量相似度在跨语言场景下效果显著下降。建议缓解措施增加：(1)优先使用UMLS/MeSH的CUI映射实现术语对齐；(2)对无法通过术语库匹配的实体，采用保守策略（不合并，保留两者）；(3)定义跨语言去重的单独准确率指标。"
|
||||
},
|
||||
{
|
||||
"target_expert": "产品经理",
|
||||
"target_file": "temp/review_pm.json",
|
||||
"target_item": {
|
||||
"type": "user_experience_concern",
|
||||
"index": 1,
|
||||
"content": "报告质量的可信度建立：用户如何判断AI生成报告的准确性和完整性"
|
||||
},
|
||||
"stance": "partial",
|
||||
"comment": "产品经理从用户体验角度提出的建议'每条结论标注证据来源链接'方向正确，但'显示文献覆盖率和证据强度评分'需要谨慎。",
|
||||
"reasoning": "从AI能力视角，'证据强度评分'涉及专业判断，AI评分可能给用户造成'虚假的专业感'。建议：(1)证据来源链接必须实现；(2)文献覆盖率需明确定义（相对于什么总量？）；(3)'证据强度评分'不宜由AI直接给出数值，可改为'研究类型分布'（如：包含3项RCT、5项队列研究等），让用户自行判断。"
|
||||
},
|
||||
{
|
||||
"target_expert": "产品经理",
|
||||
"target_file": "temp/review_pm.json",
|
||||
"target_item": {
|
||||
"type": "issue",
|
||||
"index": 4,
|
||||
"content": "报告输出形式单一：仅支持结构化中文报告，未考虑用户对不同格式和深度的需求"
|
||||
},
|
||||
"stance": "partial",
|
||||
"comment": "建议'报告详略程度可选（摘要版/标准版/详细版）'从产品角度合理，但从AI能力角度需要注意：不同详略程度需要不同的生成策略，不是简单的截取或扩展。",
|
||||
"reasoning": "摘要版需要高质量的信息压缩能力（保留关键信息、去除冗余），详细版需要更多的推理和综合能力。建议：(1)MVP阶段仅提供标准版，降低复杂度；(2)如需多版本，应分别定义质量标准和验收指标；(3)不同版本的生成应视为不同的AI任务，而非后处理。"
|
||||
},
|
||||
{
|
||||
"target_expert": "领域专家",
|
||||
"target_file": "temp/review_domain.json",
|
||||
"target_item": {
|
||||
"type": "issue",
|
||||
"index": 1,
|
||||
"content": "证据等级评估方法未明确：精神科遵循循证医学原则，需要明确采用何种证据分级体系（如GRADE、Oxford证据等级），以及如何处理不同研究设计的证据权重"
|
||||
},
|
||||
"stance": "partial",
|
||||
"comment": "领域专家要求明确证据分级体系的方向正确，但建议'建立研究设计类型的自动识别和分级逻辑'对AI能力预期过高。",
|
||||
"reasoning": "从AI能力视角，GRADE评估需要判断偏倚风险、不一致性、间接性、不精确性、发表偏倚五个维度，这需要深度理解研究方法学。当前LLM在此任务上的可靠性未经大规模验证。建议采用分层策略：(1)Phase 1仅做研究类型分类（RCT/观察性研究/病例报告等）；(2)Phase 2引入偏倚风险初筛（基于规则+AI辅助）；(3)GRADE完整评估定位为人工任务，AI仅提供辅助信息。"
|
||||
},
|
||||
{
|
||||
"target_expert": "领域专家",
|
||||
"target_file": "temp/review_domain.json",
|
||||
"target_item": {
|
||||
"type": "suggestion",
|
||||
"index": 7,
|
||||
"content": "MVP阶段合规性建议：即使在MVP阶段，也应包含诊断标准版本标注和基本的证据等级评估，这是精神科文献分析的最低专业要求"
|
||||
},
|
||||
"stance": "disagree",
|
||||
"comment": "诊断标准版本标注可在MVP实现（从文献元数据或全文中提取关键词如'DSM-5'），但'证据等级评估'不应作为MVP的最低要求。",
|
||||
"reasoning": "从AI能力和MVP策略视角分析：(1)诊断标准版本标注是信息提取任务，AI可靠性较高，可纳入MVP；(2)证据等级评估是专业判断任务，AI可靠性存疑，错误评估可能比不评估更危险；(3)MVP核心价值是'高效文献搜索+结构化呈现'，不应因追求专业完整性而引入不可靠功能。建议MVP阶段：标注诊断标准版本+研究类型分类，明确告知用户'证据等级需人工判断'。"
|
||||
},
|
||||
{
|
||||
"target_expert": "领域专家",
|
||||
"target_file": "temp/review_domain.json",
|
||||
"target_item": {
|
||||
"type": "missing_item",
|
||||
"index": 0,
|
||||
"content": "缺少量表和评估工具识别功能：精神科研究大量使用标准化量表（如PANSS、HAM-D、MADRS等），系统应能识别和提取文献中使用的评估量表"
|
||||
},
|
||||
"stance": "partial",
|
||||
"comment": "量表识别功能需求合理，但实现复杂度需注意。从AI能力视角，量表名称提取相对简单，但量表版本识别、评分结果提取涉及更复杂的信息抽取。",
|
||||
"reasoning": "建议分层实现：(1)量表名称识别（基于预定义量表库的关键词匹配+LLM辅助）可在Phase 1实现；(2)量表评分结果提取（如'HAM-D基线评分24.5分，终点评分12.3分'）需要结构化信息抽取能力，建议放在Phase 2；(3)需定义量表识别的准确率指标（如召回率>=80%，精确率>=90%）。"
|
||||
}
|
||||
],
|
||||
|
||||
"new_insights": [
|
||||
{
|
||||
"description": "博弈中发现：多位专家都提到了证据等级评估，但对AI在此任务上的能力边界认识不一致。需要在需求文档中明确区分'AI可独立完成的任务'与'AI仅提供辅助的任务'，避免用户对AI能力形成错误预期。",
|
||||
"triggered_by": "开发专家issue[5] + 领域专家issue[1] + 领域专家suggestion[7]的综合分析"
|
||||
},
|
||||
{
|
||||
"description": "博弈中发现：开发专家关注技术实现可行性，领域专家关注专业合规性，两者在证据等级评估上的建议存在冲突——开发建议简化，领域建议必须包含。需要在需求中建立'智能化任务分级框架'，明确哪些任务AI可自动完成、哪些需人工确认、哪些仅作参考。",
|
||||
"triggered_by": "开发专家suggestion[2]与领域专家suggestion[7]的冲突分析"
|
||||
}
|
||||
],
|
||||
|
||||
"summary": "本轮评价重点关注三个方面：(1)证据等级评估的AI能力边界问题，多位专家有不同预期，需要统一认识；(2)跨语言语义去重的技术可行性，需引入标准术语库；(3)MVP范围界定，应将'可靠的基础功能'优先于'有风险的专业功能'。核心建议是在需求中建立'AI任务可靠性分级'，区分AI可独立完成、AI辅助人工确认、仅供参考三个层次。"
|
||||
}
|
||||
128
.claude/skills/requirement-generator-v1/temp/evaluate_dev.json
Normal file
128
.claude/skills/requirement-generator-v1/temp/evaluate_dev.json
Normal file
@ -0,0 +1,128 @@
|
||||
{
|
||||
"expert_role": "开发专家",
|
||||
"debate_phase": "evaluate",
|
||||
|
||||
"evaluations": [
|
||||
{
|
||||
"target_expert": "产品经理",
|
||||
"target_file": "temp/review_pm.json",
|
||||
"target_item": {
|
||||
"type": "missing_item",
|
||||
"index": 4,
|
||||
"content": "移动端适配：是否需要支持移动端访问和使用"
|
||||
},
|
||||
"stance": "disagree",
|
||||
"comment": "MVP阶段不应考虑移动端适配，技术投入产出比低",
|
||||
"reasoning": "1) 目标用户（科研人员、医学生、分析师）的核心使用场景是桌面端长时间研究工作，移动端需求弱；2) 该产品允许小时级执行时间，移动端使用场景不适合；3) 移动端适配会显著增加前端开发工作量，包括响应式布局、移动端交互优化、长连接稳定性等；4) 建议在产品PMF验证后再考虑移动端，MVP阶段应聚焦核心价值验证"
|
||||
},
|
||||
{
|
||||
"target_expert": "产品经理",
|
||||
"target_file": "temp/review_pm.json",
|
||||
"target_item": {
|
||||
"type": "suggestion",
|
||||
"index": 2,
|
||||
"content": "建议细化用户故事：将场景进一步拆解为用户故事（As a...I want...So that...），便于开发理解和验收"
|
||||
},
|
||||
"stance": "partial",
|
||||
"comment": "用户故事对开发有帮助，但当前需求文档的场景描述已足够详细",
|
||||
"reasoning": "当前文档第2.1节的场景描述已包含触发条件、操作步骤、预期结果，这些信息对于开发理解需求已经足够。用户故事格式更多是Scrum流程的形式要求，对于Agent开发这类技术复杂度高的项目，更重要的是技术方案设计文档而非用户故事卡片。建议根据团队实际情况决定是否采用。"
|
||||
},
|
||||
{
|
||||
"target_expert": "产品经理",
|
||||
"target_file": "temp/review_pm.json",
|
||||
"target_item": {
|
||||
"type": "issue",
|
||||
"index": 4,
|
||||
"content": "报告输出形式单一：仅支持结构化中文报告，未考虑用户对不同格式和深度的需求"
|
||||
},
|
||||
"stance": "partial",
|
||||
"comment": "格式多样化有价值，但需分阶段实现",
|
||||
"reasoning": "1) 支持Word/PDF输出需要集成文档生成库（如python-docx、reportlab），增加技术复杂度；2) 报告详略程度可选意味着需要设计多套报告模板和生成逻辑；3) 建议MVP阶段先用Markdown格式（用户可自行转换为Word/PDF），第二阶段再增加格式选项；4) 英文报告选项涉及全流程的语言切换，复杂度较高，可作为后续版本功能"
|
||||
},
|
||||
{
|
||||
"target_expert": "AI专家",
|
||||
"target_file": "temp/review_ai.json",
|
||||
"target_item": {
|
||||
"type": "suggestion",
|
||||
"index": 1,
|
||||
"content": "建议2：将证据等级评估任务降级为'研究类型分类'（如RCT/队列研究/病例报告等），减少AI判断的主观性和错误风险"
|
||||
},
|
||||
"stance": "disagree",
|
||||
"comment": "研究类型分类虽然简化，但可能无法满足用户核心需求",
|
||||
"reasoning": "1) 从用户访谈看，证据等级评估是循证医学的核心要求，精神科医生明确指出这是重要功能；2) 单纯的研究类型分类价值有限，用户通过检索结果就能看到研究类型；3) 技术上可行的折中方案：基于研究类型+样本量+盲法等元数据进行规则化的初步证据等级判断，而非完全依赖LLM推理；4) 建议标注'AI初评'并提供评估依据，让用户自行判断是否需要人工复核"
|
||||
},
|
||||
{
|
||||
"target_expert": "AI专家",
|
||||
"target_file": "temp/review_ai.json",
|
||||
"target_item": {
|
||||
"type": "suggestion",
|
||||
"index": 5,
|
||||
"content": "建议6：明确定义单次任务的文献处理上限（如50篇），超出时提供分批处理或用户筛选机制"
|
||||
},
|
||||
"stance": "partial",
|
||||
"comment": "文献数量上限的思路正确，但50篇可能过于保守",
|
||||
"reasoning": "1) 以GPT-4-turbo的128K上下文为例，每篇文献摘要约500-1000 tokens，理论上可处理100+篇；2) 但考虑到分析过程需要输出，建议分层处理：第一轮粗筛（相关性排序）可处理200篇，第二轮精读分析处理Top 50-80篇；3) 实际上限应根据选用的LLM模型和文献平均长度动态调整，而非硬编码固定值；4) 建议技术实现时设置可配置参数而非固定数值"
|
||||
},
|
||||
{
|
||||
"target_expert": "AI专家",
|
||||
"target_file": "temp/review_ai.json",
|
||||
"target_item": {
|
||||
"type": "ai_risk",
|
||||
"index": 0,
|
||||
"content": "引用幻觉风险：LLM在生成引用时可能编造不存在的文献（包括作者、标题、期刊、DOI等），这是当前大模型的已知弱点"
|
||||
},
|
||||
"stance": "partial",
|
||||
"comment": "幻觉风险确实存在，但建议的'引用验证Agent'可能过度设计",
|
||||
"reasoning": "1) 幻觉风险的根本解决方案是架构设计：报告生成Agent的引用必须且只能来自搜索Agent返回的文献列表，通过Prompt约束和结构化输出即可，不需要额外增加一个Agent；2) 增加引用验证Agent会增加系统复杂度和延迟；3) 更实用的方案：在报告生成Agent的输出中要求包含文献ID索引，后处理阶段直接校验ID是否在原始搜索结果中；4) 建议将此作为报告生成Agent的内置功能而非独立Agent"
|
||||
},
|
||||
{
|
||||
"target_expert": "领域专家",
|
||||
"target_file": "temp/review_domain.json",
|
||||
"target_item": {
|
||||
"type": "issue",
|
||||
"index": 0,
|
||||
"content": "缺少诊断标准版本标注功能：精神科文献分析必须注意诊断标准的演变（DSM-IV vs DSM-5, ICD-10 vs ICD-11），不同版本的诊断标准可能导致研究结果不可比"
|
||||
},
|
||||
"stance": "partial",
|
||||
"comment": "诊断标准版本标注有价值，但'自动识别'的技术实现有挑战",
|
||||
"reasoning": "1) 诊断标准版本通常不在文献摘要的结构化字段中，需要从全文或摘要文本中提取，依赖NLP/LLM判断；2) 部分文献可能未明确说明使用的诊断标准版本；3) 建议分两步实现：MVP阶段在报告中增加'诊断标准'提醒章节，提示用户关注此问题；第二阶段通过LLM分析摘要内容尝试自动识别并标注；4) 对于无法自动识别的情况，应标注'未明确'而非强行推断"
|
||||
},
|
||||
{
|
||||
"target_expert": "领域专家",
|
||||
"target_file": "temp/review_domain.json",
|
||||
"target_item": {
|
||||
"type": "issue",
|
||||
"index": 2,
|
||||
"content": "未涵盖临床试验注册库：精神科药物和治疗研究需要关注ClinicalTrials.gov、WHO ICTRP等临床试验注册库，这对于了解正在进行的研究和发表偏倚评估至关重要"
|
||||
},
|
||||
"stance": "partial",
|
||||
"comment": "临床试验注册库有价值，但API可用性和数据结构需要评估",
|
||||
"reasoning": "1) ClinicalTrials.gov提供公开API（clinicaltrials.gov/api），技术上可接入；2) 但临床试验数据的结构与文献数据差异大（试验状态、招募情况、预期完成时间等），需要单独设计数据模型和展示方式；3) WHO ICTRP没有稳定的公开API，需要通过网页抓取，合规性和稳定性存疑；4) 建议：MVP阶段仅整合ClinicalTrials.gov，作为'相关在研试验'补充章节；WHO ICTRP作为第二阶段考虑"
|
||||
},
|
||||
{
|
||||
"target_expert": "领域专家",
|
||||
"target_file": "temp/review_domain.json",
|
||||
"target_item": {
|
||||
"type": "suggestion",
|
||||
"index": 7,
|
||||
"content": "MVP阶段合规性建议：即使在MVP阶段，也应包含诊断标准版本标注和基本的证据等级评估，这是精神科文献分析的最低专业要求"
|
||||
},
|
||||
"stance": "partial",
|
||||
"comment": "认同专业性要求，但MVP阶段的实现深度需要权衡",
|
||||
"reasoning": "1) MVP阶段的核心目标是验证'多数据源并行搜索+结构化报告生成'的核心价值，过多专业功能会增加开发周期；2) 折中方案：MVP阶段在报告中增加'研究方法学注意事项'章节，以文字提醒形式涵盖诊断标准差异、证据等级解读等内容，而非实现自动化识别；3) 证据等级评估可先实现基于研究类型的简化版本（如Meta分析>RCT>队列研究>病例报告），第二阶段再完善为GRADE标准；4) 这样既体现了专业性考量，又控制了MVP阶段的技术复杂度"
|
||||
}
|
||||
],
|
||||
|
||||
"new_insights": [
|
||||
{
|
||||
"description": "知识图谱Schema设计需要考虑精神科领域特殊字段",
|
||||
"triggered_by": "领域专家提出的诊断标准版本、评估量表、安全性数据等要求，这些都需要在知识图谱的节点和边属性中预留字段，否则第二阶段引入知识图谱时需要重新设计Schema"
|
||||
},
|
||||
{
|
||||
"description": "MVP阶段也需要基础去重能力",
|
||||
"triggered_by": "AI专家提到'MVP阶段暂不使用知识图谱，但去重需求在MVP阶段同样存在'。从技术角度看，MVP阶段应实现基于DOI/PMID的精确去重，这是低成本高收益的功能，不需要等到知识图谱引入"
|
||||
}
|
||||
],
|
||||
|
||||
"summary": "本轮交叉评价中，开发专家对其他专家的9条意见进行了回应。主要分歧集中在：1) 移动端适配时机（与产品经理分歧）；2) 证据等级评估的实现方式（与AI专家分歧，反对降级为纯研究类型分类）；3) 引用验证Agent的必要性（与AI专家分歧，建议通过架构设计而非额外Agent解决）；4) 诊断标准自动识别的可行性（与领域专家部分分歧，建议分阶段实现）。新发现的技术洞察包括知识图谱Schema需预留领域特殊字段，以及MVP阶段也应实现基础去重能力。"
|
||||
}
|
||||
@ -0,0 +1,109 @@
|
||||
{
|
||||
"expert_role": "精神科医生",
|
||||
"domain": "精神医学/精神疾病研究",
|
||||
"debate_phase": "evaluate",
|
||||
|
||||
"evaluations": [
|
||||
{
|
||||
"target_expert": "开发专家",
|
||||
"target_file": "temp/review_dev.json",
|
||||
"target_item": {
|
||||
"type": "issue",
|
||||
"index": 5,
|
||||
"content": "证据等级评估的实现复杂度被低估：医学领域的证据等级评估（如GRADE标准）需要专业知识和结构化判断，仅依靠LLM分析可能准确性不足"
|
||||
},
|
||||
"stance": "partial",
|
||||
"comment": "开发专家正确识别了证据等级评估的复杂性，但其建议'标注评估结果仅供参考，需人工复核'不够充分。在精神科临床实践中，证据等级评估不仅是技术问题，更涉及专业判断标准的选择。GRADE与Oxford证据等级体系在精神科的应用存在差异，例如对于心理治疗研究，GRADE可能需要调整标准。",
|
||||
"reasoning": "精神科循证医学实践要求明确采用何种证据分级体系，并且需要考虑精神科特有的研究设计（如对照组选择困难、盲法难以实施等）对证据等级评估的影响。建议不仅要明确标注需人工复核，更需要在系统设计中预设精神科适用的评估模板。"
|
||||
},
|
||||
{
|
||||
"target_expert": "开发专家",
|
||||
"target_file": "temp/review_dev.json",
|
||||
"target_item": {
|
||||
"type": "suggestion",
|
||||
"index": 0,
|
||||
"content": "建议增加技术选型章节：明确开发语言（Python推荐）、Agent框架（LangGraph/AutoGen/CrewAI）、知识图谱（Neo4j Community版）、消息队列（Redis）等核心技术决策"
|
||||
},
|
||||
"stance": "partial",
|
||||
"comment": "技术选型建议合理，但从精神科文献研究的角度，还需要补充医学术语标准化的技术组件。精神科术语的规范化处理（DSM-5/ICD-11术语库、MeSH/UMLS集成）应作为技术选型的必要组成部分，而非可选功能。",
|
||||
"reasoning": "精神科文献使用的诊断术语存在多种表述方式和历史演变，如果技术选型不包含术语标准化组件，将直接影响搜索召回率和知识图谱去重质量。这是精神科领域应用的刚性需求。"
|
||||
},
|
||||
{
|
||||
"target_expert": "产品经理",
|
||||
"target_file": "temp/review_pm.json",
|
||||
"target_item": {
|
||||
"type": "issue",
|
||||
"index": 2,
|
||||
"content": "缺少关键使用场景：仅覆盖'文献综述撰写'和'研究题目探索'两个场景，但目标用户群体的其他高频场景未涉及"
|
||||
},
|
||||
"stance": "partial",
|
||||
"comment": "产品经理建议补充'医学生临床问题查证场景'是有价值的，但该场景的需求应该更具体化。精神科医学生和规培医生的典型需求包括：诊断鉴别依据查询、治疗方案选择依据、药物选择与剂量调整依据、以及临床指南解读等。这些场景的输出格式和证据要求与文献综述不同。",
|
||||
"reasoning": "精神科临床决策支持与学术研究综述有本质区别。临床场景更关注指南推荐级别、禁忌症与注意事项、药物相互作用等实用信息，而非全面的文献回顾。产品设计应区分这两类需求的差异化处理。"
|
||||
},
|
||||
{
|
||||
"target_expert": "产品经理",
|
||||
"target_file": "temp/review_pm.json",
|
||||
"target_item": {
|
||||
"type": "user_experience_concerns",
|
||||
"index": 2,
|
||||
"content": "专业术语和概念的理解门槛：不同层次用户对精神疾病领域术语的熟悉程度不同"
|
||||
},
|
||||
"stance": "partial",
|
||||
"comment": "产品经理关注不同用户的术语理解差异是正确的，但其建议'根据用户角色调整报告语言复杂度'需要谨慎实施。精神科专业术语的简化必须确保准确性，不能为了通俗性而牺牲专业精确性。例如，'精神分裂症'不能简化为'精神病'，'抑郁发作'与'抑郁症'有明确的临床区别。",
|
||||
"reasoning": "精神科术语的规范使用涉及诊断准确性和临床安全。建议采用'保持专业术语+增加解释注释'的方式，而非直接简化术语。这样既满足初级用户的理解需求，又不损失专业准确性。"
|
||||
},
|
||||
{
|
||||
"target_expert": "AI专家",
|
||||
"target_file": "temp/review_ai.json",
|
||||
"target_item": {
|
||||
"type": "suggestion",
|
||||
"index": 1,
|
||||
"content": "将证据等级评估任务降级为'研究类型分类'（如RCT/队列研究/病例报告等），减少AI判断的主观性和错误风险"
|
||||
},
|
||||
"stance": "disagree",
|
||||
"comment": "作为精神科医生，我不同意将证据等级评估完全降级为研究类型分类。对于精神科临床研究者和医学生而言，证据等级评估是文献分析的核心价值所在。仅提供研究类型分类而不评估证据强度，将大幅降低系统对目标用户的实际帮助。",
|
||||
"reasoning": "精神科临床决策高度依赖循证医学原则，医生需要知道'这项治疗的证据强度是什么'而不仅仅是'这是一项RCT'。建议的替代方案是：采用结构化评估模板（如根据样本量、随机化方法、盲法、失访率等客观指标），并明确标注AI评估的局限性，而非放弃证据等级评估功能。"
|
||||
},
|
||||
{
|
||||
"target_expert": "AI专家",
|
||||
"target_file": "temp/review_ai.json",
|
||||
"target_item": {
|
||||
"type": "issue",
|
||||
"index": 2,
|
||||
"content": "知识图谱的'实体语义去重'能力要求过高。跨语言（中英文）、跨数据源的医学实体语义相似度判断（如判断'精神分裂症'与'Schizophrenia'为同一实体）需要强大的领域知识和对齐能力"
|
||||
},
|
||||
"stance": "partial",
|
||||
"comment": "AI专家正确识别了跨语言术语对齐的挑战，但低估了精神科领域术语标准化的现有资源。WHO的ICD-11已提供多语言官方术语对照，NLM的UMLS也包含大量精神科术语的跨语言映射。建议不是从零构建语义匹配能力，而是充分利用这些现有标准术语库。",
|
||||
"reasoning": "精神科领域有成熟的国际术语标准体系（ICD-11、DSM-5的官方翻译、MeSH主题词表），核心术语的跨语言对齐可以通过整合这些标准资源解决，而非完全依赖AI语义判断。这大大降低了技术实现难度。"
|
||||
},
|
||||
{
|
||||
"target_expert": "AI专家",
|
||||
"target_file": "temp/review_ai.json",
|
||||
"target_item": {
|
||||
"type": "ai_risks",
|
||||
"index": 1,
|
||||
"content": "证据等级评估不可靠风险：证据等级评估需要理解研究设计细节（如随机化方法、盲法、样本量计算等），LLM可能给出看似合理但实际错误的评估"
|
||||
},
|
||||
"stance": "partial",
|
||||
"comment": "AI专家对风险的识别是准确的，但其缓解建议'MVP阶段可考虑简化为研究类型分类'过于保守。精神科领域的循证医学实践已经发展出相对标准化的评估框架，可以将其转化为结构化评估规则，降低AI主观判断的依赖。",
|
||||
"reasoning": "例如，Cochrane偏倚风险评估工具已有明确的评估维度和标准，可以将这些标准转化为系统可执行的检查清单。AI的任务变成'从文献中提取相关信息填充清单'而非'直接判断证据等级'，这样既保留了证据评估功能，又降低了AI错误风险。"
|
||||
}
|
||||
],
|
||||
|
||||
"new_insights": [
|
||||
{
|
||||
"description": "需要区分'临床决策支持'与'学术研究综述'两类不同需求的差异化处理策略",
|
||||
"triggered_by": "产品经理关于补充医学生临床问题查证场景的建议"
|
||||
},
|
||||
{
|
||||
"description": "证据等级评估可采用'结构化信息提取+规则化评分'模式替代完全的AI主观判断，兼顾功能价值与可靠性",
|
||||
"triggered_by": "AI专家建议将证据等级评估降级为研究类型分类的观点"
|
||||
},
|
||||
{
|
||||
"description": "精神科标准术语库（ICD-11、MeSH、UMLS）应作为技术架构的基础组件纳入，而非可选功能",
|
||||
"triggered_by": "开发专家关于技术选型的建议未提及医学术语标准化组件"
|
||||
}
|
||||
],
|
||||
|
||||
"summary": "本轮交叉评价中，我从精神医学专业视角对其他专家的7条观点进行了评价。主要争议点集中在：(1)证据等级评估功能的保留与实现方式——AI专家建议降级为研究类型分类，我认为应采用结构化评估模板保留此核心功能；(2)技术选型需补充医学术语标准化组件作为刚性需求；(3)临床决策支持场景与学术研究场景需要差异化设计；(4)精神科术语的通俗化处理需保持专业准确性。同时，我肯定了开发专家对证据评估复杂性的识别、产品经理对用户分层的关注。"
|
||||
}
|
||||
132
.claude/skills/requirement-generator-v1/temp/evaluate_pm.json
Normal file
132
.claude/skills/requirement-generator-v1/temp/evaluate_pm.json
Normal file
@ -0,0 +1,132 @@
|
||||
{
|
||||
"expert_role": "产品经理",
|
||||
"debate_phase": "evaluate",
|
||||
|
||||
"evaluations": [
|
||||
{
|
||||
"target_expert": "开发专家",
|
||||
"target_file": "temp/review_dev.json",
|
||||
"target_item": {
|
||||
"type": "suggestion",
|
||||
"index": 0,
|
||||
"content": "建议增加技术选型章节：明确开发语言（Python推荐）、Agent框架（LangGraph/AutoGen/CrewAI）、知识图谱（Neo4j Community版）、消息队列（Redis）等核心技术决策"
|
||||
},
|
||||
"stance": "partial",
|
||||
"comment": "同意需要技术选型，但需求文档应保持技术中立，具体技术选型应在设计文档中明确",
|
||||
"reasoning": "需求文档的职责是定义'做什么'而非'怎么做'。过早在需求文档中指定具体技术（如Neo4j、Redis）会限制技术团队的选型空间，也可能让非技术背景的用户感到困惑。建议在需求文档中仅说明技术约束（如需要知识图谱存储能力），具体选型留给技术设计阶段。"
|
||||
},
|
||||
{
|
||||
"target_expert": "开发专家",
|
||||
"target_file": "temp/review_dev.json",
|
||||
"target_item": {
|
||||
"type": "issue",
|
||||
"index": 0,
|
||||
"content": "外部数据源API访问可行性未验证：PsycINFO、Embase、Cochrane Library等商业数据库需要机构订阅和API授权...个人/小团队难以获得合法稳定的API访问权限"
|
||||
},
|
||||
"stance": "partial",
|
||||
"comment": "问题指出正确，但建议的解决方案需考虑用户价值",
|
||||
"reasoning": "开发专家建议MVP阶段仅使用PubMed，这从技术可行性角度合理，但从用户价值角度看，PsycINFO是精神科文献的核心数据库，缺失会显著降低产品价值。建议：(1) 在需求文档中明确标注各数据源的获取难度；(2) 探索用户自带机构账号的模式；(3) 与用户确认数据源优先级，而非开发团队单方面砍掉。访谈结果显示用户明确需要多数据源覆盖，这是核心价值主张。"
|
||||
},
|
||||
{
|
||||
"target_expert": "AI专家",
|
||||
"target_file": "temp/review_ai.json",
|
||||
"target_item": {
|
||||
"type": "suggestion",
|
||||
"index": 1,
|
||||
"content": "将证据等级评估任务降级为'研究类型分类'（如RCT/队列研究/病例报告等），减少AI判断的主观性和错误风险"
|
||||
},
|
||||
"stance": "disagree",
|
||||
"comment": "该建议与用户核心需求冲突，不建议采纳",
|
||||
"reasoning": "用户访谈明确表达了对'证据等级评估'的需求，这是循证医学研究的核心能力，也是产品差异化的关键点。如果降级为'研究类型分类'，产品价值将大打折扣，用户自己分类也很容易做到。建议采取折中方案：(1) 提供证据等级评估但标注'AI初评，建议专业复核'；(2) 提供评估依据的透明说明；(3) 分阶段提升评估准确性。不能因为技术有挑战就放弃核心功能。"
|
||||
},
|
||||
{
|
||||
"target_expert": "AI专家",
|
||||
"target_file": "temp/review_ai.json",
|
||||
"target_item": {
|
||||
"type": "suggestion",
|
||||
"index": 5,
|
||||
"content": "明确定义单次任务的文献处理上限（如50篇），超出时提供分批处理或用户筛选机制"
|
||||
},
|
||||
"stance": "partial",
|
||||
"comment": "同意需要上限机制，但50篇可能过于保守",
|
||||
"reasoning": "从用户角度看，一个全面的文献综述可能涉及100+篇文献，人为限制50篇可能无法满足用户需求。建议：(1) 与用户确认典型场景下的文献数量预期；(2) 采用'核心+扩展'模式，确保核心文献完整分析，扩展文献摘要分析；(3) 让用户自行决定处理范围而非系统硬性限制。技术限制不应成为产品设计的主导因素。"
|
||||
},
|
||||
{
|
||||
"target_expert": "AI专家",
|
||||
"target_file": "temp/review_ai.json",
|
||||
"target_item": {
|
||||
"type": "suggestion",
|
||||
"index": 3,
|
||||
"content": "MVP阶段建议先实现用户对搜索策略的确认和调整功能，确保检索方向正确后再进行分析"
|
||||
},
|
||||
"stance": "partial",
|
||||
"comment": "建议方向正确，但需权衡用户体验",
|
||||
"reasoning": "增加'搜索策略确认'步骤会打断用户的使用流程，增加交互复杂度。对于'提高效率'这一核心目标有所削弱。建议采取可选模式：(1) 默认自动执行，快速出结果；(2) 高级用户可开启'策略确认'模式；(3) 在结果页面提供'调整搜索范围后重新生成'的入口。避免过度设计导致使用门槛提高。"
|
||||
},
|
||||
{
|
||||
"target_expert": "领域专家",
|
||||
"target_file": "temp/review_domain.json",
|
||||
"target_item": {
|
||||
"type": "issue",
|
||||
"index": 0,
|
||||
"content": "缺少诊断标准版本标注功能：精神科文献分析必须注意诊断标准的演变（DSM-IV vs DSM-5, ICD-10 vs ICD-11），不同版本的诊断标准可能导致研究结果不可比"
|
||||
},
|
||||
"stance": "partial",
|
||||
"comment": "问题指出专业且重要，但建议的实现方式需要商榷",
|
||||
"reasoning": "领域专家建议'自动识别并标注每篇文献采用的诊断标准版本'，这在技术上有相当难度，因为很多文献并未在摘要中明确说明诊断标准版本。建议分阶段实现：(1) MVP阶段在报告中增加'诊断标准差异提醒'的通用说明；(2) 后续版本尝试从文献发表年份和关键词推断可能采用的标准；(3) 对于明确提及标准版本的文献进行标注。避免承诺无法实现的功能。"
|
||||
},
|
||||
{
|
||||
"target_expert": "领域专家",
|
||||
"target_file": "temp/review_domain.json",
|
||||
"target_item": {
|
||||
"type": "suggestion",
|
||||
"index": 7,
|
||||
"content": "MVP阶段合规性建议：即使在MVP阶段，也应包含诊断标准版本标注和基本的证据等级评估，这是精神科文献分析的最低专业要求"
|
||||
},
|
||||
"stance": "disagree",
|
||||
"comment": "对MVP范围的建议过于激进，可能导致MVP阶段延期",
|
||||
"reasoning": "MVP的核心目标是验证产品的核心价值假设（多数据源搜索 + 结构化报告生成），过多的专业功能会增加MVP的复杂度和开发周期。诊断标准自动识别是一个技术难点，强制纳入MVP可能导致：(1) MVP延期交付，错过用户反馈窗口；(2) 功能实现质量不高反而损害用户信任。建议MVP阶段通过'专业提醒'而非'自动识别'方式解决，后续迭代中逐步增强。用户访谈中未将此列为最高优先级需求。"
|
||||
},
|
||||
{
|
||||
"target_expert": "领域专家",
|
||||
"target_file": "temp/review_domain.json",
|
||||
"target_item": {
|
||||
"type": "issue",
|
||||
"index": 2,
|
||||
"content": "未涵盖临床试验注册库：精神科药物和治疗研究需要关注ClinicalTrials.gov、WHO ICTRP等临床试验注册库"
|
||||
},
|
||||
"stance": "partial",
|
||||
"comment": "数据源建议有价值，但应纳入第二阶段",
|
||||
"reasoning": "临床试验注册库确实是评估发表偏倚的重要数据源，但从用户核心需求看，当前8个数据源已覆盖主要文献来源。建议：(1) 将临床试验注册库作为第二阶段扩展；(2) 当前需求文档已将Google Scholar、预印本等列为扩展数据源，可将ClinicalTrials.gov加入扩展列表；(3) MVP阶段优先确保核心数据源的稳定可用。避免数据源过多导致系统复杂度急剧增加。"
|
||||
},
|
||||
{
|
||||
"target_expert": "开发专家",
|
||||
"target_file": "temp/review_dev.json",
|
||||
"target_item": {
|
||||
"type": "tech_risk",
|
||||
"index": 2,
|
||||
"content": "LLM调用成本和延迟风险：大量文献分析需频繁调用LLM，可能产生高额API费用，且存在速率限制"
|
||||
},
|
||||
"stance": "partial",
|
||||
"comment": "成本风险需要关注，但应在需求文档中明确成本预期",
|
||||
"reasoning": "开发专家提出的成本风险是合理的，但解决方向不应是'降低分析质量'或'限制文献数量'，而是：(1) 在需求文档的非功能性需求中增加'单次任务成本上限'指标；(2) 与用户确认可接受的成本范围；(3) 将成本作为设计约束而非功能裁剪的理由。用户访谈中明确接受'小时级执行时间'，说明用户更看重质量而非速度/成本。"
|
||||
}
|
||||
],
|
||||
|
||||
"new_insights": [
|
||||
{
|
||||
"description": "需求文档缺少'成本与资源约束'章节，导致各专家从自身视角提出功能裁剪建议，缺乏统一的决策基准",
|
||||
"triggered_by": "开发专家关于LLM调用成本的担忧 + AI专家关于文献数量限制的建议"
|
||||
},
|
||||
{
|
||||
"description": "MVP范围存在争议：开发和AI专家倾向于最小化功能，领域专家要求纳入专业必需功能，需要与用户重新确认MVP的核心验收标准",
|
||||
"triggered_by": "领域专家'MVP阶段合规性建议' vs 当前MVP功能清单的差距"
|
||||
},
|
||||
{
|
||||
"description": "产品定位需要澄清：是'通用文献研究助手恰好用于精神科'还是'精神科专用文献研究助手'？这影响领域专业功能的优先级判断",
|
||||
"triggered_by": "领域专家提出的多项精神科专业需求（诊断标准、量表识别、药物安全性等）与用户访谈中'医疗精神疾病领域'定位的匹配度"
|
||||
}
|
||||
],
|
||||
|
||||
"summary": "本轮交叉评价共对其他专家提出9条评价意见。主要关注点：(1) 反对将核心功能（如证据等级评估）降级，这会损害产品核心价值；(2) 技术可行性问题应作为设计约束而非功能裁剪理由；(3) MVP范围需与用户重新确认，避免各方从自身视角定义MVP导致的范围争议；(4) 需求文档应补充成本/资源约束章节，作为功能决策的统一基准。同时发现3个需要进一步澄清的问题，建议补充到需求迭代中。"
|
||||
}
|
||||
@ -0,0 +1,112 @@
|
||||
{
|
||||
"project_info": {
|
||||
"type": "agent_dev"
|
||||
},
|
||||
"requirements": {
|
||||
"background": "开发一个面向医疗精神疾病领域的深度研究助手（DeepResearch Assistant），帮助科研人员、医学生和医疗信息分析师进行系统性文献调研。该助手能够根据用户提出的研究问题，自动执行多数据源并行搜索，对搜索到的文献进行智能分析，最终生成高质量、结构化的研究报告，确保引用准确、逻辑清晰。",
|
||||
"objectives": "1. 提高文献调研效率：将传统需要数天的文献调研工作压缩到小时级别完成\n2. 提升研究质量：确保文献覆盖全面、引用准确可追溯、分析逻辑严谨\n3. 构建长期知识库：通过知识图谱积累领域知识，支持持续研究和知识发现",
|
||||
"target_users": "1. 科研人员/学者：进行精神疾病领域的学术研究\n2. 医学生/规培医生：学习精神科知识，辅助学业\n3. 医疗信息分析师：处理大量文献数据，支持机构决策",
|
||||
"core_features": [
|
||||
"多数据源并行文献搜索：支持PubMed、PsycINFO、Embase、Cochrane Library、CNKI、万方、bioRxiv/medRxiv、Google Scholar等多个权威数据源的并行检索",
|
||||
"智能文献分析与综合：对检索到的文献进行自动摘要提取、证据等级评估、关键发现对比分析",
|
||||
"结构化研究报告生成：生成包含研究背景、核心文献分析、研究方法与证据等级、研究结论与知识空白、标准格式引用的完整报告",
|
||||
"Multi-Agent执行进度展示：实时显示当前执行步骤和进度（如并行搜索中→搜索到X篇文献→分析中→生成报告）",
|
||||
"知识图谱存储与动态更新：将搜索到的文献、概念、作者、研究时间线等信息存入知识图谱，作为长久知识库",
|
||||
"全图去重机制：实现文献ID去重、实体语义去重（识别同义词如'抑郁症'='MDD'）、关系级去重，确保知识图谱逻辑清晰无冗余",
|
||||
"基于知识图谱的推理与充分性检查：利用已有知识图谱辅助判断研究覆盖是否充分，指导报告生成"
|
||||
],
|
||||
"use_cases": [
|
||||
{
|
||||
"scenario": "文献综述撰写",
|
||||
"trigger": "用户输入研究问题，如'近5年精神分裂症认知功能障碍的非药物治疗进展'",
|
||||
"steps": [
|
||||
"1. 用户输入研究问题",
|
||||
"2. 系统展示Multi-Agent执行进度：解析问题→制定搜索策略",
|
||||
"3. 并行搜索多个数据源，实时显示'正在搜索PubMed...'、'已找到X篇文献'",
|
||||
"4. 对文献进行智能分析和综合",
|
||||
"5. 将新文献动态加入知识图谱，执行去重",
|
||||
"6. 生成结构化研究报告"
|
||||
],
|
||||
"expected_result": "获得一份包含背景概述、核心文献分析、证据等级评估、研究结论与知识空白、标准格式引用的完整中文研究报告"
|
||||
},
|
||||
{
|
||||
"scenario": "研究题目探索",
|
||||
"trigger": "用户希望了解某个新研究方向的进展和空白",
|
||||
"steps": [
|
||||
"1. 用户输入探索性问题",
|
||||
"2. 系统搜索相关文献并分析研究现状",
|
||||
"3. 识别该领域的知识空白和潜在研究方向",
|
||||
"4. 生成研究现状与机会分析报告"
|
||||
],
|
||||
"expected_result": "了解该方向的研究现状、主要发现、知识空白和潜在研究机会"
|
||||
}
|
||||
],
|
||||
"input_output": {
|
||||
"input": "用户以自然语言输入的研究问题（支持中英文提问）",
|
||||
"output": "结构化中文研究报告，包含：研究背景与现状概述、核心文献摘要与分析、研究方法与证据等级、研究结论与知识空白、标准格式文献引用列表"
|
||||
},
|
||||
"data_access": [
|
||||
"PubMed/MEDLINE（生物医学文献）",
|
||||
"PsycINFO（心理学专业数据库）",
|
||||
"Embase（欧洲文献+药物研究）",
|
||||
"Cochrane Library（循证医学/系统评价）",
|
||||
"CNKI（中国知网）",
|
||||
"万方数据",
|
||||
"bioRxiv/medRxiv（预印本）",
|
||||
"Google Scholar（综合学术搜索）"
|
||||
],
|
||||
"business_constraints": [
|
||||
"报告输出语言为中文",
|
||||
"支持中英文文献处理",
|
||||
"允许小时级执行时间以保证研究深度和全面性"
|
||||
],
|
||||
"non_functional": {
|
||||
"performance": "允许小时级执行时间，追求全面深入的研究结果而非快速响应",
|
||||
"security": "无特殊安全要求，主要处理公开学术文献",
|
||||
"scale": "个人/小团队使用（1-10人），日均查询10-50次"
|
||||
},
|
||||
"acceptance_criteria": [
|
||||
"引用文献均可查证：报告中引用的每篇文献都能在对应数据源中找到原文",
|
||||
"报告结构完整：包含背景、文献分析、证据等级、结论、引用等必要章节",
|
||||
"进度反馈清晰：Multi-Agent执行过程可视化展示，用户能了解当前进度",
|
||||
"支持复杂研究问题：能处理多维度、跨领域的精神疾病研究问题",
|
||||
"知识图谱去重有效：同一文献不重复入库，同义实体能识别合并，关系边不重复"
|
||||
]
|
||||
},
|
||||
"delivery_plan": {
|
||||
"phases": [
|
||||
{
|
||||
"phase_number": 1,
|
||||
"goal": "MVP版本：实现核心搜索和报告生成能力",
|
||||
"features": [
|
||||
"3个核心数据源并行搜索（PubMed、PsycINFO、Embase）",
|
||||
"结构化报告生成（固定模板）",
|
||||
"Multi-Agent执行进度展示",
|
||||
"文字形式存储搜索结果（暂不使用知识图谱）"
|
||||
]
|
||||
},
|
||||
{
|
||||
"phase_number": 2,
|
||||
"goal": "完善版本：扩展数据源，引入知识图谱与完整去重",
|
||||
"features": [
|
||||
"扩展全部数据源（Cochrane、CNKI、万方、预印本、Google Scholar）",
|
||||
"知识图谱存储（文献引用关系、概念/实体关系、作者合作关系、研究时间线）",
|
||||
"完整去重机制（文献ID去重、实体语义去重、关系级去重）",
|
||||
"基于知识图谱的推理与充分性检查",
|
||||
"报告格式动态调整（根据问题类型灵活调整报告结构）"
|
||||
]
|
||||
}
|
||||
],
|
||||
"phase_rationale": "MVP阶段聚焦核心价值验证（搜索+报告生成），知识图谱及其相关功能（去重、推理）作为整体在第二阶段一起引入，避免功能割裂"
|
||||
},
|
||||
"user_constraints": {
|
||||
"explicit_tech_constraints": [
|
||||
"使用知识图谱进行文献存储与动态更新",
|
||||
"建立全图去重机制（文献ID去重+实体语义去重+关系级去重）",
|
||||
"采用Multi-Agent架构实现并行处理和进度展示"
|
||||
]
|
||||
},
|
||||
"documentation": {
|
||||
"recommended_template": "D:\\AA_Work\\AIEC-团队开发规范Skills\\.claude\\skills\\requirement-generator-v1\\templates\\agent_dev_template.md"
|
||||
}
|
||||
}
|
||||
170
.claude/skills/requirement-generator-v1/temp/response_ai.json
Normal file
170
.claude/skills/requirement-generator-v1/temp/response_ai.json
Normal file
@ -0,0 +1,170 @@
|
||||
{
|
||||
"expert_role": "AI专家",
|
||||
"debate_phase": "respond",
|
||||
|
||||
"responses_to_evaluations": [
|
||||
{
|
||||
"from_expert": "开发专家",
|
||||
"from_file": "temp/evaluate_dev.json",
|
||||
"evaluation_index": 3,
|
||||
"their_target": {
|
||||
"my_file": "temp/review_ai.json",
|
||||
"my_item_type": "suggestion",
|
||||
"my_item_index": 1,
|
||||
"my_item_content": "建议2：将证据等级评估任务降级为'研究类型分类'（如RCT/队列研究/病例报告等），减少AI判断的主观性和错误风险"
|
||||
},
|
||||
"their_comment": "研究类型分类虽然简化，但可能无法满足用户核心需求。从用户访谈看，证据等级评估是循证医学的核心要求，精神科医生明确指出这是重要功能。技术上可行的折中方案：基于研究类型+样本量+盲法等元数据进行规则化的初步证据等级判断，而非完全依赖LLM推理",
|
||||
"my_decision": "accept",
|
||||
"my_response": "开发专家的评价合理。我重新审视用户访谈结果，确认证据等级评估是用户的核心需求。开发专家提出的'规则化评估'方案比我原建议的'降级为研究类型分类'更好地平衡了用户价值与技术可靠性。基于客观元数据（研究类型、样本量、盲法、失访率等）进行规则化评估，确实比完全依赖LLM主观判断更可控，同时又能保留证据等级评估这一核心功能。",
|
||||
"action": "modify",
|
||||
"modification": "将原建议修改为：'建议采用结构化规则评估方式实现证据等级评估功能，基于研究类型、样本量、盲法、随机化等客观元数据进行规则化判断，降低对LLM主观推理的依赖，并明确标注AI评估的局限性，建议用户进行专业复核'"
|
||||
},
|
||||
{
|
||||
"from_expert": "开发专家",
|
||||
"from_file": "temp/evaluate_dev.json",
|
||||
"evaluation_index": 4,
|
||||
"their_target": {
|
||||
"my_file": "temp/review_ai.json",
|
||||
"my_item_type": "suggestion",
|
||||
"my_item_index": 5,
|
||||
"my_item_content": "建议6：明确定义单次任务的文献处理上限（如50篇），超出时提供分批处理或用户筛选机制"
|
||||
},
|
||||
"their_comment": "文献数量上限的思路正确，但50篇可能过于保守。以GPT-4-turbo的128K上下文为例，每篇文献摘要约500-1000 tokens，理论上可处理100+篇。建议分层处理：第一轮粗筛可处理200篇，第二轮精读分析处理Top 50-80篇。实际上限应根据选用的LLM模型和文献平均长度动态调整，而非硬编码固定值",
|
||||
"my_decision": "accept",
|
||||
"my_response": "开发专家的技术分析更加准确。我提出的'50篇'确实过于保守，没有充分考虑当前LLM的实际能力和分层处理策略。开发专家提出的分层处理方案（粗筛200篇 -> 精读50-80篇）和动态调整策略更符合实际工程需求。将上限设置为可配置参数而非硬编码，也更具工程灵活性。",
|
||||
"action": "modify",
|
||||
"modification": "将原建议修改为：'建议采用分层处理策略：第一轮粗筛可处理200篇（相关性排序），第二轮精读分析处理Top 50-80篇核心文献。具体上限应根据选用的LLM模型和文献平均长度动态配置，而非固定数值。超出处理能力时，应明确告知用户已分析文献范围'"
|
||||
},
|
||||
{
|
||||
"from_expert": "开发专家",
|
||||
"from_file": "temp/evaluate_dev.json",
|
||||
"evaluation_index": 5,
|
||||
"their_target": {
|
||||
"my_file": "temp/review_ai.json",
|
||||
"my_item_type": "ai_risk",
|
||||
"my_item_index": 0,
|
||||
"my_item_content": "引用幻觉风险：LLM在生成引用时可能编造不存在的文献（包括作者、标题、期刊、DOI等），这是当前大模型的已知弱点"
|
||||
},
|
||||
"their_comment": "幻觉风险确实存在，但建议的'引用验证Agent'可能过度设计。幻觉风险的根本解决方案是架构设计：报告生成Agent的引用必须且只能来自搜索Agent返回的文献列表，通过Prompt约束和结构化输出即可，不需要额外增加一个Agent。更实用的方案：在报告生成Agent的输出中要求包含文献ID索引，后处理阶段直接校验ID是否在原始搜索结果中",
|
||||
"my_decision": "accept",
|
||||
"my_response": "开发专家的方案更加简洁有效。我原建议的'引用验证Agent'确实增加了不必要的系统复杂度。通过架构设计层面的约束（强制引用只能来自搜索结果列表+结构化输出+ID索引校验）就能解决幻觉问题，这是更优雅的工程方案。将验证逻辑作为后处理步骤而非独立Agent，符合奥卡姆剃刀原则。",
|
||||
"action": "modify",
|
||||
"modification": "将原建议'增加引用验证Agent'修改为：'建议通过架构设计防范引用幻觉：(1)报告生成Agent的引用必须且只能来自搜索Agent返回的文献列表；(2)采用结构化输出格式，要求包含文献ID索引；(3)后处理阶段校验所有引用ID是否存在于原始搜索结果中。这一机制应作为报告生成Agent的内置功能，无需增加独立的验证Agent'"
|
||||
},
|
||||
{
|
||||
"from_expert": "产品经理",
|
||||
"from_file": "temp/evaluate_pm.json",
|
||||
"evaluation_index": 2,
|
||||
"their_target": {
|
||||
"my_file": "temp/review_ai.json",
|
||||
"my_item_type": "suggestion",
|
||||
"my_item_index": 1,
|
||||
"my_item_content": "建议2：将证据等级评估任务降级为'研究类型分类'（如RCT/队列研究/病例报告等），减少AI判断的主观性和错误风险"
|
||||
},
|
||||
"their_comment": "该建议与用户核心需求冲突，不建议采纳。用户访谈明确表达了对'证据等级评估'的需求，这是循证医学研究的核心能力，也是产品差异化的关键点。如果降级为'研究类型分类'，产品价值将大打折扣。建议采取折中方案：提供证据等级评估但标注'AI初评，建议专业复核'，提供评估依据的透明说明",
|
||||
"my_decision": "accept",
|
||||
"my_response": "产品经理的评价切中要害。我原先过于强调技术风险而忽视了用户核心需求和产品价值。证据等级评估确实是该产品的差异化价值点，完全降级会显著削弱产品竞争力。结合开发专家和产品经理的建议，正确的方向是：保留证据等级评估功能，但采用规则化评估+透明说明+人工复核提示的方式降低风险。",
|
||||
"action": "modify",
|
||||
"modification": "撤回原'降级为研究类型分类'建议，修改为：'保留证据等级评估功能，采用以下策略降低风险：(1)基于客观元数据的规则化评估；(2)标注AI初评，建议专业复核；(3)提供评估依据的透明说明，让用户了解判断逻辑'"
|
||||
},
|
||||
{
|
||||
"from_expert": "产品经理",
|
||||
"from_file": "temp/evaluate_pm.json",
|
||||
"evaluation_index": 3,
|
||||
"their_target": {
|
||||
"my_file": "temp/review_ai.json",
|
||||
"my_item_type": "suggestion",
|
||||
"my_item_index": 5,
|
||||
"my_item_content": "建议6：明确定义单次任务的文献处理上限（如50篇），超出时提供分批处理或用户筛选机制"
|
||||
},
|
||||
"their_comment": "同意需要上限机制，但50篇可能过于保守。从用户角度看，一个全面的文献综述可能涉及100+篇文献，人为限制50篇可能无法满足用户需求。建议采用'核心+扩展'模式，确保核心文献完整分析，扩展文献摘要分析。让用户自行决定处理范围而非系统硬性限制",
|
||||
"my_decision": "accept",
|
||||
"my_response": "产品经理从用户需求角度的分析很有价值。'核心+扩展'的分层模式比硬性上限更灵活，也更符合实际使用场景。结合开发专家的技术分析，最终方案应该是：分层处理+动态上限+用户可选范围，而非我原先建议的硬性50篇限制。",
|
||||
"action": "modify",
|
||||
"modification": "已在对开发专家的回应中修改，此处保持一致：采用分层处理策略（核心文献完整分析+扩展文献摘要分析），上限动态可配置，用户可选择处理范围"
|
||||
},
|
||||
{
|
||||
"from_expert": "产品经理",
|
||||
"from_file": "temp/evaluate_pm.json",
|
||||
"evaluation_index": 4,
|
||||
"their_target": {
|
||||
"my_file": "temp/review_ai.json",
|
||||
"my_item_type": "suggestion",
|
||||
"my_item_index": 3,
|
||||
"my_item_content": "建议4：MVP阶段建议先实现用户对搜索策略的确认和调整功能，确保检索方向正确后再进行分析"
|
||||
},
|
||||
"their_comment": "建议方向正确，但需权衡用户体验。增加'搜索策略确认'步骤会打断用户的使用流程，增加交互复杂度。对于'提高效率'这一核心目标有所削弱。建议采取可选模式：默认自动执行，快速出结果；高级用户可开启'策略确认'模式；在结果页面提供'调整搜索范围后重新生成'的入口",
|
||||
"my_decision": "partial",
|
||||
"my_response": "产品经理的用户体验考量是合理的，强制确认步骤确实会增加使用门槛。但从AI能力边界角度，我仍认为提供策略确认的选项是必要的——当用户问题模糊或跨领域时，自动生成的搜索策略可能偏离用户意图。产品经理建议的'可选模式'是很好的折中方案，既保持默认的简洁流程，又为需要精确控制的用户提供入口。",
|
||||
"action": "modify",
|
||||
"modification": "将原建议修改为：'建议提供搜索策略确认的可选功能：(1)默认模式：自动执行搜索，快速出结果；(2)高级模式：用户可开启搜索策略预览与调整；(3)在结果页面提供调整搜索范围后重新生成的入口。这样既保持效率又为高级用户提供控制能力'"
|
||||
},
|
||||
{
|
||||
"from_expert": "领域专家",
|
||||
"from_file": "temp/evaluate_domain.json",
|
||||
"evaluation_index": 4,
|
||||
"their_target": {
|
||||
"my_file": "temp/review_ai.json",
|
||||
"my_item_type": "suggestion",
|
||||
"my_item_index": 1,
|
||||
"my_item_content": "建议2：将证据等级评估任务降级为'研究类型分类'（如RCT/队列研究/病例报告等），减少AI判断的主观性和错误风险"
|
||||
},
|
||||
"their_comment": "作为精神科医生，我不同意将证据等级评估完全降级为研究类型分类。对于精神科临床研究者和医学生而言，证据等级评估是文献分析的核心价值所在。建议的替代方案是：采用结构化评估模板（如根据样本量、随机化方法、盲法、失访率等客观指标），并明确标注AI评估的局限性，而非放弃证据等级评估功能",
|
||||
"my_decision": "accept",
|
||||
"my_response": "领域专家作为精神科医生的专业判断最具权威性。证据等级评估对精神科循证实践的重要性我在原评审中低估了。领域专家提出的'结构化评估模板'方案与开发专家的建议一致，这进一步验证了这是正确的技术路线。我接受这一评价，撤回原'降级'建议。",
|
||||
"action": "modify",
|
||||
"modification": "已在前述回应中修改，此处保持一致：撤回'降级为研究类型分类'建议，改为采用结构化评估模板方案"
|
||||
},
|
||||
{
|
||||
"from_expert": "领域专家",
|
||||
"from_file": "temp/evaluate_domain.json",
|
||||
"evaluation_index": 5,
|
||||
"their_target": {
|
||||
"my_file": "temp/review_ai.json",
|
||||
"my_item_type": "issue",
|
||||
"my_item_index": 2,
|
||||
"my_item_content": "知识图谱的'实体语义去重'能力要求过高。跨语言（中英文）、跨数据源的医学实体语义相似度判断（如判断'精神分裂症'与'Schizophrenia'为同一实体）需要强大的领域知识和对齐能力"
|
||||
},
|
||||
"their_comment": "AI专家正确识别了跨语言术语对齐的挑战，但低估了精神科领域术语标准化的现有资源。WHO的ICD-11已提供多语言官方术语对照，NLM的UMLS也包含大量精神科术语的跨语言映射。建议不是从零构建语义匹配能力，而是充分利用这些现有标准术语库",
|
||||
"my_decision": "accept",
|
||||
"my_response": "领域专家提供了非常有价值的信息。我在原评审中确实低估了医学领域现有术语标准化资源的成熟度。ICD-11多语言术语对照、UMLS跨语言映射等资源可以大幅降低语义去重的技术难度。利用标准术语库进行对齐，而非完全依赖AI语义判断，是更可靠的技术路线。这也与我原评审中建议使用MeSH/UMLS的方向一致，但我之前没有充分认识到这些资源的完备程度。",
|
||||
"action": "modify",
|
||||
"modification": "修改原issue描述，承认现有标准术语库资源可有效支持跨语言术语对齐：'跨语言实体语义去重可通过整合现有标准术语库（ICD-11多语言对照、UMLS映射、MeSH主题词表）实现核心术语对齐，技术难度低于从零构建语义匹配能力。建议将标准术语库整合作为技术架构的基础组件'"
|
||||
},
|
||||
{
|
||||
"from_expert": "领域专家",
|
||||
"from_file": "temp/evaluate_domain.json",
|
||||
"evaluation_index": 6,
|
||||
"their_target": {
|
||||
"my_file": "temp/review_ai.json",
|
||||
"my_item_type": "ai_risk",
|
||||
"my_item_index": 1,
|
||||
"my_item_content": "证据等级评估不可靠风险：证据等级评估需要理解研究设计细节（如随机化方法、盲法、样本量计算等），LLM可能给出看似合理但实际错误的评估"
|
||||
},
|
||||
"their_comment": "AI专家对风险的识别是准确的，但其缓解建议'MVP阶段可考虑简化为研究类型分类'过于保守。精神科领域的循证医学实践已经发展出相对标准化的评估框架，可以将其转化为结构化评估规则，降低AI主观判断的依赖。例如Cochrane偏倚风险评估工具已有明确的评估维度和标准，可以将这些标准转化为系统可执行的检查清单",
|
||||
"my_decision": "accept",
|
||||
"my_response": "领域专家提供了极具建设性的方案。Cochrane偏倚风险评估工具等现有评估框架可以被转化为结构化检查清单，这让AI的任务从'主观判断证据等级'变为'提取信息填充检查清单'，显著降低了风险。这个方案比我原建议的'降级为研究类型分类'更好地平衡了功能价值与可靠性。我的原风险识别是准确的，但缓解策略确实过于保守。",
|
||||
"action": "modify",
|
||||
"modification": "修改原ai_risk的mitigation建议：'缓解策略：(1)采用Cochrane偏倚风险评估工具等现有评估框架，将其转化为结构化检查清单；(2)AI任务定位为从文献中提取信息填充清单，而非直接判断证据等级；(3)基于清单结果进行规则化的证据等级判断；(4)明确标注AI评估局限性，建议专业复核'"
|
||||
}
|
||||
],
|
||||
|
||||
"response_summary": {
|
||||
"total_evaluations_received": 9,
|
||||
"accept_count": 8,
|
||||
"partial_count": 1,
|
||||
"reject_count": 0,
|
||||
"key_modifications": [
|
||||
"撤回'证据等级评估降级为研究类型分类'建议，改为采用结构化规则评估+标准化框架方案",
|
||||
"撤回'增加引用验证Agent'建议，改为通过架构设计（结构化输出+ID校验）防范幻觉",
|
||||
"将'50篇文献上限'修改为分层处理策略（粗筛200篇+精读50-80篇）+动态配置",
|
||||
"将'强制搜索策略确认'修改为可选模式（默认自动+高级模式可开启）",
|
||||
"承认现有医学标准术语库（ICD-11、UMLS、MeSH）可有效支持跨语言术语对齐"
|
||||
],
|
||||
"lessons_learned": [
|
||||
"过于强调技术风险可能导致忽视用户核心需求和产品价值，需在风险与价值间取得平衡",
|
||||
"应充分利用领域现有的标准化资源和评估框架，而非假设一切需从零构建",
|
||||
"架构设计层面的约束往往比增加额外组件更优雅地解决问题"
|
||||
]
|
||||
}
|
||||
}
|
||||
135
.claude/skills/requirement-generator-v1/temp/response_dev.json
Normal file
135
.claude/skills/requirement-generator-v1/temp/response_dev.json
Normal file
@ -0,0 +1,135 @@
|
||||
{
|
||||
"expert_role": "开发专家",
|
||||
"debate_phase": "respond",
|
||||
|
||||
"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": "suggestion",
|
||||
"my_item_index": 0,
|
||||
"my_item_content": "建议增加技术选型章节：明确开发语言（Python推荐）、Agent框架（LangGraph/AutoGen/CrewAI）、知识图谱（Neo4j Community版）、消息队列（Redis）等核心技术决策"
|
||||
},
|
||||
"their_comment": "同意需要技术选型，但需求文档应保持技术中立，具体技术选型应在设计文档中明确",
|
||||
"my_decision": "accept",
|
||||
"my_response": "产品经理的观点正确。需求文档的职责确实是定义'做什么'而非'怎么做'。我过早将具体技术方案（Neo4j、Redis等）写入建议，模糊了需求与设计的边界。技术选型确实应在后续的技术设计文档中明确。",
|
||||
"action": "modify",
|
||||
"modification": "修改建议为：'建议在需求文档中明确技术约束（如需要知识图谱存储能力、需要支持并行任务调度、需要实时进度反馈能力），具体技术选型留待技术设计阶段确定'"
|
||||
},
|
||||
{
|
||||
"from_expert": "产品经理",
|
||||
"from_file": "temp/evaluate_pm.json",
|
||||
"evaluation_index": 1,
|
||||
"their_target": {
|
||||
"my_file": "temp/review_dev.json",
|
||||
"my_item_type": "issue",
|
||||
"my_item_index": 0,
|
||||
"my_item_content": "外部数据源API访问可行性未验证：PsycINFO、Embase、Cochrane Library等商业数据库需要机构订阅和API授权...个人/小团队难以获得合法稳定的API访问权限"
|
||||
},
|
||||
"their_comment": "问题指出正确，但建议的解决方案需考虑用户价值。开发专家建议MVP阶段仅使用PubMed，这从技术可行性角度合理，但从用户价值角度看，PsycINFO是精神科文献的核心数据库，缺失会显著降低产品价值",
|
||||
"my_decision": "partial",
|
||||
"my_response": "产品经理从用户价值角度提出的补充是合理的。我原建议过于保守，仅从技术可行性角度考虑而忽视了业务价值。但技术可行性问题客观存在，PsycINFO确实需要机构订阅。接受产品经理'探索用户自带机构账号模式'的建议，并认可应与用户确认数据源优先级。",
|
||||
"action": "modify",
|
||||
"modification": "修改建议为：'(1) MVP阶段优先使用免费开放API的数据源（PubMed E-utilities、bioRxiv API）；(2) 在需求文档中明确标注各数据源的授权获取方式、成本和优先级；(3) 探索用户自带机构账号的集成模式（如OAuth代理）；(4) 与用户确认数据源优先级，而非开发团队单方面决定'"
|
||||
},
|
||||
{
|
||||
"from_expert": "产品经理",
|
||||
"from_file": "temp/evaluate_pm.json",
|
||||
"evaluation_index": 8,
|
||||
"their_target": {
|
||||
"my_file": "temp/review_dev.json",
|
||||
"my_item_type": "tech_risk",
|
||||
"my_item_index": 2,
|
||||
"my_item_content": "LLM调用成本和延迟风险：大量文献分析需频繁调用LLM，可能产生高额API费用，且存在速率限制"
|
||||
},
|
||||
"their_comment": "成本风险需要关注，但应在需求文档中明确成本预期",
|
||||
"my_decision": "accept",
|
||||
"my_response": "产品经理的建议正确。成本风险不应成为功能裁剪的理由，而应作为设计约束纳入需求文档。用户访谈中明确接受'小时级执行时间'，说明用户更看重质量而非速度/成本。我原建议的缓解措施方向正确，但缺少与用户确认可接受成本范围这一关键步骤。",
|
||||
"action": "modify",
|
||||
"modification": "修改风险缓解措施为：'(1) 在需求文档的非功能性需求中增加"单次任务成本上限"指标；(2) 与用户确认可接受的成本范围；(3) 预估单次研究的Token消耗和成本；(4) 使用分层模型策略（简单任务用小模型）；(5) 实现本地缓存避免重复分析'"
|
||||
},
|
||||
{
|
||||
"from_expert": "AI专家",
|
||||
"from_file": "temp/evaluate_ai.json",
|
||||
"evaluation_index": 0,
|
||||
"their_target": {
|
||||
"my_file": "temp/review_dev.json",
|
||||
"my_item_type": "issue",
|
||||
"my_item_index": 5,
|
||||
"my_item_content": "证据等级评估的实现复杂度被低估：医学领域的证据等级评估（如GRADE标准）需要专业知识和结构化判断，仅依靠LLM分析可能准确性不足"
|
||||
},
|
||||
"their_comment": "开发专家的技术实现视角正确，但建议方案'结合文献元数据进行规则化判断'过于乐观。证据等级评估不仅是实现复杂度问题，更是AI能力边界问题",
|
||||
"my_decision": "partial",
|
||||
"my_response": "AI专家对AI能力边界的深入分析是有价值的，我确实低估了GRADE评估的多维度复杂性（偏倚风险、结果一致性、精确性等）。但结合领域专家的观点，完全放弃证据等级评估会损害产品核心价值。接受AI专家关于能力边界的分析，但不同意将任务完全降级。",
|
||||
"action": "modify",
|
||||
"modification": "修改建议为：'(1) 采用分层策略：Phase 1做研究类型分类+基于规则的结构化信息提取（样本量、随机化方法、盲法等），Phase 2引入偏倚风险初筛；(2) 明确区分AI可独立完成的任务（信息提取）与仅供参考的任务（证据强度判断）；(3) 在报告中显示评估依据的透明说明，标注AI评估的局限性；(4) 采用领域专家建议的结构化评估模板（如Cochrane偏倚风险工具），将AI任务定位为信息提取而非判断'"
|
||||
},
|
||||
{
|
||||
"from_expert": "AI专家",
|
||||
"from_file": "temp/evaluate_ai.json",
|
||||
"evaluation_index": 1,
|
||||
"their_target": {
|
||||
"my_file": "temp/review_dev.json",
|
||||
"my_item_type": "suggestion",
|
||||
"my_item_index": 2,
|
||||
"my_item_content": "建议细化MVP验收标准：当前验收标准偏定性，建议增加定量指标如'引用准确率>=95%'、'去重准确率>=90%'"
|
||||
},
|
||||
"their_comment": "定量指标方向正确，但95%引用准确率的可行性需要验证。建议分层设定：引用来源可追溯率100%（刚性约束）与引用格式准确率>=95%（允许容错）",
|
||||
"my_decision": "accept",
|
||||
"my_response": "AI专家的分层设定建议非常精准。将'可追溯性'与'格式准确性'分开定义，前者作为刚性约束（禁止AI自行生成引用），后者允许容错，这既保证了学术诚信，又考虑了实际可行性。完全接受此建议。",
|
||||
"action": "modify",
|
||||
"modification": "修改建议为：'建议分层定义验收指标：(1) 刚性约束：引用来源可追溯率=100%（所有引用必须来自搜索返回结果，禁止AI自行生成）；(2) 质量指标：引用格式准确率>=95%（DOI、作者、标题等信息与原始数据一致）；(3) 去重准确率>=90%（允许边界情况保留两者）'"
|
||||
},
|
||||
{
|
||||
"from_expert": "AI专家",
|
||||
"from_file": "temp/evaluate_ai.json",
|
||||
"evaluation_index": 2,
|
||||
"their_target": {
|
||||
"my_file": "temp/review_dev.json",
|
||||
"my_item_type": "tech_risk",
|
||||
"my_item_index": 1,
|
||||
"my_item_content": "知识图谱去重准确性风险：'语义去重'依赖NLP/向量匹配，可能出现误判（重复未识别或错误合并），影响报告质量"
|
||||
},
|
||||
"their_comment": "风险识别准确，但缓解措施'分层去重'未充分考虑跨语言场景。中英文医学术语的语义对齐需要依赖标准术语库",
|
||||
"my_decision": "accept",
|
||||
"my_response": "AI专家和领域专家都指出了跨语言术语对齐的问题，并提供了具体的解决方案（UMLS/MeSH CUI映射、ICD-11多语言术语对照）。我原建议仅提到向量相似度，确实不足以解决跨语言问题。接受引入标准术语库的建议。",
|
||||
"action": "modify",
|
||||
"modification": "修改缓解措施为：'(1) 分层去重：先DOI/PMID精确匹配，再UMLS/MeSH CUI映射实现跨语言术语对齐，最后标题相似度匹配；(2) 对无法通过术语库匹配的实体，采用保守策略（不合并，保留两者）；(3) 设置相似度阈值，边界情况保留两者并标注供人工复核；(4) 定义跨语言去重的单独准确率指标'"
|
||||
},
|
||||
{
|
||||
"from_expert": "领域专家",
|
||||
"from_file": "temp/evaluate_domain.json",
|
||||
"evaluation_index": 0,
|
||||
"their_target": {
|
||||
"my_file": "temp/review_dev.json",
|
||||
"my_item_type": "issue",
|
||||
"my_item_index": 5,
|
||||
"my_item_content": "证据等级评估的实现复杂度被低估：医学领域的证据等级评估（如GRADE标准）需要专业知识和结构化判断，仅依靠LLM分析可能准确性不足"
|
||||
},
|
||||
"their_comment": "开发专家正确识别了证据等级评估的复杂性，但其建议'标注评估结果仅供参考，需人工复核'不够充分。在精神科临床实践中，证据等级评估涉及专业判断标准的选择，需要在系统设计中预设精神科适用的评估模板",
|
||||
"my_decision": "accept",
|
||||
"my_response": "领域专家的建议非常专业。精神科研究存在特有的方法学挑战（对照组选择困难、盲法难以实施等），通用的GRADE/Oxford体系可能需要调整。采用领域专家建议的'预设精神科适用评估模板'和'结构化信息提取+规则化评分'模式，既保留功能价值，又降低AI错误风险。",
|
||||
"action": "modify",
|
||||
"modification": "修改建议为：'(1) 明确证据等级评估采用的具体标准，并考虑精神科特有的研究设计特点；(2) 采用结构化评估模板（如Cochrane偏倚风险工具），将AI任务定位为从文献中提取相关信息填充清单，而非直接判断证据等级；(3) 在系统设计中预设精神科适用的评估模板，考虑心理治疗研究等特殊场景；(4) 标注评估结果需专业人员复核，并显示评估依据的透明说明'"
|
||||
},
|
||||
{
|
||||
"from_expert": "领域专家",
|
||||
"from_file": "temp/evaluate_domain.json",
|
||||
"evaluation_index": 1,
|
||||
"their_target": {
|
||||
"my_file": "temp/review_dev.json",
|
||||
"my_item_type": "suggestion",
|
||||
"my_item_index": 0,
|
||||
"my_item_content": "建议增加技术选型章节：明确开发语言（Python推荐）、Agent框架（LangGraph/AutoGen/CrewAI）、知识图谱（Neo4j Community版）、消息队列（Redis）等核心技术决策"
|
||||
},
|
||||
"their_comment": "技术选型建议合理，但从精神科文献研究的角度，还需要补充医学术语标准化的技术组件。精神科术语的规范化处理（DSM-5/ICD-11术语库、MeSH/UMLS集成）应作为技术选型的必要组成部分",
|
||||
"my_decision": "accept",
|
||||
"my_response": "领域专家指出了我在技术建议中的重要遗漏。精神科术语存在多种表述方式和历史演变，术语标准化组件确实是刚性需求而非可选功能。这直接影响搜索召回率和知识图谱去重质量。",
|
||||
"action": "modify",
|
||||
"modification": "结合产品经理和领域专家的意见，修改建议为：'建议在需求文档中明确以下技术约束：(1) 需要知识图谱存储能力；(2) 需要支持并行任务调度；(3) 需要实时进度反馈能力；(4) 必须集成医学术语标准化组件（ICD-11、DSM-5术语库、MeSH/UMLS），作为搜索和去重的基础能力。具体技术选型留待技术设计阶段确定'"
|
||||
}
|
||||
]
|
||||
}
|
||||
@ -0,0 +1,152 @@
|
||||
{
|
||||
"expert_role": "精神科医生",
|
||||
"domain": "精神医学/精神疾病研究",
|
||||
"debate_phase": "respond",
|
||||
|
||||
"responses_to_evaluations": [
|
||||
{
|
||||
"from_expert": "开发专家",
|
||||
"from_file": "temp/evaluate_dev.json",
|
||||
"evaluation_index": 6,
|
||||
"their_target": {
|
||||
"my_file": "temp/review_domain.json",
|
||||
"my_item_type": "issue",
|
||||
"my_item_index": 0,
|
||||
"my_item_content": "缺少诊断标准版本标注功能：精神科文献分析必须注意诊断标准的演变（DSM-IV vs DSM-5, ICD-10 vs ICD-11），不同版本的诊断标准可能导致研究结果不可比"
|
||||
},
|
||||
"their_comment": "诊断标准版本标注有价值，但'自动识别'的技术实现有挑战。诊断标准版本通常不在文献摘要的结构化字段中，需要从全文或摘要文本中提取，依赖NLP/LLM判断；部分文献可能未明确说明使用的诊断标准版本。建议分两步实现：MVP阶段在报告中增加'诊断标准'提醒章节，第二阶段通过LLM分析尝试自动识别",
|
||||
"my_decision": "accept",
|
||||
"my_response": "接受开发专家的分阶段实现建议。从临床角度，诊断标准差异确实是影响研究可比性的关键因素，但我认可技术实现的难度。MVP阶段通过'提醒章节'的方式让用户关注此问题是务实的做法，这已经能够满足基本的专业提醒需求。第二阶段再实现自动识别是合理的技术演进路径。",
|
||||
"action": "modify",
|
||||
"modification": "将原建议修改为：MVP阶段在报告中增加'诊断标准注意事项'提醒章节，提示用户关注文献中诊断标准版本的差异；第二阶段通过LLM从摘要/全文中识别并标注诊断标准版本，对无法识别的文献标注'未明确'"
|
||||
},
|
||||
{
|
||||
"from_expert": "开发专家",
|
||||
"from_file": "temp/evaluate_dev.json",
|
||||
"evaluation_index": 7,
|
||||
"their_target": {
|
||||
"my_file": "temp/review_domain.json",
|
||||
"my_item_type": "issue",
|
||||
"my_item_index": 2,
|
||||
"my_item_content": "未涵盖临床试验注册库：精神科药物和治疗研究需要关注ClinicalTrials.gov、WHO ICTRP等临床试验注册库，这对于了解正在进行的研究和发表偏倚评估至关重要"
|
||||
},
|
||||
"their_comment": "ClinicalTrials.gov提供公开API，技术上可接入。但临床试验数据的结构与文献数据差异大，需要单独设计数据模型。WHO ICTRP没有稳定的公开API，合规性和稳定性存疑。建议MVP阶段仅整合ClinicalTrials.gov作为'相关在研试验'补充章节",
|
||||
"my_decision": "accept",
|
||||
"my_response": "接受开发专家的技术评估。作为临床医生，我更关注的是能否获取在研试验信息以评估发表偏倚，而非具体通过哪个平台获取。ClinicalTrials.gov覆盖了大部分国际主要临床试验，足以满足基本需求。WHO ICTRP的技术限制是客观的，可以暂缓。",
|
||||
"action": "modify",
|
||||
"modification": "将原建议修改为：MVP阶段可暂不整合临床试验注册库；第二阶段优先整合ClinicalTrials.gov作为'相关在研试验'补充章节，WHO ICTRP根据技术条件评估后再决定是否整合"
|
||||
},
|
||||
{
|
||||
"from_expert": "开发专家",
|
||||
"from_file": "temp/evaluate_dev.json",
|
||||
"evaluation_index": 8,
|
||||
"their_target": {
|
||||
"my_file": "temp/review_domain.json",
|
||||
"my_item_type": "suggestion",
|
||||
"my_item_index": 7,
|
||||
"my_item_content": "MVP阶段合规性建议：即使在MVP阶段，也应包含诊断标准版本标注和基本的证据等级评估，这是精神科文献分析的最低专业要求"
|
||||
},
|
||||
"their_comment": "MVP阶段的核心目标是验证'多数据源并行搜索+结构化报告生成'的核心价值，过多专业功能会增加开发周期。折中方案：MVP阶段在报告中增加'研究方法学注意事项'章节，以文字提醒形式涵盖诊断标准差异、证据等级解读等内容，而非实现自动化识别",
|
||||
"my_decision": "partial",
|
||||
"my_response": "部分接受开发专家的观点。我理解MVP阶段需要控制开发周期，但作为领域专家，我需要强调：如果报告中完全没有证据等级信息，对于循证医学背景的用户来说，报告的专业价值会大打折扣。我接受用'研究类型分类'替代完整的GRADE评估作为折中，但希望MVP阶段至少能区分系统评价/Meta分析、RCT、队列研究、病例报告等基本研究类型。这是信息提取任务，技术难度相对可控。",
|
||||
"action": "modify",
|
||||
"modification": "将原建议修改为：MVP阶段(1)在报告中增加'研究方法学注意事项'提醒章节，(2)实现基本的研究类型分类（系统评价/RCT/队列研究/病例报告等），标注为'研究类型'而非'证据等级'以降低用户预期；完整的GRADE证据等级评估留待第二阶段"
|
||||
},
|
||||
{
|
||||
"from_expert": "产品经理",
|
||||
"from_file": "temp/evaluate_pm.json",
|
||||
"evaluation_index": 5,
|
||||
"their_target": {
|
||||
"my_file": "temp/review_domain.json",
|
||||
"my_item_type": "issue",
|
||||
"my_item_index": 0,
|
||||
"my_item_content": "缺少诊断标准版本标注功能：精神科文献分析必须注意诊断标准的演变（DSM-IV vs DSM-5, ICD-10 vs ICD-11），不同版本的诊断标准可能导致研究结果不可比"
|
||||
},
|
||||
"their_comment": "问题指出专业且重要，但建议的实现方式需要商榷。'自动识别并标注每篇文献采用的诊断标准版本'在技术上有相当难度，因为很多文献并未在摘要中明确说明诊断标准版本。建议分阶段实现，避免承诺无法实现的功能",
|
||||
"my_decision": "accept",
|
||||
"my_response": "接受产品经理的务实建议。确实，作为临床医生我更关注的是'用户需要意识到诊断标准差异'这个目标，而非必须实现'自动识别'这个具体技术手段。分阶段实现的方案既能满足专业提醒的基本需求，又不会因为承诺过高而损害用户信任。",
|
||||
"action": "modify",
|
||||
"modification": "同上（与开发专家评价的修改一致）：MVP阶段通过提醒章节解决，第二阶段尝试自动识别"
|
||||
},
|
||||
{
|
||||
"from_expert": "产品经理",
|
||||
"from_file": "temp/evaluate_pm.json",
|
||||
"evaluation_index": 6,
|
||||
"their_target": {
|
||||
"my_file": "temp/review_domain.json",
|
||||
"my_item_type": "suggestion",
|
||||
"my_item_index": 7,
|
||||
"my_item_content": "MVP阶段合规性建议：即使在MVP阶段，也应包含诊断标准版本标注和基本的证据等级评估，这是精神科文献分析的最低专业要求"
|
||||
},
|
||||
"their_comment": "对MVP范围的建议过于激进，可能导致MVP阶段延期。诊断标准自动识别是一个技术难点，强制纳入MVP可能导致功能实现质量不高反而损害用户信任。用户访谈中未将此列为最高优先级需求",
|
||||
"my_decision": "partial",
|
||||
"my_response": "部分接受产品经理的观点。我承认原建议可能对MVP范围定义过于激进。但需要澄清：我强调的'最低专业要求'是指用户需要能够获得研究质量相关的信息，而非必须实现复杂的自动化功能。接受将'诊断标准自动识别'改为'提醒章节'，但坚持MVP阶段应包含基本的'研究类型分类'功能——这是区分研究质量的基础信息，且技术实现相对简单（基于关键词和文献类型字段即可初步判断）。",
|
||||
"action": "modify",
|
||||
"modification": "调整原建议：(1)诊断标准版本从'自动识别'改为'提醒章节'；(2)证据等级评估从'GRADE标准'降级为'研究类型分类'，明确标注为AI初步分类；(3)在需求文档中说明'完整的循证医学评估功能'将在第二阶段完善"
|
||||
},
|
||||
{
|
||||
"from_expert": "产品经理",
|
||||
"from_file": "temp/evaluate_pm.json",
|
||||
"evaluation_index": 7,
|
||||
"their_target": {
|
||||
"my_file": "temp/review_domain.json",
|
||||
"my_item_type": "issue",
|
||||
"my_item_index": 2,
|
||||
"my_item_content": "未涵盖临床试验注册库：精神科药物和治疗研究需要关注ClinicalTrials.gov、WHO ICTRP等临床试验注册库"
|
||||
},
|
||||
"their_comment": "数据源建议有价值，但应纳入第二阶段。当前8个数据源已覆盖主要文献来源。建议将临床试验注册库作为第二阶段扩展，可将ClinicalTrials.gov加入扩展列表。避免数据源过多导致系统复杂度急剧增加",
|
||||
"my_decision": "accept",
|
||||
"my_response": "接受产品经理的优先级建议。从产品角度看，MVP阶段确实应聚焦核心数据源的稳定可用。临床试验注册库虽然对评估发表偏倚有价值，但这是更高级的研究需求，可以放在第二阶段。在需求文档中将ClinicalTrials.gov列入扩展数据源清单是合理的安排。",
|
||||
"action": "modify",
|
||||
"modification": "将临床试验注册库从'核心需求'调整为'第二阶段扩展需求'，建议在需求文档第5.1节扩展数据源列表中增加ClinicalTrials.gov"
|
||||
},
|
||||
{
|
||||
"from_expert": "AI专家",
|
||||
"from_file": "temp/evaluate_ai.json",
|
||||
"evaluation_index": 5,
|
||||
"their_target": {
|
||||
"my_file": "temp/review_domain.json",
|
||||
"my_item_type": "issue",
|
||||
"my_item_index": 1,
|
||||
"my_item_content": "证据等级评估方法未明确：精神科遵循循证医学原则，需要明确采用何种证据分级体系（如GRADE、Oxford证据等级），以及如何处理不同研究设计的证据权重"
|
||||
},
|
||||
"their_comment": "要求明确证据分级体系的方向正确，但建议'建立研究设计类型的自动识别和分级逻辑'对AI能力预期过高。GRADE评估需要判断偏倚风险、不一致性、间接性、不精确性、发表偏倚五个维度，这需要深度理解研究方法学。建议采用分层策略：Phase 1仅做研究类型分类，Phase 2引入偏倚风险初筛，GRADE完整评估定位为人工任务",
|
||||
"my_decision": "accept",
|
||||
"my_response": "接受AI专家的专业分析。作为临床医生，我深知GRADE评估的复杂性——即便是经过培训的研究者，进行GRADE评估也需要大量时间和专业判断。AI专家提出的分层策略是合理的：Phase 1做研究类型分类（这是可靠的信息提取任务），Phase 2尝试偏倚风险初筛，完整GRADE评估保留为人工任务。这样既不会给用户造成'虚假的专业感'，又能提供有价值的辅助信息。",
|
||||
"action": "modify",
|
||||
"modification": "将原建议修改为分层实现策略：(1) MVP阶段实现研究类型分类（系统评价/Meta分析、RCT、队列研究、病例对照、病例报告等），标注为'研究类型'；(2) 第二阶段尝试偏倚风险初筛（基于规则+AI辅助）；(3) 在报告中明确说明'完整的GRADE证据等级评估需要专业人员判断，本系统仅提供研究类型分类作为参考'"
|
||||
},
|
||||
{
|
||||
"from_expert": "AI专家",
|
||||
"from_file": "temp/evaluate_ai.json",
|
||||
"evaluation_index": 6,
|
||||
"their_target": {
|
||||
"my_file": "temp/review_domain.json",
|
||||
"my_item_type": "suggestion",
|
||||
"my_item_index": 7,
|
||||
"my_item_content": "MVP阶段合规性建议：即使在MVP阶段，也应包含诊断标准版本标注和基本的证据等级评估，这是精神科文献分析的最低专业要求"
|
||||
},
|
||||
"their_comment": "诊断标准版本标注可在MVP实现（从文献元数据或全文中提取关键词如'DSM-5'），但'证据等级评估'不应作为MVP的最低要求。证据等级评估是专业判断任务，AI可靠性存疑，错误评估可能比不评估更危险。建议MVP阶段：标注诊断标准版本+研究类型分类，明确告知用户'证据等级需人工判断'",
|
||||
"my_decision": "accept",
|
||||
"my_response": "接受AI专家的风险分析。这是一个重要的视角——从临床安全角度看，'错误的证据等级评估'确实可能比'不评估'更危险，因为用户可能基于错误评估做出不当的临床决策。AI专家提出的方案（诊断标准关键词提取+研究类型分类+明确告知用户需人工判断）是负责任的做法，符合循证医学'避免误导'的原则。",
|
||||
"action": "modify",
|
||||
"modification": "接受AI专家建议，将MVP阶段的专业功能调整为：(1)诊断标准关键词提取（如识别文献中出现的'DSM-5'、'ICD-11'等关键词并标注）；(2)研究类型分类；(3)在报告中明确说明'证据等级评估需专业人员判断，本系统仅提供研究类型分类作为参考'"
|
||||
},
|
||||
{
|
||||
"from_expert": "AI专家",
|
||||
"from_file": "temp/evaluate_ai.json",
|
||||
"evaluation_index": 7,
|
||||
"their_target": {
|
||||
"my_file": "temp/review_domain.json",
|
||||
"my_item_type": "missing_item",
|
||||
"my_item_index": 0,
|
||||
"my_item_content": "缺少量表和评估工具识别功能：精神科研究大量使用标准化量表（如PANSS、HAM-D、MADRS等），系统应能识别和提取文献中使用的评估量表"
|
||||
},
|
||||
"their_comment": "量表识别功能需求合理，但实现复杂度需注意。量表名称提取相对简单，但量表版本识别、评分结果提取涉及更复杂的信息抽取。建议分层实现：量表名称识别可在Phase 1实现，量表评分结果提取放在Phase 2，需定义量表识别的准确率指标",
|
||||
"my_decision": "accept",
|
||||
"my_response": "接受AI专家的分层实现建议。从临床实用性角度，量表名称识别已经能够提供有价值的信息——让用户知道各研究使用了哪些评估工具，便于判断结果的可比性。量表评分结果的具体数值提取确实更复杂，且用户往往需要查阅原文确认。分层实现是合理的策略。",
|
||||
"action": "modify",
|
||||
"modification": "将原建议调整为分层实现：(1) Phase 1实现量表名称识别（基于预定义的精神科常用量表库进行关键词匹配，如PANSS、HAM-D、MADRS、CGI、YMRS等），在报告中列出各研究使用的评估量表；(2) Phase 2尝试量表评分结果提取，并定义准确率指标（如召回率>=80%，精确率>=90%）"
|
||||
}
|
||||
]
|
||||
}
|
||||
119
.claude/skills/requirement-generator-v1/temp/response_pm.json
Normal file
119
.claude/skills/requirement-generator-v1/temp/response_pm.json
Normal file
@ -0,0 +1,119 @@
|
||||
{
|
||||
"expert_role": "产品经理",
|
||||
"debate_phase": "respond",
|
||||
|
||||
"responses_to_evaluations": [
|
||||
{
|
||||
"from_expert": "开发专家",
|
||||
"from_file": "temp/evaluate_dev.json",
|
||||
"evaluation_index": 0,
|
||||
"their_target": {
|
||||
"my_file": "temp/review_pm.json",
|
||||
"my_item_type": "missing_item",
|
||||
"my_item_index": 4,
|
||||
"my_item_content": "移动端适配：是否需要支持移动端访问和使用"
|
||||
},
|
||||
"their_comment": "MVP阶段不应考虑移动端适配，技术投入产出比低",
|
||||
"my_decision": "accept",
|
||||
"my_response": "接受开发专家的观点。回顾用户访谈记录，目标用户（科研人员、医学生、分析师）的核心使用场景确实是桌面端长时间研究工作。该产品允许小时级执行时间，移动端使用场景确实不适合。我原始提出移动端适配是作为'需考虑的问题'而非MVP必需功能，开发专家的分析更为务实。建议在产品PMF验证后再评估移动端需求。",
|
||||
"action": "withdraw",
|
||||
"modification": null
|
||||
},
|
||||
{
|
||||
"from_expert": "开发专家",
|
||||
"from_file": "temp/evaluate_dev.json",
|
||||
"evaluation_index": 1,
|
||||
"their_target": {
|
||||
"my_file": "temp/review_pm.json",
|
||||
"my_item_type": "suggestion",
|
||||
"my_item_index": 2,
|
||||
"my_item_content": "建议细化用户故事：将场景进一步拆解为用户故事（As a...I want...So that...），便于开发理解和验收"
|
||||
},
|
||||
"their_comment": "用户故事对开发有帮助，但当前需求文档的场景描述已足够详细",
|
||||
"my_decision": "partial",
|
||||
"my_response": "部分接受。开发专家指出当前文档的场景描述已包含触发条件、操作步骤、预期结果，这点是正确的。但我认为用户故事的价值不仅在于'形式要求'，更在于确保需求从用户视角出发、便于验收测试用例设计。对于Agent开发项目，建议折中方案：保持当前场景描述格式，但在验收标准部分增加基于用户故事的测试用例描述。",
|
||||
"action": "modify",
|
||||
"modification": "将建议修改为：'建议在验收标准部分增加基于用户视角的测试用例描述（如：用户输入XX问题，期望获得包含YY内容的报告），确保开发和测试团队理解用户预期'"
|
||||
},
|
||||
{
|
||||
"from_expert": "开发专家",
|
||||
"from_file": "temp/evaluate_dev.json",
|
||||
"evaluation_index": 2,
|
||||
"their_target": {
|
||||
"my_file": "temp/review_pm.json",
|
||||
"my_item_type": "issue",
|
||||
"my_item_index": 4,
|
||||
"my_item_content": "报告输出形式单一：仅支持结构化中文报告，未考虑用户对不同格式和深度的需求"
|
||||
},
|
||||
"their_comment": "格式多样化有价值，但需分阶段实现",
|
||||
"my_decision": "accept",
|
||||
"my_response": "完全接受开发专家的分阶段实现建议。我原始建议过于笼统，未考虑技术实现成本。开发专家提出的方案更合理：MVP阶段先用Markdown格式（用户可自行转换），第二阶段再增加Word/PDF输出。英文报告选项确实涉及全流程语言切换，复杂度高，可放到后续版本。我将修改建议，明确分阶段路径。",
|
||||
"action": "modify",
|
||||
"modification": "将建议修改为：'建议分阶段支持报告格式：MVP阶段输出Markdown格式（用户可通过工具转换为其他格式）；Phase 2增加直接导出Word/PDF功能；英文报告作为后续版本考虑'"
|
||||
},
|
||||
{
|
||||
"from_expert": "AI专家",
|
||||
"from_file": "temp/evaluate_ai.json",
|
||||
"evaluation_index": 3,
|
||||
"their_target": {
|
||||
"my_file": "temp/review_pm.json",
|
||||
"my_item_type": "user_experience_concern",
|
||||
"my_item_index": 1,
|
||||
"my_item_content": "报告质量的可信度建立：用户如何判断AI生成报告的准确性和完整性"
|
||||
},
|
||||
"their_comment": "产品经理从用户体验角度提出的建议'每条结论标注证据来源链接'方向正确，但'显示文献覆盖率和证据强度评分'需要谨慎。'证据强度评分'涉及专业判断，AI评分可能给用户造成'虚假的专业感'",
|
||||
"my_decision": "partial",
|
||||
"my_response": "部分接受AI专家的观点。我认同'证据强度评分'存在给用户造成虚假专业感的风险，这是AI能力边界问题。但作为产品经理，我需要平衡'降低用户理解门槛'和'避免过度承诺'。接受AI专家建议将'证据强度评分'改为'研究类型分布'呈现方式。但关于'文献覆盖率'，我认为仍有价值——可以定义为'相对于搜索返回总量的纳入比例'，帮助用户理解报告的筛选逻辑。",
|
||||
"action": "modify",
|
||||
"modification": "将建议修改为：'(1)证据来源链接必须实现（每条结论标注对应文献）；(2)显示研究类型分布（如：包含3项RCT、5项队列研究等），替代AI直接评分；(3)展示文献筛选逻辑（如：搜索到200篇，相关性筛选后纳入50篇）'"
|
||||
},
|
||||
{
|
||||
"from_expert": "AI专家",
|
||||
"from_file": "temp/evaluate_ai.json",
|
||||
"evaluation_index": 4,
|
||||
"their_target": {
|
||||
"my_file": "temp/review_pm.json",
|
||||
"my_item_type": "issue",
|
||||
"my_item_index": 4,
|
||||
"my_item_content": "报告输出形式单一：仅支持结构化中文报告，未考虑用户对不同格式和深度的需求"
|
||||
},
|
||||
"their_comment": "建议'报告详略程度可选'从产品角度合理，但从AI能力角度需要注意：不同详略程度需要不同的生成策略，不是简单的截取或扩展",
|
||||
"my_decision": "accept",
|
||||
"my_response": "完全接受AI专家的技术分析。我作为产品经理确实低估了'详略程度可选'的技术复杂度。AI专家指出摘要版需要高质量信息压缩能力，详细版需要更多推理综合能力，这是不同的AI任务而非简单的后处理。接受建议：MVP阶段仅提供标准版，如后续需要多版本，应分别定义质量标准和验收指标。",
|
||||
"action": "modify",
|
||||
"modification": "将建议修改为：'MVP阶段仅提供标准版报告格式，聚焦核心价值验证。如后续版本需支持详略程度可选，应将不同版本视为独立的AI任务，分别定义质量标准和验收指标'"
|
||||
},
|
||||
{
|
||||
"from_expert": "领域专家",
|
||||
"from_file": "temp/evaluate_domain.json",
|
||||
"evaluation_index": 2,
|
||||
"their_target": {
|
||||
"my_file": "temp/review_pm.json",
|
||||
"my_item_type": "issue",
|
||||
"my_item_index": 2,
|
||||
"my_item_content": "缺少关键使用场景：仅覆盖'文献综述撰写'和'研究题目探索'两个场景，但目标用户群体的其他高频场景未涉及"
|
||||
},
|
||||
"their_comment": "产品经理建议补充'医学生临床问题查证场景'是有价值的，但该场景的需求应该更具体化。精神科临床决策支持与学术研究综述有本质区别。",
|
||||
"my_decision": "accept",
|
||||
"my_response": "完全接受领域专家的专业意见。我原始建议确实过于笼统。领域专家指出精神科临床决策支持更关注指南推荐级别、禁忌症与注意事项、药物相互作用等实用信息，而非全面的文献回顾——这是我未考虑到的领域专业知识。需要区分'临床决策支持'与'学术研究综述'两类需求的差异化处理策略。",
|
||||
"action": "modify",
|
||||
"modification": "将建议修改为：'建议明确区分两类使用场景并差异化设计：(1)学术研究场景：当前需求文档已覆盖的文献综述、研究探索；(2)临床决策支持场景：诊断鉴别依据、治疗方案选择、药物选择与剂量调整等，输出格式应更聚焦实用信息（指南推荐级别、禁忌症等）而非全面文献回顾。MVP阶段可先聚焦学术研究场景，临床决策支持作为Phase 2扩展'"
|
||||
},
|
||||
{
|
||||
"from_expert": "领域专家",
|
||||
"from_file": "temp/evaluate_domain.json",
|
||||
"evaluation_index": 3,
|
||||
"their_target": {
|
||||
"my_file": "temp/review_pm.json",
|
||||
"my_item_type": "user_experience_concerns",
|
||||
"my_item_index": 2,
|
||||
"my_item_content": "专业术语和概念的理解门槛：不同层次用户对精神疾病领域术语的熟悉程度不同"
|
||||
},
|
||||
"their_comment": "产品经理关注不同用户的术语理解差异是正确的，但其建议'根据用户角色调整报告语言复杂度'需要谨慎实施。精神科专业术语的简化必须确保准确性，不能为了通俗性而牺牲专业精确性。",
|
||||
"my_decision": "accept",
|
||||
"my_response": "完全接受领域专家的专业判断。我原始建议'根据用户角色调整报告语言复杂度'确实存在风险。领域专家指出'精神分裂症'不能简化为'精神病'，'抑郁发作'与'抑郁症'有明确的临床区别——这些都是我作为非医学专业人士容易忽视的问题。接受'保持专业术语+增加解释注释'的方案，这样既满足初级用户理解需求，又不损失专业准确性。",
|
||||
"action": "modify",
|
||||
"modification": "将建议修改为：'采用'保持专业术语+增加解释注释'的方式处理术语理解门槛问题：(1)报告中保持精神科专业术语的规范使用，确保专业准确性；(2)对核心专业术语提供悬浮解释或脚注；(3)提供概念关系图辅助理解。不采用直接简化术语的方式，避免损失专业精确性'"
|
||||
}
|
||||
]
|
||||
}
|
||||
130
.claude/skills/requirement-generator-v1/temp/review_ai.json
Normal file
130
.claude/skills/requirement-generator-v1/temp/review_ai.json
Normal file
@ -0,0 +1,130 @@
|
||||
{
|
||||
"reviewer_role": "AI专家",
|
||||
"review_date": "2025-12-07",
|
||||
"document_path": "D:\\AA_Work\\AIEC-团队开发规范Skills\\.claude\\skills\\requirement-generator-v1\\requirement.md",
|
||||
|
||||
"strengths": [
|
||||
"优点1：Multi-Agent架构设计合理，职责分工明确，调度Agent、搜索Agent、分析Agent、报告生成Agent、去重Agent各司其职，符合复杂任务分解的最佳实践",
|
||||
"优点2：Agent能力边界定义清晰（第6.2节），明确划分了各Agent'能做'与'不能做'的范围，有助于避免职责混乱",
|
||||
"优点3：分阶段交付计划合理，MVP阶段聚焦核心价值验证，知识图谱作为完整功能在第二阶段引入，避免功能割裂",
|
||||
"优点4：异常处理场景考虑周全（第4.2节），包括数据源失败、空结果、文献过多、重复识别等场景",
|
||||
"优点5：允许小时级执行时间，对AI深度分析任务的时间预期合理，未过度追求不切实际的响应速度"
|
||||
],
|
||||
|
||||
"issues": [
|
||||
{
|
||||
"severity": "high",
|
||||
"category": "质量标准",
|
||||
"description": "引用准确性验收标准缺乏量化指标。文档仅表述'每篇文献都能在对应数据源中找到原文'，但未定义可接受的准确率阈值，也未说明如何处理AI生成幻觉引用的风险",
|
||||
"location": "第9.1节 功能验收标准 - 引用准确性",
|
||||
"suggestion": "建议明确：(1)引用准确率目标值（如>98%）；(2)幻觉检测机制（如引用验证Agent）；(3)人工抽查的抽样比例和方法"
|
||||
},
|
||||
{
|
||||
"severity": "high",
|
||||
"category": "智能化适用性",
|
||||
"description": "证据等级评估的AI能力边界未明确。证据等级评估（如牛津证据等级、GRADE评分）是专业性极强的任务，需要理解研究设计、统计方法、偏倚风险等，当前LLM在此任务上的可靠性存疑",
|
||||
"location": "第3.2节 输出 - 研究方法与证据等级；第6.1节 分析Agent职能",
|
||||
"suggestion": "建议：(1)明确证据等级评估的标准体系（如采用Oxford还是GRADE）；(2)定义AI评估的准确率目标；(3)考虑人工复核机制或标注AI评估的置信度"
|
||||
},
|
||||
{
|
||||
"severity": "high",
|
||||
"category": "能力要求",
|
||||
"description": "知识图谱的'实体语义去重'能力要求过高。跨语言（中英文）、跨数据源的医学实体语义相似度判断（如判断'精神分裂症'与'Schizophrenia'为同一实体）需要强大的领域知识和对齐能力，当前方案未说明如何实现",
|
||||
"location": "第6.1节 去重Agent职能；第7.2节 完整去重机制",
|
||||
"suggestion": "建议：(1)引入标准医学术语库（如UMLS、MeSH）作为对齐基准；(2)明确语义相似度的判定阈值；(3)定义去重准确率目标"
|
||||
},
|
||||
{
|
||||
"severity": "medium",
|
||||
"category": "人机协作与降级",
|
||||
"description": "缺乏AI分析结果的人工确认机制。文献分析、证据等级评估、知识空白识别等任务的输出直接生成报告，未设计用户确认或修正的环节",
|
||||
"location": "第4.1节 典型主流程；第6.1节 分析Agent",
|
||||
"suggestion": "建议增加：(1)关键分析结果的用户确认步骤；(2)报告生成前的摘要预览与用户反馈机制；(3)报告输出后的纠错/补充入口"
|
||||
},
|
||||
{
|
||||
"severity": "medium",
|
||||
"category": "质量标准",
|
||||
"description": "'复杂问题处理'验收标准过于模糊。'能处理多维度、跨领域的精神疾病研究问题'缺乏具体定义，什么算'多维度'？什么算'跨领域'？如何验证'处理成功'？",
|
||||
"location": "第9.1节 功能验收标准 - 复杂问题处理",
|
||||
"suggestion": "建议：(1)定义3-5个典型复杂问题测试用例；(2)明确复杂问题的评判维度（如涉及的疾病类型数量、治疗方法数量等）；(3)定义处理成功的标准"
|
||||
},
|
||||
{
|
||||
"severity": "medium",
|
||||
"category": "能力要求",
|
||||
"description": "报告生成Agent的'综合分析'能力边界不清。将多篇文献的发现进行综合分析、识别知识空白、提出研究方向，这需要较强的推理和创造性，但文档未说明期望的分析深度和可靠性要求",
|
||||
"location": "第3.2节 报告结构 - 研究结论与知识空白；第6.1节 报告生成Agent",
|
||||
"suggestion": "建议：(1)明确综合分析的深度要求（如是否需要提出创新性见解）；(2)区分'事实性总结'与'推断性分析'的边界；(3)对推断性内容标注置信度或来源"
|
||||
},
|
||||
{
|
||||
"severity": "medium",
|
||||
"category": "任务复杂度",
|
||||
"description": "调度Agent的'问题解析与搜索策略制定'能力要求可能被低估。将自然语言研究问题转化为多数据源的有效检索式（如PubMed的MeSH词+布尔逻辑）是需要专业知识的复杂任务",
|
||||
"location": "第6.1节 调度Agent职能；第4.1节 问题解析",
|
||||
"suggestion": "建议：(1)提供检索策略模板或规则；(2)考虑用户确认或调整搜索策略的环节；(3)定义搜索召回率/准确率的验收指标"
|
||||
},
|
||||
{
|
||||
"severity": "low",
|
||||
"category": "智能化适用性",
|
||||
"description": "全文获取服务标注为'可选'，但部分分析任务（如证据等级评估、方法学分析）可能需要全文信息，仅依赖摘要可能导致分析质量下降",
|
||||
"location": "第5.2节 系统集成需求 - 文献全文获取服务",
|
||||
"suggestion": "建议明确：(1)仅依赖摘要时的功能降级范围；(2)哪些分析任务必须依赖全文；(3)全文不可用时的处理策略"
|
||||
},
|
||||
{
|
||||
"severity": "low",
|
||||
"category": "分阶段演进",
|
||||
"description": "MVP阶段'暂不使用知识图谱'，但去重需求（如同一文献在PubMed和Embase都出现）在MVP阶段同样存在，未说明MVP阶段如何处理",
|
||||
"location": "第7.1节 阶段1功能清单",
|
||||
"suggestion": "建议明确MVP阶段的简化去重策略（如仅基于DOI/PMID的精确匹配去重）"
|
||||
}
|
||||
],
|
||||
|
||||
"missing_items": [
|
||||
"遗漏项：未定义AI生成内容的幻觉检测与防范机制。文献引用、研究发现等内容存在AI编造的风险，需要明确验证机制",
|
||||
"遗漏项：未说明搜索Agent访问各数据源的API/接口方式及限制（如PubMed API的访问频率限制、PsycINFO的授权要求等）",
|
||||
"遗漏项：未定义分析Agent处理单次任务的文献数量上限。当搜索返回数百篇文献时，AI分析的上下文长度限制如何处理？",
|
||||
"遗漏项：未说明知识图谱的Schema设计（实体类型、关系类型、属性定义），这对后续开发有重要影响",
|
||||
"遗漏项：未定义报告生成的格式输出能力（如是否支持导出Word/PDF、引用格式是否可配置如APA/Vancouver等）"
|
||||
],
|
||||
|
||||
"ai_risks": [
|
||||
{
|
||||
"risk_level": "high",
|
||||
"description": "引用幻觉风险：LLM在生成引用时可能编造不存在的文献（包括作者、标题、期刊、DOI等），这是当前大模型的已知弱点",
|
||||
"impact": "严重损害研究报告的学术可信度，可能导致用户引用不存在的文献",
|
||||
"mitigation": "建议：(1)所有引用必须来自搜索Agent返回的实际文献列表，报告生成Agent禁止自行'补充'引用；(2)增加引用验证Agent进行回查；(3)在报告中明确标注'所有引用均经过来源验证'"
|
||||
},
|
||||
{
|
||||
"risk_level": "high",
|
||||
"description": "证据等级评估不可靠风险：证据等级评估需要理解研究设计细节（如随机化方法、盲法、样本量计算等），LLM可能给出看似合理但实际错误的评估",
|
||||
"impact": "误导用户对研究证据的判断，可能影响医疗决策参考",
|
||||
"mitigation": "建议：(1)证据等级评估结果标注'AI初评，建议人工复核'；(2)提供评估依据的透明说明；(3)MVP阶段可考虑简化为研究类型分类而非证据等级评估"
|
||||
},
|
||||
{
|
||||
"risk_level": "medium",
|
||||
"description": "跨语言语义理解偏差风险：中英文医学术语的对齐（如'精神分裂症'与'Schizophrenia'的各种变体）可能出现错误，导致去重遗漏或错误合并",
|
||||
"impact": "知识图谱质量下降，可能遗漏重要文献或错误合并不同概念",
|
||||
"mitigation": "建议：(1)优先使用标准术语库（MeSH、ICD-11）进行术语对齐；(2)语义相似度判断设置保守阈值；(3)对高不确定性的合并进行人工确认"
|
||||
},
|
||||
{
|
||||
"risk_level": "medium",
|
||||
"description": "上下文长度限制风险：当搜索返回大量文献（如100+篇）时，LLM无法在单次推理中处理所有内容，需要分批处理可能导致信息遗漏或不一致",
|
||||
"impact": "文献分析可能不完整，综合结论可能遗漏重要发现",
|
||||
"mitigation": "建议：(1)定义分批处理策略和信息汇总机制；(2)对长文献列表进行相关性排序，优先处理高相关性文献；(3)明确告知用户'已分析X篇文献，另有Y篇待后续分析'"
|
||||
},
|
||||
{
|
||||
"risk_level": "low",
|
||||
"description": "Agent协作一致性风险：多Agent异步协作可能导致信息传递偏差，如搜索Agent返回的文献在传递给分析Agent时信息丢失或变形",
|
||||
"impact": "可能导致分析结果与原始文献不符",
|
||||
"mitigation": "建议：(1)定义Agent间数据交换的标准格式；(2)关键信息（如DOI、引用格式）全程保持原始值透传；(3)增加端到端的一致性校验"
|
||||
}
|
||||
],
|
||||
|
||||
"suggestions": [
|
||||
"建议1：增加'引用验证Agent'角色，专门负责校验报告中的每条引用是否与搜索结果一致，防止幻觉引用",
|
||||
"建议2：将证据等级评估任务降级为'研究类型分类'（如RCT/队列研究/病例报告等），减少AI判断的主观性和错误风险",
|
||||
"建议3：在报告输出中增加'AI置信度声明'，对事实性内容和推断性内容进行区分标注",
|
||||
"建议4：MVP阶段建议先实现用户对搜索策略的确认和调整功能，确保检索方向正确后再进行分析",
|
||||
"建议5：建议引入MeSH/UMLS等标准医学术语库，作为跨语言术语对齐的基准，提升去重准确性",
|
||||
"建议6：明确定义单次任务的文献处理上限（如50篇），超出时提供分批处理或用户筛选机制",
|
||||
"建议7：考虑增加'分析结果预览'环节，在生成完整报告前让用户确认关键发现是否准确"
|
||||
]
|
||||
}
|
||||
116
.claude/skills/requirement-generator-v1/temp/review_dev.json
Normal file
116
.claude/skills/requirement-generator-v1/temp/review_dev.json
Normal file
@ -0,0 +1,116 @@
|
||||
{
|
||||
"reviewer_role": "开发专家",
|
||||
"strengths": [
|
||||
"Multi-Agent架构设计清晰：调度Agent、搜索Agent、分析Agent、报告生成Agent、去重Agent职责划分明确，符合单一职责原则",
|
||||
"并行搜索设计合理：多数据源并行搜索能有效提升效率，时序图清晰展示了协作关系",
|
||||
"分阶段交付策略务实：MVP版本聚焦核心价值验证，第二阶段再引入知识图谱，降低了初期技术风险",
|
||||
"异常处理考虑周全：数据源访问失败、搜索结果为空、文献过多、重复文献等场景都有对应处理方案",
|
||||
"Agent能力边界定义清晰：明确列出了每个Agent'能做'和'不能做'的范围，有助于开发实现"
|
||||
],
|
||||
"issues": [
|
||||
{
|
||||
"severity": "high",
|
||||
"category": "技术可行性",
|
||||
"description": "外部数据源API访问可行性未验证：PsycINFO、Embase、Cochrane Library等商业数据库需要机构订阅和API授权，CNKI和万方的API调用政策限制严格，个人/小团队难以获得合法稳定的API访问权限",
|
||||
"location": "5.1 外部数据源需求",
|
||||
"suggestion": "1) 在MVP阶段仅使用免费开放API的数据源（如PubMed E-utilities、bioRxiv API）；2) 明确标注各数据源的授权获取方式和成本；3) 对于无法直接API访问的数据源，考虑提供手动导入或浏览器插件辅助方案"
|
||||
},
|
||||
{
|
||||
"severity": "high",
|
||||
"category": "架构合理性",
|
||||
"description": "知识图谱技术选型和存储方案未明确：需求中提到'知识图谱存储系统'但未说明具体技术选型（Neo4j/ArangoDB/RDF Store等）、数据模型设计、以及'语义去重'的具体实现算法",
|
||||
"location": "5.2 系统集成需求 / 8.1 技术约束",
|
||||
"suggestion": "1) 明确知识图谱的技术选型及选型理由；2) 定义知识图谱的本体模型（节点类型、关系类型、属性）；3) 详细说明'实体语义去重'的技术方案（基于规则/向量相似度/LLM判断）"
|
||||
},
|
||||
{
|
||||
"severity": "high",
|
||||
"category": "技术可行性",
|
||||
"description": "实时进度展示的技术实现方式不明确：Multi-Agent并行执行时如何实现'实时'进度反馈？是使用WebSocket、SSE还是轮询？Agent间如何传递进度状态？",
|
||||
"location": "4.1 典型主流程 / 8.2 性能要求",
|
||||
"suggestion": "1) 明确进度反馈的技术实现机制（推荐SSE或WebSocket）；2) 定义进度事件的数据结构；3) 说明Agent间状态同步机制"
|
||||
},
|
||||
{
|
||||
"severity": "medium",
|
||||
"category": "架构合理性",
|
||||
"description": "Agent通信机制未定义：Multi-Agent架构中，Agent之间如何通信？是通过消息队列、直接调用、还是共享内存？调度Agent如何等待并收集所有搜索Agent的结果？",
|
||||
"location": "6.3 Agent间协作关系",
|
||||
"suggestion": "1) 明确Agent间通信的技术方案（推荐消息队列如Redis Stream或进程内事件总线）；2) 定义消息格式和协议；3) 说明并行任务的超时和重试机制"
|
||||
},
|
||||
{
|
||||
"severity": "medium",
|
||||
"category": "性能要求",
|
||||
"description": "'合理时间内完成（允许小时级）'表述模糊：小时级是1小时还是10小时？不同复杂度的研究问题是否有不同的时间预期？",
|
||||
"location": "9.2 非功能验收标准",
|
||||
"suggestion": "1) 按问题复杂度分级定义时间预期（简单问题30分钟内，复杂问题2小时内）；2) 定义超时机制和用户中断接口"
|
||||
},
|
||||
{
|
||||
"severity": "medium",
|
||||
"category": "技术可行性",
|
||||
"description": "证据等级评估的实现复杂度被低估：医学领域的证据等级评估（如GRADE标准）需要专业知识和结构化判断，仅依靠LLM分析可能准确性不足",
|
||||
"location": "3.2 输出 / 6.1 Agent列表",
|
||||
"suggestion": "1) 明确证据等级评估的具体标准（GRADE/Oxford等）；2) 考虑结合文献元数据（研究类型、样本量）进行规则化判断；3) 标注评估结果仅供参考，需人工复核"
|
||||
},
|
||||
{
|
||||
"severity": "medium",
|
||||
"category": "架构合理性",
|
||||
"description": "全文获取服务的可选性带来功能一致性风险：文档标注'文献全文获取服务（可选）'，但分析Agent的深度分析能力高度依赖全文内容，仅靠摘要难以实现高质量分析",
|
||||
"location": "5.2 系统集成需求",
|
||||
"suggestion": "1) 评估仅基于摘要分析的可行性和质量影响；2) 如全文为可选，需在报告中明确标注分析深度受限；3) 考虑使用Unpaywall等开放全文获取渠道"
|
||||
},
|
||||
{
|
||||
"severity": "low",
|
||||
"category": "技术风险",
|
||||
"description": "多数据源返回结果的格式标准化未考虑：不同数据源（PubMed XML、CNKI自有格式等）返回的文献元数据格式差异大，需要统一的数据模型和转换层",
|
||||
"location": "5.1 外部数据源需求",
|
||||
"suggestion": "1) 定义统一的文献元数据模型；2) 每个搜索Agent负责将源格式转换为统一格式；3) 处理字段缺失的情况"
|
||||
},
|
||||
{
|
||||
"severity": "low",
|
||||
"category": "技术可行性",
|
||||
"description": "中英文混合处理的技术挑战未评估：同一研究问题涉及中英文文献时，关键词翻译、术语对齐、结果融合都存在技术难点",
|
||||
"location": "3.1 输入 / 8.4 其他非功能性要求",
|
||||
"suggestion": "1) 明确中英文关键词的翻译/对齐策略；2) 定义中英文文献的融合排序规则；3) 考虑使用医学术语库（如UMLS）辅助术语标准化"
|
||||
}
|
||||
],
|
||||
"missing_items": [
|
||||
"缺少技术栈选型说明：未明确开发语言、框架、部署环境等基础技术决策",
|
||||
"缺少LLM模型选型和调用方式：Agent的智能能力依赖LLM，但未说明使用哪个模型、API调用方式、Token消耗预估",
|
||||
"缺少错误恢复机制说明：长时间运行的任务如何支持断点续传或中间结果保存",
|
||||
"缺少并发控制策略：10人同时使用时如何管理API调用配额和系统资源",
|
||||
"缺少数据持久化方案：除知识图谱外，研究报告、搜索历史如何存储",
|
||||
"缺少监控和日志方案：分布式Agent系统的问题排查和性能监控机制"
|
||||
],
|
||||
"tech_risks": [
|
||||
{
|
||||
"risk_level": "high",
|
||||
"description": "商业数据库API访问受限风险",
|
||||
"impact": "PsycINFO、Embase等核心数据源无法接入，导致文献覆盖不全面，核心价值受损",
|
||||
"mitigation": "1) 优先评估各数据源API可用性；2) 准备替代方案（如通过机构账号网页抓取，但需评估合规性）；3) MVP阶段仅承诺PubMed"
|
||||
},
|
||||
{
|
||||
"risk_level": "high",
|
||||
"description": "知识图谱去重准确性风险",
|
||||
"impact": "'语义去重'依赖NLP/向量匹配，可能出现误判（重复未识别或错误合并），影响报告质量",
|
||||
"mitigation": "1) 分层去重：先DOI/PMID精确匹配，再标题相似度，最后语义判断；2) 设置相似度阈值，边界情况保留两者；3) 提供人工复核入口"
|
||||
},
|
||||
{
|
||||
"risk_level": "medium",
|
||||
"description": "LLM调用成本和延迟风险",
|
||||
"impact": "大量文献分析需频繁调用LLM，可能产生高额API费用，且存在速率限制",
|
||||
"mitigation": "1) 预估单次研究的Token消耗和成本；2) 使用分层模型策略（简单任务用小模型）；3) 实现本地缓存避免重复分析"
|
||||
},
|
||||
{
|
||||
"risk_level": "medium",
|
||||
"description": "长时间任务稳定性风险",
|
||||
"impact": "小时级任务期间可能遇到网络中断、进程崩溃，导致研究结果丢失",
|
||||
"mitigation": "1) 实现检查点机制保存中间状态；2) 支持任务恢复和断点续传；3) 设置合理超时，避免无限等待"
|
||||
}
|
||||
],
|
||||
"suggestions": [
|
||||
"建议增加技术选型章节：明确开发语言（Python推荐）、Agent框架（LangGraph/AutoGen/CrewAI）、知识图谱（Neo4j Community版）、消息队列（Redis）等核心技术决策",
|
||||
"建议增加POC验证步骤：在正式开发前，验证核心数据源API可用性、知识图谱去重效果、LLM分析质量三个关键技术点",
|
||||
"建议细化MVP验收标准：当前验收标准偏定性，建议增加定量指标如'引用准确率>=95%'、'去重准确率>=90%'",
|
||||
"建议增加成本预估：预估MVP和完整版的API调用成本、存储成本、运维成本，确保商业可行性",
|
||||
"建议采用增量式知识图谱更新：每次研究任务后增量更新，而非全量重建，提高效率和数据一致性"
|
||||
]
|
||||
}
|
||||
163
.claude/skills/requirement-generator-v1/temp/review_domain.json
Normal file
163
.claude/skills/requirement-generator-v1/temp/review_domain.json
Normal file
@ -0,0 +1,163 @@
|
||||
{
|
||||
"reviewer_role": "精神科医生",
|
||||
"domain": "精神医学/精神疾病研究",
|
||||
"strengths": [
|
||||
"目标用户定义准确：明确了科研人员、医学生和医疗信息分析师三类核心用户，符合精神科文献研究的实际使用场景",
|
||||
"数据源选择合理：PubMed、PsycINFO、Embase是精神科文献检索的核心数据库，Cochrane Library对于获取高质量系统评价至关重要",
|
||||
"报告结构包含证据等级评估：这是循证精神医学的核心要求，有助于临床决策",
|
||||
"支持中英文文献处理：精神科研究需要同时关注国际和国内研究进展，这一设计符合实际需求",
|
||||
"并行多数据源搜索策略：能够提高文献覆盖的全面性，减少遗漏重要研究的风险"
|
||||
],
|
||||
"issues": [
|
||||
{
|
||||
"severity": "high",
|
||||
"category": "领域合规性",
|
||||
"description": "缺少诊断标准版本标注功能：精神科文献分析必须注意诊断标准的演变（DSM-IV vs DSM-5, ICD-10 vs ICD-11），不同版本的诊断标准可能导致研究结果不可比",
|
||||
"location": "第3.2节 输出-报告结构",
|
||||
"suggestion": "在文献分析和报告中增加'诊断标准版本'字段，自动识别并标注每篇文献采用的诊断标准版本，并在报告中专门说明诊断标准差异对结果解读的影响",
|
||||
"domain_specific": true
|
||||
},
|
||||
{
|
||||
"severity": "high",
|
||||
"category": "业务流程",
|
||||
"description": "证据等级评估方法未明确：精神科遵循循证医学原则，需要明确采用何种证据分级体系（如GRADE、Oxford证据等级），以及如何处理不同研究设计（RCT、队列研究、病例对照等）的证据权重",
|
||||
"location": "第3.2节 报告结构-研究方法与证据等级",
|
||||
"suggestion": "明确指定采用GRADE证据分级体系或Oxford证据等级标准，并在系统中建立研究设计类型的自动识别和分级逻辑",
|
||||
"domain_specific": true
|
||||
},
|
||||
{
|
||||
"severity": "high",
|
||||
"category": "数据要求",
|
||||
"description": "未涵盖临床试验注册库：精神科药物和治疗研究需要关注ClinicalTrials.gov、WHO ICTRP等临床试验注册库，这对于了解正在进行的研究和发表偏倚评估至关重要",
|
||||
"location": "第5.1节 外部数据源需求",
|
||||
"suggestion": "在数据源列表中增加ClinicalTrials.gov和WHO ICTRP作为扩展数据源，用于获取正在进行和已完成但未发表的临床试验信息",
|
||||
"domain_specific": true
|
||||
},
|
||||
{
|
||||
"severity": "medium",
|
||||
"category": "领域合规性",
|
||||
"description": "缺少专业术语规范化处理：精神科术语有严格规范（如'精神分裂症'而非'精神病'，'双相障碍'而非'躁郁症'），系统应能识别并规范化用户输入的非标准术语",
|
||||
"location": "第3.1节 输入",
|
||||
"suggestion": "建立精神科标准术语库（基于DSM-5/ICD-11），在问题解析阶段自动识别并提示用户使用规范术语，或自动映射到标准术语进行搜索",
|
||||
"domain_specific": true
|
||||
},
|
||||
{
|
||||
"severity": "medium",
|
||||
"category": "业务流程",
|
||||
"description": "未区分药物治疗与非药物治疗的文献分析逻辑：精神科治疗分为药物治疗（抗精神病药、抗抑郁药等）和非药物治疗（心理治疗、物理治疗如TMS/ECT），两类研究的评估指标和证据要求不同",
|
||||
"location": "第6.1节 Agent列表-分析Agent",
|
||||
"suggestion": "在分析Agent的能力中增加治疗类型分类功能，针对不同治疗类型采用不同的分析框架和评估指标",
|
||||
"domain_specific": true
|
||||
},
|
||||
{
|
||||
"severity": "medium",
|
||||
"category": "风险识别",
|
||||
"description": "缺少药物安全性数据的特别关注：精神科药物（尤其是抗精神病药）有重要的安全性问题（如代谢综合征、锥体外系反应、心脏QT延长），文献分析应特别提取安全性数据",
|
||||
"location": "第3.2节 输出-报告结构",
|
||||
"suggestion": "在报告结构中增加'安全性与不良反应'章节，专门汇总药物治疗相关文献的安全性数据和长期随访结果",
|
||||
"domain_specific": true
|
||||
},
|
||||
{
|
||||
"severity": "medium",
|
||||
"category": "业务流程",
|
||||
"description": "未提及临床实践指南的整合：精神科有多个权威临床指南（APA指南、NICE指南、WFSBP指南、中国精神科指南），系统应能识别并优先呈现指南级证据",
|
||||
"location": "第5.1节 外部数据源需求",
|
||||
"suggestion": "增加主要精神科临床指南数据库或链接，在报告中专门标注与现行指南一致或冲突的研究发现",
|
||||
"domain_specific": true
|
||||
},
|
||||
{
|
||||
"severity": "low",
|
||||
"category": "领域合规性",
|
||||
"description": "输入示例专业术语可进一步优化：示例'近5年精神分裂症认知功能障碍的非药物治疗进展'使用正确，但建议增加更多体现专业深度的示例",
|
||||
"location": "第3.1节 输入示例",
|
||||
"suggestion": "增加如'治疗抵抗性抑郁症的增效治疗策略'、'首发精神分裂症的早期干预证据'等更专业的示例",
|
||||
"domain_specific": true
|
||||
},
|
||||
{
|
||||
"severity": "low",
|
||||
"category": "数据要求",
|
||||
"description": "未明确处理预印本文献的风险提示：预印本（bioRxiv/medRxiv）未经同行评审，在精神科临床决策中需谨慎使用",
|
||||
"location": "第5.1节 外部数据源需求",
|
||||
"suggestion": "在报告中对预印本来源的文献进行明确标注和风险提示，说明其未经同行评审的局限性",
|
||||
"domain_specific": true
|
||||
}
|
||||
],
|
||||
"missing_items": [
|
||||
"缺少量表和评估工具识别功能：精神科研究大量使用标准化量表（如PANSS、HAM-D、MADRS等），系统应能识别和提取文献中使用的评估量表",
|
||||
"缺少随访时长信息提取：精神疾病多为慢性病程，长期随访数据对评估治疗效果至关重要，报告应汇总各研究的随访时长",
|
||||
"缺少样本特征汇总：精神科研究需关注样本的疾病亚型、病程、共病情况等，这些影响结果的可推广性",
|
||||
"缺少研究质量评估工具整合：如Cochrane偏倚风险评估工具、Newcastle-Ottawa量表等，用于评估纳入文献的方法学质量"
|
||||
],
|
||||
"domain_risks": [
|
||||
{
|
||||
"risk_level": "high",
|
||||
"description": "诊断标准不一致导致的研究可比性问题：不同年代的研究可能采用不同版本的诊断标准（DSM-III, DSM-IV, DSM-5），直接比较可能产生误导性结论",
|
||||
"regulation": "DSM-5 (APA, 2013), ICD-11 (WHO, 2019)",
|
||||
"impact": "可能导致对治疗效果的错误评估，影响临床决策",
|
||||
"mitigation": "系统应自动识别并标注诊断标准版本，在综合分析时考虑标准差异的影响"
|
||||
},
|
||||
{
|
||||
"risk_level": "high",
|
||||
"description": "药物安全性信息遗漏风险：仅关注疗效数据而忽视安全性数据可能导致不完整的研究结论",
|
||||
"regulation": "FDA药物安全性监管要求, CFDA药品不良反应监测规定",
|
||||
"impact": "可能遗漏重要的安全性警示信息，影响用药决策",
|
||||
"mitigation": "在分析框架中强制纳入安全性数据提取模块，报告必须包含安全性章节"
|
||||
},
|
||||
{
|
||||
"risk_level": "medium",
|
||||
"description": "预印本证据误用风险：预印本未经同行评审，其结论可能存在方法学问题",
|
||||
"regulation": "循证医学证据等级标准",
|
||||
"impact": "可能将不可靠的研究结论纳入分析，影响综述质量",
|
||||
"mitigation": "对预印本来源进行明确标识，降低其在证据综合中的权重"
|
||||
},
|
||||
{
|
||||
"risk_level": "medium",
|
||||
"description": "发表偏倚未充分评估：阴性结果研究较少发表，可能导致对治疗效果的高估",
|
||||
"regulation": "Cochrane系统评价手册对发表偏倚的评估要求",
|
||||
"impact": "可能系统性高估治疗效果",
|
||||
"mitigation": "整合临床试验注册库数据，识别已注册但未发表的研究，在报告中评估发表偏倚风险"
|
||||
}
|
||||
],
|
||||
"compliance_checklist": [
|
||||
{
|
||||
"requirement": "诊断标准规范（DSM-5/ICD-11）",
|
||||
"status": "missing",
|
||||
"note": "需求文档未提及诊断标准版本的识别和标注功能"
|
||||
},
|
||||
{
|
||||
"requirement": "循证医学证据分级体系",
|
||||
"status": "unclear",
|
||||
"note": "提及了证据等级评估但未明确采用何种标准体系（GRADE/Oxford等）"
|
||||
},
|
||||
{
|
||||
"requirement": "临床指南整合",
|
||||
"status": "missing",
|
||||
"note": "未提及APA、NICE、WFSBP等权威临床指南的整合"
|
||||
},
|
||||
{
|
||||
"requirement": "安全性数据监测",
|
||||
"status": "missing",
|
||||
"note": "报告结构中未包含专门的安全性与不良反应章节"
|
||||
},
|
||||
{
|
||||
"requirement": "研究伦理规范",
|
||||
"status": "satisfied",
|
||||
"note": "文档明确说明主要处理公开学术文献，不涉及患者隐私数据"
|
||||
},
|
||||
{
|
||||
"requirement": "专业术语规范使用",
|
||||
"status": "unclear",
|
||||
"note": "输入示例使用了规范术语，但未说明系统如何处理非标准术语输入"
|
||||
}
|
||||
],
|
||||
"suggestions": [
|
||||
"建立精神科专业术语规范化模块：整合DSM-5和ICD-11术语体系，实现用户输入的自动规范化转换",
|
||||
"增加临床试验注册库作为数据源：整合ClinicalTrials.gov和WHO ICTRP，支持发表偏倚评估和研究完整性分析",
|
||||
"完善证据等级评估体系：明确采用GRADE或Oxford证据等级标准，建立研究设计类型的自动识别逻辑",
|
||||
"增加安全性数据专项提取：在分析框架中加入不良反应、长期安全性、药物相互作用等数据的提取模块",
|
||||
"整合主要临床实践指南：建立APA、NICE、WFSBP、中国精神科指南的索引，在报告中标注研究发现与指南的一致性",
|
||||
"建立常用精神科量表库：收录PANSS、HAM-D、MADRS、CGI等常用量表，自动识别文献中的评估工具",
|
||||
"增加研究质量评估功能：整合Cochrane偏倚风险工具和Newcastle-Ottawa量表，系统化评估纳入文献的方法学质量",
|
||||
"MVP阶段合规性建议：即使在MVP阶段，也应包含诊断标准版本标注和基本的证据等级评估，这是精神科文献分析的最低专业要求"
|
||||
]
|
||||
}
|
||||
116
.claude/skills/requirement-generator-v1/temp/review_pm.json
Normal file
116
.claude/skills/requirement-generator-v1/temp/review_pm.json
Normal file
@ -0,0 +1,116 @@
|
||||
{
|
||||
"reviewer_role": "产品经理",
|
||||
"strengths": [
|
||||
"目标用户定义清晰：明确划分科研人员、医学生、医疗信息分析师三类用户群体，用户画像具体",
|
||||
"使用场景描述完整：提供了文献综述撰写和研究题目探索两个典型场景，包含触发条件、操作步骤和预期结果",
|
||||
"交互流程可视化：使用Mermaid图清晰展示主流程和Agent间协作关系，便于理解系统运作机制",
|
||||
"输入输出定义规范：明确了输入格式（自然语言）和输出结构（五部分报告），并提供了具体示例",
|
||||
"分阶段交付策略合理：MVP阶段聚焦核心价值验证，第二阶段再引入知识图谱等高级功能，避免功能割裂",
|
||||
"异常处理考虑周全：涵盖数据源访问失败、搜索结果为空、文献过多、重复文献等常见异常场景"
|
||||
],
|
||||
"issues": [
|
||||
{
|
||||
"severity": "high",
|
||||
"category": "业务目标",
|
||||
"description": "核心目标缺乏可量化指标：'将传统需要数天的文献调研工作压缩到小时级别完成'缺少具体基准数据，'提升研究质量'没有可衡量的评估标准",
|
||||
"location": "1.2 目标与价值 - 核心目标",
|
||||
"suggestion": "建议量化目标，如：'将5天文献调研工作缩短至4小时内'，'引用准确率达到98%以上'，'用户满意度评分达到4.5/5'"
|
||||
},
|
||||
{
|
||||
"severity": "high",
|
||||
"category": "用户需求验证",
|
||||
"description": "需求来源和验证方式不明确：文档未说明这些需求是否来自真实用户调研，没有用户痛点分析和需求优先级排序的依据",
|
||||
"location": "全文",
|
||||
"suggestion": "建议补充：1) 需求调研方法（用户访谈/问卷/竞品分析）；2) 用户当前解决方案及痛点；3) 需求优先级排序依据"
|
||||
},
|
||||
{
|
||||
"severity": "high",
|
||||
"category": "场景完整性",
|
||||
"description": "缺少关键使用场景：仅覆盖'文献综述撰写'和'研究题目探索'两个场景，但目标用户群体的其他高频场景未涉及",
|
||||
"location": "2.1 典型使用场景",
|
||||
"suggestion": "建议补充场景：1) 医学生临床问题查证场景；2) 科研人员论文写作引用场景；3) 分析师定期追踪领域动态场景；4) 多人协作共享研究成果场景"
|
||||
},
|
||||
{
|
||||
"severity": "medium",
|
||||
"category": "用户体验",
|
||||
"description": "进度反馈机制描述不够具体：仅提到'实时展示搜索进度'，但未明确进度信息的具体内容、展示形式和更新频率",
|
||||
"location": "4.1 典型主流程 - 进度展示",
|
||||
"suggestion": "建议明确：1) 进度条/百分比/文字描述的具体形式；2) 每个阶段预估耗时；3) 用户可执行的操作（暂停/取消/调整策略）"
|
||||
},
|
||||
{
|
||||
"severity": "medium",
|
||||
"category": "功能需求",
|
||||
"description": "报告输出形式单一：仅支持结构化中文报告，未考虑用户对不同格式和深度的需求",
|
||||
"location": "3.2 输出",
|
||||
"suggestion": "建议支持：1) 报告详略程度可选（摘要版/标准版/详细版）；2) 输出格式可选（Markdown/Word/PDF）；3) 英文报告选项"
|
||||
},
|
||||
{
|
||||
"severity": "medium",
|
||||
"category": "场景完整性",
|
||||
"description": "边缘场景覆盖不足：未考虑用户输入模糊问题、跨学科问题、时效性要求高的问题等边缘情况",
|
||||
"location": "2.1 典型使用场景",
|
||||
"suggestion": "建议补充：1) 模糊问题的引导澄清机制；2) 跨学科问题的处理策略；3) 用户指定时间范围/文献类型的筛选功能"
|
||||
},
|
||||
{
|
||||
"severity": "medium",
|
||||
"category": "验收标准",
|
||||
"description": "部分验收标准不够具体可测：'能处理多维度、跨领域的精神疾病研究问题'、'在合理时间内完成'缺乏明确判定标准",
|
||||
"location": "9.1 功能验收标准",
|
||||
"suggestion": "建议明确：1) 定义'复杂问题'的具体标准和测试用例；2) 明确'合理时间'的具体范围（如：50篇文献4小时内）"
|
||||
},
|
||||
{
|
||||
"severity": "low",
|
||||
"category": "功能需求",
|
||||
"description": "用户反馈和迭代机制缺失：用户对报告质量的反馈如何收集？系统如何基于反馈持续优化？",
|
||||
"location": "全文",
|
||||
"suggestion": "建议增加：1) 报告满意度评分机制；2) 用户标注引用错误/遗漏的功能；3) 基于反馈优化搜索和分析策略的机制"
|
||||
},
|
||||
{
|
||||
"severity": "low",
|
||||
"category": "功能需求",
|
||||
"description": "历史记录和知识复用功能未提及：用户能否查看历史研究？能否基于之前的研究继续深入？",
|
||||
"location": "全文",
|
||||
"suggestion": "建议补充：1) 研究历史记录查看；2) 基于历史研究的增量更新；3) 多次研究结果的对比分析"
|
||||
},
|
||||
{
|
||||
"severity": "low",
|
||||
"category": "非功能性需求",
|
||||
"description": "数据源访问成本和合规性未评估：多个数据源（PsycINFO、Embase等）需要付费订阅，CNKI等有访问限制",
|
||||
"location": "5.1 外部数据源需求",
|
||||
"suggestion": "建议评估：1) 各数据源的访问成本和授权方式；2) 学术数据库API调用限制；3) 免费替代方案的可行性"
|
||||
}
|
||||
],
|
||||
"missing_items": [
|
||||
"竞品分析：未分析现有类似产品（如Elicit、Consensus、Semantic Scholar）的优劣势",
|
||||
"用户旅程地图：缺少完整的用户使用旅程，从发现需求到完成研究的全过程",
|
||||
"失败场景处理：用户对报告不满意时的重新生成、调整参数机制",
|
||||
"多用户协作：团队场景下的研究共享、协作批注功能",
|
||||
"移动端适配：是否需要支持移动端访问和使用",
|
||||
"数据导出与集成：与Zotero、EndNote等文献管理工具的集成需求"
|
||||
],
|
||||
"user_experience_concerns": [
|
||||
{
|
||||
"concern": "长时间等待的用户体验：允许小时级执行时间，用户在等待期间如何感知进度和价值",
|
||||
"impact": "用户可能因长时间无明显反馈而放弃使用，降低产品粘性",
|
||||
"suggestion": "建议：1) 分阶段输出中间结果（如先出搜索结果列表，再逐步更新分析）；2) 提供预估完成时间；3) 支持后台执行+完成通知"
|
||||
},
|
||||
{
|
||||
"concern": "报告质量的可信度建立：用户如何判断AI生成报告的准确性和完整性",
|
||||
"impact": "用户可能对AI生成内容持怀疑态度，需要大量人工核查，降低效率提升价值",
|
||||
"suggestion": "建议：1) 每条结论标注证据来源链接；2) 显示文献覆盖率和证据强度评分；3) 标记AI不确定的内容"
|
||||
},
|
||||
{
|
||||
"concern": "专业术语和概念的理解门槛：不同层次用户对精神疾病领域术语的熟悉程度不同",
|
||||
"impact": "医学生等初级用户可能难以理解报告中的专业内容，降低产品价值",
|
||||
"suggestion": "建议：1) 支持专业术语的悬浮解释；2) 根据用户角色调整报告语言复杂度；3) 提供概念关系图辅助理解"
|
||||
}
|
||||
],
|
||||
"suggestions": [
|
||||
"建议补充用户调研数据：增加用户访谈、问卷调查等需求验证环节的说明，提升需求可信度",
|
||||
"建议增加竞品对比分析：分析Elicit、Consensus等竞品的功能和不足，明确本产品差异化定位",
|
||||
"建议细化用户故事：将场景进一步拆解为用户故事（As a...I want...So that...），便于开发理解和验收",
|
||||
"建议增加MVP验证指标：明确MVP阶段的成功标准，如用户留存率、报告采用率、任务完成率等",
|
||||
"建议考虑渐进式复杂度：首次使用提供简化模式，高级用户可解锁更多定制选项",
|
||||
"建议补充错误恢复机制：系统故障或异常中断后，如何恢复进度、避免重复工作"
|
||||
]
|
||||
}
|
||||
@ -0,0 +1,138 @@
|
||||
# {{PROJECT_NAME}} - 需求文档
|
||||
|
||||
**文档版本**: 1.0
|
||||
**创建时间**: {{CREATED_DATE}}
|
||||
**生成方式**: Claude Code 智能需求生成器
|
||||
**项目类型**: Agent 开发
|
||||
|
||||
---
|
||||
|
||||
## 1. 背景与目标
|
||||
|
||||
### 1.1 项目背景
|
||||
{{BACKGROUND}}
|
||||
|
||||
### 1.2 目标与价值
|
||||
{{OBJECTIVES_AND_VALUE}}
|
||||
|
||||
---
|
||||
|
||||
## 2. 使用场景与触发方式
|
||||
|
||||
### 2.1 典型使用场景
|
||||
{{SCENARIOS}}
|
||||
|
||||
### 2.2 使用入口与触发方式
|
||||
{{ENTRY_METHODS}}
|
||||
|
||||
---
|
||||
|
||||
## 3. 输入输出定义
|
||||
|
||||
### 3.1 输入
|
||||
{{INPUT_DEFINITION}}
|
||||
|
||||
### 3.2 输出
|
||||
{{OUTPUT_DEFINITION}}
|
||||
|
||||
---
|
||||
|
||||
## 4. 交互流程说明
|
||||
|
||||
### 4.1 典型主流程
|
||||
|
||||
{{MAIN_WORKFLOW}}
|
||||
|
||||
> 建议使用 Mermaid 流程图展示：
|
||||
> ```mermaid
|
||||
> flowchart TD
|
||||
> Start([开始]) --> Step1[步骤1]
|
||||
> Step1 --> Step2[步骤2]
|
||||
> Step2 --> End([结束])
|
||||
> ```
|
||||
|
||||
### 4.2 异常与分支流程
|
||||
|
||||
{{EXCEPTION_AND_BRANCH_FLOWS}}
|
||||
|
||||
---
|
||||
|
||||
## 5. 外部系统与数据依赖
|
||||
|
||||
### 5.1 外部数据源需求
|
||||
{{DATA_ACCESS_REQUIREMENTS}}
|
||||
|
||||
### 5.2 系统集成需求
|
||||
{{SYSTEM_INTEGRATION}}
|
||||
|
||||
### 5.3 数据交互时序
|
||||
{{DATA_FLOW_SEQUENCE}}
|
||||
|
||||
> 建议使用 Mermaid 序列图展示数据在各系统间的流转:
|
||||
> ```mermaid
|
||||
> sequenceDiagram
|
||||
> participant U as 用户
|
||||
> participant A as Agent
|
||||
> participant D as 数据库
|
||||
> participant E as 外部API
|
||||
>
|
||||
> U->>A: 发起请求
|
||||
> A->>D: 查询数据
|
||||
> D-->>A: 返回结果
|
||||
> A->>E: 调用外部服务
|
||||
> E-->>A: 返回响应
|
||||
> A-->>U: 展示最终结果
|
||||
> ```
|
||||
|
||||
---
|
||||
|
||||
## 6. 系统模块与Agent角色定义
|
||||
|
||||
### 6.1 Agent列表与核心职能
|
||||
{{ROLE_CORE_FUNCTIONS}}
|
||||
|
||||
### 6.2 Agent能力边界
|
||||
{{CAPABILITY_BOUNDARIES}}
|
||||
|
||||
### 6.3 Agent间协作关系
|
||||
{{AGENT_INTERACTIONS}}
|
||||
|
||||
> 建议使用 Mermaid 图展示 Agent 间的调用关系:
|
||||
> ```mermaid
|
||||
> flowchart LR
|
||||
> Main[主Agent] --> Sub1[子Agent1]
|
||||
> Main --> Sub2[子Agent2]
|
||||
> Sub1 --> Sub3[子Agent3]
|
||||
> ```
|
||||
|
||||
---
|
||||
|
||||
## 7. 分阶段交付计划
|
||||
|
||||
{{PHASES}}
|
||||
|
||||
---
|
||||
|
||||
## 8. 技术约束与非功能性需求
|
||||
|
||||
### 8.1 技术约束
|
||||
{{TECH_CONSTRAINTS}}
|
||||
|
||||
### 8.2 性能要求
|
||||
{{PERFORMANCE_REQUIREMENTS}}
|
||||
|
||||
### 8.3 安全要求
|
||||
{{SECURITY_REQUIREMENTS}}
|
||||
|
||||
### 8.4 其他非功能性要求
|
||||
{{OTHER_REQUIREMENTS}}
|
||||
|
||||
---
|
||||
|
||||
## 9. 验收标准
|
||||
|
||||
### 9.1 功能验收标准
|
||||
{{FUNCTIONAL_ACCEPTANCE}}
|
||||
|
||||
### 9.2 非功能验收标准
|
||||
{{NON_FUNCTIONAL_ACCEPTANCE}}
|
||||
@ -0,0 +1,183 @@
|
||||
# {{FEATURE_NAME}} 优化 - 需求文档
|
||||
|
||||
**文档版本**: 1.0
|
||||
**创建时间**: {{CREATED_DATE}}
|
||||
**生成方式**: Claude Code 智能需求生成器
|
||||
**项目类型**: 功能优化/更新
|
||||
|
||||
---
|
||||
|
||||
## 1. 现状分析
|
||||
|
||||
### 1.1 当前问题
|
||||
{{CURRENT_PROBLEMS}}
|
||||
|
||||
### 1.2 问题影响
|
||||
{{PROBLEM_IMPACT}}
|
||||
|
||||
### 1.3 问题根因
|
||||
{{ROOT_CAUSE}}
|
||||
|
||||
---
|
||||
|
||||
## 2. 优化目标
|
||||
|
||||
### 2.1 功能目标
|
||||
{{FUNCTIONAL_GOALS}}
|
||||
|
||||
### 2.2 性能目标
|
||||
{{PERFORMANCE_GOALS}}
|
||||
|
||||
### 2.3 质量目标
|
||||
{{QUALITY_GOALS}}
|
||||
|
||||
### 2.4 优先级
|
||||
{{PRIORITY}}
|
||||
|
||||
---
|
||||
|
||||
## 3. 优化方案概述
|
||||
|
||||
### 3.1 主要优化方向
|
||||
{{OPTIMIZATION_DIRECTIONS}}
|
||||
|
||||
### 3.2 技术方案
|
||||
{{TECHNICAL_SOLUTION}}
|
||||
|
||||
### 3.3 预期效果
|
||||
{{EXPECTED_RESULTS}}
|
||||
|
||||
---
|
||||
|
||||
## 4. 功能变更
|
||||
|
||||
### 4.1 新增功能
|
||||
{{NEW_FEATURES}}
|
||||
|
||||
### 4.2 修改功能
|
||||
{{MODIFIED_FEATURES}}
|
||||
|
||||
### 4.3 废弃功能
|
||||
{{DEPRECATED_FEATURES}}
|
||||
|
||||
---
|
||||
|
||||
## 5. 技术变更方向
|
||||
|
||||
### 5.1 架构调整
|
||||
{{ARCHITECTURE_CHANGES}}
|
||||
> 注：描述架构模式的调整，而非具体技术选型
|
||||
|
||||
### 5.2 技术能力需求变化
|
||||
{{TECHNICAL_CAPABILITY_CHANGES}}
|
||||
|
||||
### 5.3 数据层变更方向
|
||||
{{DATA_LAYER_CHANGES}}
|
||||
> 注：描述数据结构、索引等的变更需求，具体实现待开发团队设计
|
||||
|
||||
### 5.4 API 变更
|
||||
{{API_CHANGES}}
|
||||
> 注：描述接口行为的变更，而非实现细节
|
||||
|
||||
### 5.5 具体技术选型
|
||||
|
||||
⏳ **待开发团队决定**
|
||||
|
||||
建议考虑的因素：
|
||||
- 与现有技术栈的兼容性
|
||||
- 变更的风险和成本
|
||||
- 团队熟悉度
|
||||
- 可维护性
|
||||
|
||||
{{TECH_STACK_CONSIDERATIONS}}
|
||||
|
||||
---
|
||||
|
||||
## 6. 兼容性与迁移
|
||||
|
||||
### 6.1 向后兼容性
|
||||
{{BACKWARD_COMPATIBILITY}}
|
||||
|
||||
### 6.2 数据迁移方案
|
||||
{{DATA_MIGRATION}}
|
||||
|
||||
### 6.3 回滚策略
|
||||
{{ROLLBACK_STRATEGY}}
|
||||
|
||||
---
|
||||
|
||||
## 7. 影响范围
|
||||
|
||||
### 7.1 受影响的模块
|
||||
{{AFFECTED_MODULES}}
|
||||
|
||||
### 7.2 受影响的用户
|
||||
{{AFFECTED_USERS}}
|
||||
|
||||
### 7.3 风险评估
|
||||
{{RISK_ASSESSMENT}}
|
||||
|
||||
---
|
||||
|
||||
## 8. 测试策略
|
||||
|
||||
### 8.1 测试范围
|
||||
{{TEST_SCOPE}}
|
||||
|
||||
### 8.2 测试用例
|
||||
{{TEST_CASES}}
|
||||
|
||||
### 8.3 性能测试
|
||||
{{#if NEEDS_PERFORMANCE_TEST}}
|
||||
{{PERFORMANCE_TEST_PLAN}}
|
||||
{{else}}
|
||||
本次优化无需专门的性能测试。
|
||||
{{/if}}
|
||||
|
||||
---
|
||||
|
||||
## 9. 发布计划
|
||||
|
||||
### 9.1 发布方式
|
||||
{{RELEASE_METHOD}}
|
||||
|
||||
### 9.2 发布步骤
|
||||
{{RELEASE_STEPS}}
|
||||
|
||||
### 9.3 监控指标
|
||||
{{MONITORING_METRICS}}
|
||||
|
||||
---
|
||||
|
||||
## 10. 验收标准
|
||||
|
||||
### 10.1 功能验收
|
||||
{{FUNCTIONAL_ACCEPTANCE}}
|
||||
|
||||
### 10.2 性能验收
|
||||
{{PERFORMANCE_ACCEPTANCE}}
|
||||
|
||||
### 10.3 稳定性验收
|
||||
{{STABILITY_ACCEPTANCE}}
|
||||
|
||||
---
|
||||
|
||||
## 附录
|
||||
|
||||
### A. 相关文档
|
||||
{{RELATED_DOCS}}
|
||||
|
||||
### B. 技术债务
|
||||
{{TECH_DEBT}}
|
||||
|
||||
---
|
||||
|
||||
**技术决策概况**
|
||||
- ✅ 用户明确决策: {{EXPLICIT_COUNT}} 项
|
||||
- 💡 智能推断决策: {{INFERRED_COUNT}} 项
|
||||
- ⏳ 待团队决定: {{PENDING_COUNT}} 项
|
||||
|
||||
**图例说明**：
|
||||
- ✅ = 用户明确要求
|
||||
- 💡 = 根据业务需求智能推断
|
||||
- ⏳ = 待开发团队决定
|
||||
@ -0,0 +1,227 @@
|
||||
# {{TEST_TARGET}} 测试 - 需求文档
|
||||
|
||||
**文档版本**: 1.0
|
||||
**创建时间**: {{CREATED_DATE}}
|
||||
**生成方式**: Claude Code 智能需求生成器
|
||||
**项目类型**: 测试项目
|
||||
|
||||
---
|
||||
|
||||
## 1. 测试概述
|
||||
|
||||
### 1.1 测试对象
|
||||
{{TEST_TARGET}}
|
||||
|
||||
### 1.2 测试背景
|
||||
{{TEST_BACKGROUND}}
|
||||
|
||||
### 1.3 测试目标
|
||||
{{TEST_OBJECTIVES}}
|
||||
|
||||
---
|
||||
|
||||
## 2. 测试类型与范围
|
||||
|
||||
### 2.1 测试类型
|
||||
{{TEST_TYPES}}
|
||||
|
||||
### 2.2 测试范围
|
||||
{{TEST_SCOPE}}
|
||||
|
||||
### 2.3 测试深度
|
||||
{{TEST_DEPTH}}
|
||||
|
||||
### 2.4 排除范围
|
||||
{{OUT_OF_SCOPE}}
|
||||
|
||||
---
|
||||
|
||||
## 3. 测试场景
|
||||
|
||||
### 3.1 正常场景
|
||||
{{NORMAL_SCENARIOS}}
|
||||
|
||||
### 3.2 异常场景
|
||||
{{EXCEPTION_SCENARIOS}}
|
||||
|
||||
### 3.3 边界场景
|
||||
{{BOUNDARY_SCENARIOS}}
|
||||
|
||||
### 3.4 用户故事/测试用例
|
||||
{{TEST_CASES}}
|
||||
|
||||
---
|
||||
|
||||
## 4. 测试数据
|
||||
|
||||
### 4.1 数据来源
|
||||
{{DATA_SOURCE}}
|
||||
|
||||
### 4.2 数据量级
|
||||
{{DATA_VOLUME}}
|
||||
|
||||
### 4.3 数据准备方式
|
||||
{{DATA_PREPARATION}}
|
||||
|
||||
### 4.4 隐私保护要求
|
||||
{{PRIVACY_REQUIREMENTS}}
|
||||
|
||||
---
|
||||
|
||||
## 5. 测试环境
|
||||
|
||||
### 5.1 环境配置
|
||||
{{ENVIRONMENT_CONFIG}}
|
||||
|
||||
### 5.2 依赖服务
|
||||
{{DEPENDENCIES}}
|
||||
|
||||
### 5.3 测试能力需求
|
||||
{{TEST_CAPABILITY_REQUIREMENTS}}
|
||||
> 注：描述需要的测试能力（如自动化测试、性能测试、接口测试等），而非具体工具
|
||||
|
||||
### 5.4 环境准备
|
||||
{{ENVIRONMENT_SETUP}}
|
||||
|
||||
---
|
||||
|
||||
## 6. 测试方式
|
||||
|
||||
### 6.1 自动化策略
|
||||
{{AUTOMATION_STRATEGY}}
|
||||
|
||||
### 6.2 测试技术方向
|
||||
{{TEST_TECHNOLOGY_DIRECTION}}
|
||||
> 注：描述测试技术方向（如单元测试、集成测试、E2E测试等）
|
||||
|
||||
### 6.3 具体测试工具和框架
|
||||
|
||||
⏳ **待开发团队决定**
|
||||
|
||||
建议考虑的因素：
|
||||
- 与现有测试技术栈的兼容性
|
||||
- 团队熟悉度
|
||||
- 自动化程度
|
||||
- CI/CD 集成便利性
|
||||
|
||||
{{TEST_TOOL_CONSIDERATIONS}}
|
||||
|
||||
### 6.4 CI/CD 集成
|
||||
{{CICD_INTEGRATION}}
|
||||
|
||||
### 6.4 测试执行计划
|
||||
{{TEST_EXECUTION_PLAN}}
|
||||
|
||||
---
|
||||
|
||||
## 7. 性能指标
|
||||
|
||||
{{#if HAS_PERFORMANCE_TEST}}
|
||||
### 7.1 响应时间要求
|
||||
{{RESPONSE_TIME}}
|
||||
|
||||
### 7.2 吞吐量要求
|
||||
{{THROUGHPUT}}
|
||||
|
||||
### 7.3 并发要求
|
||||
{{CONCURRENCY}}
|
||||
|
||||
### 7.4 资源限制
|
||||
{{RESOURCE_LIMITS}}
|
||||
|
||||
### 7.5 稳定性要求
|
||||
{{STABILITY_REQUIREMENTS}}
|
||||
{{else}}
|
||||
本测试项目不涉及性能测试。
|
||||
{{/if}}
|
||||
|
||||
---
|
||||
|
||||
## 8. 验收标准
|
||||
|
||||
### 8.1 通过标准
|
||||
{{PASS_CRITERIA}}
|
||||
|
||||
### 8.2 覆盖率要求
|
||||
{{COVERAGE_REQUIREMENTS}}
|
||||
|
||||
### 8.3 缺陷标准
|
||||
{{DEFECT_CRITERIA}}
|
||||
|
||||
### 8.4 性能基线
|
||||
{{#if HAS_PERFORMANCE_TEST}}
|
||||
{{PERFORMANCE_BASELINE}}
|
||||
{{else}}
|
||||
无性能基线要求。
|
||||
{{/if}}
|
||||
|
||||
---
|
||||
|
||||
## 9. 测试计划
|
||||
|
||||
### 9.1 测试阶段
|
||||
{{TEST_PHASES}}
|
||||
|
||||
### 9.2 时间安排
|
||||
{{SCHEDULE}}
|
||||
|
||||
### 9.3 人员分工
|
||||
{{TEAM_ASSIGNMENT}}
|
||||
|
||||
### 9.4 里程碑
|
||||
{{MILESTONES}}
|
||||
|
||||
---
|
||||
|
||||
## 10. 交付物
|
||||
|
||||
### 10.1 测试报告
|
||||
{{TEST_REPORT_REQUIREMENTS}}
|
||||
|
||||
### 10.2 测试用例
|
||||
{{TEST_CASE_DELIVERABLES}}
|
||||
|
||||
### 10.3 自动化脚本
|
||||
{{#if HAS_AUTOMATION}}
|
||||
{{AUTOMATION_DELIVERABLES}}
|
||||
{{else}}
|
||||
本测试为手动测试，无自动化脚本交付。
|
||||
{{/if}}
|
||||
|
||||
### 10.4 缺陷列表
|
||||
{{DEFECT_LIST_FORMAT}}
|
||||
|
||||
---
|
||||
|
||||
## 11. 风险与应对
|
||||
|
||||
### 11.1 测试风险
|
||||
{{TEST_RISKS}}
|
||||
|
||||
### 11.2 应对措施
|
||||
{{MITIGATION_STRATEGIES}}
|
||||
|
||||
---
|
||||
|
||||
## 附录
|
||||
|
||||
### A. 测试用例详细列表
|
||||
{{DETAILED_TEST_CASES}}
|
||||
|
||||
### B. 测试环境清单
|
||||
{{ENVIRONMENT_CHECKLIST}}
|
||||
|
||||
### C. 工具和框架说明
|
||||
{{TOOLS_DOCUMENTATION}}
|
||||
|
||||
---
|
||||
|
||||
**技术决策概况**
|
||||
- ✅ 用户明确决策: {{EXPLICIT_COUNT}} 项
|
||||
- 💡 智能推断决策: {{INFERRED_COUNT}} 项
|
||||
- ⏳ 待团队决定: {{PENDING_COUNT}} 项
|
||||
|
||||
**图例说明**：
|
||||
- ✅ = 用户明确要求
|
||||
- 💡 = 根据业务需求智能推断
|
||||
- ⏳ = 待开发团队决定
|
||||
393
.claude/skills/requirement-generator-v1/开发文档.md
Normal file
393
.claude/skills/requirement-generator-v1/开发文档.md
Normal file
@ -0,0 +1,393 @@
|
||||
# requirement-generator-v1 - 开发文档
|
||||
|
||||
## 核心设计理念
|
||||
|
||||
设计原则:
|
||||
|
||||
1. **动态适应用户能力**: 业务语言优先，通过观察用户回答动态评估其技术深度，切换语言风格
|
||||
2. **允许用户中途介入**：允许用户中途完全介入，及时修正
|
||||
3. **多专家博弈评审**：4位专家独立评审 + 两轮交叉博弈，通过观点碰撞提升评审质量
|
||||
4. **用户需求基准原则**：以用户原始需求为最高准则，专家建议不可违背用户核心需求
|
||||
5. **最终校验确保质量**：确保最终的需求文档以客观、陈述性输出，前后逻辑闭环，无明显矛盾
|
||||
|
||||
## 执行流程概览
|
||||
|
||||
```mermaid
|
||||
flowchart TB
|
||||
subgraph Phase1_4["阶段 1-4: 需求生成"]
|
||||
A[用户描述] --> B[项目类型判断]
|
||||
B --> C[智能访谈]
|
||||
C --> D[生成 requirement.md]
|
||||
end
|
||||
|
||||
subgraph Phase5["阶段 5: 用户交互"]
|
||||
D --> E{用户选择}
|
||||
E -->|修改| F[修改文档]
|
||||
F --> E
|
||||
E -->|结束| G[流程结束]
|
||||
end
|
||||
|
||||
subgraph Phase6["阶段 6: 多角色评审"]
|
||||
E -->|进入评审| H[领域识别]
|
||||
|
||||
subgraph Review["独立评审"]
|
||||
H --> I1[开发专家]
|
||||
H --> I2[产品经理]
|
||||
H --> I3[AI专家]
|
||||
H --> I4[领域专家]
|
||||
end
|
||||
|
||||
subgraph Debate1["博弈-评价阶段"]
|
||||
I2 & I3 & I4 --> J1[开发专家评价]
|
||||
I1 & I3 & I4 --> J2[产品经理评价]
|
||||
I1 & I2 & I4 --> J3[AI专家评价]
|
||||
I1 & I2 & I3 --> J4[领域专家评价]
|
||||
end
|
||||
|
||||
subgraph Debate2["博弈-回应阶段"]
|
||||
J2 & J3 & J4 --> K1[开发专家回应]
|
||||
J1 & J3 & J4 --> K2[产品经理回应]
|
||||
J1 & J2 & J4 --> K3[AI专家回应]
|
||||
J1 & J2 & J3 --> K4[领域专家回应]
|
||||
end
|
||||
|
||||
K1 & K2 & K3 & K4 --> L{决策模式}
|
||||
L -->|用户确认| M1[req_consolidator]
|
||||
L -->|自动应用| M2[req_auto_consolidator]
|
||||
M1 & M2 --> N[requirement_final.md]
|
||||
N --> O[质量审查]
|
||||
O --> P[输出最终总结]
|
||||
end
|
||||
```
|
||||
|
||||
## 阶段详细说明
|
||||
|
||||
### 阶段 1-4: 需求生成
|
||||
|
||||
```
|
||||
用户描述 → 项目类型判断 → 智能访谈 → 生成需求文档(requirement.md)
|
||||
```
|
||||
|
||||
### 阶段 5: 用户交互
|
||||
|
||||
系统展示文档概览，询问用户选择下一步操作：
|
||||
- **修改**: 用户编辑或提出修改建议，完成后再次询问
|
||||
- **进入多角色评审**: 进入阶段6
|
||||
- **结束**: 直接使用当前版本
|
||||
|
||||
### 阶段 6: 多角色评审
|
||||
|
||||
#### 6.1 领域识别与角色生成
|
||||
|
||||
读取 requirement.md，分析项目领域特征，生成领域专家角色定义，保存到 `temp/domain_role.md`。
|
||||
|
||||
#### 6.2 独立评审（并行）
|
||||
|
||||
4位专家并行评审 requirement.md：
|
||||
|
||||
| 专家 | 输出文件 | 评审重点 |
|
||||
|------|----------|----------|
|
||||
| 开发专家 | `temp/review_dev.json` | 技术可行性、架构、性能、风险 |
|
||||
| 产品经理 | `temp/review_pm.json` | 业务目标、用户价值、场景完整性 |
|
||||
| AI专家 | `temp/review_ai.json` | 智能化需求合理性、AI能力边界 |
|
||||
| 领域专家 | `temp/review_domain.json` | 领域合规性、行业规范、特殊要求 |
|
||||
|
||||
#### 6.3 博弈-评价阶段：交叉评价（并行）
|
||||
|
||||
每位专家阅读其他3位专家的评审结果，对有冲突、不合理或需要补充的观点进行评价：
|
||||
|
||||
| 专家 | 读取文件 | 输出文件 |
|
||||
|------|----------|----------|
|
||||
| 开发专家 | review_pm/ai/domain.json | `temp/evaluate_dev.json` |
|
||||
| 产品经理 | review_dev/ai/domain.json | `temp/evaluate_pm.json` |
|
||||
| AI专家 | review_dev/pm/domain.json | `temp/evaluate_ai.json` |
|
||||
| 领域专家 | review_dev/pm/ai.json | `temp/evaluate_domain.json` |
|
||||
|
||||
**评价输出格式**（必须包含目标定位）：
|
||||
```json
|
||||
{
|
||||
"responses": [
|
||||
{
|
||||
"target_expert": "产品经理",
|
||||
"target_file": "temp/review_pm.json",
|
||||
"target_location": "issues[2]",
|
||||
"target_content": "对方观点摘要",
|
||||
"my_comment": "我的评价",
|
||||
"reasoning": "专业理由"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
#### 6.4 博弈-回应阶段：交叉回应（并行）
|
||||
|
||||
每位专家只读取针对自己的评价，决定是否修正原始观点，确定最终立场：
|
||||
|
||||
| 专家 | 读取内容 | 输出文件 |
|
||||
|------|----------|----------|
|
||||
| 开发专家 | evaluate_*.json 中 target_expert="开发专家" | `temp/response_dev.json` |
|
||||
| 产品经理 | evaluate_*.json 中 target_expert="产品经理" | `temp/response_pm.json` |
|
||||
| AI专家 | evaluate_*.json 中 target_expert="AI专家" | `temp/response_ai.json` |
|
||||
| 领域专家 | evaluate_*.json 中 target_expert="领域专家" | `temp/response_domain.json` |
|
||||
|
||||
**回应输出包含**：
|
||||
- `final_issues`: 最终问题列表（含 consensus_level: unanimous/majority/contested）
|
||||
- `withdrawn_issues`: 被说服后撤回的问题
|
||||
- `new_issues_from_debate`: 博弈中新发现的问题
|
||||
|
||||
#### 6.5 决策模式选择
|
||||
|
||||
询问用户选择处理方式：
|
||||
- **用户确认模式**: 调用 `req_consolidator`，逐项与用户确认
|
||||
- **自动应用模式**: 调用 `req_auto_consolidator`，自动评估并应用
|
||||
|
||||
#### 6.6 汇总整合
|
||||
|
||||
汇总Agent读取 **14个文件**：
|
||||
|
||||
| 类别 | 文件 | 数量 |
|
||||
|------|------|------|
|
||||
| 用户需求基准 | `temp/interview_result.json` | 1 |
|
||||
| 原始需求文档 | `requirement.md` | 1 |
|
||||
| 初始评审 | `temp/review_*.json` | 4 |
|
||||
| 交叉评价 | `temp/evaluate_*.json` | 4 |
|
||||
| 交叉回应 | `temp/response_*.json` | 4 |
|
||||
|
||||
**合并决策规则**：
|
||||
1. **可以采纳**: 优化补充用户需求、细化实现细节的建议
|
||||
2. **谨慎采纳**: 与用户需求有出入但专家一致认同的建议
|
||||
3. **禁止采纳**: 完全背离用户原始需求的建议（即使专家全员同意）
|
||||
|
||||
**共识度处理**：
|
||||
- `unanimous`（全员一致）: 自动采纳
|
||||
- `majority`（多数同意）: 自动采纳
|
||||
- `contested`（存在争议）: 按裁决规则处理或询问用户
|
||||
|
||||
#### 6.7 质量审查
|
||||
|
||||
调用 `review_report` 检查最终文档：
|
||||
- 文档结构是否符合模板（不能有多余章节）
|
||||
- 客观性（无评审标注、讨论性词汇）
|
||||
- 逻辑严谨性（前后无矛盾）
|
||||
- 闭环性（功能描述完整）
|
||||
- 业务完整性（无"待确认"的业务问题）
|
||||
|
||||
## 专家博弈流程图
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant Main as 主窗口
|
||||
participant Dev as 开发专家
|
||||
participant PM as 产品经理
|
||||
participant AI as AI专家
|
||||
participant Domain as 领域专家
|
||||
participant Consolidator as 汇总Agent
|
||||
|
||||
Note over Main: 阶段6.2 独立评审
|
||||
par 并行评审
|
||||
Main->>Dev: mode: review
|
||||
Main->>PM: mode: review
|
||||
Main->>AI: mode: review
|
||||
Main->>Domain: mode: review
|
||||
end
|
||||
Dev-->>Main: review_dev.json
|
||||
PM-->>Main: review_pm.json
|
||||
AI-->>Main: review_ai.json
|
||||
Domain-->>Main: review_domain.json
|
||||
|
||||
Note over Main: 阶段6.3 博弈-评价阶段
|
||||
par 并行评价
|
||||
Main->>Dev: mode: evaluate
|
||||
Main->>PM: mode: evaluate
|
||||
Main->>AI: mode: evaluate
|
||||
Main->>Domain: mode: evaluate
|
||||
end
|
||||
Dev-->>Main: evaluate_dev.json
|
||||
PM-->>Main: evaluate_pm.json
|
||||
AI-->>Main: evaluate_ai.json
|
||||
Domain-->>Main: evaluate_domain.json
|
||||
|
||||
Note over Main: 阶段6.4 博弈-回应阶段
|
||||
par 并行回应
|
||||
Main->>Dev: mode: respond
|
||||
Main->>PM: mode: respond
|
||||
Main->>AI: mode: respond
|
||||
Main->>Domain: mode: respond
|
||||
end
|
||||
Dev-->>Main: response_dev.json
|
||||
PM-->>Main: response_pm.json
|
||||
AI-->>Main: response_ai.json
|
||||
Domain-->>Main: response_domain.json
|
||||
|
||||
Note over Main: 阶段6.6 汇总整合
|
||||
Main->>Consolidator: 整合14个文件
|
||||
Consolidator-->>Main: requirement_final.md
|
||||
```
|
||||
|
||||
## Agent 协作架构
|
||||
|
||||
### 需求生成 Agents (阶段1-4)
|
||||
|
||||
| Agent | 职责 | 关键能力 |
|
||||
|-------|------|---------|
|
||||
| **project_type_matcher** | 项目类型识别 | 语义匹配，置信度分级 |
|
||||
| **req_interviewer** | 智能访谈 | 动态评估技术深度，业务到技术转化 |
|
||||
| **req_writer** | 文档生成 | 模板驱动，决策标注 |
|
||||
|
||||
### 评审 Agents (阶段6)
|
||||
|
||||
| Agent | 视角 | 重点 | 工作模式 |
|
||||
|-------|------|------|----------|
|
||||
| **dev_expert_reviewer** | 技术 | 可行性、架构、性能、风险 | review/evaluate/respond |
|
||||
| **pm_reviewer** | 业务 | 目标、价值、场景、验收标准 | review/evaluate/respond |
|
||||
| **ai_expert_reviewer** | 智能化 | AI能力边界、智能化合理性 | review/evaluate/respond |
|
||||
| **domain_expert_reviewer** | 领域 | 合规性、行业规范、特殊要求 | review/evaluate/respond |
|
||||
| **req_consolidator** | 整合 | 用户确认模式，多轮交互 | - |
|
||||
| **req_auto_consolidator** | 整合 | 自动评估模式，无用户交互 | - |
|
||||
| **review_report** | 质量 | 客观性、逻辑严谨性、业务完整性 | - |
|
||||
|
||||
## 目录结构
|
||||
|
||||
```
|
||||
requirement-generator-v1/
|
||||
├── SKILL.md # 主流程（简化版）
|
||||
├── 开发文档.md # 本文档
|
||||
├── references/ # 详细指南（渐进式披露）
|
||||
│ ├── phase3_interview_guide.md
|
||||
│ └── phase6_review_guide.md
|
||||
├── assets/ # 项目类型配置
|
||||
│ ├── agent_dev.md
|
||||
│ ├── feature_update.md
|
||||
│ └── testing.md
|
||||
└── templates/ # 需求文档模板
|
||||
├── agent_dev_template.md
|
||||
├── feature_update_template.md
|
||||
└── testing_template.md
|
||||
|
||||
项目 agents/ (D:\AA_Work\AIEC-团队开发规范Skills\.claude\agents\)
|
||||
├── project_type_matcher.md
|
||||
├── req_interviewer.md
|
||||
├── req_writer.md
|
||||
├── dev_expert_reviewer.md
|
||||
├── pm_reviewer.md
|
||||
├── ai_expert_reviewer.md
|
||||
├── domain_expert_reviewer.md
|
||||
├── req_consolidator.md
|
||||
├── req_auto_consolidator.md
|
||||
└── review_report.md
|
||||
|
||||
temp/ (运行时生成)
|
||||
├── interview_result.json # 访谈结果
|
||||
├── domain_role.md # 领域专家角色定义
|
||||
├── review_dev.json # 开发专家初始评审
|
||||
├── review_pm.json # 产品经理初始评审
|
||||
├── review_ai.json # AI专家初始评审
|
||||
├── review_domain.json # 领域专家初始评审
|
||||
├── evaluate_dev.json # 开发专家交叉评价
|
||||
├── evaluate_pm.json # 产品经理交叉评价
|
||||
├── evaluate_ai.json # AI专家交叉评价
|
||||
├── evaluate_domain.json # 领域专家交叉评价
|
||||
├── response_dev.json # 开发专家交叉回应
|
||||
├── response_pm.json # 产品经理交叉回应
|
||||
├── response_ai.json # AI专家交叉回应
|
||||
├── response_domain.json # 领域专家交叉回应
|
||||
└── consolidation_report.json # 汇总应用记录（自动模式）
|
||||
```
|
||||
|
||||
## 数据传递策略
|
||||
|
||||
本 Skill 采用以下数据传递模式：
|
||||
|
||||
| 传递方向 | 策略 | 说明 |
|
||||
|----------|------|------|
|
||||
| 主窗口 → Agent | 标识符/模式 | 仅传递 `mode: review/evaluate/respond` |
|
||||
| Agent → temp/ | JSON文件 | 结构化数据存储，便于其他Agent读取 |
|
||||
| Agent → 主窗口 | 概要文字 | 简洁提示，详细数据在文件中 |
|
||||
| Agent → Agent | 文件路径 | 通过 `temp/*.json` 传递，主窗口不加载 |
|
||||
|
||||
## 关键设计决策
|
||||
|
||||
### 1. 专家博弈机制
|
||||
|
||||
采用博弈机制提升评审质量，每轮博弈包含两个阶段：
|
||||
- **评价阶段**: 专家指出其他专家观点中的问题
|
||||
- **回应阶段**: 专家根据评价决定是否修正
|
||||
|
||||
**设计理由**: 单轮评审可能存在盲点，博弈过程可发现更多问题，共识度标注帮助汇总决策。
|
||||
|
||||
### 2. 原始评审不可变
|
||||
|
||||
`review_*.json` 在生成后保持不变，所有修正记录在 `response_*.json` 中。
|
||||
|
||||
**设计理由**: 保留完整的观点演变历史，便于追溯和审计。
|
||||
|
||||
### 3. 用户需求基准原则
|
||||
|
||||
汇总时以 `interview_result.json` 中的用户原始需求为最高准则，专家建议不可违背。
|
||||
|
||||
**设计理由**: 专家是辅助角色，最终产品要满足用户需求。
|
||||
|
||||
### 4. Agent 自治性
|
||||
|
||||
所有 Agent 采用自治设计模式：
|
||||
- 执行规则、工具使用规范固化在 Agent 定义中
|
||||
- Agent 自行读取配置文件（路径在 Agent 定义中硬编码）
|
||||
- 主窗口仅传递模式标识，不传递执行逻辑
|
||||
|
||||
### 5. 文档版本管理
|
||||
|
||||
采用双文档策略保留完整历史：
|
||||
- `requirement.md`: 初版文档，生成后不再修改
|
||||
- `requirement_final.md`: 评审优化版，仅在阶段6生成
|
||||
|
||||
## 扩展指南
|
||||
|
||||
### 添加新项目类型
|
||||
|
||||
1. 参考现有配置文件（如 `assets/agent_dev.md`）创建新配置
|
||||
2. 编辑 frontmatter 字段：type, keywords, priority
|
||||
3. 定义核心问题（业务版本 + 技术版本）
|
||||
4. 设计业务到技术的映射规则
|
||||
5. 创建对应的文档模板 `templates/{type}_template.md`
|
||||
6. 测试访谈流程和文档生成完整性
|
||||
|
||||
### 添加新评审专家
|
||||
|
||||
1. 在 `agents/` 目录创建新专家定义文件
|
||||
2. 实现三种工作模式：review/evaluate/respond
|
||||
3. 定义专家视角和评审重点
|
||||
4. 更新 SKILL.md 和 phase6_review_guide.md 中的调用列表
|
||||
5. 更新汇总 Agent 的文件读取列表
|
||||
|
||||
## 常见场景处理
|
||||
|
||||
### 用户描述过于简短
|
||||
|
||||
当 project_type_matcher 返回低置信度时：
|
||||
1. 系统列出所有可用项目类型供用户选择
|
||||
2. req_interviewer 通过多轮访谈补充缺失信息
|
||||
|
||||
### 用户选择"未知类型"
|
||||
|
||||
系统采用开放式访谈模式：
|
||||
1. req_interviewer 通过开放式问题理解项目本质
|
||||
2. Agent 自主决定文档结构
|
||||
3. req_writer 根据 custom_sections 构建文档（不使用预定义模板）
|
||||
|
||||
### 专家意见严重冲突
|
||||
|
||||
当 `contested` 级别问题较多时：
|
||||
- **用户确认模式**: 向用户展示争议双方观点，由用户决定
|
||||
- **自动应用模式**: 按裁决规则处理（合规性优先 > 技术可行性优先 > 用户价值优先）
|
||||
|
||||
### 博弈后仍有分歧
|
||||
|
||||
即使博弈后仍有 `contested` 问题：
|
||||
1. 汇总 Agent 根据裁决规则自动处理
|
||||
2. 在 `consolidation_report.json` 中记录裁决过程
|
||||
3. 用户可事后查看裁决依据
|
||||
|
||||
---
|
||||
|
||||
**最后更新**: 2025-12-01
|
||||
**Skill 版本**: v1
|
||||
Binary file not shown.
98
.claude/skills/requirement-generator-v1/需求文档skill解释稿.md
Normal file
98
.claude/skills/requirement-generator-v1/需求文档skill解释稿.md
Normal file
@ -0,0 +1,98 @@
|
||||
# 总体目标
|
||||
|
||||
用一句话说，就是能够动态适应不同背景的用户，把"模糊的想法"变成"专业的需求文档"
|
||||
|
||||
首先阶段1-阶段4可以看作是一个小整体，它的目标是动态引导用户澄清并发散初步需求，生成一个需求文档初稿。
|
||||
|
||||
随后的阶段5可以看作是一个小整体，会有一个“多专家协同评审”的阶段，通过多个专业视角改进初稿，最终生成高质量的终稿。
|
||||
|
||||
整个过程就像传统公司中的“Team”在帮你整理思路、写文档、再帮你审核。
|
||||
|
||||
|
||||
|
||||
human in the loop
|
||||
|
||||
|
||||
|
||||
## 各阶段详解
|
||||
|
||||
### 系统准备阶段：
|
||||
|
||||
针对常见项目大类（如 Agent 开发），系统预设了对应的需求文档的模板，和方法论式的访谈策略
|
||||
|
||||
**这样做的好处是：**系统不是从零开始猜你要什么，而是带着"行业经验"来帮用户梳理需求，问的问题更专业，输出的文档更规范。
|
||||
|
||||
|
||||
|
||||
### 阶段 1：初始构想录入
|
||||
|
||||
第一阶段：你要做的事情很简单：随便说说你的想法、目标或者遇到的问题就行。不需要很正式，可以是"我想做一个医疗领域的可沿著手"这样的一句话。
|
||||
|
||||
|
||||
|
||||
### 阶段 2：智能类型判定
|
||||
|
||||
系统会自动判断你要做的是什么类型的项目。这里有个置信度机制：如果系统很确定，就直接推荐给你确认；如果有点把握但不完全确定，会给你推荐加备选让你来选；如果不太确定，就列出所有可能让你自己定。
|
||||
|
||||
判断出类型后，系统就会加载对应的项目大类模板和对应访谈策略方法论，为下一步做准备。
|
||||
|
||||
|
||||
|
||||
### 阶段 3：动态需求挖掘
|
||||
|
||||
这是核心亮点之一。这不是让你填问卷，而是"智能访谈"。系统会根据访谈策略的方法论，结合你每一步的回答，动态决定下一个问题问什么。你说清楚的内容就跳过，说模糊的地方就追问并给出选项。同时有"完整性检查点"，确保关键信息都收集到了才往下走。
|
||||
|
||||
|
||||
|
||||
### 阶段 4：初稿自动生成
|
||||
|
||||
系统会把访谈收集到的信息，按照对应项目类型的标准模板，自动生成一份完整的需求文档初稿。你不用自己动笔。
|
||||
|
||||
|
||||
|
||||
### 阶段 5：阶段性成果与决策点
|
||||
|
||||
系统会给你展示一个成果概览，包括项目类型、有几个功能、多少场景、技术约束等。然后你有三个选择：
|
||||
|
||||
**选择一：修改文档**。如果觉得哪里不对，可以直接修改。
|
||||
|
||||
**选择二：快速通道**。如果初稿已经够用了，可以直接结束，使用当前版本。
|
||||
|
||||
**选择三：高级评审**。如果想要更专业的把关，可以进入专家评审环节。
|
||||
|
||||
|
||||
|
||||
### 阶段 6：专家级优化与评审
|
||||
|
||||
如果你选择了高级评审，系统会启动四个虚拟专家同时评审你的文档，这四个虚拟专家包括三个固定专家：开发专家、产品经理、AI专家，并根据阶段1-4生成的初稿内容动态生成“领域专家”。
|
||||
|
||||
四位专家会带着自己的角色设定，以多个专业的视角，同时对需求文档初稿进行评审，就相当于一个Team在工作
|
||||
|
||||
四个专家的意见汇总后，你可以选择"人工确认模式"一条条看建议自己决定采纳哪些，或者选择"自动应用模式"让 AI自动判断哪些建议该采纳。
|
||||
|
||||
最后还有一道质量审查，检查合规性、客观性、逻辑性，确保没问题才最终交付。
|
||||
|
||||
|
||||
|
||||
## 最终交付物
|
||||
|
||||
整个流程结束后，你会得到三份文件：原始初稿备份、评审过程记录、以及最终定稿的需求文档。
|
||||
|
||||
|
||||
|
||||
## 三个核心亮点
|
||||
|
||||
**预置专业知识**：不同项目类型有专属的模板和访谈策略，问得准、写得规范，不是泛泛而谈。
|
||||
|
||||
**动态适应**：根据你的回答和上下文智能调整问题，不是死板的问卷，而是像真人访谈一样灵活。
|
||||
|
||||
**多视角把关**：一个人想问题容易有盲区，用多个"专家角色"并行审核，从不同角度查漏补缺。
|
||||
|
||||
---
|
||||
|
||||
|
||||
|
||||
## 价值总结
|
||||
|
||||
传统方式是自己想、自己写、自己改，容易遗漏关键信息。这套方案让 AI
|
||||
带着行业经验帮你问、帮你写、帮你审，最终交付的是可用且专业的需求文档。
|
||||
BIN
.claude/skills/requirement-generator-v1/需求自动生成agent.pdf
Normal file
BIN
.claude/skills/requirement-generator-v1/需求自动生成agent.pdf
Normal file
Binary file not shown.
Reference in New Issue
Block a user