死也要死得明白：vibe 项目的失败复盘实战

本系列之前有三篇内容和「失败」沾边，但注意区别：《side-project-kill-list》解决的是决策——什么时候该杀掉一个项目；《vibe-project-feature-sunset-guide》讲的是单个功能的下线 SOP；《agent-failure-modes-guide》是 Agent 技术故障的图鉴。这篇讲的是杀完之后：项目已经死了，或者你已经决定让它死，接下来怎么做一次真正的失败复盘——把这次死，变成下一场活的养料。

先承认：失败确实很疼，但糊涂着死更疼

关掉一个项目是什么感觉？Dinnr 的创始人 Michal Bohanes 在他的复盘里写过一段话，大意是：他每天在西伦敦一个冰冷的仓库里坐 9 个小时，一周 6 天，暖风机在 14 度的房间里吹出几个 25 度的气泡，工业大冰箱空荡荡的——订单来了，他就骑自行车去附近的超市现买食材。运营了 15 个月，平均每天大约 1 单，客单价 26 英镑，名义毛利率 30%，但因为量太小，每一单都在赔钱。最后他拒绝了一轮已经谈好的小额融资，选择直接拔掉插头。他的原话是："Dinnr simply didn't have legs (never had them to begin with)."——这家公司从来就没有站起来过。

这段描述之所以值得全文引用，是因为它撕掉了一层遮羞布：大多数失败不是「差一点就成功」，而是从一开始就没有机会（there never was an opportunity）。创始人自己在复盘里承认了这一点。这需要勇气，也正是复盘的价值所在——失败本身不是资产，诚实的复盘才是。

先看一组数据，来自 CB Insights 2026 年 3 月 5 日发布的《Why Startups Fail: Top 9 Reasons》。他们分析了自 2023 年以来关停的 431 家 VC 支持的创业公司（其中 385 家有足够公开信息可以归因）：

• 70% 的公司把「资金耗尽」列为死因，但 CB Insights 明确指出，这几乎总是死亡的最终表现，而非根因——就像验尸报告上写「钝器伤」，对你避开车祸毫无帮助。
• 真正的原因排在下面：43% 产品市场契合度（PMF）不足、29% 时机不对、19% 单位经济模型不成立。一家公司经常同时命中多个原因，所以数字加起来超过 100%。
• 这 431 家公司死前一共烧掉了 175 亿美元，中位数融资 1100 万美元，平均 4800 万美元；从最后一轮融资到死亡的中位数时间是 22 个月。Olive（医疗 AI，估值曾达 40 亿美元）和 Convoy（数字货运，融资超 10 亿美元）在 2023 年 10 月的两周之内相继关停——钱多，也救不了方向错。

这组数据的结论对 vibe 开发者尤其扎心：死因几乎永远在上游。钱烧完只是结果，真正杀死项目的是更早的那个决定——选了个没人要的方向、选了个到不了用户的渠道、或者算了一笔永远算不平的账。复盘，就是回到上游，把那个决定找出来。

第一章 · 复盘五问：到底死在哪

复盘最大的敌人不是情绪，是自我美化。人天然会把失败归因于外部（市场不好、运气不好、投资人不好），把成功归因于自己。复盘五问的作用，就是逼你把每个维度都摊开，逐个诚实回答。下面这张框架图建议保存下来，关掉项目的那个晚上，对着它写：

第一问 · 需求：用户真的疼吗？

问的不是「这个想法好不好」，而是「有没有人为这个问题疼到愿意付钱」。检验方法来自 Dinnr 创始人的血泪教训，也是《The Mom Test》这本书的核心：永远不要向用户推销你的产品再问反馈，而要问他们过去的行为——他们上次为这个问题采取行动是什么时候？如果答案是「从来没有」，那这就不是一个等待被解决的问题。

一个危险信号：如果用户听完你的介绍说「这个想法真好」，但自己从不用——Dinnr 的创始人把这叫「Such-A-Good-Idea Delusion」（好想法幻觉）：项目倒闭后，很多人真诚地惋惜「这么好的想法怎么就没了」，他忍不住反问「那你为什么不用呢」，对方的回答是「太忙了没时间做饭」。点赞不等于需求，只有掏钱（或付出时间/数据等真实成本）的行为才算数。

第二问 · 获客：流量到底从哪来？

