# 构思精炼与评估标准

在第 2 阶段（评估与收敛）中，用这份评分标准来压力测试各个方向。并不是每个维度都适用于每个想法 - 具体用哪些维度，要根据上下文判断。

## 核心评估维度

### 1. 用户价值

这是最重要的维度。如果价值不清楚，其他都没意义。

**止痛药 vs. 维生素：**
- **止痛药：** 解决的是急迫、频繁的问题。用户会主动来找它，并愿意从当前方案切换。信号包括：人们带着情绪描述这个问题、他们已经在自己找补丁、他们愿意为解决方案付费。
- **维生素：** 可有可无，只是让事情稍微好一点。用户不会特地去找它。信号包括：人们会礼貌点头说“挺不错”，但不会改变行为。

**要问的问题：**
- 你能否说出现在就有这个问题的 3 个具体人？
- 他们现在怎么做？（真实竞争对手永远是当前的替代做法。）
- 他们会从当前做法切换吗？什么条件下会切换？
- 他们多久会遇到一次这个问题？（每天遇到的问题 > 每月遇到的问题）
- 这是一个用户在主动“拉”的问题，还是你觉得他们应该想要的问题？

**红旗：**
- “谁都能用” - 如果你说不出具体用户，价值就不清楚
- “像 X 但更好” - 细微改进通常不足以驱动采用
- 问题是真的，但很少见 - 痛感强但频率低，通常不值得做成产品

### 2. 可行性

这个东西真的能做出来吗？不只是技术上能不能，还是现实中能不能。

**技术可行性：**
- 核心技术是否已经存在，而且可靠？
- 最难的技术问题是什么？是业界已知难题，还是新问题？
- 有没有依赖你控制不了的第三方、API 或数据源？
- 最小技术栈是什么？（如果答案是“一大堆”，那就是信号。）

**资源可行性：**
- 做出 MVP 至少要多少人、多少精力？
- 是否需要你没有的专业能力？
- 有没有监管、法律或合规要求？

**价值出现速度：**
- 你多久能把东西放到用户面前？
- 有没有一种能在几天 / 几周内交付价值的版本，而不是几个月？
- 关键路径是什么？必须先发生什么？

**红旗：**
- “我们只需要先解决 [非常难的研究问题]”
- 多个依赖都必须同时工作
- MVP 仍然需要几个月 - 这很可能不够“最小”

### 3. 差异化

这个方案到底哪里真正不同？不是更好，而是 **不同**。

**要问的问题：**
- 如果用户把它讲给朋友听，朋友会怎么描述？这个描述有吸引力吗？
- 它有什么独一无二的能力？（如果你说不出来，这是问题。）
- 这种差异是否持久？竞争对手能在一周内抄走吗？
- 这种差异是用户在意的，还是只有构建者觉得有趣？

**差异化类型（从强到弱）：**
1. **新能力：** 做到以前做不到的事
2. **10 倍提升：** 在关键维度上好到足以改变行为
3. **新受众：** 把已有能力带给以前被排除的人群
4. **新场景：** 在现有方案失效的场景下可用
5. **更好的 UX：** 能力相同，但体验大幅更简单
6. **更便宜：** 同样的东西，成本更低（最弱，最容易被复制）

**红旗：**
- 差异化完全建立在技术上，而不是用户体验上
- 只是“更快 / 更便宜 / 更好看”，却没有结构性原因
- 真正差异化的功能，不是用户最在意的功能

## 假设审计

对每个方向，都要把假设分成三类：

### 必须为真（致命项）
如果这些假设错了，这个想法就直接死掉。它们必须在动手前验证。

例子：“用户会愿意把数据给我们” - 如果不愿意，整个产品就无法运作。

### 应该为真（重要项）
这些假设会显著影响成败，但不至于一错全死。如果它们不成立，你可以调整做法。

例子：“用户更喜欢自助，而不是和真人沟通” - 如果不成立，你可能要换获客方式，但核心产品仍可能成立。

### 可能为真（锦上添花）
关于次要功能或优化的假设。在核心还没验证前，不要优先去验证它们。

例子：“用户会想把结果分享给队友” - 这是增长功能，不是核心价值主张。

## 决策框架

在不同方向之间做选择时，用这个矩阵排序：

|                    | 高可行性 | 低可行性 |
|--------------------|---------|---------|
| **高价值**         | 先做这个 | 值得冒险 |
| **低价值**         | 只有很简单时才做 | 不要做 |

然后用差异化作为同一象限里不同选项的决胜因素。

## MVP 取舍原则

定义所选方向的 MVP 范围时，遵循这些原则：

1. **只做一件事，而且做好。** MVP 应该把一个用户任务做到位，不是把三件事都做一半。
2. **先验证最危险的假设。** MVP 的主要目的，是测试最可能出错的那个假设。
3. **按时间盒，而不是按功能列表。** “我们在 [时间范围] 内能做出什么并验证？” 比 “我们需要哪些功能？” 更好。
4. **“Not Doing” 列表是强制项。** 明确写出砍掉了什么，以及为什么。这样才能防止范围膨胀，逼出真正的优先级。
5. **如果第一版不让你觉得有点寒酸，那你做晚了。** 第一版应该让开发者自己都觉得不完整。如果没有这种感觉，说明你做过头了。