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，告诉我。"——用户只需确认或一句话纠正。

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