很多 vibe 项目死在这一问：产品做出来了，然后呢？靠什么让人知道？复盘时列出你尝试过的所有获客渠道和每个渠道的真实转化数据。如果答案是「主要靠发个帖子碰运气」，那死因不是产品不好，是没有可重复的获客引擎。诚实一点：你有没有为获客投入过和写代码同等量级的精力？大多数独立开发者的答案是没有。

第三问 · 变现：这笔账算得过来吗？

把单位经济模型摊开算：获客成本（CAC）是多少，客单价和复购能覆盖吗？RethinkDB 的创始人 Slava Akhmechet 在复盘里承认，他们从一开始就选错了市场——用户把 RethinkDB 当成开源工具，几乎没人愿意为它付钱；而如果设置实质性的价格门槛，用户转身就能找到一堆免费替代品。市场选错了，后面的一切优化都是错的。你的项目也一样：如果从第一天起就没有人愿意为这类东西付费，那不是定价策略问题，是市场本身不付费的问题。

第四问 · 执行：是不是把好牌打烂了？

这是最难诚实回答的一问，因为矛头指向自己。Kiko 的复盘是这一问的教科书：团队同时想做好几个想法，注意力被分散；CEO 自己承认「有时候太慢了，在不重要的事情上浪费时间，忽视了真正关键的事」；还招错了一个人——那个人什么任务都没完成，消失了几个月。以及一个很多独立开发者会中枪的：从一开始就没有让投资人（或任何外部 accountability）介入，没人从外部给你泼冷水、给建议。

执行维度的复盘要具体到人、事、时间：哪个决定是错的？哪段代码/功能是浪费？哪次拖延致命？写下来，不要用「执行力不够」这种正确的废话糊弄过去。

第五问 · 时机：是来得太早，还是太晚？

CB Insights 的数据里，29% 的失败归因于时机。时机问题最难复盘，因为它最像「运气」。但可以问一个更具体的问题：如果晚一年/早一年做，结果会不一样吗？如果答案是「不会，问题本身就不成立」，那就不是时机问题，是需求问题，别拿时机当遮羞布。如果答案是「会」，那就把你对时机的判断写下来——这是你下一场最重要的情报。

五问问完，你应该能指着其中一到两个维度说：「主要死在这里。」如果五个都答不上来，说明复盘还不够诚实，重来。

第二章 · 失败资产回收清单：把尸体变成弹药

项目死了，不等于投入全打了水漂。Kiko 最传奇的一笔操作是：团队把 Kiko 的软件放到 eBay 上拍卖，最后以 258,100 美元成交。一个失败项目的代码，卖出了 25 万美元。这就是「失败资产回收」——死掉的项目里，藏着下一场的启动资金。

下面这张清单，建议逐项打勾：

资产类别	你手里可能有什么	回收方式
代码与组件	认证模块、支付集成、后台管理面板、爬虫/数据管道、UI 组件库	抽成可复用的私有模板库；开源出去换 star 和声誉；甚至像 Kiko 一样直接卖掉
域名	项目域名（尤其是有一定权重或好记的）	留给下一个项目用；或挂到域名市场出售；301 跳转到你的个人主页，把残余流量接住
用户列表与社群	注册用户邮箱、Discord/微信群成员、Twitter 关注者	这是最值钱的资产。关停通知邮件里，诚实说明原因 + 预告下一个项目，把信任迁移过去
内容与信任	你写的教程、复盘文章、技术分享、build in public 的记录	一篇诚实的失败复盘，带来的信任红利经常超过项目本身（见第三章）
数据与洞察	用户访谈记录、转化漏斗数据、定价测试结果、踩过的坑	整理成内部备忘录；下一场的选题会直接用上——你比所有人都更懂这个细分市场为什么不行
关系	合作过的开发者、给你反馈的用户、聊过的投资人	关停时逐一发一封真诚的告别信，很多人会在你下一个项目时回来

注意一个心态陷阱：很多人关掉项目后，第一反应是删库、注销域名、假装这事没发生过，觉得「失败的痕迹越少越好」。恰恰相反——删掉的是证据，留下的是资产。RethinkDB 关停几个月后，技术被 Linux 基金会（CNCF）接管，继续作为社区开源项目活着；它的创始人后来去了 Stripe，复盘文章成了开发者社区的经典。这就是资产回收的终极形态：项目死了，影响力没死。

第三章 · 公开复盘写作指南：怎么写不翻车

build in public 的信任红利是真实存在的。一篇诚实的失败复盘，经常比项目本身获得更多的阅读、更多的尊重、更多的下一次机会。但公开复盘也是高风险动作：写得好是坦荡，写不好是甩锅大会。下面是「说什么」和「不说什么」的边界：

