Back to Details

ask-questions-if-underspecified

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Ask Questions If Underspecified

若需求不明确，先提出疑问

When to Use

使用场景

Use this skill when a request has multiple plausible interpretations or key details (objective, scope, constraints, environment, or safety) are unclear.
当请求存在多种合理解读，或关键细节（目标、范围、约束、环境或安全性）不明确时，使用此技巧。

When NOT to Use

不适用场景

Do not use this skill when the request is already clear, or when a quick, low-risk discovery read can answer the missing details.
当请求已经明确，或通过快速、低风险的探索性阅读即可补充缺失细节时，请勿使用此技巧。

Goal

目标

Ask the minimum set of clarifying questions needed to avoid wrong work; do not start implementing until the must-have questions are answered (or the user explicitly approves proceeding with stated assumptions).
提出最少必要的澄清问题，避免做无用功；在必须澄清的问题得到解答（或用户明确同意基于所述假设推进）之前，不要开始实施。

Workflow

工作流程

1) Decide whether the request is underspecified

1) 判断需求是否不明确

Treat a request as underspecified if after exploring how to perform the work, some or all of the following are not clear:
  • Define the objective (what should change vs stay the same)
  • Define "done" (acceptance criteria, examples, edge cases)
  • Define scope (which files/components/users are in/out)
  • Define constraints (compatibility, performance, style, deps, time)
  • Identify environment (language/runtime versions, OS, build/test runner)
  • Clarify safety/reversibility (data migration, rollout/rollback, risk)
If multiple plausible interpretations exist, assume it is underspecified.
在探索如何开展工作后，若以下部分或全部内容不清晰，则判定需求不明确：
  • 明确目标（哪些需要变更，哪些保持不变）
  • 定义“完成”状态（验收标准、示例、边缘情况）
  • 定义范围（涉及哪些文件/组件/用户，排除哪些）
  • 定义约束条件（兼容性、性能、风格、依赖、时间）
  • 明确环境（语言/运行时版本、操作系统、构建/测试运行器）
  • 澄清安全性/可回滚性（数据迁移、发布/回滚、风险）
若存在多种合理解读，则默认需求不明确。

2) Ask must-have questions first (keep it small)

2) 先提出必须澄清的问题（控制数量）

Ask 1-5 questions in the first pass. Prefer questions that eliminate whole branches of work.
Make questions easy to answer:
  • Optimize for scannability (short, numbered questions; avoid paragraphs)
  • Offer multiple-choice options when possible
  • Suggest reasonable defaults when appropriate (mark them clearly as the default/recommended choice; bold the recommended choice in the list, or if you present options in a code block, put a bold "Recommended" line immediately above the block and also tag defaults inside the block)
  • Include a fast-path response (e.g., reply 
    defaults
    to accept all recommended/default choices)
  • Include a low-friction "not sure" option when helpful (e.g., "Not sure - use default")
  • Separate "Need to know" from "Nice to know" if that reduces friction
  • Structure options so the user can respond with compact decisions (e.g., 
    1b 2a 3c
    ); restate the chosen options in plain language to confirm
首次提问控制在1-5个。优先选择能排除整类无效工作方向的问题。
让问题易于回答：
  • 优化可读性（简短的编号问题；避免段落式提问）
  • 尽可能提供多选选项
  • 适当情况下给出合理默认值（明确标记为默认/推荐选项；在列表中加粗推荐选项，若在代码块中展示选项，需在块上方添加加粗的“推荐”行，并在块内标记默认值）
  • 提供快速回复路径（例如，回复
    defaults
    以接受所有推荐/默认选项）
  • 必要时加入低门槛的“不确定”选项（例如，“不确定 - 使用默认值”）
  • 若能降低沟通成本，可区分“必须知晓”和“可选知晓”的问题
  • 结构化选项，让用户可以用简洁的方式回复（例如，
    1b 2a 3c
    ）；用平实语言重述用户的选择以确认

3) Pause before acting

3) 行动前暂停

Until must-have answers arrive:
  • Do not run commands, edit files, or produce a detailed plan that depends on unknowns
  • Do perform a clearly labeled, low-risk discovery step only if it does not commit you to a direction (e.g., inspect repo structure, read relevant config files)
If the user explicitly asks you to proceed without answers:
  • State your assumptions as a short numbered list
  • Ask for confirmation; proceed only after they confirm or correct them
在必须澄清的问题得到解答前：
  • 不要执行命令、编辑文件，或制定依赖未知信息的详细计划
  • 仅可执行标记清晰的低风险探索步骤，且该步骤不会让你绑定到某个方向（例如，检查仓库结构、阅读相关配置文件）
若用户明确要求你在无答案的情况下推进：
  • 将你的假设整理为简短的编号列表
  • 请求确认；仅在用户确认或修正假设后再推进

4) Confirm interpretation, then proceed

4) 确认解读，再推进

Once you have answers, restate the requirements in 1-3 sentences (including key constraints and what success looks like), then start work.
得到答案后，用1-3句话重述需求（包括关键约束和成功标准），然后开始工作。

Question templates

提问模板

  • "Before I start, I need: (1) ..., (2) ..., (3) .... If you don't care about (2), I will assume ...."
  • "Which of these should it be? A) ... B) ... C) ... (pick one)"
  • "What would you consider 'done'? For example: ..."
  • "Any constraints I must follow (versions, performance, style, deps)? If none, I will target the existing project defaults."
  • Use numbered questions with lettered options and a clear reply format
text
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)
  • "开始前，我需要确认：(1) ..., (2) ..., (3) .... 若你不关心(2)，我将假设...."
  • "应该选择以下哪一项？A) ... B) ... C) ...（选一个）"
  • "你如何定义‘完成’？例如：..."
  • "我需要遵循哪些约束条件（版本、性能、风格、依赖）？若无，我将以现有项目的默认配置为准。"
  • 使用带编号的问题和带字母的选项，并提供清晰的回复格式
text
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)

Anti-patterns

反模式

  • Don't ask questions you can answer with a quick, low-risk discovery read (e.g., configs, existing patterns, docs).
  • Don't ask open-ended questions if a tight multiple-choice or yes/no would eliminate ambiguity faster.
  • 若通过快速、低风险的探索性阅读即可找到答案（例如，配置文件、现有模式、文档），请勿提问。
  • 若通过严谨的多选或是非题能更快消除歧义，请勿提出开放式问题。