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)

反面做法

• 不要询问可以通过快速、低风险查阅获得答案的问题（例如，查看配置、现有模式、文档）。
• 如果精简的选择题或是非题能更快消除歧义，就不要提出开放式问题。