ask-questions

信息不明确时先提问

目标

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

工作流

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)

反面模式

• 不要询问通过快速、低风险的探索性阅读就能回答的问题（例如查看配置、现有模式、文档）。
• 如果精简的多选题或是／否问题能更快消除歧义，就不要提出开放式问题。