Back to Details

ask-questions

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.
  • 不要提出可以通过快速、低风险的探索性阅读就能找到答案的问题（例如，配置文件、现有模式、文档）。
  • 如果选择题或是非题能更快消除歧义，就不要提出开放式问题。