结构化需求提问对齐

Goal

• 通过结构化提问消除模糊需求，确保在动手实现前对齐理解。

Prerequisites

• 确认用户能参与需求对齐会话。
• 获取最小上下文：用户原始需求描述。

核心流程

1. 收集原始需求: 记录用户的原始描述
2. 短发散: 给出 2-4 个可能方向，暴露关键取舍
3. 识别模糊点: 列出所有不确定的部分
4. 逐点提问: 对每个模糊点提出具体问题
5. 确认理解: 用自己的话复述需求，请用户确认
6. 生成结构化文档: 输出标准需求格式

提问模板

维度	问题模板
目标	"这个功能要解决什么问题？"
用户	"谁会使用这个功能？"
边界	"什么情况下不需要这个功能？"
验收	"怎样算做完了？"
约束	"有什么技术限制？"

Workflow

1. 收集原始需求：记录用户原始描述
2. 短发散：列出 2-4 个方向和取舍，不改文件
3. 识别模糊点：列出所有不确定的部分
4. 逐点提问：对每个模糊点提出具体问题
5. 确认理解：用自己的话复述需求，请用户确认
6. 生成结构化文档：输出标准需求格式

与 adk-requirements-triage 的区别

• adk-structured-requirements-questioning: 通过结构化提问消除模糊需求
• adk-requirements-triage: 将明确需求转为可验证的工程条目

Quality Gate

• 所有模糊点已对齐并记录
• 用户已确认需求理解
• 输出结构化需求文档

Evidence Template

- 模糊点清单: (已对齐 N 个)
- 用户确认: pass / needs-fix
- 输出文档路径: <path>

合理化借口拦截

借口	现实	正确做法
"需求已经很清楚了"	模糊需求是 bug 的温床	按流程逐点确认
"用户说的我都理解了"	理解偏差很难自我发现	复述并请用户确认

健壮性规范

• 输入验证: 检查用户描述是否为空或过于模糊
• 重试策略: 提问 3 次仍无法对齐则建议用户补充文档
• 超时控制: 单轮对齐不超过 5 轮提问
• 异常隔离: 某个维度对齐失败不影响其他维度
• 日志记录: 记录每个模糊点和最终确认结果