---
title: "C. 常见误区诊断清单"
---


![02-mindset_appendix_C-mistakes.png](/images/Basic/02-mindset_appendix_C-mistakes.png)
# C. 常见误区诊断清单

本附录汇总第二章七个思维模型的常见误区。每个误区都配有「症状描述」「问题诊断」「改进建议」，帮助你自检和避坑。


## 如何使用本清单

1. **自检**：对照每个误区的「症状」，看看自己是否踩坑
2. **诊断**：理解为什么这是问题
3. **改进**：按建议调整你的思路


## 一、JTBD 思维的常见误区

### 误区 1.1：只描述功能，不描述任务

**症状**

你的需求描述是这样的：
> 「我想做一个待办清单 App，要有添加任务、删除任务、分类标签、截止日期……」

**问题诊断**

这是「功能清单」，不是「任务描述」。它告诉 AI 你想要什么功能，但没有说明用户要完成什么任务、为什么需要这些功能。

AI 可能会照单全做，但做出来的东西不一定能解决真正的问题。

**改进建议**

用 JTBD 句式重新描述：
> 「当职场新人在早上开始工作时，想要快速记录今天要做的事，以便于不会遗漏重要任务。」

然后再推导功能：既然任务是「快速记录」，那么「添加任务」必须在 3 秒内完成。「分类标签」可能反而会拖慢速度，可以不做。


### 误区 1.2：只看功能任务，忽略情感和社会任务

**症状**

你只考虑用户「要做什么」，没有考虑用户「想要什么感受」和「想被如何看待」。

**问题诊断**

用户选择一个产品，往往不只是因为功能，还因为情感和社会因素。

- 一个待办清单 App，功能任务是「记录任务」
- 情感任务可能是「减少焦虑、感到掌控」
- 社会任务可能是「在同事面前显得靠谱」

如果你只关注功能任务，可能会做出一个「功能正确但没人想用」的产品。

**改进建议**

每次做 JTBD 分析时，都问自己三个问题：

| 层次 | 问题 |
|-----|------|
| 功能任务 | 用户要完成什么具体事情？ |
| 情感任务 | 用户想要什么感受？ |
| 社会任务 | 用户想被别人如何看待？ |


### 误区 1.3：把「我想做」当成「用户需要」

**症状**

你的出发点是「我想做一个 xxx」，而不是「我发现用户需要 xxx」。

**问题诊断**

这是一个常见的心理偏差。我们往往会假设自己的想法就是用户的需求，而不去验证这个假设。

结果是：花了大量时间做出来的东西，只有自己觉得好。

**改进建议**

把「我想做」转换成「用户需要」：

| 原始想法 | 转换后 |
|---------|-------|
| 我想做一个待办清单 | 谁需要待办清单？他们现在怎么解决这个问题？ |
| 我觉得这个功能很酷 | 有没有用户真的需要这个功能？ |

最好的验证方式：找到 3 个目标用户，问问他们现在是怎么做的。


## 二、逆向思维的常见误区

### 误区 2.1：只列风险，不想应对措施

**症状**

你的 Pre-mortem 分析是这样的：
> 「可能失败的原因：功能太多做不完、用户不买账、技术实现不了……」

然后就没了。

**问题诊断**

列出风险只是第一步。如果没有对应的预防措施，这个分析就是空谈。

**改进建议**

每个风险必须配一个预防措施。用这个格式：

```
风险：_______________
预防措施：_______________
```

如果想不出预防措施，说明这个风险需要更认真对待——要么它真的很难避免（那可能不该做），要么你还没想清楚（那需要继续思考）。


### 误区 2.2：过度悲观，被风险吓住

**症状**

你做完 Pre-mortem 分析后，发现有 10 个可能失败的原因，然后决定不做了。

**问题诊断**

逆向思维不是为了让你放弃，而是为了让你「明知有坑还能避开」。

每个项目都有风险，关键是识别哪些是「致命风险」（必须避免），哪些是「可控风险」（可以接受）。

**改进建议**

用「可能性 × 严重性」矩阵评估每个风险：

| | 严重性高 | 严重性低 |
|---|---------|---------|
| **可能性高** | 必须解决 | 注意即可 |
| **可能性低** | 准备预案 | 可以忽略 |

只有「可能性高 + 严重性高」的风险是致命的。如果这类风险无法避免，可能确实不该做。但如果可以预防，那就做好预防措施，然后继续。


### 误区 2.3：Pre-mortem 做一次就完了

**症状**

你在项目开始时做了 Pre-mortem，然后再也没有回顾过。

**问题诊断**

项目进行过程中，会出现新的信息。当初没预料到的风险可能会出现，当初担心的风险可能已经化解。

**改进建议**

