Reasoning Frameworks

---
name: "reasoning-frameworks"
description: "结构化思维与推理框架集。涵盖第一性原理、MECE、逆向思维、费曼技巧、思维导图、决策矩阵、SWOT分析、5Whys根因分析。帮助Agent更系统化地分析问题和做出决策。"
priority: 0.5
imported-from: "hermes"
source-path: "hermes/skills/software-development/reasoning-frameworks/SKILL.md"
---
# 推理框架 · Reasoning Frameworks

## 核心理念
结构化思维 = 把模糊的问题变成可执行的步骤。
好的框架让复杂问题变简单，让简单问题不被忽略。

## 框架速查表

| 框架 | 适用场景 | 核心步骤 |
|------|---------|---------|
| 第一性原理 | 创新、突破性思考 | 拆解到不可再分 → 重新构建 |
| MECE | 分类、问题拆解 | 相互独立 → 完全穷尽 |
| 逆向思维 | 风险评估、目标设定 | 从目标倒推 → 识别关键路径 |
| 费曼技巧 | 理解复杂概念 | 解释给小白 → 找出盲区 → 简化 |
| 5 Whys | 根因分析 | 连续问5个为什么 |
| 决策矩阵 | 多方案选型 | 列选项 → 列维度 → 打分 |
| SWOT | 战略分析 | 优势/劣势/机会/威胁 |
| 金字塔原理 | 表达、写作 | 结论先行 → 分组归纳 → 逻辑递进 |
| 第一性+类比混合 | 技术选型 | 拆解底层原理 → 类比已知方案 |
| 预 Mortem | 项目风险 | 假设已失败 → 回溯原因 |

## 1. 第一性原理 (First Principles)

### 适用场景
```
- 技术选型（为什么用这个框架？）
- 突破性设计（有没有更好的方式？）
- 分析复杂问题（真正的问题是什么？）
```

### 步骤
```
Step 1: 识别当前假设
  "我们需要用微服务" → 为什么？
  
Step 2: 拆解到不可再分的基本事实
  - 系统需要处理100 QPS
  - 团队3个人
  - 部署在单台服务器
  
Step 3: 从基本事实重新构建
  - 100 QPS 单体完全够用
  - 3个人维护微服务太重
  - 结论：单体架构更合适
```

### 模板
```
## 第一性原理分析

### 当前假设
[当前的做法或信念]

### 拆解到基本事实
1. [不可再分的事实]
2. [不可再分的事实]
3. [不可再分的事实]

### 重新构建
[从基本事实推导出的新方案]

### 结论
[选择]
```

## 2. MECE (Mutually Exclusive, Collectively Exhaustive)

### 适用场景
```
- 问题拆解（还有遗漏吗？）
- 功能规划（覆盖全了吗？）
- 根因分类（归因完整吗？）
```

### 步骤
```
Step 1: 明确分析对象
  用户增长放缓的原因

Step 2: 找到分类维度（确保MECE）
  维度1: 按来源分 → 新用户 / 老用户
  维度2: 按环节分 → 曝光 / 点击 / 注册 / 付费
  
Step 3: 验证
  相互独立？→ 新用户和老用户不重叠
  完全穷尽？→ 所有用户要么新要么老
```

### 常用MECE分类框架
```
- 时间维度：过去 / 现在 / 未来
- 空间维度：内部 / 外部
- 流程维度：输入 / 处理 / 输出
- 层次维度：战略 / 战术 / 执行
- 3C：公司 / 客户 / 竞争对手
- 4P：产品 / 价格 / 渠道 / 推广
```

## 3. 逆向思维 (Inversion)

### 适用场景
```
- 风险评估（什么会导致失败？）
- 目标设定（如何避免最坏情况？）
- 方案评审（这个方案可能在什么情况下失效？）
```

### 步骤
```
Step 1: 明确目标
  目标：系统99.9%可用性

Step 2: 问"如何确保失败？"
  - 不做备份
  - 单点部署
  - 没有监控告警
  - 没有容错机制

Step 3: 反转成行动项
  ✅ 做跨区域备份
  ✅ 多节点部署
  ✅ 配置监控告警
  ✅ 实现熔断降级
```

