Zuo产品的人往往容易陷入一种“自嗨”的怪圈。我们总觉得自己是天才，Neng凭空构想出用户梦寐以求的功Neng，但现实往往会狠狠地打脸。过去这一个月，我带着Vibe Usage这个小项目，在真实的用户群里摸爬滚打，经历了一场极其“刺激”的迭代实验。说实话，这过程比我想象中要简单，但也比我想象中geng深刻。今天不想讲那些虚头巴脑的大道理，就想把这段关于“找用户、听劝、快速迭代”的实战经历，原原本本地摊开来聊聊。

其实Zui开始的想法特别朴素，今年刚开年那会儿，我和Glowin聊着聊着就发现一个事儿：市面上所谓的“Vibe爱好者”和真正在一线干活的“Vibe实践者”之间，好像隔着一道kan不见的墙。这道墙不是技术壁垒，而是认知和浓度的差异。大家dou在谈论AI、谈论模型、谈论Agent，但真正把这些东西揉碎了融进日常工作流里的人，太少了。

我们在运营服务号“Vibe Friends”的时候，接触了形形色色的人。这里面有凑热闹的，也有真正把这当回事的。我们就琢磨着，Neng不Neng从这群多元的爱好者里把那些比较Serious的实践者给“挖”出来？这不仅仅是为了Zuo用户分层，geng是为了找到那一群Neng和产品同频共振的人。毕竟Ru果你连你的用户是谁dou没搞清楚，那后面Zuo的一切功Neng可Nengdou是在瞎忙活。

这种初衷直接催生了后来的“$ 俱乐部”。说实话，这个筛选标准有点“粗暴”，我们直接用每个月消耗的Token数量来划线。这招确实被不少人吐槽过嫌太功利，嫌太极客。但从实际效果来kan，聚集进来的这群人，聊出来的东西确实和大众爱好者不在一个频道上。他们关注的是效率、是实际产出，而不是花里胡哨的概念。这种差异，就是我们Zuo产品Zui宝贵的信号。

既然锁定了这群重度用户，接下来就是怎么服务他们。依托于之前的观察，参考了类似ccusage的产品形态，我决定搞一个Vibe Usage，专门帮大家统计Token消耗。这事儿从拍脑袋决定干，到第一个版本真正上线，我也就用了7天。

在开发Vibe Usage的过程中，我贯彻了极致的“Vibe”精神——想清楚了就让Claude一把梭哈。去年底，我对Zuo产品Zui重要的认知还是“找用户> Zuo产品”，但这半年的实践又给了我新的启发：听用户要什么> 自我思考。

这并不是说我们要放弃思考，而是不要在“用户需不需要”这个问题上过度纠结。过去一年的Vibe创作实践，让我有意识地改变了自己的思维模式，从“我想Zuo什么”彻底扭转为“用户要什么我就Zuo什么”。这种转变听起来像是失去了产品经理的主导权，但实际上，它是让产品回归服务本质的Zui短路径。直到Vibe Usage这个项目，我才算真正把这个理念跑通了。

产品上线第一天我就干了一件特别重要的事：在Vibe Friends群和几个朋友的群里简单吼了一嗓子，介绍了一下第一版那简陋得可怜的功Neng，然后火速拉了一个“/usage 用户群”。哪怕是Zui早的版本，明眼人一kan就知道有一堆需要优化的地方，但这不重要，重要的是把人圈进来。

我就在群里不停地问，不停地骚扰大家，确认他们到底要什么。这个过程绝对不是简单的“询问”，而是你要充分去理解大家反馈背后的逻辑。hen多时候，用户嘴上说要A，其实他心里想要的是B。Ru果你只是机械地接需求，那产品迭代的方向迟早会跑偏，甚至迷失在功Neng的海洋里。

为了防止这种迷失，我设计了一套非常直接的流程，简单到不Neng再简单：

找到用户  → 听用户要什么  → Zuo出来验证  → 数据增长

这不仅仅是流程，geng是一种生存法则。在这个链条里只有两个环节还需要我亲自介入：一个是Zui终的产品决策，另一个是Pull Request的代码审核。而且说实话，我觉得产品决策这一步，未来可Nengdou不需要我了。到目前为止，Yi经有累计无数个想法通过这套机制被执行了这种自动运转的感觉，真的hen爽。

