Menu
需求模糊、含隐藏假设或 X-Y problem，需先澄清再动手时。
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
审查代码（自己的或别人的），需有重点、分层次地看时。
Git 改动需编写规范提交信息时。
遇到 bug、报错、崩溃或行为异常，需定位根因时。
设计或改进错误处理与日志时。
在 Lion-Skills 仓库创建或修改 skill 时。
为代码标识符（变量/函数/类/文件/API/数据库字段）决定名字时。
| name | clarifying-questions |
| description | 需求模糊、含隐藏假设或 X-Y problem，需先澄清再动手时。 |
在动手前把模糊需求搞清楚。核心：澄清是少数能"以最小成本避免最大返工"的动作——一行代码没写时问清楚，比写完一千行发现方向错便宜几个数量级。但澄清本身也有成本（消耗用户耐心），所以重点是少而准——问对的关键问题，而不是多而全地把所有未知都问一遍。
不该用：需求已经清楚（直接做，问反而是拖延）；纯技术实现细节的请教（直接答）；用户明确说"按你的判断来"且确有默认合理选择（用默认、标注假设即可，不必走完整澄清流程）。
与相邻 skill 的衔接：clarifying-questions 在"澄清需求 → 写 spec → 拆任务"流水线的最上游。需求搞清楚后，进入 spec-writing 把方案固化、再进 task-breakdown 拆任务。注意 task-breakdown / spec-writing 内部也有"澄清"环节——那是嵌入式的小澄清；本 skill 是以澄清为核心动作、处理更早期更模糊需求的专职 skill。
不是所有模糊都该追问。先快速判断需求模糊的"性质"，决定要不要问、问多少：
created_at）→ 不问，用默认、标注"我假设 X"。判断尺子：**这个模糊不澄清，会不会让我做错方向、整个返工？**会 → 必须问；不会、只是细节差异 → 用默认假设推进。
用户给的需求经常是"表面需求"——描述了想做什么，但藏了假设、漏了上下文、甚至问错了方向。澄清的核心是穿透表面：
识别隐含假设：用户描述里的每个形容词、每个限定词，都可能藏着未明说的假设。
把用户的描述逐词过一遍，找出会改变方案的隐含假设，确认它们。
识别 X-Y problem：用户说要解决 Y，但 Y 其实是为了解决 X 的一个候选方案——而 X 可能还有更好的解法。
识别信号：用户要的"方案"听起来太具体、太底层（写脚本、改某个字段、加某个配置），而真正的问题（为什么需要这么做）没说。这时先问"你想解决的是什么问题 / 这个需求是怎么来的"，把 Y 放回 X 的语境。
挑战不必要的复杂度（但要有度）：用户常常在描述里把"必须的"和"锦上添花的"混在一起，甚至把后者当成前者。澄清时主动挑战："你真的需要 X 吗？还是简单方案就够了？"例：用户要"模糊匹配 + 高亮 + 实时搜索"，可能用户名精确匹配就够——别被详细描述带着走、把每条都当硬需求。
挑战的尺度：挑战"锦上添花的"，不挑战"用户真在意的"。判断方法是问"如果没有 X，业务还能跑吗"——能跑且只是体验差一点 → 可挑战；跑不了或用户明确在意 → 别砍。过度砍复杂度比过度加复杂度更危险——前者砍掉了用户真需要的东西，后者只是多花点功夫。挑战完把决策权交回用户，而不是替用户决定"这个不需要"。
问的方式直接决定用户愿不愿答、答得准不准。
给默认假设让用户确认，而非开放式追问：
假设式让用户一句话就能校正方向，把"想答案"的认知负担降到最低。
区分"假设"和"硬问题"：不是所有未知都适合用假设推进——分两类处理，负担分配才合理：
混淆两者的代价：把硬问题当假设（替用户决定了方向）→ 返工；把假设当硬问题（每个细节都追问）→ 用户被问烦。判断尺子还是那条：**不答会不会做错方向？**会 → 硬问题；不会 → 假设。
多选项时，给倾向而非让用户选：当澄清出多个候选方案（如 logrotate / 日志聚合 / 查根因），别只罗列后问"你倾向哪个"——那把决策的认知负担又抛回给用户。先基于已建立的上下文给一个倾向性建议 + 理由（"如果是突然暴增，我倾向先查根因；如果是慢性增长，logrotate 是首选——你的日志是哪种情况？"），让用户在"确认/纠正倾向"和"回答分支条件"之间二选一，而非从零选。
问"为什么"，建立上下文：与其问"你要 A 还是 B"，不如先问"这个需求是怎么来的 / 你想解决什么"。后者能一次说清动机，往往顺便回答了前者、还可能暴露 X-Y problem。
带"为什么问"：每个问题附带一句"为什么问这个"——让用户理解这个未知如何影响方案，而非感觉被盘问。例："数据量大概多少？（决定用 Postgres 全文搜索还是上 ES）"。
优先级排序：把问题按"不答就动不了手"的程度排序，阻塞项在前、锦上添花的在后。一次别超过 5-6 个——多了用户接不住，且通常前 2-3 个回答就能让方向明朗。
澄清有边际收益，也有边际成本。停下来的信号：
澄清的目标不是消除所有未知，而是把"会导致返工的未知"清掉。剩下的用合理假设 + 边走边调。
回答自相矛盾或不现实时：用户的澄清回答可能互相打架（"要支持百万用户但不引入新组件"）或与客观现实冲突（"零停机迁移"且"旧系统正在被废弃"）。别默默接受矛盾——显式指出矛盾点，把它抛回给用户："百万用户量级通常需要 Redis 集群这类组件，你说的'不引入新组件'是指绝对不引入、还是尽量少引入？这两个目标有点冲突，需要排个优先级。"指出矛盾比假装没看见更负责任——硬接矛盾的后果是实现期被迫单方面违反其中一条，且通常是更重要的那条。
澄清不是无限循环，要有一个收口动作让需求进入可执行状态：
收口让澄清有始有终——澄清的产出是一份双方对齐的需求理解，不是一堆问了但没结论的问题。
| 问题 | 修法 |
|---|---|
| 不问直接猜（"做个登录"→ 直接做账号密码） | 模糊到有多个合理方向时必须问阻塞项，猜错的返工代价最大 |
| 开放式连环追问（"你要什么 X？"× N） | 改用默认假设让用户确认，用户一句话就能校正 |
| 问了无关紧要的细节（按钮颜色、字段命名） | 聚焦"会改变方案的未知"，实现细节用默认 |
| 把用户的每条描述都当硬需求 | 挑战不必要的复杂度，问"你真的需要 X 吗" |
| 顺着用户的方案走，错过 X-Y problem | 用户方案太具体太底层时，先问"真正想解决什么" |
| 澄清没完没了，用户被问烦 | 核心方向一明就停，剩下用假设推进 |
| 问了但不听，按自己原假设走 | 用户的回答要显式纳入后续判断，不是走形式 |
| 多选项只罗列让用户从零选 | 先给基于上下文的倾向性建议，让用户确认/纠正 |
| 用户回答自相矛盾时默默接受 | 显式指出矛盾点，把优先级判断抛回给用户 |
| 澄清完没收口，需求悬在半空 | 回放需求摘要 + 明确下一步 + 列出未答未知 |