# 需求澄清问题生成框架

> 指导 LLM 根据项目上下文动态生成澄清问题的框架

---

## 1. 问题生成原则

### 1.1 核心原则

- **上下文感知**：基于用户已提供的信息和之前的回答生成问题
- **渐进深入**：从宏观到微观，从业务到技术逐步细化
- **避免重复**：不询问已明确的信息
- **实用性导向**：每个问题都应影响后续设计决策

### 1.2 问题质量标准

每个问题应满足：
1. 与当前项目类型/领域相关
2. 有明确的业务或技术影响
3. 选项覆盖常见场景，同时保留灵活性
4. 至少 4 个有意义的选项 + "其他"选项

---

## 2. 问题分类框架

在需求澄清阶段，按以下维度逐一生成问题：

### 2.1 业务维度

**触发条件**：涉及业务逻辑、用户角色、工作流程时

**问题生成方向**：
- 用户角色与权限边界
- 核心业务流程与变体
- 数据所有权与共享规则
- 业务规则与约束条件
- 异常情况处理策略

**示例问题模式**：
```
基于您描述的[业务场景]，我需要了解：
[具体业务问题]？

选项：
A) [最常见场景]
B) [替代场景]
C) [边界场景]
D) [其他常见变体]
E) 其他：_______
```

### 2.2 技术维度

**触发条件**：涉及技术选型、架构决策、集成需求时

**问题生成方向**：
- 架构模式偏好
- 技术栈约束或偏好
- 集成与扩展需求
- 数据处理策略
- 部署与运维需求

**问题生成依据**：
- 项目规模（小型/中型/大型）
- 团队技术背景
- 性能预期
- 现有系统约束

### 2.3 安全维度

**触发条件**：涉及用户数据、敏感操作、合规要求时

**问题生成方向**：
- 认证与授权要求
- 数据分类与保护级别
- 合规标准要求
- 审计与日志需求
- 安全事件响应

**问题深度调整**：
- 涉及 PII：深入询问数据保护
- 涉及金融：询问交易安全
- 涉及医疗：询问合规要求

### 2.4 性能维度

**触发条件**：涉及高并发、大数据量、实时性要求时

**问题生成方向**：
- 预期用户规模与增长
- 响应时间要求
- 数据量级估算
- 可用性要求
- 扩展策略偏好

**问题精度调整**：
- 小型项目：询问基本预期
- 中大型项目：深入询问具体指标

### 2.5 用户体验维度

**触发条件**：涉及界面设计、用户交互、可访问性时

**问题生成方向**：
- 目标用户群体特征
- 设备与平台支持
- 无障碍要求
- 品牌与风格偏好
- 用户反馈机制

---

## 3. 动态问题生成流程

### 3.1 问题选择策略

```
1. 分析用户初始描述，提取关键信息
2. 识别信息缺口（哪些关键决策点未明确）
3. 按优先级排序问题：
   - 阻塞性问题（影响整体架构）优先
   - 细节问题（影响实现细节）靠后
4. 每次生成一个问题，等待回答后调整后续问题
```

### 3.2 上下文追踪

在澄清过程中，追踪以下信息：

| 信息类别 | 已知内容 | 待澄清 |
|----------|----------|--------|
| 业务领域 | | |
| 用户角色 | | |
| 技术约束 | | |
| 安全要求 | | |
| 性能预期 | | |
| 用户体验 | | |

### 3.3 问题生成示例

**场景：用户描述"需要一个任务管理系统"**

第一轮（业务维度）：
```
这个任务管理系统的使用场景是什么？

A) 个人任务管理
B) 团队协作任务管理
C) 项目管理（含甘特图、里程碑）
D) 工作流/审批任务管理
E) 其他：_______
```

根据回答调整后续问题：

如果选择 B（团队协作）：
```
团队成员之间的任务如何分配？

A) 管理者统一分配
B) 成员自主认领
C) 混合模式（可分配也可认领）
D) 按技能自动匹配
E) 其他：_______
```

如果选择 A（个人任务管理）：
```
任务需要哪些组织方式？

A) 简单列表
B) 分类/标签
C) 优先级 + 截止日期
D) 番茄钟/时间跟踪
E) 其他：_______
```

---

## 4. 问题生成检查清单

在生成每个问题前，确认：

- [ ] 该问题的答案会影响后续设计
- [ ] 该信息尚未在之前的对话中明确
- [ ] 问题的表述清晰、无歧义
- [ ] 选项覆盖了常见场景
- [ ] 包含"其他"选项以处理特殊情况

---

## 5. 澄清终止条件

当满足以下条件时，可以结束澄清阶段：

1. **核心决策点已明确**：
   - 业务范围和边界
   - 主要用户角色和流程
   - 技术架构方向
   - 关键约束条件

2. **信息足够进入下一阶段**：
   - 可以开始模块划分
   - 可以定义数据实体
   - 可以设计 API 轮廓

3. **剩余问题可在后续阶段细化**：
   - 具体字段定义 → 模块设计阶段
   - UI 组件细节 → UI/UX 规范阶段
   - 性能调优参数 → 架构规范阶段

---

## 6. 特殊场景处理

### 6.1 用户回答不确定

如果用户表示"不确定"或"还没想好"：
- 提供行业最佳实践作为默认选项
- 说明各选项的利弊
- 建议采用可逆的决策（后期可调整）

### 6.2 用户需求矛盾

如果发现回答中存在矛盾：
- 指出矛盾点
- 询问优先级
- 提供权衡建议

### 6.3 超出范围的需求

如果用户提出的需求超出项目范围：
- 确认是否需要纳入
- 如纳入，评估对时间线的影响
- 如不纳入，记录为未来迭代项