# Clarifying Questions

> 需求模糊、含隐藏假设或 X-Y problem，需先澄清再动手时。

- Skill: `lion-1209/clarifying-questions` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add lion-1209/clarifying-questions`
- Raw SKILL.md: https://api.skillmd.com/api/skills/lion-1209/clarifying-questions/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: Lion-1209 (https://skillmd.com/u/lion-1209)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/lion-1209/clarifying-questions

---


# Clarifying Questions

## 概述

在动手前把模糊需求搞清楚。核心：**澄清是少数能"以最小成本避免最大返工"的动作**——一行代码没写时问清楚，比写完一千行发现方向错便宜几个数量级。但澄清本身也有成本（消耗用户耐心），所以重点是**少而准**——问对的关键问题，而不是多而全地把所有未知都问一遍。

## 何时使用

- 用户一句话甩需求，关键细节缺失（"做个登录""加个搜索"）
- 用户描述详细但藏隐含假设（"实时搜索"——实时是多实时？数据多大？）
- 疑似 X-Y problem：用户要的方案可能不是真正需要解决的问题
- 用户脑里似乎有想法但表达不全

**不该用**：需求已经清楚（直接做，问反而是拖延）；纯技术实现细节的请教（直接答）；用户明确说"按你的判断来"且确有默认合理选择（用默认、标注假设即可，不必走完整澄清流程）。

**与相邻 skill 的衔接**：clarifying-questions 在"**澄清需求** → 写 spec → 拆任务"流水线的最上游。需求搞清楚后，进入 `spec-writing` 把方案固化、再进 `task-breakdown` 拆任务。注意 task-breakdown / spec-writing 内部也有"澄清"环节——那是嵌入式的小澄清；本 skill 是**以澄清为核心动作**、处理更早期更模糊需求的专职 skill。

## 核心内容

### 先判断：该不该问、问多少

不是所有模糊都该追问。先快速判断需求模糊的"性质"，决定要不要问、问多少：

- **完全无法动手的模糊**（"做个系统"）→ 必须问，不问就是猜，猜错的代价最大。
- **能动手但有多个合理方向**（"做个登录"——账号密码 / OAuth / 手机号都合理）→ 问**阻塞方向选择的关键 1-2 个**，其余用默认假设推进。
- **只有一个合理默认的小模糊**（"加个时间戳"——基本就是 `created_at`）→ 不问，用默认、标注"我假设 X"。

判断尺子：**这个模糊不澄清，会不会让我做错方向、整个返工？**会 → 必须问；不会、只是细节差异 → 用默认假设推进。

### 问什么：穿透表面，找真正的问题

用户给的需求经常是"表面需求"——描述了想做什么，但藏了假设、漏了上下文、甚至问错了方向。澄清的核心是**穿透表面**：

**识别隐含假设**：用户描述里的每个形容词、每个限定词，都可能藏着未明说的假设。

- "实时搜索"——实时是多实时？（100ms？1s？这决定要不要上 ES）
- "高并发"——多高？（100 QPS 和 10 万 QPS 是两个世界）
- "支持多语言"——哪几种？UI 多语言还是数据多语言？

把用户的描述逐词过一遍，找出**会改变方案的隐含假设**，确认它们。

**识别 X-Y problem**：用户说要解决 Y，但 Y 其实是为了解决 X 的一个候选方案——而 X 可能还有更好的解法。

- 用户："帮我写个清理三个月前日志的脚本"（Y）
- 真正的问题：日志占空间（X）—— 但更好的解法可能是 logrotate、日志聚合、或先查为什么日志暴增（是不是异常？），而不是手写清理脚本

识别信号：用户要的"方案"听起来**太具体、太底层**（写脚本、改某个字段、加某个配置），而**真正的问题**（为什么需要这么做）没说。这时先问"你想解决的是什么问题 / 这个需求是怎么来的"，把 Y 放回 X 的语境。

**挑战不必要的复杂度（但要有度）**：用户常常在描述里把"必须的"和"锦上添花的"混在一起，甚至把后者当成前者。澄清时主动挑战："你真的需要 X 吗？还是简单方案就够了？"例：用户要"模糊匹配 + 高亮 + 实时搜索"，可能用户名精确匹配就够——别被详细描述带着走、把每条都当硬需求。

挑战的尺度：**挑战"锦上添花的"，不挑战"用户真在意的"**。判断方法是问"如果没有 X，业务还能跑吗"——能跑且只是体验差一点 → 可挑战；跑不了或用户明确在意 → 别砍。过度砍复杂度比过度加复杂度更危险——前者砍掉了用户真需要的东西，后者只是多花点功夫。挑战完**把决策权交回用户**，而不是替用户决定"这个不需要"。

### 怎么问：让用户低成本回答

问的方式直接决定用户愿不愿答、答得准不准。

**给默认假设让用户确认，而非开放式追问**：

- 差（开放式）："你要什么登录方式？"——用户得从头想，消耗耐心。
- 好（假设式）："我假设账号密码登录 + 邮箱注册（最常见的默认）。如果你要的是 OAuth/手机验证码/SSO，告诉我。"——用户只需确认或一句话纠正。

假设式让用户**一句话就能校正方向**，把"想答案"的认知负担降到最低。

**区分"假设"和"硬问题"**：不是所有未知都适合用假设推进——分两类处理，负担分配才合理：

- **用假设推进的**（低负担）：有合理默认、错了也容易回头改的实现细节。如"429 body 格式""Redis key 命名"——给默认、标"不对再纠正"，不必等用户答。
- **必须作为硬问题等用户答的**（高负担但必要）：会改变方案方向、错了要返工的根本决策。如"登录方式选哪种""数据量多大""是不是 X-Y problem"——这些**不能替用户假设**，必须显式问、等回答。

混淆两者的代价：把硬问题当假设（替用户决定了方向）→ 返工；把假设当硬问题（每个细节都追问）→ 用户被问烦。判断尺子还是那条：**不答会不会做错方向？**会 → 硬问题；不会 → 假设。

**多选项时，给倾向而非让用户选**：当澄清出多个候选方案（如 logrotate / 日志聚合 / 查根因），别只罗列后问"你倾向哪个"——那把决策的认知负担又抛回给用户。先基于已建立的上下文给一个**倾向性建议 + 理由**（"如果是突然暴增，我倾向先查根因；如果是慢性增长，logrotate 是首选——你的日志是哪种情况？"），让用户在"确认/纠正倾向"和"回答分支条件"之间二选一，而非从零选。

**问"为什么"，建立上下文**：与其问"你要 A 还是 B"，不如先问"这个需求是怎么来的 / 你想解决什么"。后者能一次说清动机，往往顺便回答了前者、还可能暴露 X-Y problem。

**带"为什么问"**：每个问题附带一句"为什么问这个"——让用户理解这个未知如何影响方案，而非感觉被盘问。例："数据量大概多少？（决定用 Postgres 全文搜索还是上 ES）"。

**优先级排序**：把问题按"不答就动不了手"的程度排序，阻塞项在前、锦上添花的在后。一次别超过 5-6 个——多了用户接不住，且通常前 2-3 个回答就能让方向明朗。

### 何时停止：别为澄清而澄清

澄清有边际收益，也有边际成本。停下来的信号：

- **核心方向已明**：用户回答后，"该做什么"已经清楚，剩下的都是实现细节 → 停，进入下一步（spec / 直接做）。
- **用户开始说"剩下的你看着办"**：用户已把决策权交给你 → 用合理默认假设推进，标注"我假设 X，不对再纠正"。
- **澄清本身变难**：用户答不上来（"我也不知道数据量多大"）→ 别逼问，提议"我先按 X 假设推进，遇到再调整"。

**澄清的目标不是消除所有未知，而是把"会导致返工的未知"清掉**。剩下的用合理假设 + 边走边调。

**回答自相矛盾或不现实时**：用户的澄清回答可能互相打架（"要支持百万用户但不引入新组件"）或与客观现实冲突（"零停机迁移"且"旧系统正在被废弃"）。别默默接受矛盾——**显式指出矛盾点**，把它抛回给用户："百万用户量级通常需要 Redis 集群这类组件，你说的'不引入新组件'是指绝对不引入、还是尽量少引入？这两个目标有点冲突，需要排个优先级。"指出矛盾比假装没看见更负责任——硬接矛盾的后果是实现期被迫单方面违反其中一条，且通常是更重要的那条。

### 产出形态：澄清完如何收口

澄清不是无限循环，要有一个**收口动作**让需求进入可执行状态：

- **回放已澄清的需求摘要**：澄清结束前，用一段话复述"我理解的需求是 X，关键决策是 Y，剩下的用 Z 假设推进"。让用户一眼确认"你理解对了"——这一步能抓住澄清中的误解（你以为澄清了、其实理解偏了）。
- **明确下一步**：澄清完直接说"接下来我进 spec / 直接拆任务 / 直接做"，让用户知道需求已进入下一环节，不会卡在"还要不要再问"的不确定里。
- **未答的未知显式列出**：用户跳过没答的、或用"你看着办"交回的，显式标注"以下我用默认假设推进，不对再纠正"，别让它们无声地变成隐患。

收口让澄清有始有终——澄清的产出是**一份双方对齐的需求理解**，不是一堆问了但没结论的问题。

## 常见错误

| 问题 | 修法 |
|------|------|
| 不问直接猜（"做个登录"→ 直接做账号密码） | 模糊到有多个合理方向时必须问阻塞项，猜错的返工代价最大 |
| 开放式连环追问（"你要什么 X？"× N） | 改用默认假设让用户确认，用户一句话就能校正 |
| 问了无关紧要的细节（按钮颜色、字段命名） | 聚焦"会改变方案的未知"，实现细节用默认 |
| 把用户的每条描述都当硬需求 | 挑战不必要的复杂度，问"你真的需要 X 吗" |
| 顺着用户的方案走，错过 X-Y problem | 用户方案太具体太底层时，先问"真正想解决什么" |
| 澄清没完没了，用户被问烦 | 核心方向一明就停，剩下用假设推进 |
| 问了但不听，按自己原假设走 | 用户的回答要显式纳入后续判断，不是走形式 |
| 多选项只罗列让用户从零选 | 先给基于上下文的倾向性建议，让用户确认/纠正 |
| 用户回答自相矛盾时默默接受 | 显式指出矛盾点，把优先级判断抛回给用户 |
| 澄清完没收口，需求悬在半空 | 回放需求摘要 + 明确下一步 + 列出未答未知 |