独立开发最容易失控的地方，不是代码写得不够快，而是所有项目都被当成“正在开发”。一旦探索、发布、维护和暂停混在一起，开发者就会不断切换上下文，在新功能、用户反馈、客服和获客之间来回消耗，却很难判断哪个项目值得继续投入。

更可行的做法，是把项目状态当成资源分配机制，而不是进度标签。项目进入不同状态，就应当拥有不同目标、投入强度和退出条件。这样可以减少每天重新选择方向的成本，也能避免因为已经投入过时间，就被迫继续维护一个没有反馈的项目。

四种状态，四种决策

探索状态的目标不是完成产品，而是验证问题。此时只实现能够让用户完成一个核心动作的最小版本，例如生成、整理、转换、检查或发布中的某一步。项目必须边界清楚，能够说明服务谁、解决什么问题，以及用户为什么愿意尝试。

发布状态意味着核心功能已经可用，重点应从继续堆功能转向让目标用户真正接触产品。产品说明、使用示例和首次体验往往比额外增加功能更优先。发布不是验证结束，而是让真实使用取代部分猜测的开始。

维护状态不等于满足所有需求。优先处理阻塞使用、反复出现和影响信任的问题，其余反馈排队处理。用户的赞赏、访问和讨论只能说明有人看见产品；重复使用、主动提出具体需求和付费意愿，才是更接近产品价值的信号。

暂停状态则是主动停止持续消耗。代码、反馈和未解决问题可以保留，但不能因为沉没成本而继续投入。暂停并不等于失败，而是承认当前证据不足以支持更高投入。

用状态控制切换

并行开发不应理解为多个项目同时高速推进，更接近于一个项目集中推进，其他项目低频观察，必要时再切换重点。每次切换前，都应回答三个问题：最近获得了什么事实反馈？下一步要验证什么？如果仍然没有信号，何时暂停？

如果缺少快速交付能力、用户触达渠道，或无法承受注意力切换，先把一个产品做深通常更稳妥。项目状态管理的价值，不是让一人公司拥有更多项目，而是让有限时间持续流向最值得验证的假设。