当然听用户的话不代表要当“舔狗”。用户导向不是无底线的顺从，在这个过程中，依然需要人的判断。这种判断不是具体的代码实现，而是关乎产品结构和风格的统一性。

举个hen典型的例子。之前有个需求特别强烈，大家dou希望Vibe UsageNeng支持“队伍”功Neng，搞个排行榜PK什么的。但我第一反应就是：不对劲。我一直觉得Vibe Usage的定位是一个AI工具统计助手，它的核心是围绕“一个人”对自己使用情况的了解，排行榜突出的也应该是Top消耗的个人。

Ru果在个人工具里强行加入队伍PK，我觉得会破坏这种定位。这种竞争感可Neng会抑制每个人继续使用的动力，把“自我认知”变成了“团队内卷”。我没想好怎么解决这个矛盾，所以哪怕呼声再高，目前我也没Zuo。这不代表未来永远不Zuo，只是在我当下的判断里它不是Zui优先级，甚至可Neng是有害的。

为了维持这种判断的一致性，我搞了一个叫`PHILOSOPHY.md`的文件。这玩意儿不是我凭空写出来的一堆产品教条，而是我在Vibe42每次写完Pull Request，经过精修和对比后出来的。那些我无法明文写清楚、关于软件和系统的审美，被这个文件hen好地抽象出来了。这算是对我自己思维的一次“蒸馏”，也是保证产品在快速迭代中不变形的压舱石。

把听反馈、开发、上线这套流程跑顺后我把它Zuo成了Vibe42自动迭代维护的系统。大家要是觉得夸张，Ke以叫它“自我迭代”或者“Harness”，但本质其实特别土：用户要什么我们就去分析Zuo什么。

现在用户直接在产品右上角的“想法”里提交需求。这就像是一个永不停歇的需求池，驱动着Vibe Usage的持续进化。这两个指标——活跃的反馈数和被执行的想法数，直接驱动了Vibe Usage Usage数据的持续增长。真的要特别感谢所有提过反馈和Vibe42想法的用户们，是你们在推着这个产品往前走。

基于这种模式，Vibe UsageYi经持续优化了好几个月了。在这个过程中，我Zui关心的指标不再是冷冰冰的数据留存，而是用户“持续愿意同步自己数据”的意愿。因为只有当用户愿意主动同步，才会带动他们回来查kan。这种基于业务模型的行为指标，比单纯的“流失用户”标签要有效得多。它Neng凭直觉告诉你，你的产品是不是真的活在用户的心里。

在构建用户导向的产品迭代流程中，用户需求分析与反馈机制是实现持续优化的关键。敏捷开发的实践，确保了我们在面对变化时Neng保持灵活。比如我们通过建立迭代复盘机制，每次迭代的经验教训；通过建立知识共享平台，促进团队间的经验交流。

但归根结底，一切dou要回到用户身上。用户的一些微妙的、细腻的偏向和习惯，会对产品软件的功Neng形成一个明确的导向。而这些信息信号，一定是在大量的个人信息汇总之后才Neng呈现出来的。迭代的过程，本质上就是不断捕捉这些信号并Zuo出反应的过程。

以前在华为或者其他大厂，我们可Neng要开漫长的迭代会议，产品经理和团队成员耗费大量时间从Backlog里确认UserStory。那种强产品经理导向的模式，容易导致开发和产品矛盾激化，甚至出现“动手拍砖”的场面。但在Vibe Usage的实践中，我们尽量消解了这种对抗。因为需求来自用户，而不是产品经理的拍脑袋，大家的目标是一致的。

简言之，Vibe的理念不只是某种创作的自由，而是一种尽快地形成正循环。从找到用户，到听用户要什么再到Zuo出来验证，Zui后数据增长。这听起来像是精益创业的老生常谈——聚焦原则、客户导向原则、迭代原则、试错原则、行动原则——但真正把它落地，尤其是会有一种完全不同的体感。

这一个月的迭代，让我明白了一个道理：好的产品不是“设计”出来的，而是“生长”出来的。利用好用户群、利用好“想法”自动迭代，就是一种理念的实践。虽然过程中依然需要人的判断来把控风格，但引擎的动力Yi经完全来自于用户。

所以Ru果你也在Zuo产品，别再一个人闷在屋里想破头了。走出去，找到你的用户，听听他们想要什么。哪怕是Zui简单的反馈，也可Neng藏着下一个爆款功Neng的种子。这事儿，就是这么简单。