Vibe Usage：1個月迭代總結，一個用戶要什麼就做什麼的產品實踐
整理版優先睇
作者透過Vibe Usage實踐「用戶要什麼就做什麼」，利用用戶羣同自動化系統快速迭代產品，驗證理念。
作者過去一年轉變思維，由「我想做什麼」改為「用戶要什麼就做什麼」，但一直未做出好產品。直到Vibe Usage，佢同Glowin發現Vibe愛好者同實踐者之間有壁壘，於是創立$999俱樂部篩選嚴肅嘅實踐者，並快速開發Vibe Usage幫助統計Token消耗。
上線後，作者即時通過Vibe Friends羣推廣，並拉咗/usage用戶羣，用簡單嘅信號判斷需求強度：冇反應代表冇用，幾個人話OK代表需求唔強烈，多人話唔錯就放進To Do，多人積極回應甚至吐槽就代表有真需求，要立即問清楚細節並簡化方案。佢將呢個流程固化為Vibe42自動迭代系統，用戶可以喺產品右上角「想法」提交需求。
Vibe42系統分為Analysis、Product、Dev三步，由Agent分析反饋、決策是否做、用Claude Code開發，最後由作者審核Pull Request並自動上線。一個月內累計執行164個想法。作者亦保留判斷，例如反對支援隊伍功能，認為會抑制個人使用。最終Vibe Usage得到高留存：1D留存89%（工作日）、7D留存87.5%，證明呢種模式有效。
- 結論：實踐「用戶要什麼就做什麼」理念，透過快速迭代同用戶反饋驅動產品成功，係Vibe Coding嘅核心。
- 方法：建立用戶羣，用簡單訊號判斷需求強度；利用Vibe42自動化系統實現從想法到上線嘅閉環，大幅加速開發。
- 差異：$999俱樂部篩選嚴肅實踐者，佢哋更關注實踐、真實用戶同有效信息，同一般Vibe愛好者好唔同。
- 啟發：產品決策仍然需要人嘅判斷，例如透過PHILOSOPHY.md保持風格統一，唔好盲目滿足所有需求。
- 可行動點：建立自己嘅用戶反饋渠道，最小化開發週期，用留存數據驗證產品方向，同時保留核心判斷力。
從「我想做」到「用戶要什麼就做什麼」
作者過去一年嘅Vibe創作實踐，令佢有意識改變自己做產品嘅思維，由「我想做什麼」改成「找到用戶，用戶要什麼就做什麼」。但之後好長時間都冇做出咩太好嘅產品，直到Vibe Usage令佢再次實踐呢個理念。
找到用戶，用戶要什麼就做什麼
呢個轉變係Vibe創作嘅核心：找用戶 > 做產品
$999俱樂部：用Token消耗篩選實踐者
作者同Glowin發現，普遍嘅Vibe愛好者同真實嘅Vibe實踐者之間有壁壘，認知同使用AI、Vibe、模型、Agent嘅程度好唔同。所以佢哋創立$999俱樂部，用每個月消耗嘅Token去識別更全力用Vibe Coding嘅一羣人。
$999俱樂部用Token消耗篩選實踐者
呢個篩選方式雖被吐槽，但聚集到嘅成員交流內容同大眾有顯著差異：大家唔會浪費時間討論邊個模型好，更多係實踐出真知；好少過度討論創意，而係落腳喺有冇真實用戶；會嚴肅但真誠質疑彼此產品，唔吝嗇坦誠帶嚟嘅有效信息。
實踐出真知，聚焦真實用戶
聽用戶要什麼：用羣組反應判斷需求強度
上線第一日，作者就喺Vibe Friends羣推廣，然後拉咗/usage用戶羣。佢不停問大家，並總結出簡單判斷法則：
- 1 羣組冇反應 → 99%冇用
- 2 得1-2人話OK → 需求唔強烈
- 3 好幾個人話唔錯 → 需求存在，值得放進To Do，簡單就立刻上線
- 4 大家回覆積極（甚至吐槽積極） → 99%有真需求，要藉機問清楚細節，簡化方案，做到用戶心坎上
呢個判斷方式簡單但有效：積極反應=真需求，平淡反應=非核心
聽用戶要什麼 > 自我思考
作者強調，聽用戶要什麼比自我思考更重要，呢個理念貫穿Vibe Usage嘅整個開發過程。
用Vibe42實現「用戶想要・用戶得到」
作者將聽用戶反饋到開發上線嘅流程，做成Vibe42自動迭代系統。用戶可以喺產品右上角「想法」提交需求，系統會自動分析、決策同開發。
系統分為Analysis、Product、Dev三個步驟
- 1 Analysis：Agent分析用戶反饋，查找相關數據、文檔同代碼，睇下有冇人提過同類，形成分析結論md。
- 2 Product：Agent根據反饋同分析，決策是否做，如果做就輸出需求文檔PRD。
- 3 Dev：套用Claude Code，喺Sandbox開發，開發質量依賴完整項目文檔（包括AGENTS.md等），完成後發Pull Request畀作者審核。
- 4 人：作者審核Pull Request，改動大就本地測試，冇問題就merge並自動上線。
用戶想要 · 用戶得到
呢個系統實現咗「用戶想要 · 用戶得到」，但作者依然保留判斷：例如反對支援隊伍功能，因為覺得會抑制個人使用。
保留判斷：PHILOSOPHY.md同留存數據
作者認為產品決策仍然需要人嘅判斷，尤其係產品結構同風格嘅統一性。佢寫咗PHILOSOPHY.md，係從每次Pull Request同精修中對比總結出嚟嘅原則，抽象咗佢對軟件系統嘅審美。
PHILOSOPHY.md係作者對自己審美嘅「蒸餾」
作者對隊伍功能嘅判斷：「我覺得不對」，認為Vibe Usage係圍繞個人使用統計，隊伍會抑制每個人繼續用落去。
「我覺得不對」：保留產品定位嘅判斷
基於呢種模式，Vibe Usage持續優化一個月，最關心嘅指標係用戶持續願意同步數據。1D留存：89%（工作日），70%（週末）；7D留存：87.5%。呢兩個指標驅動產品繼續增長。
高留存證明「用戶要什麼就做什麼」嘅有效性
過去一年嘅Vibe創作實踐，令我意識到要改變自己做產品嘅思維，由 我想做啲乜 改成 揾到用戶，用戶想要乜就做乜 。但之後好長時間都冇做出乜嘢好嘅產品，直到 Vibe Usage 令我再次實踐呢個理念。
一開始點解要做 Vibe Usage
初衷好簡單，年初嘅時候，Glowin 同我意識到普遍嘅 Vibe 愛好者 同真實嘅 Vibe 實踐者 之間係有隔閡嘅，大家嘅認知，真實使用 AI、Vibe、模型、Agent 嘅程度同濃度都唔同。所以，我哋喺服務號 Vibe Friends 入面多元嘅 Vibe 愛好者嘅同時，想挖掘出入面比較認真嘅實踐者。
呢個初衷催生咗 $999 俱樂部 ，甚至有啲「粗暴」咁用每個月消耗嘅 Token 嚟識別更加全力用緊 Vibe Coding 嘅一班人。呢個篩選方式當然都俾人「吐槽」過，但係從目前聚集到嘅 $999 俱樂部成員所交流嘅內容嚟睇，確實同大眾嘅愛好者有顯著嘅差異。包括但不限於：
大家唔會浪費太多時間討論邊個模型、工具好，更多係實踐出真知 大家極少過度討論某個想法嘅「創意」，而係更多落腳喺有冇真實用戶上面 大家亦都會更加嚴肅但真誠咁質疑彼此做嘅產品，唔吝嗇坦誠帶嚟嘅有效資訊
亦都基於呢個，參考咗類似 ccusage 嘅產品之後，決定做一個 Vibe Usage 嚟幫大家統計好自己嘅 Token 消耗。由決定搞，到第一個版本上線我用咗 4 日。
充分實踐「用戶想要 · 用戶得到」
喺做 Vibe Usage 嘅過程，我好 Vibe，即係話諗清楚咗讓 Claude 一次過搞掂。去年底，我對 Vibe 最重要嘅認知就係找用戶 > 做產品。呢半年又有咗新嘅理解，就係 聽用戶要什麼 > 自我思考。
簡單講，Vibe 嘅理念唔只係某種創作嘅自由，而係一種盡快形成正循環：
揾到用戶
→ 聽用戶要什麼
→ 做出來（可以是demo也可以是產品）驗證
→ 數據增長（最好是收入，起碼也得是留存）
建立用戶羣，聽到「用戶想要」嘅心聲
所以，喺 Vibe Usage 上線嘅第一日開始，我就透過 Vibe Friends 羣同埋一啲朋友嘅羣入面簡單介紹咗第一版嘅功能，然後快速開咗個 /usage 用戶羣，即使係最早嘅版本，好明顯有好多需要優化嘅地方。我亦都係噉喺羣入面問大家嚟確認用戶們想要啲乜。
呢個過程唔係簡單嘅詢問，而係你要充分理解大家嘅回饋：
羣入面冇反應 → 99% 冇用 有1-2個人話OK → 就係唔積極，就係需求唔強烈 好幾個人話唔錯 → 應該需求係存在嘅，好值得放到 To Do 入面，如果簡單就即刻上線 大家回覆積極（甚至係吐槽嘅積極） → 99% 說明有真需求，要藉住大家嘅積極問清楚更多細節，簡化自己嘅方案，做到用戶嘅心坎上
就係咁簡單，就透過呢個羣嚟做需求
用 Vibe42 嚟實現「用戶想要 · 用戶得到」
跟住，我將呢個聽用戶回饋，到開發上線嘅流程保留落嚟。做成咗 Vibe42 自動迭代維護嘅系統（大家可以誇張咁叫佢做自我迭代、Harness，但其實就係用戶想要乜就去分析做乜），簡單講就係可以喺產品嘅右上角「想法」入面提交你覺得需要嘅嘢。然後我就簡單設計咗呢幾步：
Analysis ：Agent 會分析用戶反饋、找一下相關數據、文檔和代碼、然後看下最近有沒有人提了同類的，形成分析結論的 md 文字。Product ：Agent 基於用戶反饋和分析結論，參考文檔和代碼，決策是否做，如果做就具體輸出需求文檔 PRD 的 md 文字Dev ：套着一個 Claude Code，Product Agent 決定做且我審核可以做之後，就在一個 Sandbox 裏開始具體的開發了，開發質量最大的依賴就是完整的項目文檔（不只是 AGENTS.md，我寫了非常多），如果修改完了，就會直接發 Pull Request 我來審核人 ：我還是會看下 Pull Request，改動大就本地跑一下，沒問題就 merge 了，然後就自動上線。
呢個流程入面只有產品決策同 Pull Request 仲需要我，當然產品決策呢一步我覺得之後可以唔使。到目前為止已經有累計 164 個想法被執行過咗。
但係，依然會有自己嘅「判斷」
利用好用戶羣、利用好「想法」自動迭代，係一種理念嘅實踐。但係呢個過程中依然需要人嘅判斷，唔係具體嘅實現，而係產品結構、風格嘅統一性。
PHILOSOPHY.md：我喺文件入面會有咁樣一個類似 principles 嘅文件，佢唔係我空口寫出嚟嘅一堆產品判斷依據，而係喺 Vibe42 每次自己寫完嘅 pull request 同我精修之後，做對比總結出嚟嘅。呢啲我無辦法明文寫清楚嘅，我對於軟件、系統嘅審美俾呢個文件好好咁抽象咗出嚟，亦都算係對我嘅「蒸餾」。就係我覺得唔啱 ：有個需求就係希望 Vibe Usage 支援團隊，我一直都覺得 Vibe Usage 係個 AI 工具統計嘅定位，圍繞嘅係一個人對自己使用嘅瞭解，排行榜亦都突出嘅係 Top 消耗嘅個人。呢個定位入面對於團隊嘅 PK 感覺唔係咁啱。我冇諗好，唔一定未來唔會做，只係目前我嘅判斷入面覺得佢唔太需要，或者話會抑制每個人自己繼續用落去。
用戶數據
基於呢種模式，Vibe Usage 持續優化咗 1 個月喇，我最關心嘅指標唔只係睇數據嘅留存，而係持續願意同步自己嘅數據，因為呢個會帶動返嚟睇。
1D 留存：89%（工作日），70%（週末） 7D 留存：87.5%
呢兩個指標驅動緊 Vibe Usage 嘅持續增加，更加要多謝所有提過回饋同 Vibe42 想法嘅用戶們，亦都歡迎大家繼續支持！
使用連結：https://vibecafe.ai/usage
過去1年的Vibe創作實踐，讓我有意識的改變了自己做產品的思維，從 我想做什麼 改成 找到用戶，用戶要什麼就做什麼 。但後面很長時間也沒有做出什麼太好的產品，直到 Vibe Usage 讓我再次實踐這個理念。
一開始為什麼要做 Vibe Usage
初衷很簡單，年初的時候，Glowin 和我意識到普遍的 Vibe 愛好者 和真實的 Vibe 實踐者 之間是有壁的，大家的認知，真實使用 AI、Vibe、模型、Agent 的程度和濃度是不同的。因此，我們在服務號 Vibe Friends 裏多元的 Vibe 愛好者的同時，想要挖掘出裏面比較 Serious 的實踐者。
這個初衷催生了 $999 俱樂部 ，甚至有點“粗暴”地用每個月消耗的 Token 來去識別更全力在用 Vibe Coding 的一羣人。這個篩選方式當然也被「吐槽」過，但從目前聚集到的 $999 俱樂部的成員所交流的內容來看，確實和大眾的愛好者有顯著的差異性。包含但不限於：
大家並不會浪費太多時間討論哪個模型、工具好，更多是實踐出真知 大家極少過度討論某個想法的“創意”，而是更多落腳在有沒有真實用戶上 大家也會更嚴肅但是真誠的質疑彼此做的產品，不吝嗇坦誠帶來的有效信息
也依託於此，參考了類似 ccusage 的產品後，決定做一個 Vibe Usage 來幫大家統計好自己的 Token 消耗。從決定搞，到第一個版本上線我用 4 天。
充分實踐「用戶想要 · 用戶得到」
在做 Vibe Usage 的過程，我很 Vibe，也就是說想清楚了讓 Claude 一把梭好。去年底，我對 Vibe 最重要的認知就是找用戶 > 做產品。這半年又有了新的理解，就是 聽用戶要什麼 > 自我思考。
簡言之，Vibe 的理念不只是某種創作的自由，而是一種儘快地形成正循環：
找到用戶
→ 聽用戶要什麼
→ 做出來（可以是demo也可以是產品）驗證
→ 數據增長（最好是收入，起碼也得是留存）
建用戶羣，聽到「用戶想要」的心聲
因此，在 Vibe Usage 上線的第一天起，我就通過 Vibe Friends 羣和一些朋友的羣裏簡單介紹了第一版的功能，然後快速拉了個 /usage 用戶羣，即使是最早的版本，很明顯有非常多需要優化的地方。我也用不停地在羣裏問大家來確認用戶們要什麼。
這個過程不是簡單的詢問，而是你要充分理解大家的反饋：
羣裏沒有反應 → 99% 沒用 有1-2人說OK → 就是不積極，就是需求不強烈 好幾個人說不錯 → 應該需求是存在的，很值得放到 To Do 裏了，如果簡單就立刻上線 大家回覆積極（甚至吐槽的積極） → 99% 說明有真需求，要藉着大家的積極問清楚更多細節，簡化自己的方案，做到用戶的心坎上
就是這麼簡單，就通過這羣來做需求
用 Vibe42 來實現「用戶想要 · 用戶得到」
後面，我把這個聽用戶反饋，到開發上線的留存。做成了 Vibe42 自動迭代維護的系統（大家可以誇張地叫它啥自我迭代、Harness，但其實就是用戶要什麼就去分析做什麼），簡言之就是可以在產品的右上角「想法」裏提交你覺得需要。然後我就簡單設計了這麼幾步：
Analysis ：Agent 會分析用戶反饋、找一下相關數據、文檔和代碼、然後看下最近有沒有人提了同類的，形成分析結論的 md 文字。Product ：Agent 基於用戶反饋和分析結論，參考文檔和代碼，決策是否做，如果做就具體輸出需求文檔 PRD 的 md 文字Dev ：套着一個 Claude Code，Product Agent 決定做且我審核可以做之後，就在一個 Sandbox 裏開始具體的開發了，開發質量最大的依賴就是完整的項目文檔（不只是 AGENTS.md，我寫了非常多），如果修改完了，就會直接發 Pull Request 我來審核人 ：我還是會看下 Pull Request，改動大就本地跑一下，沒問題就 merge 了，然後就自動上線。
這個流程裏只有產品決策和 Pull Request 還需要我，當然產品決策這一步我覺得之後可以不用了。到目前為止已經有累計 164 個想法被執行過了。
但是，依然會有自己的「判斷」
利用好用戶羣、利用好「想法」自動迭代，是一種理念的實踐。但這個過程中依然需要人的判斷，不是具體的實現，而是產品結構、風格的統一性。
PHILOSOPHY.md：我在文檔裏會有這樣的一個類似 principles 的文件，它不是我空口寫出來的一堆產品的判斷依據，而是在 Vibe42 每次自己的寫完的 pull request 和我精修之後，做對比總結出來的。這些我無法明文寫清楚的，我對於軟件、系統的審美被這個文件很好的抽象出來了，也算是對我自己的”蒸餾“。就是我覺得不對 ：有個需求就是希望 Vibe Usage 支持隊伍，我一直都覺得 Vibe Usage 是個 AI 工具統計的定位，圍繞的是一個人對自己使用的瞭解，排行榜也突出的是 Top 消耗的個人。這個定位裏對於隊伍的 PK 感覺不太對。我沒有想好，不一定未來不會做，只是目前我的判斷裏感覺它不太需要，或者說會抑制每個人自己繼續用下去。
用戶數據
基於這種模式，Vibe Usage 持續優化了 1 個月了，我最關心的是指標不只是看數據的留存，而是持續願意同步自己數據，因為這個會帶動回來查看。
1D 留存：89%（工作日），70%（週末） 7D 留存：87.5%
這兩個指標驅動着 Vibe Usage 的持續增加，更要感謝所有提過反饋和 Vibe42 想法的用戶們，也歡迎大家繼續支持！
使用連結：https://vibecafe.ai/usage