名称: 询问问题以防未明确指定 描述: 在实施前澄清要求。不要自动使用，仅在明确调用时使用。
询问问题以防未明确指定
目标
询问避免错误工作所需的最少澄清问题；在必须的问题得到回答（或用户明确批准继续基于陈述的假设）之前，不要开始实施。
工作流程
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）
反模式
- 不要询问可以通过快速、低风险发现读取回答的问题（例如，配置、现有模式、文档）。
- 不要询问开放式问题，如果紧密的多项选择或是/否能更快消除歧义。
最初由 @thsottiaux 创建