Back to Details

thinking-socratic

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Socratic Questioning

苏格拉底式提问

Core rule: Surface the load-bearing assumption or undefined term before you build. Ask only what you cannot resolve yourself; stop when the next action is decision-ready.
核心规则： 在开始构建前，先找出关键的假设或未定义的术语。只询问那些你自己无法解决的问题；当下一步行动已明确时，停止提问。

When to Use

适用场景

  • Request is underspecified ("make it fast", "add a dashboard", "fix the bug") and a guess would misbuild.
  • Claim rests on an unstated assumption that may be the real problem.
  • Someone treats a premise as "obvious" or jumps to a solution before the problem is defined.
  • Debugging a vague symptom that needs a checkable specific before investigation.
  • 需求描述不明确（如“让它变快”、“添加一个仪表盘”、“修复这个bug”），仅凭猜测会导致构建错误。
  • 某项主张基于未明确说明的假设，而该假设可能才是真正的问题所在。
  • 有人将某个前提视为“显而易见”，或是在问题定义清楚前就直接跳到解决方案。
  • 调试模糊的症状，需要先明确可验证的具体信息才能展开调查。

When NOT to Use

不适用场景

  • Spec is already clear and actionable — do the work; do not interrogate for theater.
  • Ambiguity is resolvable by reading code, running a command, or checking docs — resolve it yourself.
  • Mid-execution of an agreed plan — re-questioning every step is friction, not rigor.
  • Emergency where one load-bearing fact is enough to act — clarify that fact, then act (prefer ooda).
  • You need the strongest opposing case, not clarification — use steel-manning.
  • You need causal chain depth on a defined failure — use five-whys-plus or scientific-method.
  • 需求规格已经清晰且可执行——直接开展工作；不要为了形式而追问。
  • 模糊点可以通过阅读代码、运行命令或查阅文档解决——自行解决即可。
  • 正在执行已达成共识的计划——反复质疑每一步会造成阻碍，而非严谨。
  • 紧急情况，只需一个关键事实即可行动——先明确该事实，再采取行动（优先使用OODA循环）。
  • 你需要的是最强的对立论点，而非澄清——使用“钢人论证”法。
  • 你需要针对明确的故障深挖因果链——使用“五问法增强版”或科学方法。

Procedure

操作流程

  1. Name the gap. State what is undefined, assumed, or uncheckable. If you can fill it from tools/repo without the user, do that and stop.
  2. Ask the load-bearing question first. Prefer one question whose answer most changes what you will build. Categories (use only what the gap needs):
    • Clarification — "What does X mean / for whom / success looks like?"
    • Assumption — "What must be true? What if it is false?"
    • Evidence — "What supports this? What would disprove it?"
    • Perspective — "Who is affected / who would disagree?"
    • Implication — "What follows if we do this?"
    • Meta — "Is this the right question?"
  3. Resolve or branch. From the answer, either (a) write the clarified requirement/decision and proceed, or (b) ask at most one follow-up that still gates the work. Do not run all six categories by default.
  4. Make assumptions explicit. Restate: "This assumes X; success means Y; out of scope is Z." Confirm only if still ambiguous after your restatement.
  5. Stop at decision-ready clarity. When the next action no longer depends on a hidden premise, end questioning and act or hand off. Cap user-facing questions tightly; prefer batching the few that truly gate work.
  1. 明确空白点：指出哪些内容未定义、被假设或是无法验证。如果可以通过工具/代码库自行填补空白，就直接处理并停止提问。
  2. 先问关键问题：优先提出一个答案会最大程度改变后续构建方向的问题。可根据空白点选择以下类别（仅使用所需的类别）：
    • 澄清类——“X指的是什么？针对谁？成功的标准是什么？”
    • 假设类——“哪些情况必须成立？如果不成立会怎样？”
    • 证据类——“什么能支持这一点？什么能反驳这一点？”
    • 视角类——“哪些人会受到影响？哪些人可能不同意？”
    • 影响类——“如果我们这么做会有什么后果？”
    • 元问题类——“这是正确的问题吗？”
  3. 解决或跟进：根据回答，要么（a）撰写明确的需求/决策并推进工作，要么（b）最多再提出一个仍会阻碍工作的后续问题。不要默认遍历所有六个类别。
  4. 明确假设：重述内容：“本次工作假设X成立；成功标准为Y；Z不在范围内。”如果重述后仍存在模糊性，再进行确认。
  5. 达到决策就绪清晰度即停止：当下一步行动不再依赖隐藏的前提时，结束提问并开始行动或移交工作。严格控制面向用户的提问数量；优先将真正阻碍工作的少量问题一次性提出。

Output

输出格式

text
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>
text
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>

Verification

验证

  • Falsify / stop: If answers do not change the plan, you asked non-load-bearing questions — stop interrogating. If the "clarification" is still a guess, do not build; name the remaining blocker.
  • Over-application guard: Do not Socratic-interview a well-specified task. Do not outsource facts you can read or measure. Do not turn every step of execution into a new question round.
  • 验证无效则停止：如果回答不会改变计划，说明你提出的是非关键问题——停止追问。如果“澄清”后仍需猜测，不要开始构建；明确剩余的阻碍点。
  • 避免过度使用：不要对已明确规格的任务进行苏格拉底式提问。不要将自己可以查阅或测量的问题推给他人。不要将执行的每一步都变成一轮新的提问。