说什么：四个必须有的部分

• 时间线和数字。什么时候开始、什么时候决定关、烧了多少钱、用户数/收入曲线的真实数字。数字是复盘可信度的地基。Dinnr 的复盘里连「第一天 3 单、第一周 12 单」这种难堪的数字都写了，这正是它被转发多年的原因。
• 你认为是真正死因的那一到两个维度。用第一章的五问框架组织，不要罗列十个原因——罗列十个等于没说。
• 你当时是怎么想的。决策时的信息、假设和情绪。读者要看的不是上帝视角的正确复盘，而是「一个聪明人当时为什么会做出那个决定」。
• 如果重来，你会怎么做。这是全文最有价值的一段，也是对下一场的直接交代。

不说什么：四条红线

• 不甩锅到具体的人。可以谈「招错了人」（Kiko 的创始人就写了），但不要点名、不要写细节到让人社死的程度。复盘是面向未来的，不是清算大会。
• 不攻击投资人、合作方。即使你觉得他们有问题。公开处刑的短期快感，代价是整个圈子对你的信任折价。
• 不写未经证实的指控。「我怀疑竞争对手刷单」这种话，没有证据就不要写。怀疑一旦公开，就成了你的立场。
• 不美化、不虚构数字。复盘里的数据会被引用、被截图。Dinnr 创始人宁可写「每单都在赔钱」也不粉饰——诚实是唯一的护城河。

一个可直接套用的结构

1. 一句话：项目是什么，什么时候关的。
2. 三到五个关键数字（时间、钱、用户、收入）。
3. 死因：用五问框架，只讲最主要的一到两个。
4. 当时为什么这么决策（信息、假设、情绪都要）。
5. 如果重来，我会怎么做（3 条以内，要具体）。
6. 感谢名单：用户、合作者、投资人——真诚地写，这是信任迁移的关键一步。

最后一点：复盘发出前，给联合创始人/核心成员看一遍。不是征求许可，是避免事实出入。公开复盘里最翻车的，往往不是观点，而是被当事人指出的事实错误。

第四章 · 三个真实失败案例拆解

下面三个案例都来自 Failory Startup Cemetery（收录 120+ 家关停公司的死因分析）及创始人自己的一手复盘。案例中的事实和数字均引用原文，不做演绎。每个案例后附一段点评：把它放进第一章的五问框架里看。

案例一 · Dinnr：需求维度的经典反面教材

背景：Dinnr 是伦敦的一个同城食材配送平台：用户在网站上选食谱，平台把按分量配好的食材和打印好的菜谱当日送到家，家里只需要备好油盐胡椒。2012 年 9 月上线，2014 年 1 月 12 日创始人决定关停，实际运营约 15 个月。

原文关键事实（来自创始人 Michal Bohanes 2014 年 8 月 17 日发表于 Medium 的复盘《Seven lessons I learned from the failure of my first startup, Dinnr》）：

• 上线前的市场调研看起来一片大好：250 个目标用户里 70% 说会买，内测组点赞，一对一访谈也都说「有搞头」。
• 上线第一天：3 单；第一周：12 单。创始人形容「像从梦幻之地被一拳打回现实」。
• 15 个月后：平均每天约 1 单，客单价 26 英镑，名义毛利率 30%，但因为量太小，每一单都在赔钱。
• 创始人搭进去几万英镑个人积蓄。关停时他已经谈好一轮小额融资，但主动拒绝了——「这笔钱只够再撑几个月、再获几个低频用户，不可能给投资人 10 倍回报；拿这笔钱继续，是不道德的。」
• 他的核心结论："we were not solving anyone's problem"（我们没有解决任何人的问题）。调研时犯的错是「把产品推销给用户再问反馈」——用户说「会买」的真实意思是「在极端假设下不排除买一次的可能」，而他当成了「上线我就买」。

点评（对照五问）：这是第一问「需求」的教科书级失败。最值得所有 vibe 开发者抄下来的一句话是他的诊断：不要问用户未来会怎么做（"would you buy this?"），要问他们过去做过什么。他还提出了一个可操作性极强的检验法：访谈时直接要承诺——「好，给我 20 英镑，下周二我给你送一份原型」。他事后复盘，10 个访谈对象里 7 个说喜欢，但真上线后只有 2 个人在几周甚至几个月后成了客户。你的项目也一样：在写下一行代码之前，先找到愿意为原型付 20 英镑（或等值真实成本）的人，找不到，就先别写。

