thinking-socratic

苏格拉底式提问

核心规则： 开始构建前，先指出关键假设或未定义的术语。只问你自己无法解决的问题；当下一步行动已具备决策所需的信息时，就停止提问。

适用场景

• 请求定义不充分（“让它更快”“添加一个仪表板”“修复这个错误”），凭猜测实现可能会偏离需求。
• 某个主张依赖未明说的假设，而这个假设可能才是真正的问题。
• 有人把某个前提当作“不言自明”，或在问题尚未定义时就跳到解决方案。
• 调试模糊的症状，需要先明确可验证的具体问题再进行调查。

不适用场景

• 规格已经清晰且可执行——直接着手处理；不要为了形式而盘问。
• 通过阅读代码、运行命令或查阅文档就能消除歧义——自行解决。
• 正在执行已达成一致的计划——每一步都重新提问只会增加阻力，而非严谨性。
• 紧急情况下只需一个关键事实就能采取行动——先确认该事实，然后行动（优先使用 ooda）。
• 你需要的是最有力的反方论据，而非澄清——使用 steel-manning。
• 你需要深入探究已明确故障的因果链——使用 five-whys-plus 或 scientific-method。

流程

1. 指出缺口。 说明哪些内容尚未定义、只是被假设，或无法核查。如果你可以通过工具或仓库自行补全，就自行处理并停止提问。
2. 先问关键问题。 优先提出一个答案最能影响你将要构建内容的问题。类别如下（只使用解决当前缺口所需的类别）：
   • 澄清——“X 是什么意思／面向谁／怎样才算成功？”
   • 假设——“哪些条件必须成立？如果不成立呢？”
   • 证据——“有什么依据？什么情况会推翻这一点？”
   • 视角——“谁会受到影响／谁可能持不同意见？”
   • 影响——“如果这样做，会带来什么结果？”
   • 元问题——“这是不是正确的问题？”
3. 解决问题或分支处理。 根据答案，(a) 写明澄清后的需求或决策，然后继续；或 (b) 最多再问一个仍会影响工作的后续问题。不要默认把六类问题全部问一遍。
4. 明确假设。 重述：“这里假设 X；成功意味着 Y；不在范围内的是 Z。”只有在重述后仍有歧义时才要求确认。
5. 在信息足以做出决策时停止。 当下一步行动不再取决于隐藏前提时，就结束提问并采取行动或移交工作。严格限制面向用户的问题数量；优先一次提出少数几个真正会影响工作的关键问题。

输出

gap: <what was vague or assumed>
resolved_by: self | user | mixed
questions_asked:
  - <only questions actually needed>
assumptions_made_explicit:
  - <X must be true / success = Y>
clarified_requirement: <decision-ready statement>
next_action: <build | investigate | re-scope | stop>
stop_reason: clear_enough | self_resolved | blocked_on_<fact>

验证

• 证伪／停止： 如果答案不会改变计划，说明你问的问题并非关键问题——停止追问。如果所谓的“澄清”仍然只是猜测，就不要开始构建；指出仍待解决的障碍。
• 防止过度应用： 不要用苏格拉底式提问盘问规格明确的任务。不要把你自己可以查阅或测量的事实交给用户去确认。不要把执行中的每一步都变成新一轮提问。