1个月迭代实战：Vibe Usage用户需求快速响应榜单

Vibe Usage 的诞生逻辑：从认知断层到精准筛选

动机非常直接。年初，Glowin 团队观察到市场上的 Vibe 爱好者与深度实践者之间存在显著能力鸿沟——大家对 AI、Vibe、模型、Agent 的实际投入与理解深度差异巨大。因此，我们在服务更广泛 Vibe 用户的同时，也迫切需要把那些真正持续落地的实践者识别出来。

这个判断催生了 $999 俱乐部——用月 Token 消耗量这一硬指标，快速筛出真正“all in”Vibe Coding 的人。这个门槛自然引发过争议，但从成员间的交流质量看，筛选效果非常扎实：

• 没人浪费时间争论模型或工具优劣，实战数据说明一切
• 很少空谈创意概念，讨论焦点始终围绕真实用户反馈
• 成员间互评产品时直接且坦诚，用有效信息换取真知灼见

基于上述经验，参考 ccusage 的产品思路后，我们决定打造 Vibe Usage——帮助用户精确追踪自己的 Token 消耗。从决策到第一个版本上线，仅用了 4 天。

「用户想要 · 用户得到」的极致闭环

Vibe Usage 的开发过程本身就是 Vibe 理念的实践——想清楚后，全部交给 Claude 执行。去年底的核心认知是：找到用户 > 做产品。今年我们进一步提炼：听用户要什么 > 自我思考。

简而言之，Vibe 不仅代表创作自由，更是一种快速建立正向循环的方法：

找到用户→ 听用户要什么→ 做出原型或产品→ 验证→ 数据增长（优先收入，至少留存）

搭建用户群，直接捕捉「用户想要」的信号

产品上线当天，便在有限范围内介绍了第一版功能，并迅速建立反馈渠道。即便最早期的版本也有大量待优化细节——关键不是“提问”，而是精准解码反馈信号：

• 群内无人回应 → 99% 是无效功能
• 1-2 人表示“还可以” → 需求不迫切，优先级低
• 多人主动说“不错” → 需求真实存在，若实现简单则立即上线
• 想法刚发出就引发热烈讨论（包括吐槽）→ 99% 是真需求，顺着讨论深度挖掘细节，简化方案，直击用户痛点

需求就这样直接从用户对话中萃取而来。

Vibe42：自动化「用户想要 · 用户得到」的工程系统

随后，这套“聆听到开发”的流程被固化为自动迭代系统——Vibe42。用户可在产品右上角的「想法」入口提交需求，系统自动执行以下步骤：

• Analysis：Agent 分析用户反馈，检索相关数据、文档和代码，识别是否已有同类需求，输出分析结论。
• Product：Agent 基于反馈与分析结论，参考文档和代码，决定是否执行。若确定开发，则输出详细需求文档。
• Dev：通过 Claude Code 在沙盒中开始具体开发，质量依赖完备的项目文档（不限于 AGENTS.md，描述极其详尽）。修改完成后自动提交 Pull Request 待审核。
• 人：最终 Pull Request 仍需人工确认——大改动本地跑一遍，无问题合并后自动上线。

当前流程中，唯一需要人介入的只有产品决策和 Pull Request 审核——产品决策环节未来也可能被替代。截至目前，已有 164 个想法被完整执行并交付。

保留必要的「判断」边界

善用用户群和「想法」自动迭代是核心理念的落地，但产品结构与风格的统一性依然需要人的判断——这并非实现层面的决策，而是取舍与审美。

1. PHILOSOPHY.md：项目文档中专门维护了一份类似设计原则的文件。它不是凭空写出的判断标准，而是在 Vibe42 每次自动生成 Pull Request、并经过人工精修后，逐步对比提炼而来。那些无法书面化的审美直觉，被这份文件有效抽象，成为判断经验的“蒸馏”成果。

2. 持续觉得“不对劲”的地方：例如有用户希望 Vibe Usage 增加队伍功能。但产品的定位是个人 AI 工具追踪，核心应围绕每个人对自身使用情况的认知，排行榜也突出个人 Token 消耗 Top。引入队伍 PK 会稀释这一聚焦点。这个判断未必绝对正确，只是现阶段直觉认为它并不必要，甚至可能干扰用户持续使用的动力。

用户数据印证模式有效性

在这种迭代模式下，Vibe Usage 持续优化约 1 个月。我们最关注的指标不是简单留存，而是用户愿意持续同步数据——因为这会驱动他们主动回访查看：

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

这两个指标持续推动着 Vibe Usage 的迭代方向。最后，特别感谢所有提交过反馈、投出过「想法」的用户们。

来源：互联网