案例二 · RethinkDB：选错市场 + 优化错指标

背景：RethinkDB 是一个为实时 Web 应用设计的开源分布式 NoSQL 数据库，2009 年开始开发，2016 年 10 月公司关停。关停几个月后，技术被 Linux 基金会（CNCF）接管，继续作为社区项目存活。

原文关键事实（来自创始人 Slava Akhmechet 2017 年 1 月 18 日的复盘《RethinkDB - Why we failed》，全文约 2600 词；Failory 墓地亦有收录分析）：

• 创始人的核心自我诊断只有一句话，被科技媒体反复引用："We picked a terrible market and optimized the product for the wrong metrics of goodness."（我们选了一个糟糕的市场，还朝着错误的「好产品」标准去优化。）
• 「选错市场」：用户从一开始就把 RethinkDB 当成开源工具，几乎没人愿意为它付钱；而一旦设置实质性价格门槛，用户转身就能找到一堆免费替代品。
• 「优化错指标」：团队追求的「好」是——发布一个完美无瑕的产品、设计简洁的接口、保证数据一致性。但用户真正想要的是：尽快可用（他们等了将近 3 年）、跑得快、以及一个经过验证的存 JSON 文档、做报表的方式。讽刺的是，竞争对手 MongoDB 早期产品 bug 不少，却大受欢迎——因为它先满足了用户真正要的东西。
• 他还留下一句给所有开发者工具创业者的话："If you do set out to build a developer tools company, tread carefully. The market is filled with good alternatives. User expectations are high and prices are low."

点评（对照五问）：这是第三问「变现」和第四问「执行」的复合失败，但根在第三问。vibe 开发者最容易踩的坑和 RethinkDB 一模一样：把「用户觉得酷」当成「用户愿意付钱」。GitHub star、Hacker News 首页、Twitter 转发——这些都是「觉得酷」的指标，不是付费意愿。RethinkDB 的教训翻译成 vibe 语境就是：在你为「完美架构」打磨第三个月的时候，先回答一个问题——有没有 10 个人愿意为现在这个半成品按月付费？如果没有，你优化的方向可能和 RethinkDB 一样，是错的。

案例三 · Kiko：把好牌打烂的执行样本

背景：Kiko 是一个 Ajax 时代的在线日历应用，带 API 集成，界面友好，可以跨电脑访问、分享日历。运营约 3 年后关停。最出名的是它的结局：团队把软件放到 eBay 上拍卖，以 258,100 美元成交——可能是创业史上最体面的「卖尸」案例。

原文关键事实（来自 Failory 墓地对 Kiko 的分析，综合创始人复盘）：

• 死因一：团队同时想做好几个想法和计划，注意力从主业上被分散，导致延误。
• 死因二：CEO 自己承认，有时候太慢了，在不重要的事情上浪费时间，忽视了真正关键的事。
• 死因三：招错了一个人——那个人什么任务都没完成，消失了几个月，直接拖累了团队产出。
• 死因四：从一开始就没有让投资人介入、寻求他们的指导。Failory 把 Kiko 归类为「Bad Management」（管理失败）。

点评（对照五问）：这是第四问「执行」的纯粹样本，而且每一条都精准命中独立开发者的常见死法。「同时做好几个想法」——vibe 开发者同时开三个 side project 的样子；「在不重要的事情上浪费时间」——为落地页调了两周配色，核心功能还没跑通；「没有外部 accountability」——一个人开发，最大的风险就是没人对你说「这方向是错的」。Kiko 的案例还有一层积极意义：它证明了第二章的资产回收不是鸡汤——连失败项目的代码都能卖 25 万美元，你的域名、用户列表、复盘文章，只会更值钱。别删库，挂牌吧。

最后：复盘是写给下一场的

回到开头那句话：失败本身不是资产，诚实的复盘才是。CB Insights 的数据告诉我们，43% 的死亡源于 PMF 不足——翻译一下，就是近一半的项目「从一开始就没有机会」。Dinnr 的创始人用了 18 个月零 12 天、几万英镑，才换来这句认知。你的复盘，就是用几个小时的诚实，买下别人用一年换来的教训。

关掉项目的那个晚上，做三件事：第一，对着五问框架写一页纸的复盘，只写给自己看，越难听越好；第二，对着资产清单打勾，能回收的全部回收；第三，决定要不要公开写——如果写，用第三章的结构，发出前给相关人看一遍。

然后，带着这页纸去开下一场。死，也要死得明白；明白了，就不算白死。