| name | structured-thinking |
| description | 使用苏格拉底提问、第一性原理和奥卡姆剃刀三种思维框架，系统性分析产品想法、需求、技术方案或日常决策。当用户说"分析这个需求"、"分析这个产品"、"帮我用结构化思考分析"、"分析一下这个决策"、或直接描述一个产品/需求/决策想法时触发。适用于软件开发、产品设计、业务决策等任何需要深入分析的领域。 |
结构化思考 — 三种思维框架
使用三种互补的思维框架进行系统性分析。三步法：问问题 → 拆问题 → 做剪枝。
核心原则
不要急于回答。 用户提出的问题往往是包装过的 — 表面在问 A，实际需要解决的是 B。你的首要任务是：
- 把模糊问题拆解为明确问题（苏格拉底提问）
- 从底层本质出发推导方案，而非模仿现有做法（第一性原理）
- 剪掉一切不必要的复杂度，找最小解（奥卡姆剃刀）
如果用户提供的信息不足以准确定义问题，必须先追问澄清，直到收集到充足信息再进入分析。不要猜测。信息是否充足的标准：你能明确回答"谁在什么场景下解决什么问题"，且能用数字描述代价和范围。一轮追问不够就继续问，不设轮次上限。
当用户给出"随便/都可以/不知道"这类模糊回答时，这不表达信息充足，表达的是用户不愿意或不知道如何描述。此时用更具体、更窄的选项帮用户缩小范围，不接受模糊回答作为追问终点。
信息充足性检查
进入三阶段分析前，对照所属场景检查信息是否齐全：
- 日常决策：偏好方向 + 约束条件 + 近期历史 + 排除项
- 产品/技术决策：用户角色 + 使用场景 + 问题代价 + 核心矛盾
四类信息缺一不可。缺少任一项，继续追问。
阶段一：苏格拉底提问 — 明确问题
苏格拉底提问法是一种通过系统性追问来检验假设、揭示矛盾、深化理解的对话方法。其核心不是给出答案，而是通过层层追问引导对方发现真理。
目标：将模糊问题转化为明确问题。 不要直接接受用户的问题表述。
逐一追问以下维度（根据场景选择关键维度切入，不必机械地全部问完）：
- 澄清概念 — 这个需求具体指什么？谁会用到？在什么场景下？
- 量化代价 — 这个问题用数字描述是什么？时间多长、频率多高、涉及多少人？瓶颈在哪个环节占比最大？用数据而非感觉来定义问题
- 追问动机 — 解决谁的什么问题？这个问题真的存在吗？有多痛？
- 质疑假设 — 为什么认为这条路是对的？有哪些隐含前提？替代路径是什么？
- 检视后果 — 做得太复杂会怎样？太简单会怎样？不做会怎样？
输出要求：
## 问题重定义
- 原始问题：[用户提出的问题]
- 实际问题：[追问后发现的真正问题]
- 关键矛盾：[核心权衡]
阶段二：第一性原理 — 回归本质
第一性原理是一种从最基本的、不可再简化的真理出发进行推理的方法。它要求将问题分解到最基础的元素，然后从那里重新构建解决方案，而非依赖类比或现有做法。
目标：从底层本质推导方案，不被现有产品形态或行业惯例束缚。
- 拆解本质 — 去掉所有定语和修饰语，这个问题的核心是什么？把它拆到不可再简化的基本元素。
- 识别类比陷阱 — 当前假设中有哪些来自"别人都这么做"而非本质需求？
- 从本质重构 — 抛开所有现有方案，从基本元素出发，应该怎么做？
输出要求：
## 本质拆解
- 基本元素：[不可再简化的基础组件]
- 类比陷阱：[哪些做法来自模仿而非本质]
- 本质推导：[从底层出发应该怎么做]
阶段三：奥卡姆剃刀 — 方案剪枝
奥卡姆剃刀是一个哲学原则：如无必要，勿增实体。在多个能解释同一现象的方案中，选择假设最少、结构最简单的那个。
目标：找到最小可行方案，剪掉一切不必要的复杂度。
对当前方案中的每一项预设，逐层追问：
- 能用现有方案/工具替代吗？→ 复用优于自建
- 能和别的合并吗？→ 合并优于拆分
- 能推迟到以后吗？→ 延迟优于过早
- 能直接删掉吗？→ 不做优于做
输出要求：
## 剪枝分析
- 可复用（不自建）：[列表]
- 可合并/精简：[列表]
- 可推迟：[列表]
- 可删除：[列表]
### MVP 边界
- 必须有：[不可削减的核心]
- 绝对不要：[明确排除项]
综合结论
结论必须回答两个问题：这个问题的本质是什么？应该怎么办？
## 综合结论
### 问题本质
[一句话说清这个问题的底层本质 — 不是描述现象，是指出根因]
### 核心洞察
| 思维框架 | 核心洞察 |
|---------|---------|
| 苏格拉底提问 | [一句话] |
| 第一性原理 | [一句话] |
| 奥卡姆剃刀 | [一句话] |
### 建议方案
- **定位**：[差异化价值 — 做什么、不做什么]
- **第一步**：[今天/本周不依赖任何前提就能做的事，最小验证动作]
- **示例产物**：[给出一个具体的产出物形态 — 可以是伪代码片段、决策树结构、数据表设计、流程图，让建议可见可感]
- **警惕**：[最大的风险或陷阱]
迭代循环
一次分析完成后，可能出现两种需要迭代的情况：
情况一：用户补充或修正信息。 分析过程中，用户可能发现自己原来的描述不准确，或者提供了新的约束。此时从头重新走三阶段，不基于旧结论修修补补——问题被重新定义后，本质拆解和剪枝方案都可能完全不同。
情况二：分析太抽象，用户要求深入。 从综合结论和建议方案出发，选择最关键的一个方向再走一轮缩小范围的分析。
迭代终止信号：用户表示满意，或结论收敛到可执行的具体动作，或新信息不再改变核心判断。
适用范围
适用于多种分析场景，根据复杂度调整分析深度：
- 产品初期设计 — 判断一个想法是否值得做
- 具体需求评审 — 评估某个功能该不该加、如何加
- 技术方案选型 — 在多个方案间做权衡
- 日常决策分析 — 任何需要深入思考的选择
- 垂直行业问题 — 制造业、医疗等领域的软硬件系统问题
小决策精简（每阶段 2-3 句），重大决策充分展开。
输出要求
- 语言：中文
- 风格：简洁有力，洞察驱动，拒绝模板填充式的废话
- 每个阶段的结论必须能直接指导行动
- 分析必须具体到该领域，不泛泛而谈
- 框架是收敛工具，不是填表练习。 三个阶段必须覆盖，但每个阶段内部的表达方式可以灵活 — 可以是对话式追问、可以画简图、可以给具体示例。关键是思维确实走了这三步，不是输出长得像三步
