questioning-framework.md 5.3 KB
需求澄清问题生成框架
指导 LLM 根据项目上下文动态生成澄清问题的框架
1. 问题生成原则
1.1 核心原则
- 上下文感知：基于用户已提供的信息和之前的回答生成问题
- 渐进深入：从宏观到微观，从业务到技术逐步细化
- 避免重复：不询问已明确的信息
- 实用性导向：每个问题都应影响后续设计决策
1.2 问题质量标准
每个问题应满足：
- 与当前项目类型/领域相关
- 有明确的业务或技术影响
- 选项覆盖常见场景，同时保留灵活性
- 至少 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. 澄清终止条件
当满足以下条件时，可以结束澄清阶段：
核心决策点已明确：
- 业务范围和边界
- 主要用户角色和流程
- 技术架构方向
- 关键约束条件
信息足够进入下一阶段：
- 可以开始模块划分
- 可以定义数据实体
- 可以设计 API 轮廓
剩余问题可在后续阶段细化：
- 具体字段定义 → 模块设计阶段
- UI 组件细节 → UI/UX 规范阶段
- 性能调优参数 → 架构规范阶段
6. 特殊场景处理
6.1 用户回答不确定
如果用户表示"不确定"或"还没想好"：
- 提供行业最佳实践作为默认选项
- 说明各选项的利弊
- 建议采用可逆的决策（后期可调整）
6.2 用户需求矛盾
如果发现回答中存在矛盾：
- 指出矛盾点
- 询问优先级
- 提供权衡建议
6.3 超出范围的需求
如果用户提出的需求超出项目范围：
- 确认是否需要纳入
- 如纳入，评估对时间线的影响
- 如不纳入，记录为未来迭代项