副业项目的“杀死清单”：6 个放弃信号与体面杀法

独立开发者最贵的不是服务器，不是 API 账单，是时间。而时间最大的黑洞，不是"没灵感"，是"不肯杀项目"——那个做了八个月、每周还在维护、但心里清楚它起不来的项目。Pieter Levels 连续做了 12 个产品，杀了 11 个，只留下 Nomad List。他后来总结："我成功的秘诀不是做了 12 个产品，是杀了 11 个。"

这篇文章给你一套"杀死清单"：6 个该放弃的信号、怎么体面地杀掉一个项目，以及杀项目省下的时间到底值多少钱。

先说说这个问题的普遍性。我访谈过的 20 多位独立开发者里，超过一半同时维护着 2 个以上的"僵尸项目"——有用户但没增长，有收入但不够生活，食之无味、弃之可惜。而他们回头看，几乎每个人的代表作都诞生在"杀掉旧项目、all in 新方向"之后的那一年。杀项目不是失败者的退场，是胜利者的腾挪。你缺的从来不是"再坚持一下"的毅力，是"及时止损"的机制。

6 个该放弃的信号

注意：单个信号出现不代表要杀，但同时出现 3 个以上，就是红灯。

信号一：连续三个月，核心指标零增长。注意是"核心指标"，不是"忙碌程度"。你每周都在修 bug、回用户邮件，看起来很忙，但注册数、付费用户、收入三条线全是平的。忙碌是最好的麻醉剂——它让你觉得"在推进"，实际上只是在维护一个静止的物体。给每个项目定一个北极星指标，三个月不动，就进入"观察名单"。

这里有个常见的自我欺骗：把"虚荣指标"的增长当成安慰剂。Twitter 粉丝涨了 200，GitHub star 多了 50，但注册转化率还是 0。记住一条铁律：不能导向收入的增长，都是幻觉。看板上只留三个数字：新增付费用户、MRR、留存率，其他的都是噪音。

信号二：你已经在"靠意志力"维护它。诚实地问自己：打开这个项目的代码仓库，你是兴奋还是叹气？如果连续一个月，每次动手前都要做心理建设，项目已经死了，只是你还没签字。独立开发者的能量是单线程的，靠意志力维持的项目，正在偷走你本可以 all in 在下一个机会上的热情。

这里要区分"正常的倦怠"和"项目已死"。正常的倦怠是周期性的——做三个月累了，休息一周又想干了；项目已死是方向性的——休息回来还是不想碰它，甚至看到用户邮件都有点烦。判断方法：给自己放 7 天假，完全不想这个项目，假期结束第一天，观察你的第一反应是"有点想回去搞"还是"又要面对它了"。后者，就是信号二。

信号三：用户反馈永远在"小修小补"，没有"aha moment"。健康的早期项目，用户会说"这个功能救了我"；垂死的项目，用户只会说"这个按钮能不能换个颜色"。当你三个月没听到任何一个让用户眼睛发亮的反馈，说明产品没有击中真需求，只是在服务"礼貌性用户"。

什么叫"礼貌性用户"？就是那些说"挺好的，加油"但从不付费、从不推荐给朋友的人。独立开发者最容易被这类反馈误导，因为它听起来是正面的。教你一个鉴别方法：看用户愿不愿意"付出代价"——付费、填冗长的 onboarding 表单、把数据迁移过来。只动嘴不动手的用户，反馈权重应该打三折。如果你的用户列表里 90% 都是这类人，产品就没有真需求支撑。

信号四：你害怕看数据。上次打开分析后台是什么时候？如果答案是"好几周前"，而且你是故意不看的——因为看了难受——数据已经在告诉你答案了。逃避数据是创始人最诚实的身体语言。

给这个信号配一个强制机制：每周一早上 9 点，日历提醒"看数据 15 分钟"，雷打不动。看三个数就行：新增用户、付费转化、流失。连续四周不敢点开这个日历，或者点开了三秒就关掉——别骗自己了，你已经在用"不看"来保护"还能抢救"的幻觉。数据不会因为你不看就变好，只会因为你不看而错过止损时机。

