---

name: ask-questions-if-underspecified description: 在实现之前先澄清需求。当存在严重疑问时使用。 risk: unknown source: community

需求不明确时提问

何时使用

当请求有多种合理解释，或关键细节（目标、范围、约束、环境或安全性）不明确时使用此技能。

何时不使用

当请求已经明确，或通过快速、低风险的探索性阅读即可回答缺失细节时，不要使用此技能。

目标

提出最少量的澄清问题以避免做错工作；在必要问题得到回答（或用户明确批准在声明的假设下继续）之前不要开始实现。

工作流程

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）

反模式

• 不要问你可以通过快速、低风险的探索性阅读（例如配置、现有模式、文档）来回答的问题。
• 如果紧凑的多选或是/否能更快消除歧义，不要问开放式问题。

限制

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