需求含糊或充满隐含假设时…

当请求描述不清、依赖未说明的假设、或有人把前提当作「显而易见」就跳到方案时，先问清关键问题再开工。

适用场景

解决思路

1. 命名缺口：说清什么是未定义的、被假设的、或无法验证的；如果自己能通过工具或代码库补齐，就直接补齐并停止提问。
2. 先问最承重的问题：优先问一个「答案最能改变你要构建什么」的问题。仅在缺口需要时，从以下类别中选用：澄清类——「X 是什么意思／给谁用／成功长什么样？」；假设类——「什么必须为真？如果为假会怎样？」；证据类——「什么支持它？什么能推翻它？」；视角类——「谁受影响／谁会反对？」；影响类——「如果我们这么做，会带来什么后果？」；元问题类——「这是不是正确的问题？」
3. 解决或分支：根据回答，要么写出澄清后的需求／决策并继续推进，要么最多再问一个仍然卡住工作的问题；不要默认把六个类别全部跑一遍。
4. 把假设显式化：复述「这假设 X；成功意味着 Y；不在范围内的是 Z」；只有在复述之后仍然含糊时才去向用户确认。
5. 在「可决策」的清晰度处停止：当下一个动作不再依赖隐藏前提时，结束提问并执行或移交；严格控制面向用户的问题数量，尽量把真正卡住工作的少数问题批量提出。
6. 停止与证伪检查：如果得到的答案并不改变计划，说明你问的是非承重问题——立刻停止盘问；如果所谓的「澄清」仍然是猜测，就不要开始构建，而是点名剩下的阻塞项。
7. 反过度应用检查：不要对规格明确的任务做苏格拉底式盘问；不要把你自己能读到或度量到的事实外包给别人；不要把执行的每一步都变成新一轮提问。
8. 输出结构化记录，字段为：gap（哪里含糊或被假设）、resolved_by（self | user | mixed）、questions_asked（只列真正需要的问题）、assumptions_made_explicit（X 必须为真／成功 = Y）、clarified_requirement（可决策的陈述）、next_action（build | investigate | re-scope | stop）、stop_reason（clear_enough | self_resolved | blocked_on_<fact>）。

适用边界 · 注意事项

• 规格已经清晰、可直接执行时，直接干活，不要为了走流程而盘问；歧义能靠读代码、跑命令或查文档解决时，自行解决而不是问用户。
• 已经就计划达成一致、正在执行中途时，不要对每一步重新提问——那是摩擦而不是严谨；紧急情况下只需先澄清一个承重事实，然后立即行动。
• 当你需要的是最强反方论证（用 steel-manning）或对已定义故障做因果链深挖（用 five-whys-plus 或科学方法）时，不要用苏格拉底式提问。