信号五：增长全靠你手动推。每次发推带来 10 个注册，不发就归零；每个客户都是你一个个聊来的，产品自己不会获客。这说明没有 product-market fit，只有 founder-market fit——你本人就是唯一的增长渠道。这在小团队早期正常，但 6 个月后还是这样，就是产品本身没有传播力和留存力。

做个简单的"度假测试"：如果你彻底消失两周（不更新、不发推、不回邮件），产品的数据会发生什么？健康的产品会缓慢衰减，垂死的项目会直接归零。这个测试很残酷，但它测的是项目本身有没有生命力，而不是你有没有生命力。

信号六：机会成本已经大到无法忽视。算一笔账：这个项目每周吃掉你 15 小时，一年就是 780 小时，相当于 4.5 个月全职工作。而你 backlog 里躺着两个你更看好的想法。杀项目不是承认失败，是把 780 小时赎回来，投给期望值更高的地方。

机会成本还有个隐形版本：心智带宽。一个半死不活的项目，即使你每周只花 2 小时维护，它也会在你脑子里占一个后台进程——洗澡时想它的 bug，睡前想它的用户投诉。这种"低功耗运行"的焦虑，比实际投入的时间更消耗人。杀掉它，关掉的不仅是一个仓库，还有一个常年占用你内存的后台进程。这种轻松感，只有杀过项目的人懂。

怎么体面地杀掉一个项目

杀项目不是"关服务器跑路"，体面地杀，有四种姿势，按体面程度排序：

• 第一档：开源 + 写复盘。把代码开源，写一篇诚实的复盘：做了什么、数据如何、为什么杀、对后来者的建议。这是 ROI 最高的杀法——一篇好的"失败复盘"带来的关注和信任，经常超过项目本身活着时的总和。Sahil Lavingia 的 Gumroad 复盘就是例子：项目差点死，复盘让他封神。你的"尸体"可能是你最好的内容资产。开源时记得清理掉密钥和用户数据，写个像样的 README 说明"这个项目为什么停止维护"，别让后来人白折腾。
• 第二档：卖掉或送人。有收入（哪怕很少）的项目，可以挂到 MicroAcquire、Flippa 这类平台上卖；没收入但有用户的，找个愿意接手的同行送出去，条件是继续服务现有用户。卖掉的钱不重要，重要的是给项目一个结局，而不是让它烂在服务器上。
• 第三档：优雅关停。提前 30-60 天通知用户，给数据导出工具，老用户按比例退款或赠送你下一个产品的终身折扣。关停信要诚实："这个产品没有达到可持续的规模，我决定关停"，不要编故事。用户对诚实的关停的容忍度，远高于你的想象——他们真正恨的是"突然消失"。体面关停的用户，有 30% 会成为你下一个产品的种子用户，这是真实发生过的转化。
• 第四档：冷冻。实在下不了决心，就正式"冷冻"：写一封给自己的信（为什么暂停、什么条件下重启），归档代码，关掉付费服务，设一个 6 个月后的日历提醒。冷冻和"拖着"的区别是：冷冻是一个决定，拖着是没做决定。决定本身就能释放心理带宽。

不管选哪档，都有一个必做动作：写复盘，公开或至少写给自己。回答四个问题：当初为什么做？哪个假设错了？数据是什么？下次怎么避免？不写复盘的杀项目，等于交了学费没拿发票——同样的坑，你大概率会再踩一遍。

如果你选第三档关停，给你关停信的五个要素，照着写就行：感谢（具体点名最早支持你的用户）、数据（诚实地说产品走到了哪里）、原因（一句话，不找借口）、安排（数据怎么导出、退款/补偿方案、关停时间表）、下一步（你在做什么新的，欢迎他们继续关注）。语气像给朋友写信，别写公关稿。人们原谅真诚的失败，不原谅含糊的消失。

