做副业，为什么更该看失败案例？

8月3日，我那套做了一年多的个人素材系统正式下线。

它不是坏了。前端、后端、任务队列、搜索和草稿生成都能跑。真正致命的一条很简单：已经没人用了。素材入口搬到更轻的工具，写稿也改成定时任务，留着原系统只会多一套服务器和维护账。

这个结果反而让我想明白一件事：做独立产品或副业，成功案例不一定是最值钱的材料。

成功故事很好看。它会告诉你做了哪些功能、用了什么技术、最后有多少用户。

但产品活下来，往往还混着时机、渠道、早期客户和运气。这些条件有的人说不清，有的人根本没意识到。我们能拆下来的，通常只是页面和功能清单。

照着这份清单做，复制出来的可能只是赢家的外形，不是它活下来的条件。

更麻烦的是，成功故事很容易把时间顺序写成因果。先上线了某个功能，后来用户涨了，两件事挨在一起，读者就会自动补成“因为这个功能，所以用户涨了”。中间可能还有一次推荐、一个大客户，或者只是竞争对手刚好退场。

对一个只有晚上和周末能动手的人来说，拿几十个小时去复制一段未经证实的因果，代价不算小。

成功案例告诉你终点长什么样，却经常省掉了它没掉进哪些坑。

失败案例则没那么光滑。用户不来、获客太贵、交付太重、回款太慢，每一条都是可以直接排除的死法。

Google 的 SRE 团队处理系统故障时，会专门写事后复盘。他们不只庆祝服务恢复，还要把事故记下来，弄清所有促成原因，再把防止复发的动作落下去。

失败经历还会逼着人分清“可修”和“该停”。按钮点不动，是可修的故障；功能全部正常，但用户根本不回来，这就不能继续用“再修一点”解释。前者需要改代码，后者需要重新判断这个产品还有没有存在的理由。

这套逻辑放到副业上也一样。失败经历不能告诉我下一次一定成功，但它能让我少在同一个洞里再掉一次。

对业余时间有限的人来说，少死一次，比多学一个成功套路更实在。

我现在更愿意在动手前先写一张“停工清单”：用户从哪里来，哪个信号能证明他愿意反复用，出现什么情况就不再继续加功能。

这张纸不会让项目显得更厉害，甚至有点扫兴。它的用处是把“我再补一个功能就好了”，换成一个可以核对的条件。

我那套系统下线后，代码和数据都进了归档，没有被当成白做。它留下的最有用东西，不是那些功能，而是一条死亡条件：入口太重，即使系统能跑，也会被更轻的路径取代。

下次再看到一个成功项目，我会先去找它旁边倒下的那几个。

真正该抄的，可能是输家死在哪一步，而非赢家做了什么。你手上的项目如果明天停掉，最可能是哪一条先断？