在项目关键节点（如 MVP 完成、第一次用户反馈后）重新审视 Pre-mortem 清单：
- 有没有新增的风险？
- 当初的预防措施有效吗？
- 有没有风险已经可以划掉？


## 三、减法思维的常见误区

### 误区 3.1：把 MVP 当成「简陋版」

**症状**

你的 MVP 是「功能残缺、体验粗糙、凑合能用」的版本。

**问题诊断**

MVP 是「最小可验证版本」，不是「最小可运行版本」。

关键区别：
- 错误理解：功能越少越好，能跑就行
- 正确理解：保留足以验证核心假设的功能，这些功能要做好

如果你的 MVP 体验太差，用户可能因为「不好用」而放弃，而不是因为「不需要」而放弃。你就没法判断问题是出在产品还是需求。

**改进建议**

MVP 的原则是：功能要少，但核心功能要做到位。

| 维度 | MVP 应该做的 | MVP 不应该做的 |
|-----|------------|--------------|
| 功能数量 | 只做 P0（3 个以内） | 不做 P1、P2 |
| 功能深度 | P0 功能做到好用 | 不凑合、不敷衍 |
| 视觉设计 | 清晰可用 | 不需要精美 |


### 误区 3.2：砍功能时心里过不去

**症状**

你知道应该做 MVP，但每个功能都舍不得砍：
> 「这个功能很重要啊……那个功能竞品都有……这个功能我都想好怎么做了……」

**问题诊断**

这是正常的心理。人类天生厌恶损失，砍掉已经想过的功能会让你觉得「亏了」。

但如果不砍，你会花更多时间在不重要的功能上，拖延真正的验证。

**改进建议**

用「不做清单」代替「功能清单」。不是「删掉功能」，而是「把功能放到不做清单」。

心理上的区别：
- 「删掉」= 这个功能没了
- 「放到不做清单」= 这个功能我想过了，决定不做，原因是 xxx，将来 xxx 时候再考虑


### 误区 3.3：不做清单太空泛

**症状**

你的不做清单是这样的：
> 「不做复杂的功能」「不做不必要的功能」

**问题诊断**

这种不做清单等于没有。什么是「复杂」？什么是「不必要」？没有清晰的边界，遇到具体问题时还是会纠结。

**改进建议**

不做清单要具体到功能名称，并写明理由：

```
不做 多设备同步，因为 需要后端开发，大大增加复杂度
不做 任务分类标签，因为 不是极简体验的核心
不做 截止日期提醒，因为 先验证「记录」这个核心价值
```


## 四、故事思维的常见误区

### 误区 4.1：用户画像只有人口统计学特征

**症状**

你的用户画像是这样的：
> 「25-35 岁，大城市，大学学历，月收入 1-2 万」

**问题诊断**

这些信息对产品设计几乎没有帮助。知道用户是「25-35 岁」，并不能告诉你他需要什么功能、会在什么场景下使用、有什么顾虑。

**改进建议**

用「三维画像」代替人口统计学：

| 维度 | 应该包含的内容 |
|-----|--------------|
| 表面属性 | 职业、每天处理多少事务、使用什么设备 |
| 行为习惯 | 什么时候用、怎么用、现在用什么替代方案 |
| 深层动机 | 害怕什么、追求什么、想成为什么样的人 |


### 误区 4.2：用户是「一群人」而不是「一个人」

**症状**

你说的用户是「年轻人」「上班族」「学生」这样的群体。

**问题诊断**

群体太抽象，无法指导具体的产品设计。「年轻人」里有学生、有职场新人、有创业者，他们的需求完全不同。

**改进建议**

给你的用户起个名字，把 TA 具体化到「能发微信问问」的程度：

| 抽象 | 具体 |
|-----|------|
| 年轻的上班族 | 小李，25 岁，互联网公司运营，每天处理 10-15 件事务 |
| 经常忘事的人 | 小李，上周因为忘了给客户回邮件被领导批评 |


### 误区 4.3：用户旅程只考虑「正常路径」

**症状**

你的用户旅程是「打开 App → 添加任务 → 完成任务 → 关闭」。

**问题诊断**

这只是理想情况。真实场景中，用户会遇到各种意外：
- 添加任务时被打断怎么办？
- 任务太多看不过来怎么办？
- 几天没用再打开时怎么办？

**改进建议**

在用户旅程中加入「异常路径」和「边界情况」：

```
正常路径：打开 → 添加 → 完成 → 关闭
异常路径 1：打开 → 添加到一半被打断 → 下次打开时能看到草稿吗？
异常路径 2：打开 → 看到 50 个未完成任务 → 会不会焦虑到关掉？
边界情况：3 天没用 → 再打开时显示什么？
```


## 五、灵魂三问的常见误区

