P02 · 0:30–1:00
02 / 31
先快速介紹背景。mojo 是一個 GLP-1 體重管理 App。打 GLP-1 藥物的人用它追蹤體重、飲食、副作用，還有跟 AI 聊天。
老實說，我真的很享受用 AI 開發 App 的過程。看著它一點一點變成我想要的形狀，真的很開心。
但做一個 App，在 2025 年其實不算最難的。難的是接下來的事。P03 · 1:00–2:00
03 / 31
老實說，開發到上架這段其實滿順利的。
我用個人 Threads 帳號問有沒有人想試，開了 Google 表單，用永久免費當誘因。三週，140 個人報名封測，真正有在測的大概 80 個，每天都會打開 App 的？30 個。
開發那幾個月，用這個 App 的人就只有我自己。所以某天突然看到 30 個人同時在線上，我又恐慌又興奮。恐慌跟興奮是同一個原因，天啊，真的有人在用了。
我還在 LINE 開了群組，30 幾個人每天聊打針的心情。族群夠精準，這個群組才有價值。那時候我對這個數字很滿意。上線當天更是，馬上就有 2 個人付費，我心想，穩了，要一炮而紅了。P06 · 3:30–5:00
自動化內容工作流
01
分析
/analysis02
策略
/strategy03
素材
/scout04
規劃
/planner05
撰寫
/writing06
品檢
/review07
配圖
/image08
定稿
/finalize09
排程
/schedule月度
週度
單篇
= human in the loop
06 / 31
先講內容這條 loop 是怎麼長出來的。
我自己是打針的人，滑 Threads 的時候發現一件事：很多人在討論猛健樂，副作用、劑量、心得，一大堆。這個話題本來就有人在聊，我只是還沒加入進去。
所以我開了一個 Threads 帳號，決定每天發一篇。
實際的內容 pipeline，拆成九個步驟：分析、策略、素材、規劃、撰寫、品檢、配圖、定稿到排程。
看到那些空心圓圈嗎？那是 human-in-the-loop，需要我點頭才會往下走。月度規劃跑全套，週度從素材開始，單篇從規劃開始。
【Reveal：真實貼文】
這是它跑完整條流程、我簽核後發出去的一則貼文。不是我寫的，是 AI 寫的，但品味是我把關的。
【Reveal：愚人節影片】
影片也是同一條 pipeline 的產物。輪到這個 reveal 時會自動從頭播放。P07 · 5:00–5:45
Threads 留言
07 / 31
Content Pipeline 是我主動發文。但後來我發現，Threads 上更有效的做法，不一定是一直發自己的內容，而是去找到已經在討論這件事的人。
所以我做了 Threads 海巡。Agent 每天搜尋相關討論，先判斷我是不是真的能提供價值，再產生適合那段對話的回覆。（進頁即顯示：海巡執行結果）
【reveal ①：留言掃描與代發草稿】
掃到的留言它會整理成一份報告，每一則都附上建議回覆。我看過、點頭，它才發出去。
【reveal ②：實際回覆案例一】
【reveal ③：實際回覆案例二】
這是實際發出去的樣子。不是亂留言，也不是硬塞廣告，是在對的討論裡出現。
結果，海巡回覆帶來的觸及和導流，常常比我自己發一篇貼文還高。P08 · 5:45–6:00
08 / 31
Threads 海巡與內容 pipeline 持續運作後，帳號累積到一千多位 followers。這不是爆紅，但代表這套獲客水管真的開始有水流進來。P09 · 6:00–6:45
LINE 群組
09 / 31
Threads 之外，這個族群還有一個特點：夠精準，精準到有很多專門的 LINE 群在討論同一件事，聊副作用、聊劑量、聊心情。
我把找得到的全部申請加進去。不是為了打廣告，是想知道這群人真正在煩惱什麼。一開始我的 distribution channel，就 Threads 和 LINE 兩個。
這些群後來變成很重要的東西，不只是內容靈感來源，接下來還有另一個用途。P12 · 8:00–9:00
但是
12 / 31
300 個人在用。但每天早上醒來第一件事，是打開後台看昨天的數字。有時候 20 個人付費，覺得今天可以活。有時候 0 個，完蛋了，要倒閉了。
然後你一邊盯著那個數字，一邊要回客服信、想今天 Threads 要發什麼、處理有人在洗邀請碼。
【reveal：Gmail 列表 → Gmail 內文】
客服不是一封信。是一直進來的各種問題，而且每一封都要理解、查資料、回覆。
【reveal：App Store Ratings & Reviews 負評】
客服信以外，App Store 上的負評也會直接留下來。不是每個人都會先來找你，有些人會直接把不滿寫在公開頁面。
【reveal：App Store Connect submission issue】
然後 Apple 的審核與 submission 問題也會插進來。產品才剛開始有人用，我同時要顧使用者和處理平台規則。
【reveal：Google Play 下架警告】
不只 Apple。Google Play 也可能因為開發人員設定檔或政策問題，直接警告應用程式會被下架。
【reveal：Threads 帳號被永久停用】
然後某天，Threads 直接把我封了。永久停用，1000 個粉絲一夜之間全部不見。Meta 沒給任何理由。
我去問人，得到的回應是：「Threads 本來就不能商用啊」、「一定是你寫了什麼奇怪的內容吧」。你們做 iOS 開發的一定懂，Apple 至少會告訴你是 Guideline 第幾點被拒。Meta 連原因都不給，然後身邊的人還覺得是你的問題。
被封兩個禮拜都沒解鎖。最後我想，算了，放棄那 1000 個粉絲，換新帳號從零開始。
【reveal：Claude 帳號付款後遭停用】
連工作上依賴的 AI 帳號，都可能在付完款之後突然被停用。這些事情彼此沒有關係，但最後全部都會流到我身上。P13 · 9:00–9:30
13 / 31
但鳥事不是全部。
同一段時間，也一直有人告訴我，她們真的喜歡 mojo：有人主動推薦給朋友、有人分享邀請碼、有人貼出自己的紀錄成果，也有人在群組裡替它說話。
這些回饋沒有讓前面的問題消失，但會提醒我，這個 App 確實有幫到人，所以我還是想把它繼續做下去。P14 · 9:30–10:15
由 Agent 處理客服
/mojo-support
查訂閱狀況
User · iOS
「想確認一下，我的訂閱狀況是正常的嗎？」
→
mojo-user-lookup 查 Supabase RPC
→
草稿：「您是 Premium，到 2026-05-15 續期，請放心。」
產品回饋
UK user · last week
"Could the period tracker be hidden?
I'm menopausal but still find mojo useful."
I'm menopausal but still find mojo useful."
→
下一版加了隱藏 toggle
UK user · follow-up
"What food apps sync to mojo?
I'd love more complete AI analysis."
I'd love more complete AI analysis."
→
正在研究整合中
14 / 31
但 mojo 的使用者還在，我後來還是回來了。
前面在社群聽的是還沒用 mojo 的人，人進來之後，要聽的變成已經在用的人。
人多了之後，麻煩也變多，客服是第一個扛不住的。這次我不只接水管，我把整條流程接成閉環：信進來、查資料庫、草擬回覆、發出去，水從頭流到尾，中間不用經過我搬。技術型問題像查訂閱狀態，幾乎全自動。
【reveal：客服流程影片】
這是實際跑一次的樣子：收到問題、查資料、草擬回覆，一條龍走完。
【reveal：產品回饋】
比較有趣的是這位英國用戶。她停經了但覺得 mojo 好用，只是希望把月經追蹤藏起來。下一版我們就加了 toggle。這種 case 不只是客服，它直接進了 roadmap，同一個 loop，不同的 gate 位置：一個全自動回覆，一個進產品需求。P15 · 10:15–11:00
需求、回饋到處都是
15 / 31
客服會告訴你使用者卡在哪裡，但回饋不只從客服來。有人寄 Email、有人在 LINE 群裡討論，也有人直接在許願池投票。
【reveal：許願池高票列表】
我把這些需求放進同一個許願池，讓使用者直接投票，想要哪個功能先做。
【reveal：Email 建議 → LINE 群組討論】
不同管道進來的聲音，不再只是散落的訊息，而是變成可以整理、比較和排優先順序的需求。
【reveal：Discord 自動同步 issue】
確認要做之後，需求會同步成 issue，排進開發流程。不是我關起門猜使用者要什麼，是他們直接告訴我。P16 · 11:00–11:50
自動化 Growth Hack
/mojo-analytics
/mojo-plunk
16 / 31
剛剛那些管道收回來的，不只是「他們想要什麼功能」。
誰什麼時候打開 App、記錄到第幾天就停了、卡在哪一步沒有升級，這些資料裡面都有。
這是我改版 onboarding 之後，agent 跑出來的新舊版對比。新版的核心漏斗完成率 76.3%，舊版 69.7%。哪一步掉了多少人，它算給我看。
【reveal：Email 自動化流程】
知道卡在哪，才知道要推什麼。使用者記錄到第幾天、該推什麼、用什麼語氣，我寫成一條工作流，交給 Email。
mojo 的自然轉換大概 9%，就是使用者自己想升級的比例。Drip marketing 不會憑空生出使用者，但可以在這 9% 之上，多撬出一些原本會流失的轉換機會。
【reveal：行銷信模板】
這封「你已經記錄 4 天，現在升級有早鳥價」就是 agent 全自動產出的。從觸發、撈數據、寫文案到排版，我沒有一封一封手寫。做一次，之後每個使用者都跑得到。P17 · 11:50–13:05
我還是 bottleneck
17 / 31
但這裡有一件事我一直沒好意思講。
mojo 的轉換其實不錯，收入也比我想的好很多。但我沒日沒夜、一個人當十個人用。真的把時薪換算下來，大概只有我以前上班的十分之一。
前面講的這些自動化，其實就是我在各處接水管。內容、海巡、LINE、社群傾聽、邀請碼、客服、許願池、email，每一條管子裡的水都流得動。AI 是水，它有的是力氣。
但我的管路東一段、西一段，彼此沒有接起來。斷掉的地方，全是我自己拿桶子在搬水：寫作那條的水，我搬去品管；品管完的，我搬去排程。水管越多，我搬得越兇。
不應該是這樣的。
【Reveal：三階梯圖】
後來我才看懂，這件事其實有三個階段。第一階，接水管：讓 AI 替你做事，半夜你睡覺，它們忙。第二階，把水管接成閉環：整條流程自己流完，你只顧閥門。第三階，讓 AI 也來當水電工：接管線、修漏水都交給它們，你退一步，設計整個管網、控管全局。
我那時候卡在第二階：閉環有了幾條，但管線跟管線之間，還是我在搬水。至於第三階長什麼樣子，我根本還不知道。P18 · 13:05–14:05
因為一個 bug，它們開始互相講話
18 / 31
然後有一天，出了一個 bug。訊息路由壞了——本來每個 agent 只能看到自己的任務，結果它們突然看到彼此的對話。
我一開始覺得完蛋了，趕快去修。但修之前我看了一眼它們在幹嘛。
寫作 agent 寫完，品管 agent 直接接過去看，改完自己丟給排程。沒有人叫它這樣做，它只是看到了前面的工作，就知道下一步該做什麼。
那一刻我才懂，這就是第三階：不是我把每條水管接好，是讓它們互相把水接過去。這不是 bug，這是 feature。P20 · 14:35–15:20
期望
結果
20 / 31
然後現實打臉了。這是圖片 review 的案例。左邊是我期望的審核品質，右邊是實際結果。
reviewer agent 看起來有 review，但它沒拿原始 brief 對照、沒有我的偏好、沒有明確的 fail criteria。結果就是多了一個很有禮貌的點頭觀眾。P21 · 15:20–16:05
Eval Loop
/content-review
Agent 產出
→
我評分
→
寫回判準
→
下次更準
每一次評分，都變成下一次的判準
21 / 31
那怎麼辦？我做了一件事：不再只看它有沒有交件，而是每一篇我都給它打分。
好在哪、爛在哪、為什麼被打回，全部寫回它的判準裡。
下一次它再寫，手上就多了我上次的標準。這條迴圈跑久了，它的品味會越來越靠近我的。
這就是 Eval Loop：評分不是為了打分數，是為了讓判準長出來。
【reveal：實際的評分畫面】
實際操作長這樣。它把草稿貼上來，我用 emoji 打分：✅ 過、👎 不行。它收到之後會自己去讀規則檔，把這次的回饋寫進判準裡。
講清楚一件事：我沒有在訓練模型，一個權重都沒動。我只是在寫規則。P23 · 16:35–17:35
23 / 31
第二個失敗更可怕：客服 case 死在半路。客服 agent 發現問題、tag 了工程師，工程師也真的查了、甚至可能修了。然後呢？case 靜靜停在半路。使用者永遠沒收到回覆，客服沒有 close。
這種失敗不會爆炸，它是安靜的。安靜比爆炸更危險。
【reveal：Stale Detection】
所以我補了一件事：讓 agent 定期回頭巡一遍，超過時限還沒 close 的，撈回來重推。
卡住的 case 不會自己喊救命，那就固定回去點名。這個叫 Stale Detection。P24 · 17:35–18:15
讓他們真的可以溝通
Identity
要和誰溝通？
Visibility
誰看得到訊息？
Triggering
如何呼叫對方？
Suppression
如何停止回應？
Delivery
哪些頻道可溝通？
≠ Collaboration
24 / 31
剛剛那幾個補丁，其實不是各自獨立的。
Eval Loop、Escalation、Stale Detection，是同一套東西的三個面向。我後來把它整理成三層。
最底下 Communication，處理誰看得到、誰該回、怎麼呼叫。
中間 Harness，剛剛講的那三個都住在這層，旁邊還有 Trigger、Context、Ownership。agent 會不會爛尾，全看這層有沒有搭好。
最上面 Loop，不同的問題，長出不同的閉環。內容有內容的 loop，客服有客服的 loop。
這三層我不逐個拆解。你只要記得一件事：前面每一個坑，最後都變成這張圖上的一格。P25 · 18:15–18:45
建立組織架構
/claude-discord-bot
/agent-collab
Hana
Intent / Taste / Risk / Final Decision
mojo
PM · 品牌社群
dev 工程
data 數據
marketer 內容
bd 合作
nana
PM · 數位分身
editor 文章
designer 簡報
innie
PM · 開發助手
solo
PM · 產品管理
doctor
跨團隊 · harness 修復
25 / 31
有了三層架構，agents 就形成一個真正的組織。我在最上面，負責 intent、taste、風險判斷和最終決策。下面四個 PM 各帶團隊：mojo 管品牌社群，nana 是我的數位分身管文章和簡報，innie 管開發，solo 管產品。底下還有 doctor，跨團隊負責修 harness，哪條水管壞了，來修的也是 AI。P28 · 19:35–20:15
從水電工變成工頭
28 / 31
還記得前面那張圖嗎？管路東一段、西一段，我自己站在中間，當那段缺的管子。
現在不一樣了。水管不只接起來，還長成了一片管網：內容、客服、回饋，環跟環互相接，水自己在裡面流。而且管線上有別的水電工了，只是它們不是人。
【reveal：水管冒出裂縫，agent 正在修】
水管還是會壞，上週排程就斷過一次。但壞掉那段，是它們自己發現、自己修好的，我只看了一眼通知。第三階就是這樣：接水管的、修水管的，都是 AI。P29 · 20:15–21:05
30 → 3000
29 / 31
開場那 30 個人，變成 3,000 多個活躍使用者，12,000 次下載。
【reveal ①：App Store】App Store 健康類排名，最高第 10 名。147 個評分，平均 4.9 分。
【reveal ②：Threads】Threads 光是最近 30 天，觀看數就 110 萬。
【reveal ③：收入截圖】收入也是。
這張是單月，而且只有 iOS 的部分。我的 iOS 收入，大概只有 Android 的五分之一。
以一個獨立開發者來說，老實說，比我一開始想的好很多。P30 · 21:05–21:50
30 / 31
這些數字，一年前的我想都不敢想。一個人，沒有團隊，七個月。
差別在哪？以前我們用工具，是加法。好用的 IDE、好的 framework，幫你多做一點，加 10%、加 20%。
AI 不一樣，它是乘法。你投入的每一分時間、每一個判斷，它直接乘上好幾倍。同樣是寫一篇文的功夫，乘出來是一條每天自己跑的內容 pipeline；同樣是回一封信的時間，乘出來是每封客服信都有人接。
剛剛那些數字，就是這樣乘出來的。不是我變強了，是我做的每件事都被乘過。
只是乘法有個特性：0 乘以多少，都是 0。AI 是那個乘數，但被乘的，是你。P31 · 21:50–22:05
Hana 花水木 · hanamizuki.tw
水該流去哪
只有你知道
只有你知道
AI 有的是力氣。方向，還是你的工作。
@hanamizuki
31 / 31
回到開場的問題：App上架之後呢？
上架之後的這七個月，我學會的不是更多 Swift。老實講，我到今天還是不太算 iOS 開發者。但我從自己搬水，做到水電工，現在勉強算個工頭，手下是一班 AI 水電工。
接水管，現在連 AI 都學得會。但水該流去哪，只有你知道。
我是花水木 Hana，謝謝大家。