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 one or more are unclear:
  • Objective (what should change vs. stay the same)
  • “Done” (acceptance criteria, examples, edge cases)
  • Scope (which files/components/users are in/out)
  • Constraints (compatibility, performance, style, deps, time)
  • Environment (runtime versions, OS, build/test runner)
  • Safety/reversibility (migration/rollback risk)
If there are multiple plausible interpretations, 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 them easy to answer:
  • Use numbered questions with short options (yes/no or a/b/c)
  • Recommend defaults when reasonable
  • Provide a fast-path response (e.g., “reply 
    defaults
    ”)
  • Separate “Need to know” vs “Nice to know” when helpful
首次提问时提出1-5个问题。优先选择能直接排除大量无效工作方向的问题。
让问题易于回答：
  • 使用带编号的问题，并提供简短选项（是/否或A/B/C）
  • 在合理情况下推荐默认选项
  • 提供快速回复路径（例如：“回复
    defaults
    即可”）
  • 必要时区分“必须明确”和“可选了解”的问题

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 allow low-risk discovery reads (repo structure/configs) if they do not commit to a direction
If the user explicitly wants you to proceed without answers:
  1. State assumptions as a short numbered list
  2. Ask for confirmation
  3. Proceed only after confirm/correct
在核心问题得到解答前：
  • 不要执行命令、编辑文件，或制定依赖未知信息的详细计划
  • 允许进行低风险的探索性阅读（如查看仓库结构/配置），只要不锁定特定方向
如果用户明确要求无需解答即可推进：
  1. 将假设整理成简短的编号列表
  2. 请求用户确认
  3. 仅在用户确认/修正后再推进

4) Confirm interpretation, then proceed

4) 确认解读，再开始工作

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

Templates

模板

  • “Before I start, I need: (1) … (2) … (3) …. If you don’t care about (2), I’ll assume ….”
  • “Which should it be? A) … B) … C) … (pick one)”
  • “What would you consider ‘done’? For example: …”
  • “Any constraints (versions, perf, style, deps)? If none, I’ll target existing project defaults.”
Example (compact decision 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) 范围？
a) 最小化变更（默认）
b) 同时重构相关区域
c) 不确定 - 使用默认选项

2) 兼容性目标？
a) 当前项目默认配置（默认）
b) 同时支持旧版本：<请指定>
c) 不确定 - 使用默认选项

回复：defaults（或1a 2a）

Anti-patterns

反模式

  • Don’t ask questions you can answer via quick, low-risk discovery (configs/docs/grep).
  • Don’t ask open-ended questions when a tight multiple-choice would resolve ambiguity faster.
  • 不要提出可以通过快速、低风险的探索（查看配置/文档/使用grep命令）就能自行解答的问题。
  • 当紧凑的选择题能更快解决歧义时，不要提出开放式问题。