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 的核心功能做到位了，而不是凑合？
• [ ] 不做清单是具体的功能名称，而非空泛描述？
• [ ] 用户画像具体到「能发微信」的程度？
• [ ] 痛点带有负面情绪，而非只是「想要」？
• [ ] 「为什么选我」说清楚了和现有方案的差异？

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