菜单
使用苏格拉底提问、第一性原理和奥卡姆剃刀三种思维框架，系统性分析产品想法、需求、技术方案或日常决策。当用户说"分析这个需求"、"分析这个产品"、"帮我用结构化思考分析"、"分析一下这个决策"、或直接描述一个产品/需求/决策想法时触发。适用于软件开发、产品设计、业务决策等任何需要深入分析的领域。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
构建验证、版本管理与发布上线。多轮确认发布目标与推送路径后执行门禁与发布，写入状态与 release notes。用户提到发布、上线、deploy、打 tag、发版、merge 到 main、推远程、构建生产包、创建 PR 时，即使未说 release 也必须使用本 skill。
技术架构设计。调研技术方案、评估开源项目、输出架构决策记录，写入 Tech-Arch.md。在 dev-planner 之前调用。
设计执行。基于 Design-Brief.md 产出原型、设计稿或设计系统。支持 Figma、Pencil、HTML/CSS 原型等多种输出方式。
需求收集与问题澄清。新建或迭代 PRD，通过交互式澄清生成结构化产品需求文档。
系统化调试修复 Bug。五阶段：收集证据→重现用例→分析(含根因归因)→假设→修复→进化记录。支持触发 code-review 和 feedback-writer。
代码审查和质量检查。调度 code-reviewer sub-agent 审查代码，检查是否符合计划和编码标准。
| name | structured-thinking |
| description | 使用苏格拉底提问、第一性原理和奥卡姆剃刀三种思维框架，系统性分析产品想法、需求、技术方案或日常决策。当用户说"分析这个需求"、"分析这个产品"、"帮我用结构化思考分析"、"分析一下这个决策"、或直接描述一个产品/需求/决策想法时触发。适用于软件开发、产品设计、业务决策等任何需要深入分析的领域。 |
使用三种互补的思维框架进行系统性分析。三步法：问问题 → 拆问题 → 做剪枝。
不要急于回答。 用户提出的问题往往是包装过的 — 表面在问 A，实际需要解决的是 B。你的首要任务是：
如果用户提供的信息不足以准确定义问题，必须先追问澄清，直到收集到充足信息再进入分析。不要猜测。信息是否充足的标准：你能明确回答"谁在什么场景下解决什么问题"，且能用数字描述代价和范围。一轮追问不够就继续问，不设轮次上限。
苏格拉底提问法是一种通过系统性追问来检验假设、揭示矛盾、深化理解的对话方法。其核心不是给出答案，而是通过层层追问引导对方发现真理。
目标：将模糊问题转化为明确问题。 不要直接接受用户的问题表述。
逐一追问以下维度（根据场景选择关键维度切入，不必机械地全部问完）：
输出要求：
## 问题重定义
- 原始问题：[用户提出的问题]
- 实际问题：[追问后发现的真正问题]
- 关键矛盾：[核心权衡]
第一性原理是一种从最基本的、不可再简化的真理出发进行推理的方法。它要求将问题分解到最基础的元素，然后从那里重新构建解决方案，而非依赖类比或现有做法。
目标：从底层本质推导方案，不被现有产品形态或行业惯例束缚。
输出要求：
## 本质拆解
- 基本元素：[不可再简化的基础组件]
- 类比陷阱：[哪些做法来自模仿而非本质]
- 本质推导：[从底层出发应该怎么做]
奥卡姆剃刀是一个哲学原则：如无必要，勿增实体。在多个能解释同一现象的方案中，选择假设最少、结构最简单的那个。
目标：找到最小可行方案，剪掉一切不必要的复杂度。
对当前方案中的每一项预设，逐层追问：
输出要求：
## 剪枝分析
- 可复用（不自建）：[列表]
- 可合并/精简：[列表]
- 可推迟：[列表]
- 可删除：[列表]
### MVP 边界
- 必须有：[不可削减的核心]
- 绝对不要：[明确排除项]
结论必须回答两个问题：这个问题的本质是什么？应该怎么办？
## 综合结论
### 问题本质
[一句话说清这个问题的底层本质 — 不是描述现象，是指出根因]
### 核心洞察
| 思维框架 | 核心洞察 |
|---------|---------|
| 苏格拉底提问 | [一句话] |
| 第一性原理 | [一句话] |
| 奥卡姆剃刀 | [一句话] |
### 建议方案
- **定位**：[差异化价值 — 做什么、不做什么]
- **第一步**：[今天/本周不依赖任何前提就能做的事，最小验证动作]
- **示例产物**：[给出一个具体的产出物形态 — 可以是伪代码片段、决策树结构、数据表设计、流程图，让建议可见可感]
- **警惕**：[最大的风险或陷阱]
一次分析完成后，可能出现两种需要迭代的情况：
情况一：用户补充或修正信息。 分析过程中，用户可能发现自己原来的描述不准确，或者提供了新的约束。此时从头重新走三阶段，不基于旧结论修修补补——问题被重新定义后，本质拆解和剪枝方案都可能完全不同。
情况二：分析太抽象，用户要求深入。 从综合结论和建议方案出发，选择最关键的一个方向再走一轮缩小范围的分析。
迭代终止信号：用户表示满意，或结论收敛到可执行的具体动作，或新信息不再改变核心判断。
适用于多种分析场景，根据复杂度调整分析深度：
小决策精简（每阶段 2-3 句），重大决策充分展开。