02-mindset_2.2-inversion-thinking_2.2.2-pre-mortem-failure-patterns.png

2.2.2 Pre-mortem失败模式分析：Vibe Coding项目避坑指南 ​

根据大量实践经验，Vibe Coding项目最常见的失败原因可以分为几大类。了解这些"前人踩过的坑"，可以帮助你在做Pre-mortem时更全面地思考。

需求层面的失败模式 ​

模式一：需求不清晰 ​

典型表现：

失败机制： AI无法读心。"好用"对你意味着什么？"提高效率"具体指哪个环节？模糊的输入只会得到模糊的输出。AI会按照它的理解去实现，而它的理解很可能和你想的完全不同。

实际案例： 用户让AI"做一个笔记App"。AI做出来的是一个功能完整的Markdown编辑器，支持语法高亮、导出PDF、多级文件夹……但用户只是想要一个能快速记录灵感的地方，一句话就够了。

Pre-mortem警示信号：

预防措施：

  1. 具体化描述：要做什么，在什么情况下，为谁服务
  2. 使用JTBD框架明确"雇佣"任务
  3. 设定可衡量的验收标准

模式二：功能复杂度爆炸 ​

典型表现：

失败机制： 复杂度的增长是指数级的，不是线性的。

AI处理复杂系统时更容易出错，也更难发现和定位问题。

实际案例： 某用户一次性要求AI实现"用户注册、登录、个人中心、任务管理、团队协作、权限控制、数据统计、消息通知"。结果代码越改越乱，三天后整个项目变成了一团无法维护的意大利面条。

Pre-mortem警示信号：

预防措施：

  1. 严格限制核心功能（3-5个）
  2. 使用MVP思维，先验证核心价值
  3. 建立明确的"不做清单"

模式三：功能与任务脱节 ​

典型表现：

失败机制： 没有从用户实际需求出发，而是在堆砌功能。

实际案例： 某用户想要做"项目管理工具"，参考Jira等工具。但他没有分析自己团队的实际工作流程，结果做出来的工具功能虽然全面，但不符合团队习惯，最后还是回到了用Excel+微信群的方式。

Pre-mortem警示信号：

预防措施：

  1. 深入分析用户真实任务
  2. 先了解现有替代方案的优缺点
  3. 从解决具体问题出发，而非复制功能

技术层面的失败模式 ​

模式一：技术选型不当 ​

典型表现：

失败机制： 追求"新"和"酷"而不是"合适"。新技术可能：

实际案例： 某用户坚持使用最新的前端框架，结果发现：

Pre-mortem警示信号：

预防措施：

  1. 选择成熟、有良好文档的技术
  2. 优先考虑AI工具支持度
  3. 评估自己的学习时间和维护成本

模式二：过度依赖AI ​

典型表现：

失败机制： AI不是全知的。它会：

实际案例： 某用户完全按照AI的建议设计数据库结构，但没有进行合理性验证。结果在生产环境中发现性能问题，数据量一增长就卡死了。

Pre-mortem警示信号：

预防措施：

  1. 保持"信任但验证"的态度
  2. 学习基础的技术判断能力
  3. 建立自己的决策框架，AI只是辅助工具

模式三：缺乏基础技术判断 ​

典型表现：

失败机制： 缺乏基础的技术判断能力：

实际案例： 某用户的网站运行几个月后被黑客攻击。原因是AI生成的代码中存在SQL注入漏洞，但用户没有技术基础识别出来。

Pre-mortem警示信号：

预防措施：

  1. 学习基础的安全和性能知识
  2. 建立测试验证流程
  3. 遇到不确定的情况时寻求专业意见

场景层面的失败模式 ​

模式一：用户群体判断错误 ​

典型表现：

失败机制： 过于宽泛的目标用户定义，导致：

实际案例： 某用户想做"大学生学习工具"，但没有细分。结果发现：

最终产品因为"谁都不太满意"而失败。

Pre-mortem警示信号：

预防措施：

  1. 细分目标用户群体
  2. 建立具体的用户画像
  3. 先服务一个小群体，验证需求后再扩展

模式二：场景假设错误 ​

典型表现：

失败机制： 没有基于真实观察做出场景假设。

实际案例： 某用户认为"白领会每天使用运动记录App"。但实际调研发现：

Pre-mortem警示信号：

预防措施：

  1. 进行真实的用户调研
  2. 观察目标用户的实际行为
  3. 基于数据而非想象做假设

模式三：替代方案评估不足 ​

典型表现：

失败机制： 低估现有方案的价值和用户习惯。

实际案例： 某用户认为"Excel表格管理客户信息太麻烦"，想做专门的CRM工具。但他没有考虑到：

结果CRM工具开发完成，但用户还是习惯用Excel。

Pre-mortem警示信号：

预防措施：

  1. 深入分析现有方案的优缺点
  2. 理解用户使用现有方案的原因
  3. 评估迁移成本和收益

习惯层面的失败模式 ​

模式一：高估持续使用意愿 ​

典型表现：

失败机制： 对新工具的持续使用意愿过于乐观。

实际案例： 某用户开发了一个"完美的时间管理App"，功能强大，界面精美。但一个月后发现：

Pre-mortem警示信号：

预防措施：

  1. 考虑市场竞争情况
  2. 评估相比现有方案的优势
  3. 做小规模测试验证用户意愿

模式二：低估迁移成本 ​

典型表现：

失败机制： 低估从现有方案迁移到新方案的成本。

实际案例： 某用户认为"从Notion迁移到新笔记工具很简单"。但实际过程中发现：

Pre-mortem警示信号：

预防措施：

  1. 详细分析迁移过程
  2. 提供迁移工具和指南
  3. 考虑渐进式迁移策略

模式三：忽视学习成本 ​

典型表现：

失败机制： 低估用户学习新工具的认知成本。

实际案例： 某用户设计的界面在开发者看来"很简单直观"。但目标用户反馈：

最终因为"太难用"而被放弃。

Pre-mortem警示信号：

预防措施：

  1. 进行用户测试，观察实际使用过程
  2. 提供详细的使用指南和教程
  3. 设计渐进式的学习路径

失败模式检查清单 ​

启动前检查 ​

在开始项目前，对照以下问题进行检查：

需求层面：

技术层面：

场景层面：

习惯层面：

进行中检查 ​

在项目进行过程中，定期检查：

失败模式学习指南 ​

从失败中学习 ​

  1. 记录失败案例：详细记录每个失败项目的情况
  2. 分析根本原因：找出表面问题背后的深层原因
  3. 总结经验教训：提炼出可以应用到未来项目的教训
  4. 建立检查清单：将教训转化为具体的预防措施

建立失败案例库 ​

建议建立一个个人失败案例库，包含：

定期回顾和更新 ​

定期回顾失败案例库：

下一步 ​

掌握了常见的失败模式后，接下来我们将学习：

通过了解这些失败模式，你可以在项目启动前就识别潜在风险，大大提高项目成功率。记住：了解失败是为了更好地成功。