Vibe Usage：1个月迭代总结，一个用户要什么就做什么的产品实践

一开始为什么要做 Vibe Usage

初衷其实很简单。年初的时候，Glowin 和团队发现市场上的 Vibe 爱好者和真正的 Vibe 实践者之间，存在着明显的认知断层——大家对 AI、Vibe、模型、Agent 的使用深度和浓度，其实完全不在一个层级。所以，我们一边服务着更多元的 Vibe 爱好者，一边也想把里面那些更认真的实践者识别出来。

这个想法直接催生了 $999 俱乐部——可以说是简单粗暴地靠每月 Token 消耗量来筛选出真正“全力投入”Vibe Coding 的人。这个门槛当然也被吐槽过，但从聚集起来的成员交流内容来看，筛选效果是显著的。你会发现：

• 几乎没人花时间争论哪个模型或工具更好，实践见真知
• 也很少过度讨论某个创意的“脑洞”，重心永远落在有没有真实用户
• 成员之间相互质疑产品时严肃而真诚，不吝啬用坦诚换回有效信息

也正是基于这一点，在参考了类似 ccusage 的产品思路后，我们决定做一个 Vibe Usage，帮大家清晰地统计好自己的 Token 消耗。从决定启动到第一个版本上线，前后只用了 4 天。

充分实践「用户想要 · 用户得到」

做 Vibe Usage 的过程很 Vibe——想清楚了，就全交给 Claude 一把梭。去年底的一个核心认知是：

简言之，Vibe 的理念不只是创作的自由，而是一种尽快形成正循环的方式：

找到用户→ 听用户要什么→ 做出来（可以是demo也可以是产品）验证→ 数据增长（最好是收入，起码也得是留存）

建用户群，听到「用户想要」的心声

产品上线的第一天，就在有限的圈子里简单介绍了第一版的功能，并快速建立起用户反馈渠道。即使是最早的版本，也明显有大量待优化的地方——这个过程中最重要的不是“问”，而是充分读懂反馈信号：

• 群里没有反应 → 99% 没用
• 有 1-2 人说 OK → 不积极，需求不强烈
• 好几个人说不错 → 需求存在，值得放进 To Do，如果实现简单就立刻上线
• 想法刚发出来就引来积极讨论（哪怕吐槽） → 99% 是真需求，顺着积极性问清楚更多细节，简化方案，做到用户心坎上

需求就是这么简单直接地从用户沟通中来的。

用 Vibe42 实现「用户想要 · 用户得到」

随后，这套“聆听到开发”的流程被设计成一个自动迭代维护的系统——Vibe42。用户可以在产品的右上角「想法」里提交需求，然后系统会自动执行几步：

• Analysis：Agent 分析用户反馈，查找相关数据、文档和代码，识别是否已有同类需求，形成分析结论。
• Product：Agent 基于反馈和分析结论，参考文档和代码，决定是否执行。如果做，就输出详细的需求文档。
• Dev：通过 Claude Code 在沙盒中开始具体开发，质量的最大依赖是完整的项目文档（不止 AGENTS.md，写得非常详尽）。修改完成后自动提交 Pull Request 以待审核。
• 人：最终的 Pull Request 还是需要人看一眼——改动大的话本地跑一下，没问题就 merge 并自动上线。

整个流程里，目前还需要人参与的就只剩产品决策和 Pull Request 审核——不过产品决策这一步，说不定哪天也可以省掉了。到目前，累计已有 164 个想法被完整执行过。

但依然会有自己的「判断」

用好用户群、用好「想法」自动迭代，这些都是理念的实践。但这中间仍然需要人来做判断——不是具体实现层面，而是产品结构和风格的统一性。

1. PHILOSOPHY.md：项目文档里专门维护了一份类似原则的文件。它不是凭空写出来的一套判断标准，而是在 Vibe42 每次自动写完 Pull Request、以及经过人工精修改之后，逐步对比总结出来的。一些无法被明文写清楚的审美，被这份文件很好地抽象了出来，也算是对自己判断经验的一种“蒸馏”。

2. 就是始终觉得“不对”的地方：比如有用户希望 Vibe Usage 支持队伍功能。但定位上，Vibe Usage 是一个个人 AI 工具统计，核心围绕的应该是每个人对自己使用的了解，排行榜也突出的是 Top 消耗的个人。加入队伍 PK 会冲淡这个聚焦。这个判断未必绝对，只是现阶段直觉上觉得它不太需要，或者说会干扰每个人自己继续用下去的动力。

用户数据

在这种模式下，Vibe Usage 持续优化了约 1 个月。最关注的指标不是简单的数据留存，而是用户愿意持续同步自己的数据——因为会带动着回来查看：

• 1D 留存：89%（工作日），70%（周末）
• 7D 留存：87.5%

这两个指标一直驱动着 Vibe Usage 的持续迭代。最后，也感谢所有提过反馈、Sparked 过想法的用户们。