# 构思框架参考

请选择性地使用这些框架。挑选最适合当前想法的视角，不要机械地把每个框架都跑一遍。目标是打开思路，而不是完成一份检查清单。

## SCAMPER

这是一种通过七种操作来改造现有想法的结构化方法：

- **Substitute（替换）**：可以替换掉什么组件、材料或流程？如果换掉核心技术、目标受众或商业模式，会怎样？
- **Combine（组合）**：如果把它和另一个产品、服务或想法合并，会怎样？哪两件平时不会放在一起的事，合在一起会变成新东西？
- **Adapt（借鉴）**：还有什么东西和它类似？可以借用其他行业、其他领域，甚至其他时代的什么做法？自然界里有没有平行机制？
- **Modify（放大 / 缩小）**：如果放大 10 倍会怎样？缩小 10 倍会怎样？如果把某个特性夸张化，或者删到最少，会怎样？
- **Put to other uses（挪作他用）**：还有谁会用它？还能解决什么别的问题？如果把它放到完全不同的场景里，会怎样？
- **Eliminate（删除）**：如果把某个功能完全删掉，会怎样？如果做到零配置，会是什么样？如果砍掉一半步骤，会怎样？
- **Reverse/Rearrange（反转 / 重排）**：如果按相反顺序做会怎样？如果由用户来做原本系统做的事（或者反过来），会怎样？如果把价值链倒过来，会怎样？

**最适合：** 改进或重想现有产品 / 功能。对绿地创意的帮助相对有限。

## How Might We（HMW）

把问题重新表述为机会，用 “How Might We...” 的方式打开思路：

- 从一个观察或痛点出发
- 把它改写成 “How might we [目标结果] for [具体用户] without [关键约束]？”
- 用不同方式写出同一个问题的多个 HMW 表达 - 不同表述会激活不同解法

**好的 HMW 具备这些特征：**
- 足够聚焦，可以执行（例如 “...帮助新用户在前 5 分钟找到相关内容”）
- 又足够开放，允许创造性解法（而不是 “...加一个推荐侧边栏”）
- 带有张力或约束，能逼出创意

**坏的 HMW 具备这些特征：**
- 太宽泛：“How might we make users happy?”
- 太狭窄：“How might we add a button to the settings page?”
- 预设了解法：“How might we build a chatbot for support?”

**最适合：** 打破卡住的思路。当人已经被某个解法绑住时，把他拉回问题本身。

## 第一性原理思维

把想法拆到最基本的事实，再从头重建：

1. **我们确定什么是真的？**（不是想当然，不是惯例，而是确实如此）
2. **我们在假设什么？** 把每个假设都列出来，哪怕看起来显而易见
3. **哪些假设可以挑战？** 对每个假设问一句：“这是物理规律，还是只是一直这么做？”
4. **根据事实重建。** 如果你只拥有这些最基础的真相，你会怎么做？

**最适合：** 跳出渐进式思维。当所有方案都只是现状的小修小补时。

## Jobs to Be Done（JTBD）

关注用户想完成什么，而不是他们口头说想要什么：

- **功能性任务**：他们想完成什么具体任务？
- **情绪性任务**：他们想获得什么感受？
- **社会性任务**：他们希望别人如何看待他们？

格式可以写成：“当我 [场景] 时，我想要 [动机]，这样我就能 [预期结果]。”

**关键洞见：** 人们买的不是产品，而是拿产品来完成任务。真正的竞争者未必在同一个品类里。（Netflix 竞争的不是其他流媒体，而是睡觉。）

**最适合：** 理解真实问题。当你不确定自己是不是在解决正确的问题时。

## 基于约束的构思

故意加上约束，逼出更有创意的解法：

- **时间约束**：“如果你只有 1 天时间做这个，会怎样？”
- **功能约束**：“如果它只能有一个功能，会怎样？”
- **技术约束**：“如果不能用 [显而易见的技术]，会怎样？”
- **成本约束**：“如果它必须永久免费，会怎样？”
- **受众约束**：“如果你的用户从来没用过电脑，会怎样？”
- **规模约束**：“如果它要支持 10 亿用户呢？如果只支持 10 个呢？”

**最适合：** 切断复杂性。当想法变得太大、太模糊时。

## 预演失败

假设这个想法已经失败，从结果倒推：

1. 现在往后推 12 个月，项目已经上线但失败了。哪里出了问题？
2. 列出所有可能的失败原因 - 技术、市场、团队、时机
3. 对每个失败模式问：这是可以预防的，还是说明这个想法本身需要改？
4. 哪些失败模式你愿意接受？哪些会直接杀死这个项目？

**最适合：** 第 2 阶段评估。压力测试那些看起来不错、却还没被认真审视过的想法。

## 类比启发

看看别的领域是怎么解决类似问题的：

- 哪个行业已经解决过这个问题的一个变体？
- 如果是 [某个公司 / 产品] 来做，它会是什么样？
- 自然系统里有没有类似机制？
- 历史上有没有相似先例？

关键是找 **结构性** 相似，而不是表面相似。“Uber for X” 只是表层类比；“一个解决陌生人之间信任问题的双边市场” 才是结构性类比。

**最适合：** 第 1 阶段展开。生成真正不同、而不是显而易见的变体。