name: interactive-requirements-gathering description: 用于从用户收集需求的结构化交互式问卷框架。使用A/B/C/D/E多项选择模式，带有加法型与独占型问题分类。 version: 1.0.0 model: sonnet invoked_by: both user_invocable: true tools: [Read, Write, Edit, AskUserQuestion] best_practices:

一次只问一个问题，绝不一次问多个
在问每个问题前分类为加法型或独占型
总是包括“输入自己的答案”和“自动生成并继续”选项
在移动到下一个问题前确认理解
使用收集的答案（而非选项）作为生成的真实来源 error_handling: graceful streaming: supported verified: false lastVerifiedAt: 2026-02-19T05:29:09.098Z

交互式需求收集

用于通过交互式问卷收集需求的结构化框架。基于Conductor方法论中经过验证的人机循环模式。

何时使用

设置新项目
定义产品需求
收集功能规格
引导用户进入新工作流
任何需要结构化用户输入的任务

核心原则

1. 问题分类

在问任何问题之前，分类其类型：

类型	目的	措辞	示例
加法型	头脑风暴，多个答案有效	“选择所有适用的”	“你需要哪些功能？”
独占型	需要单一选择	无多选短语	“我们应该使用哪个框架？”

2. 问题结构

所有问题必须遵循此结构：

[问题文本]

A) [选项A - 通常推荐，标记为“（推荐）”]
B) [选项B]
C) [选项C]
D) 输入自己的答案
E) 自动生成并继续

3. 顺序提问

关键：一次问一个问题。在下一个问题前等待响应。

正确：
1. 问问题1
2. 等待响应
3. 确认理解
4. 问问题2

错误：
1. 一起问问题1、2和3

问卷工作流

步骤1：介绍

宣布你正在处理的部分：

“我现在将帮助你定义[部分名称]。我会问几个问题来了解你的需求。”

步骤2：顺序问题

对于每个问题：

分类：这是加法型还是独占型？
制定：创建清晰的问题与选项
呈现：以A/B/C/D/E格式显示选项
等待：没有响应不要继续
确认：在继续前总结理解

步骤3：处理特殊选项

选项D（输入自己的答案）：

接受用户的自定义输入
确认自定义响应
继续到下一个问题

选项E（自动生成并继续）：

停止问这个部分的问题
基于先前的答案使用最佳判断
生成内容并呈现供审阅

步骤4：生成内容

关键：仅使用用户选择的答案作为真实来源。

正确：
- 用户选择了“OAuth 2.0” -> 生成OAuth实施细节

错误：
- 包括未选中的选项A、B、C文本
- 在生成的内容中包括问题文本

步骤5：用户确认循环

生成内容后：

“我已经起草了[文档名称]。请审阅：”

[内容预览]

你想做什么？
A) 批准 - 进行下一步
B) 建议更改 - 告诉我修改什么

请用A或B回应。

循环直到批准或用户提供替代方向。

问题模式

产品愿景问题（加法型）

这个产品的主要目标是什么？（选择所有适用的）

A) 提高用户生产力
B) 降低运营成本
C) 增强客户体验
D) 输入自己的答案
E) 自动生成并继续

技术选择问题（独占型）

我们应该使用哪个数据库？

A) PostgreSQL（推荐） - 适用于具有复杂查询的关系数据
B) MongoDB - 灵活模式的文档存储
C) SQLite - 适用于小型应用程序的轻量级
D) 输入自己的答案
E) 自动生成并继续

功能范围问题（加法型）

应该支持哪些认证方法？（选择所有适用的）

A) 邮箱/密码
B) OAuth（Google, GitHub）
C) 魔法链接
D) 输入自己的答案
E) 自动生成并继续

与AskUserQuestion工具的集成

当使用AskUserQuestion工具时，映射到此框架：

AskUserQuestion({
  questions: [
    {
      header: 'Database',
      question: 'Which database should we use?',
      multiSelect: false, // Exclusive question
      options: [
        { label: 'PostgreSQL (Recommended)', description: 'Best for relational data' },
        { label: 'MongoDB', description: 'Document store for flexible schemas' },
        { label: 'SQLite', description: 'Lightweight for small apps' },
      ],
    },
  ],
});

状态持久化

对于多步骤问卷，保存进度：

{
  "last_successful_step": "2.1_product_guide",
  "answers": {
    "product_type": "SaaS",
    "target_users": ["developers", "teams"]
  }
}

这使得能够恢复中断的工作流。

示例会话

AGENT: “我将帮助你定义产品愿景。第一个问题：”

“谁是这个产品的主要用户？”

A) 开发者
B) 商业用户
C) 最终消费者
D) 输入自己的答案
E) 自动生成并继续

USER: A, B

AGENT: “明白了 - 针对开发者和商业用户。下一个问题：”

“这个产品解决了什么问题？”

A) 简化工作流
B) 减少手动工作
C) 改善协作
D) 输入自己的答案
E) 自动生成并继续

USER: D - “自动化代码审查反馈”

AGENT: “理解 - 该产品为开发者和商业用户自动化代码审查反馈。让我生成产品愿景...”

反模式

不要：

一次问多个问题
在生成的内容中包括未选中的选项
跳过确认步骤
在不问的情况下假设答案
在选项中不加解释地使用技术术语

要：

一次一个问题
清晰、简洁的选项描述
频繁总结理解
包括逃生舱口（D、E选项）
尊重用户的自定义输入

内存协议（强制）

开始前： 读取 .claude/context/memory/learnings.md

完成后：

发现新模式 -> .claude/context/memory/learnings.md
遇到问题 -> .claude/context/memory/issues.md
做出决策 -> .claude/context/memory/decisions.md

假设中断：如果不在内存中，它就没有发生。

交互式需求收集框架Skill interactive-requirements-gathering