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 / 直接拆任务 / 直接做"，让用户知道需求已进入下一环节，不会卡在"还要不要再问"的不确定里。
• 未答的未知显式列出：用户跳过没答的、或用"你看着办"交回的，显式标注"以下我用默认假设推进，不对再纠正"，别让它们无声地变成隐患。

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

常见错误