Vibe Usage一个月迭代总结:用户需求驱动产品实践
VibeUsage基于用户反馈快速迭代,通过Token消耗筛选重度实践者,依托Vibe42系统自动处理需求并开发上线。经一个月优化,1日留存89%(工作日),7日留存87 5%。
一开始为什么要做 Vibe Usage
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 → 态度不积极,需求不强烈
- 有数人反馈不错 → 需求真实存在,值得列入待办清单,若实现简单则立即上线
- 想法刚发出便引发积极讨论(即使是吐槽) → 99% 是真实需求,顺着讨论热情追问更多细节,简化方案,切实满足用户期望
用户需求就这样简单直接地从沟通中浮现出来。
用 Vibe42 实现「用户想要 · 用户得到」
随后,我们将这套“从倾听需求到实现开发”的流程设计成了一个自动化迭代维护系统——Vibe42。用户可以在产品界面右上角的「想法」入口提交需求,系统会自动执行以下步骤:
Analysis:Agent 分析用户反馈,检索相关数据、文档和代码,判断是否已有类似需求,并生成分析结论。Product:Agent 基于反馈与分析结论,参考项目文档和代码,决定是否执行。若决定实现,则输出详细的需求文档。Dev:通过 Claude Code 在沙盒环境中开始具体开发,其质量高度依赖完整的项目文档(不仅限于 AGENTS.md,需要非常详尽)。修改完成后自动提交 Pull Request 等待审核。人:最终的 Pull Request 仍需人工审查——若改动较大则本地运行测试,确认无误后合并并自动上线。
目前整个流程中,仍需人工参与的环节只剩下产品决策和 Pull Request 审核——不过产品决策这一步,或许未来某天也能实现自动化。截至目前,累计已有 164 个想法被完整执行并上线。
但依然会有自己的「判断」
用好用户群、用好「想法」自动迭代,这些都是理念的实践。但这中间仍然需要人来做判断——不是具体实现层面,而是产品结构和风格的统一性。
PHILOSOPHY.md:项目文档中专门维护了一份类似原则的文件。它并非凭空编写的判断标准,而是在 Vibe42 每次自动生成 Pull Request 并经过人工精修后,逐步对比总结出的。一些难以用明文表述的审美偏好,被这份文件很好地抽象了出来,也算是对自身判断经验的一种“蒸馏”。另一个判断体现在始终觉得“不对”的地方:例如有用户希望 Vibe Usage 支持团队功能。但 Vibe Usage 的定位是个人 AI 工具使用统计,核心应围绕每个人对自身使用情况的了解,排行榜也突出个人消耗 Top。加入队伍 PK 会分散这一焦点。这个判断未必绝对,只是现阶段直觉认为它不太必要,或者说可能会干扰用户持续使用的动力。
用户数据
在这种模式下,Vibe Usage 持续优化了约一个月。我们最关注的指标并非简单的数据留存,而是用户是否愿意持续同步自己的数据——因为这能促使他们反复回来查看:
- 1日留存:89%(工作日),70%(周末)
- 7日留存:87.5%
这两个指标持续驱动着 Vibe Usage 的迭代优化。最后,衷心感谢所有提出反馈、Spark 过想法的用户们。
游乐网为非赢利性网站,所展示的游戏/软件/文章内容均来自于互联网或第三方用户上传分享,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系youleyoucom@outlook.com。
同类文章
Claude Code 必知的14个高效工作流,让你的开发效率提升300%
Claude Code 常用工作流 先分享几项核心判断:Claude Code 真正强大的地方,并非仅仅在于它能编写代码——而是它让“编码”这件事本身变得更加高效且可控。你大概率遇到过这类场景:接手一个陌生项目,花了一整天才能理清架构;线上出现报错,翻遍日志也找不到根本原因;想要重构遗留代码,又担心
阿里云通义AIGC平台完全指南:设计师AI生产力革命
一、写在前面:为什么设计师需要关注AIGC? 如果你还在手动一张一张制作海报、反复修改客户口中“感觉不对”的配色方案、为电商详情页准备几十张不同场景的产品图——那么你一定经历过这些痛点: 创意瓶颈:脑海中有画面,但手绘无法呈现 重复劳动:调整尺寸、更换背景、批量生成变体消耗了大量时间精力 成本焦虑:
零基础毕设代码二次开发:3文件定位法及Vue/Java修改对照表
每年一到毕业季,计算机专业的同学总会陷入一个共同的怪圈:从 GitHub 上扒下来一套代码,或者用 AI 生成一个项目,看起来挺完整的,可导师一句“加个筛选条件”或“换个页面颜色”,瞬间就懵了——不敢改,不会改,怕改崩。是不是很熟悉? 一、为什么AI生成的毕设代码你 "不敢改 "? 1 1 毕业生的三大
反向海淘订单系统:状态机与分布式事务实战设计
先分享一个反直觉的结论:反向海淘订单管理的真正挑战,往往不在于业务逻辑本身,而在于状态流转。一个订单的生命周期拉长到跨国运输,中间涉及的环节多、系统多、参与者多,状态稍有错乱就可能引发连锁事故。Taocarts团队在实践中踩了不少坑,最终沉淀下来的这套状态机与分布式事务方案,成功解决了这一复杂难题。
AI并未抢走程序员饭碗而是更新了编程菜单
AI并未大规模替代程序员,而是改变了职业结构。重复性编码岗位需求下降35%至15%,而AIAgent开发等岗位需求激增187%。开发者焦虑从“被替代”转向“跟不上变化”,60%程序员已使用AI辅助编程。人的核心价值转向架构设计、技术决策和审查AI生成代码,AI技能带来16%薪资溢价。
- 热门数据榜
相关攻略
2026-07-09 17:49
2026-07-09 16:48
2026-07-09 16:46
2026-07-09 16:46
2026-07-09 16:46
2026-07-09 16:46
2026-07-09 15:45
2026-07-09 15:45
热门教程
- 游戏攻略
- 安卓教程
- 苹果教程
- 电脑教程

