那些写好了却决定永不上线的项目：独立开发者的断舍离准则

核心结论

在独立开发领域，“决定放弃上线某些项目”本身就是产品开发不可分割的关键组成部分。在 kimura512.dev 首页上，仅展示链接存活、功能闭环的成熟作品。比起陈列半成品，果断克制展示范围是对访客与自我精力的双重尊重。

1. 终止试作原型的三大诱因

被舍弃的原型通常落入三类陷阱：差异化不明显、长期维护成本过重、或者无法用一句话讲清用户价值。写代码是快乐的，但长年累月的线上运维极其沉重。

2. 地图类试作项目的止损案例

除醉爱地图（Suiai Map）外，我曾尝试过若干空间地理类创意，后因数据清洗与定期更新成本过高而果断叫停。代码封存在独立分支，将选型反思沉淀为博客文章即可。

3. 实验性代码的处理原则

试作代码仅保存在私有仓库中，绝不在公开控制台或首页充当占位假链接，避免传递出仓促半成品的消极印象。

4. 作品展示必须严格保真

作品集中的每一条外链必须确保点击后返回 HTTP 200 并可正常交互。让访客遭遇白屏报错是严重透支专业信誉的行为。

5. 项目重启的准入硬指标

只有当评估后认为能在周末两天内上线可用 MVP 时，我才会重启旧原型。设立清晰门槛能杜绝漫无目的的反复修补。

6. 将失败教训沉淀为高质量内容

撰写项目复盘能够将沉没成本转化为长效智力资产，节省同行走弯路的时间。

7. 清理“敬请期待”空头支票

从作品集中彻底剔除假卡片，确保所见即所得，全面提升整体站点的整洁感与质感。

8. 行业经验分享

开诚布公分享“为何停止研发”，往往比单纯宣传成功更能展现架构师的权衡与判断力。

总结

学会对半成品说“不”，所发布产品的综合水准才能稳步跃升。

常见问题

Q. 废弃项目的代码彻底删除了吗？
完整保留在私有 git 历史中供随时查阅参考。

Q. 怎样才会被重新立项？
必须完全满足周末双日 MVP 快速落地的验收标准。