## 4. 五问法 (5 Whys)

### 适用场景
```
- Bug根因分析
- 性能问题溯源
- 流程改进
```

### 模板
```
## 5 Whys 分析

问题：[现象描述]

Why 1: [第一次回答]
→ 因为[原因]

Why 2: [基于Why1继续问]
→ 因为[原因]

Why 3: [基于Why2继续问]
→ 因为[原因]

Why 4: [基于Why3继续问]
→ 因为[原因]

Why 5: [基于Why4继续问]
→ 根因：[最终根因]

### 修复方案
[基于根因的解决方案]
```

### 示例
```
问题：API响应时间从200ms飙升到5s

Why 1: 为什么变慢？
→ 数据库查询变慢了

Why 2: 为什么数据库查询变慢？
→ 有个新查询没命中索引

Why 3: 为什么没命中索引？
→ 新功能上线时忘了加索引

Why 4: 为什么忘了？
→ 代码审查没有数据库变更检查环节

Why 5: 为什么没有？
→ PR模板没有数据库变更检查项

根因：PR流程缺少数据库变更检查
修复：在PR模板中增加数据库变更checkbox
```

## 5. 决策矩阵

### 适用场景
```
- 技术选型（框架/数据库/工具）
- 方案对比（多个可行方案）
- 资源分配（优先级排序）
```

### 模板
```
## 决策矩阵

### 选项
A: [方案一]
B: [方案二]
C: [方案三]

### 评估维度（权重1-5）
| 维度 | 权重 | A | B | C |
|------|------|---|---|---|
| 性能 | 5 | 4 | 3 | 5 |
| 成本 | 3 | 3 | 5 | 2 |
| 团队熟悉度 | 4 | 5 | 2 | 3 |
| 生态成熟度 | 2 | 4 | 3 | 4 |
| 可维护性 | 4 | 3 | 4 | 3 |

### 加权得分
A: 5*4 + 3*3 + 4*5 + 2*4 + 4*3 = 20+9+20+8+12 = 69
B: 5*3 + 3*5 + 4*2 + 2*3 + 4*4 = 15+15+8+6+16 = 60
C: 5*5 + 3*2 + 4*3 + 2*4 + 4*3 = 25+6+12+8+12 = 63

### 结论
推荐方案A，理由：[...]
```

## 6. 金字塔原理

### 适用场景
```
- 写技术方案文档
- 回复复杂问题
- 做技术汇报
```

### 结构
```
结论（先说结论）
├─ 论点1（支撑结论）
│  ├─ 论据1.1
│  └─ 论据1.2
├─ 论点2（支撑结论）
│  ├─ 论据2.1
│  └─ 论据2.2
└─ 论点3（支撑结论）
   ├─ 论据3.1
   └─ 论据3.2
```

### 原则
```
1. 结论先行：先说结果，再说原因
2. 以上统下：上层是下层的总结
3. 归类分组：相关论据归为一组
4. 逻辑递进：时间/结构/程度顺序
```

## 7. 预 Mortem (Premortem)

### 适用场景
```
- 项目启动前的风险评估
- 重要决策前的安全检查
- 发布前的checklist
```

### 步骤
```
Step 1: 假设项目已经失败
  "假设6个月后这个项目彻底失败了"

Step 2: 列出所有可能的失败原因
  - 技术选型错误
  - 需求理解偏差
  - 资源不足
  - 时间估计过于乐观

Step 3: 对每个原因评估
  | 失败原因 | 概率 | 影响 | 预防措施 |
  |---------|------|------|---------|
  | 技术选型错误 | 中 | 高 | 先做spike验证 |
  | 需求理解偏差 | 高 | 中 | 每周对齐确认 |

Step 4: 制定预防计划
  [针对高概率高影响项的行动方案]
```

## 参考
- `systematic-debugging` skill → 4阶段根因调试
- `memory-management` skill → 经验沉淀
- `writing-plans` skill → 实施计划