如果需求不明确则提问 (Ask Questions If Underspecified)

何时使用

当请求有多种合理的解释或关键细节（目标、范围、限制、环境或安全性）不清楚时，请使用此技能。

何时不使用

当请求已经很明确，或者可以通过快速、低风险的探索性阅读来回答缺失的细节时，请勿使用此技能。

目标

提出避免错误工作所需的最少量澄清问题；在必须回答的问题得到回答之前（或者用户明确批准在所述假设下继续进行之前），不要开始实施。

工作流程

1) 决定请求是否不明确

如果在探索如何执行工作后，以下部分或全部内容不清楚，则将请求视为不明确：

• •定义目标（什么应该改变 vs 保持不变）
• •定义“完成”（验收标准、示例、边缘情况）
• •定义范围（哪些文件/组件/用户在范围内/外）
• •定义约束（兼容性、性能、风格、依赖项、时间）
• •识别环境（语言/运行时版本、操作系统、构建/测试运行器）
• •澄清安全性/可逆性（数据迁移、推出/回滚、风险）

如果存在多种合理的解释，则假设它是不明确的。

2) 先问必须问的问题（保持简短）

在第一轮中提出 1-5 个问题。倾向于提出能够排除整个工作分支的问题。

让问题易于回答：

• •优化可扫描性（简短的编号问题；避免段落）
• •尽可能提供多项选择选项
• •在适当的时候建议合理的默认值（清楚地将其标记为默认/推荐选择；在列表中将推荐选择加粗，或者如果您在代码块中提供选项，请在代码块正上方放置一行粗体的“推荐”，并在代码块内部标记默认值）
• •包含快速路径响应（例如，回复 defaults 以接受所有推荐/默认选择）
• •在有帮助时包含低摩擦的“不确定”选项（例如，“不确定 - 使用默认值”）
• •如果能减少摩擦，请将“需要知道”与“想知道”分开
• •构建选项结构，以便用户可以用紧凑的决策进行响应（例如，1b 2a 3c）；用简单的语言重述所选选项以确认

3) 在行动前暂停

在收到必须回答的答案之前：

• •不要运行命令、编辑文件或制定依赖于未知因素的详细计划
• •仅执行明确标记的、低风险的探索步骤，前提是它不会使你承诺某个方向（例如，检查仓库结构、读取相关的配置文件）

如果用户明确要求你在没有答案的情况下继续：

• •将你的假设列为一个简短的编号列表
• •要求确认；只有在他们确认或更正后才继续

4) 确认解释，然后继续

一旦你有了答案，用 1-3 句话重述需求（包括关键约束和成功是什么样子的），然后开始工作。

问题模板

• •“在我开始之前，我需要：(1) ..., (2) ..., (3) .... 如果你不关心 (2)，我将假设 ....”
• •“应该是哪一个？A) ... B) ... C) ... (选一个)”
• •“你认为什么是‘完成’？例如：...”
• •“我必须遵循确切的约束吗（版本、性能、风格、依赖项）？如果没有，我将以现有的项目默认值为目标。”
• •使用编号问题和字母选项以及清晰的回复格式

1) 范围?
a) 最小更改 (默认)
b) 重构并触及该区域
c) 不确定 - 使用默认值
2) 兼容性目标?
a) 当前项目默认值 (默认)
b) 也支持旧版本: <指定>
c) 不确定 - 使用默认值

回复: defaults (或 1a 2a)

反模式

• •不要问你可以通过快速、低风险的探索性阅读（例如，配置、现有模式、文档）来回答的问题。
• •如果紧凑的多项选择或是/否问题能更快消除歧义，不要问开放式问题。