### 误区 5.1：用户描述太泛

**症状**

你回答「用户是谁」时，说的是：
> 「想提高效率的人」「有待办需求的人」「年轻人」

**问题诊断**

这种描述等于没有描述。「想提高效率的人」可能是学生、是职场人、是创业者，他们的需求差异巨大。

判断标准：你能给这个用户发微信吗？如果不能，说明不够具体。

**改进建议**

用这个检验标准：我能不能用一句话描述 TA 是谁、TA 在什么场景下遇到什么问题？

```
❌ 想提高效率的人
✅ 小李，25 岁职场新人，经常忘事被领导批评
```


### 误区 5.2：痛点只有「想要」没有「痛」

**症状**

你描述的痛点是：
> 「用户想要一个好用的待办清单」「用户想要更方便地记录任务」

**问题诊断**

「想要 xxx」是需求，不是痛点。痛点应该带有负面情绪：焦虑、烦躁、尴尬、害怕。

如果用户只是「想要」而没有「痛」，他可能不会真的去用你的解决方案——因为现状还过得去。

**改进建议**

检验痛点的三个标准：

| 标准 | 问题 |
|-----|------|
| 有负面情绪 | 用户会因为这个问题感到焦虑/烦躁/尴尬吗？ |
| 正在发生 | 用户这周遇到过这个问题吗？ |
| 愿意付出 | 如果有解决方案，用户会立刻用吗？ |

三个都满足，才是真痛点。


### 误区 5.3：「为什么选我」只说「我更好」

**症状**

你回答「为什么选我」时，说的是：
> 「因为我的产品更好」「因为我的设计更简洁」

**问题诊断**

「更好」不是差异化。用户为什么相信你「更好」？相比谁「更好」？好在哪里？

**改进建议**

用这个句式回答：

> 「用户现在用 [现有方案] 解决这个问题，但 [痛点]。我的方案是 [具体差异]，所以用户应该选我。」

```
❌ 因为我的产品更好
✅ 用户现在用手机备忘录记事，但经常忘记看。我的方案是「打开就是今日待办」，3秒添加任务，所以更适合需要快速记录的职场人。
```


## 六、场景应用的常见误区

### 误区 6.1：生搬硬套产品思维

**症状**

你在做数据分析或自动化脚本时，也在纠结「用户画像」「MVP」「灵魂三问」。

**问题诊断**

思维模型是工具，不是教条。不同场景需要灵活调整：
- 做产品：需要完整的用户画像、MVP 规划
- 做数据分析：核心是「给谁看、回答什么问题」
- 做自动化脚本：核心是「什么任务值得自动化」

**改进建议**

根据场景选择重点：

| 场景 | 重点模型 | 次要模型 |
|-----|---------|---------|
| 产品/工具 | JTBD、减法、灵魂三问 | 全部 |
| 数据分析 | 灵魂三问（给谁看、回答什么） | 逆向（什么会让分析出错） |
| 自动化脚本 | 问题发现、逆向思维 | 减法（先自动化哪一步） |
| 给家人做 | 故事思维 | 减法（极简设计） |


## 七、问题发现的常见误区

### 误区 7.1：烦恼日记只记不分析

**症状**

你记了一周的烦恼日记，然后就放在那里了。

**问题诊断**

记录只是第一步。价值在于分析和筛选。

**改进建议**

第 8 天必须做分析：
1. 按频率和痛苦程度打分
2. 用「问题筛选评分表」评估每个问题
3. 选出分数最高的 1-2 个问题，开始做 JTBD 分析


### 误区 7.2：选了一个「不适合自动化」的问题

**症状**

你选择自动化的任务是：
- 涉及大量主观判断（如「帮我写一份好的报告」）
- 涉及敏感数据（如「自动交易股票」）
- 错了后果很严重（如「自动给客户发合同」）

**问题诊断**

不是所有问题都适合用 Vibe Coding 解决。规则性低、敏感性高、容错性低的任务，应该谨慎处理。

**改进建议**

用「问题筛选评分表」评估，总分低于 15 分的问题，要么不做，要么只做辅助（人工复核）。


## 自检清单总结

完成项目前，用这个清单快速自检：

- [ ] 我用的是「任务描述」而非「功能清单」？
- [ ] 我考虑了功能、情感、社会三层任务？
- [ ] 每个风险都有对应的预防措施？
- [ ] MVP 的核心功能做到位了，而不是凑合？
- [ ] 不做清单是具体的功能名称，而非空泛描述？
- [ ] 用户画像具体到「能发微信」的程度？
- [ ] 痛点带有负面情绪，而非只是「想要」？
- [ ] 「为什么选我」说清楚了和现有方案的差异？

如果有任何一项打不了勾，回到对应章节重新思考。