独立开发者两年做了一堆没人用的工具 这次他怎么做才能停在 v0.2.0

一位叫 Sabahattin Kalkan 的独立开发者最近在论坛上公开复盘了他过去两年的开发节奏。两年里他做了开发者工具、命令行工具、SaaS 产品、自动化工具等多个项目，绝大多数都没人用。他这次决定做出一个和过去完全不同的选择：把产品停在 v0.2.0，不再追求完整发布。

他过去做产品的标准动作是：找到一个看起来真实的问题 → 直接开始开发 → 做着做着发现还有更多问题 → 把那些问题也加进去 → 推到 v1.0 上线。每次他都觉得"再完善一点就完美了"，但每次"再完善一点"之后产品要么复杂度爆炸要么用户依然为零。

这套模式让他两年累积了大量的"完成但没用"的项目。他后来回头复盘，发现每个项目都有相同的失败模式：开发周期越长，他对自己产品真实价值的判断越失真。等到 v1.0 上线那天，他已经完全分不清这个产品是真的能解决用户问题，还是自己用开发动作给自己制造的虚假前进感。

他这次决定停在 v0.2.0 的逻辑有几个值得专门拿出来讨论的具体步骤。

第一是把"完成"重新定义。以前的"完成"是 v1.0 加上完整功能、完整文档、完整营销页。现在的"完成"是 v0.2.0 加上能验证假设的最小功能集合，剩下的全部砍掉。

第二是把"开发完再验证"换成"边开发边验证"。他在 v0.2.0 之前就要拿到至少 10 个真实用户的反馈，反馈可以来自 Beta 用户、私聊、Discord 群、Reddit 帖子，不一定来自上线后的注册数据。

第三是把"完美发布"换成"不完美启动"。他接受 v0.2.0 在用户面前会显得粗糙、会丢脸、会被吐槽，但他接受这个代价，因为他知道 v1.0 的完美发布如果没人看，完美也没意义。

评论区里有一条值得专门展开讨论。来自另一位独立开发者："我用了四年才想明白一件事。独立开发的真正成本不是开发时间，是你的注意力分配。你把注意力放在哪里，三个月后你的产品就会长成那个方向。把注意力放在打磨功能上，产品会变成功能堆积；把注意力放在用户反馈上，产品会变成真实需求。两者的差距在三个月后才会显现，但显现之后就再也追不回来了。"

这段评论把"两年做了一堆没人用的工具"这种现象的本质讲清楚了。开发者的时间看起来是在做产品，但实际是在用开发动作训练自己的某种偏好。当偏好是"打磨功能"，产品就长成功能堆；当偏好是"接住用户反馈"，产品就长成真实需求。两年下来，前者会留下一堆没用户的功能堆，后者会留下一个真正能跑起来的产品。

他这次停在 v0.2.0 的本质，是把注意力从"打磨功能"切换到"接住用户反馈"。这个切换听起来简单，但实际执行需要克服几个真实障碍。

第一个障碍是心理上的"完成焦虑"。把 v0.2.0 当作完成产品，意味着要在自己觉得"还不完整"的状态下拿出去。这个动作对追求完美的开发者来说非常反直觉。

第二个障碍是"再多做一点就好了"的心理暗示。每个项目在 v0.2.0 的时候，开发者都会觉得"再加一点就完美了"。这种暗示是过去两年他一次次把项目推到 v1.0 又没人用的核心原因。

第几个障碍中最难克服的，是"用户反馈很慢很滞后"的现实。和开发立即反馈不同，用户反馈需要数周甚至数月才会出现。开发者必须能在慢反馈期间维持住产品方向，而不是跑回去继续打磨功能。

这件事对所有独立开发者的启示可以浓缩成一句：在 AI 时代，"做得快"是基础能力，"停得早"才是稀缺能力。能在产品看起来还能再做一轮迭代的时候主动停下来拿给用户看，比能用 AI 一周做出 MVP 的开发者，长期成功率更高。

作为正在用 AI 工具做副业的独立开发者，今天可以马上做的一件事是：把当前项目的当前状态写下来，列出哪些是"已经验证有用户要"的功能、哪些是"自己觉得该有但还没验证"的功能。如果后者超过 3 个，就应该砍掉部分功能把产品提前推出去，而不是继续推进到 v1.0。

创业找资源，上乌鸦部落。