P02 · 0:30–1:00
02 / 30
先快速介紹背景。mojo 是一個 GLP-1 體重管理 App。打 GLP-1 藥物的人用它追蹤體重、飲食、副作用，還有跟 AI 聊天。
老實說，我真的很享受用 AI 開發 App 的過程。看著它一點一點變成我想要的形狀，真的很開心。
但做一個 App，在 2025 年其實不算最難的。難的是接下來的事。P03 · 1:00–2:00
03 / 30
老實說，開發到上架這段其實滿順利的。
我用個人 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 / 30
先講內容這條 loop 是怎麼長出來的。
我自己是打針的人，滑 Threads 的時候發現一件事：很多人在討論猛健樂，副作用、劑量、心得，一大堆。這個話題本來就有人在聊，我只是還沒加入進去。
所以我開了一個 Threads 帳號，決定每天發一篇。
【Reveal：agent 動筆前的參考】
每天一篇，但動筆的不是我，是 agent。它動筆之前，手上攤開的是這些：我定義的語氣光譜，該溫柔還是機靈、坦率到什麼程度；三個使用者 persona，小安、阿莉、小真，每一篇都先想好寫給誰；還有幾條鐵律，同理心優先、不做醫療診斷。它不是空手在生成，是帶著一整套我設計的品味在寫。
實際的內容 pipeline，拆成九個步驟：分析、策略、素材、規劃、撰寫、品檢、配圖、定稿到排程。
看到那些空心圓圈嗎？那是 human-in-the-loop，需要我點頭才會往下走。月度規劃跑全套，週度從素材開始，單篇從規劃開始。
【Reveal：真實貼文】
這是它跑完整條流程、我簽核後發出去的一則貼文。不是我寫的，是 AI 寫的，但品味是我把關的。P07 · 5:00–5:45
Threads 海巡
07 / 30
Content Pipeline 是我主動發文。但後來我發現，Threads 上更有效的做法，不一定是一直發自己的內容，而是去找到已經在討論這件事的人。
所以我做了 Threads 海巡。Agent 每天搜尋相關討論，先判斷我是不是真的能提供價值，再產生適合那段對話的回覆。不是亂留言，也不是硬塞廣告，是在對的討論裡出現。
結果，海巡回覆帶來的觸及和導流，常常比我自己發一篇貼文還高。P08 · 5:45–6:30
LINE 群組
08 / 30
Threads 之外，這個族群還有一個特點：夠精準，精準到有很多專門的 LINE 群在討論同一件事，聊副作用、聊劑量、聊心情。
我把找得到的全部申請加進去。不是為了打廣告，是想知道這群人真正在煩惱什麼。一開始我的 distribution channel，就 Threads 和 LINE 兩個。
這些群後來變成很重要的東西，不只是內容靈感來源，接下來還有另一個用途。P11 · 7:45–8:45
但是
11 / 30
300 個人在用。但每天早上醒來第一件事，是打開後台看昨天的數字。有時候 20 個人付費，覺得今天可以活。有時候 0 個，完蛋了，要倒閉了。
然後你一邊盯著那個數字，一邊要回客服信、想今天 Threads 要發什麼、處理有人在洗邀請碼。
【reveal：Gmail 列表 → Gmail 內文】
客服不是一封信。是一直進來的各種問題，而且每一封都要理解、查資料、回覆。
【reveal：Threads 熱門貼文 → 1055 followers → 帳號被封 → 12 followers】
然後某天，Threads 把我封了。1000 個粉絲，一夜之間不見。Meta 沒給任何理由。
我去問人，得到的回應是——「Threads 本來就不能商用啊」、「一定是你寫了什麼奇怪的內容吧」、「你是不是偷偷做了什麼違反規範的事」。你們做 iOS 開發的一定懂，Apple 至少告訴你 Guideline 幾點幾被拒。Meta 連原因都不給，然後身邊的人還覺得是你的問題。
被封兩個禮拜都沒解鎖。最後我想，算了，放棄 1000 個粉絲，換新帳號從零開始。P12 · 8:45–9:15
看來，我需要接更多水管
12 / 30
看來，我需要接更多水管。P13 · 9:15–10:00
由 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."
→
正在研究整合中
13 / 30
但 mojo 的使用者還在，我後來還是回來了。
前面在社群聽的是還沒用 mojo 的人，人進來之後，要聽的變成已經在用的人。
人多了之後，麻煩也變多，客服是第一個扛不住的。這次我不只接水管，我把整條流程接成閉環：信進來、查資料庫、草擬回覆、發出去，水從頭流到尾，中間不用經過我搬。技術型問題像查訂閱狀態，幾乎全自動。
比較有趣的是這位英國用戶。她停經了但覺得 mojo 好用，只是希望把月經追蹤藏起來。下一版我們就加了 toggle。這種 case 不只是客服，它直接進了 roadmap，同一個 loop，不同的 gate 位置：一個全自動回覆，一個進產品需求。P15 · 10:45–11:35
自動化 Email 行銷
/mojo-plunk
15 / 30
上一頁是使用者告訴我，這一頁換我主動推。
許願池解決了「做什麼」，但轉換率還是要靠溝通去衝。這條我交給 Email。
mojo 的自然轉換大概 9%，就是使用者自己想升級的比例。Drip marketing 不會憑空生出使用者，但可以在這 9% 之上，多撬出一些原本會流失的轉換機會。
使用者記錄到第幾天、該推什麼、用什麼語氣，我寫成一條工作流。
【reveal：行銷信模板】
這封「你已經記錄 4 天，現在升級有早鳥價」就是 agent 全自動產出的。從觸發、撈數據、寫文案到排版，我沒有一封一封手寫。做一次，之後每個使用者都跑得到。P16 · 11:35–12:50
我還是 bottleneck
16 / 30
但這裡有一件事我一直沒好意思講。
mojo 的轉換其實不錯，收入也比我想的好很多。但我沒日沒夜、一個人當十個人用。真的把時薪換算下來，大概只有我以前上班的十分之一。
前面講的這些自動化，其實就是我在各處接水管。內容、海巡、LINE、社群傾聽、邀請碼、客服、許願池、email，每一條管子裡的水都流得動。AI 是水，它有的是力氣。
但我的管路東一段、西一段，彼此沒有接起來。斷掉的地方，全是我自己拿桶子在搬水：寫作那條的水，我搬去品管；品管完的，我搬去排程。水管越多，我搬得越兇。
不應該是這樣的。
【Reveal：三階梯圖】
後來我才看懂，這件事其實有三個階段。第一階，接水管：讓 AI 替你做事，半夜你睡覺，它們忙。第二階，把水管接成閉環：整條流程自己流完，你只顧閥門。第三階，讓 AI 也來當水電工：接管線、修漏水都交給它們，你退一步，設計整個管網、控管全局。
我那時候卡在第二階：閉環有了幾條，但管線跟管線之間，還是我在搬水。至於第三階長什麼樣子，我根本還不知道。P17 · 12:50–13:50
因為一個 bug，它們開始互相講話
17 / 30
然後有一天，出了一個 bug。訊息路由壞了——本來每個 agent 只能看到自己的任務，結果它們突然看到彼此的對話。
我一開始覺得完蛋了，趕快去修。但修之前我看了一眼它們在幹嘛。
寫作 agent 寫完，品管 agent 直接接過去看，改完自己丟給排程。沒有人叫它這樣做，它只是看到了前面的工作，就知道下一步該做什麼。
那一刻我才懂，這就是第三階：不是我把每條水管接好，是讓它們互相把水接過去。這不是 bug，這是 feature。P21 · 15:05–15:50
期望
結果
21 / 30
然後現實打臉了。這是圖片 review 的案例。左邊是我期望的審核品質，右邊是實際結果。
reviewer agent 看起來有 review，但它沒拿原始 brief 對照、沒有我的偏好、沒有明確的 fail criteria。結果就是多了一個很有禮貌的點頭觀眾。P22 · 15:50–16:35
Support 收到問題
→
轉給 Engineer
→
Fix?
→
22 / 30
第二個失敗更可怕：客服 case 死在半路。客服 agent 發現問題、tag 了工程師，工程師也真的查了、甚至可能修了。然後呢？case 靜靜停在半路。使用者永遠沒收到回覆，客服沒有 close。
這種失敗不會爆炸，它是安靜的。安靜比爆炸更危險。P23 · 16:35–17:35
讓他們真的可以溝通
Identity
要和誰溝通？
Visibility
誰看得到訊息？
Triggering
如何呼叫對方？
Suppression
如何停止回應？
Delivery
哪些頻道可溝通？
≠ Collaboration
23 / 30
踩過這些坑之後我把整套系統拆成三層。
第一層 Communication Stack：先解決誰看得到、誰該回、怎麼呼叫、怎麼不回。但光有溝通管道，不等於有協作能力。
第二層 Harness，這是關鍵。Trigger 決定什麼時候叫誰進來，Context 決定被叫來的人要看到什麼，Review 決定什麼才叫真的 review，Ownership 決定誰負責到底，Stale Detection 讓卡住的 case 自己浮上來，Escalation 決定什麼時候該找人或找別的 agent 來修。假審核和流程斷層，就是因為少了 Review 和 Ownership。
第三層 Workflow：不同的問題要長出不同的 team shape。內容排程是 strategist → writer → reviewer → scheduler，客服 bug 是 support → engineer → verifier → reply。P24 · 17:35–18:05
建立組織架構
/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 修復
24 / 30
有了三層架構，agents 就形成一個真正的組織。我在最上面，負責 intent、taste、風險判斷和最終決策。下面四個 PM 各帶團隊：mojo 管品牌社群，nana 是我的數位分身管文章和簡報，innie 管開發，solo 管產品。底下還有 doctor，跨團隊負責修 harness，哪條水管壞了，來修的也是 AI。P27 · 18:55–19:35
從水電工變成工頭
27 / 30
還記得前面那張圖嗎？管路東一段、西一段，我自己站在中間，當那段缺的管子。
現在不一樣了。水管不只接起來，還長成了一片管網：內容、客服、回饋，環跟環互相接，水自己在裡面流。而且管線上有別的水電工了，只是它們不是人。
【reveal：水管冒出裂縫，agent 正在修】
水管還是會壞，上週排程就斷過一次。但壞掉那段，是它們自己發現、自己修好的，我只看了一眼通知。第三階就是這樣：接水管的、修水管的，都是 AI。P30 · 21:10–21:25
Hana 花水木 · hanamizuki.tw
水該流去哪
只有你知道
只有你知道
AI 有的是力氣。方向，還是你的工作。
@hanamizuki
30 / 30
回到開場的問題：App 上架之後呢？
上架之後的這七個月，我學會的不是更多 Swift。老實講，我到今天還是不太算 iOS 開發者。但我從自己搬水，做到水電工，現在勉強算個工頭，手下是一班 AI 水電工。
接水管，現在連 AI 都學得會。但水該流去哪，只有你知道。
我是花水木 Hana，謝謝大家。