Back to Details

ask-questions-if-underspecified

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Ask Questions If Underspecified

需求不明确时请提问

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.
Originally created by @thsottiaux
  • 不要提出可以通过快速、低风险的探索性阅读就能回答的问题（例如，配置文件、现有模式、文档）
  • 如果用明确的多项选择或是非题能更快消除歧义，就不要提出开放式问题
最初由@thsottiaux创建