再给一个"两周杀项目执行计划"，把决定变成动作：第 1-2 天，做决定并写下杀的理由（一页纸，防止自己反悔）；第 3-5 天，处理用户：发关停/交接通知，开通数据导出，设置自动回复；第 6-10 天，处理资产：代码归档或开源，域名决定续费还是放掉，取消所有付费订阅（服务器、API、SaaS 工具——这一步能立刻省下真金白银）；第 11-14 天，写复盘并公开。两周结束，这个项目在法律、财务、心理三个层面都"结案"了。最怕的是"决定杀了，但服务器还开着、订阅还扣着、用户还等着"——那种半死不活的状态，比没杀更耗人。

杀项目省下的时间，到底值多少钱

来算一笔具体的账。假设你的目标是时薪 500 元（一个资深独立开发者的合理估值）：一个每周吃掉你 10 小时的"僵尸项目"，一年就是 520 小时，价值 26 万元。而它一年给你带来的收入可能是 2 万元。你每年花 26 万，买 2 万的收入，还附赠焦虑和自我怀疑。这笔账算完，杀不杀就不是情感问题，是数学问题。

更深的机会成本在于"注意力"。独立开发者的产出不是线性的——一个 all in 的好项目，产出可能是三个半吊子项目的 10 倍。Pieter Levels 的 12 个产品里，前 11 个加起来的收入，不如 Nomad List 一个月的零头。杀项目的本质，是把分散的 30% 精力，换成集中的 100% 精力，而 100% 精力在好项目上的回报是指数级的。

所以我给你的可执行建议是：每季度做一次"杀项目评审"，就像公司做财务审计一样。列出所有在维护的项目，对每个项目打三个分：过去 90 天核心指标增长（0-10）、你的热情度（0-10）、机会成本（它占你时间的比例）。总分最低的那个，认真考虑杀掉。并且，每个新项目启动时，就预设"杀线"："如果 3 个月内没有 10 个付费用户，就杀。"预设杀线最大的好处，是把"杀"从情绪化的深夜决定，变成执行既定规则——规则不心疼，你才会心疼。

杀完之后别急着开新坑，给自己 30 天的"恢复期"：第一周彻底休息，不看代码，去过正常人的生活——连续维护僵尸项目的人，判断力都是耗竭的，耗竭状态下选的方向大概率还是错的；第二周写复盘，公开版发出去，完整版留给自己；第三、四周再选方向，用三个标准过滤新想法：有没有人已经在为类似方案付钱（需求验证）、你能不能在 6 周内做出 MVP（速度验证）、这个方向失败了你认不认（杀线预设）。带着"杀过项目"的心态选方向，你会比上一次清醒得多——杀项目最大的回报不是省下的时间，是升级后的判断力。

我的观点：杀项目的能力，是独立开发者和业余爱好者的分水岭

业余爱好者做项目是为了"做出东西"，独立开发者做项目是为了"找到 work 的东西"。前者每个项目都是孩子，杀不得；后者每个项目都是实验，数据不好就关。你对项目的感情越深，你的判断力就越贵——贵到你付不起。记住，实验的价值在于"证伪"，一个被干净杀死的实验，和成功的实验一样有价值。

Google 以杀产品闻名（Google Graveyard 上躺着几百个），内部文化是"杀得快是一种能力"。独立开发者更应该如此：大公司杀项目要开三个会，你只需要一个决定。你的优势就是船小好掉头，别把这个优势浪费在"沉没成本"上。

当然，要划清一条线：杀项目不等于"遇到困难就跑"。区分"该杀"和"该坚持"的标准，是"假设检验"有没有在推进。如果你每个月都在验证一个新假设（换定价、换渠道、换人群），数据在给你反馈，哪怕慢，也是在创业；如果你只是在重复同样的动作、等奇迹发生，那就是在拖延。杀的是"停止进化的项目"，不是"遇到挫折的项目"。创业需要钝感力，但钝感力要用在"扛住波动"上，不是用在"无视数据"上。

最后送你一句话，贴在显示器上："不杀平庸的项目，你就没时间做出伟大的项目。"现在就去列出你的项目清单，打分，找出那个该杀的——然后体面地、公开地杀掉它。你会发现，杀完的那天晚上，睡得格外香。因为你终于把时间，还给了未来。而那个"未来"，才是你当初辞职（或下班后熬夜）做独立开发真正想要的东西——不是"拥有很多项目"，是"做出一个真正 work 的东西"。