ask-questions-if-underspecified

信息不足时先提问

目标

提出避免错误工作的最少量澄清问题；在必须回答的问题得到答复前，不要开始实施（除非用户明确同意按已说明的假设继续）。

工作流程

1) 判断请求是否信息不足

如果在探索如何开展工作后，以下部分有任何一项或多项尚不明确，则将请求视为信息不足：

• 明确目标（哪些内容应更改，哪些应保持不变）
• 明确“完成”的标准（验收标准、示例、边界情况）
• 明确范围（涉及和不涉及哪些文件、组件、用户）
• 明确约束（兼容性、性能、风格、依赖项、时间）
• 确认环境（语言／运行时版本、操作系统、构建／测试运行器）
• 澄清安全性／可逆性（数据迁移、发布、回滚、风险）

如果存在多种合理解释，则假定请求信息不足。

2) 先询问必须明确的问题（数量尽量少）

首轮提出 1-5 个问题。优先选择能排除整类工作方向的问题。

让问题易于回答：

• 便于快速浏览（简短、编号；避免大段文字）
• 尽可能提供选项
• 适当时建议合理的默认值（清楚标注为默认／推荐选项；在列表中将推荐选项加粗，或在代码块中列出选项时，在代码块正上方单独加粗标注“推荐”，并在代码块内标明默认选项）
• 提供快速回复方式（例如，回复 defaults 即接受所有推荐／默认选项）
• 适当时提供轻松的“不确定”选项（例如，“不确定——使用默认值”）
• 如果能减少回答负担，则将“必须了解”和“可选了解”分开
• 设计选项，便于用户简洁作答（例如，1b 2a 3c）；用简单明了的语言复述所选选项以确认

3) 开始前暂停

在收到必须明确问题的答复前：

• 不要运行命令、编辑文件，也不要制定依赖未知信息的详细计划
• 仅当不会让工作方向先入为主时，才可进行明确标注的低风险探索（例如，查看代码库结构、读取相关配置文件）

如果用户明确要求不等答复直接继续：

• 用简短编号列表说明你的假设
• 请用户确认；只有在用户确认或更正后才继续

4) 确认理解后再继续

收到答复后，用 1-3 句话重述要求（包括关键约束和成功标准），然后开始工作。

问题模板

• “开始前，我需要确认：（1）……；（2）……；（3）……。如果你对（2）没有要求，我会默认……。”
• “你希望采用哪种方案？A) …… B) …… C) ……（选一项）”
• “你认为满足什么条件才算‘完成’？例如：……”
• “有哪些约束需要遵守（版本、性能、风格、依赖项）？如果没有，我会采用项目现有的默认设置。”
• 使用带字母选项的编号问题，并明确说明回复格式

1) Scope?
a) Minimal change (default)
b) Refactor while touching the area
c) Not sure - use default
2) Compatibility target?
a) Current project defaults (default)
b) Also support older versions: <specify>
c) Not sure - use default

Reply with: defaults (or 1a 2a)

反面模式

• 不要询问可以通过快速、低风险地查看资料解答的问题（例如配置、现有惯例、文档）。
• 如果简洁的多选题或是／否问题能更快消除歧义，就不要提出开放式问题。

---

最初由 @thsottiaux 创建