若定义不明确，请提问。
ask-questions-if-underspecified
需求不足时询问
使用场景
当请求存在多种可能的解释，或关键细节（目标、范围、约束、环境或安全性）不明确时，使用此技能。不适用场景
当请求已经很明确，或者可以通过快速、低风险的探索性阅读来解答缺失细节时，不要使用此技能。目标
询问最少数量的澄清问题以避免无效工作；在必须回答的问题得到解答之前（或用户明确同意基于既定假设继续执行之前），不要开始实施。工作流
1) 判断请求是否定义不足
如果在探索如何执行工作后，以下一项或多项不明确，则视为定义不足：- 定义目标（什么应该改变 vs 什么保持不变）
- 定义“完成”（验收标准、示例、边缘情况）
- 定义范围（哪些文件/组件/用户在范围内/范围外）
- 定义约束（兼容性、性能、风格、依赖、时间）
- 确认环境（语言/运行时版本、操作系统、构建/测试运行器）
- 明确安全性/可逆性（数据迁移、发布/回滚、风险）
如果存在多种合理的解释，请将其视为定义不足。
2) 优先询问必须回答的问题（保持精简）
第一轮询问控制在 1-5 个问题。优先选择能排除整个工作分支的问题。使问题易于回答：
- 优化可扫描性（简短的编号问题；避免段落）
- 尽可能提供多选题
- 在适当的时候建议合理的默认值（清晰地标记为默认/推荐选项；在列表中将推荐选项加粗，或者如果在代码块中提供选项，在代码块上方紧跟一行加粗的“推荐”，并在代码块内部标记默认值）
- 提供快速响应路径（例如：回复
defaults以接受所有推荐/默认选项）
- 在有帮助时提供低摩擦的“不确定”选项（例如：“不确定 - 使用默认值”）
- 如果能降低沟通成本，将“必须知道”与“最好知道”分开
- 组织选项以便用户可以用紧凑的方式回答（例如：
1b 2a 3c）；随后用自然语言复述所选选项以确认
3) 在行动前暂停
在获得必须的答案之前：- 不要运行命令、编辑文件或制定依赖于未知因素的详细计划
- 仅在不决定最终方向的前提下，执行标记明确且低风险的探索步骤（例如：检查仓库结构、阅读相关配置文件）
如果用户明确要求在没有答案的情况下继续：
- 将你的假设列为一个简短的编号列表
- 请求确认；仅在用户确认或纠正后才继续执行
4) 确认理解，然后执行
获得答案后，用 1-3 句话复述需求（包括关键约束和成功标准），然后开始工作。问题模板
- “在开始之前，我需要确认：(1) ...，(2) ...，(3) ...。如果您不在意 (2)，我将假设 ...”
- “应该是以下哪一种？A) ... B) ... C) ... (请选择其一)”
- “您认为什么样的状态算作‘完成’？例如：...”
- “是否有我必须遵守的约束（版本、性能、风格、依赖）？如果没有，我将采用现有项目的默认设置。”
- 使用编号问题配合字母选项，并提供清晰的回复格式
text
1) 范围？
a) 最小化更改（默认）
b) 在涉及该区域时进行重构
c) 不确定 - 使用默认值
2) 兼容性目标？
a) 当前项目默认值（默认）
b) 同时支持旧版本：<请指定>
c) 不确定 - 使用默认值
请回复：defaults（或 1a 2a）
反模式
- 不要询问可以通过快速、低风险的探索性阅读（如配置、现有模式、文档）即可回答的问题。
- 如果紧凑的选择题或“是/否”问题能更快消除歧义，请不要询问开放式问题。
局限性
- 仅在任务明确符合上述范围时使用此技能。
- 不要将输出结果视为针对特定环境的验证、测试或专家评审的替代方案。
- 如果缺少必要的输入、权限、安全边界或验收标准，请停止并请求澄清。
