需求文档skill回溯专家博弈之前
This commit is contained in:
闫旭隆
@ -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生成需求文档。
|
||||
Reference in New Issue
Block a user