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)

反面模式

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

限制

• 仅当任务明确符合上述范围时，才使用此技能。
• 不要将输出视为特定环境验证、测试或专家评审的替代品。
• 如果缺少必需的输入、权限、安全边界或成功标准，请停止并请求澄清。