P02 · 0:30–1:00
做 APP 好容易，
可是營運好難
02 / 31
先快速介紹背景。mojo 是一個 GLP-1 體重管理 App。打 GLP-1 藥物的人用它追蹤體重、飲食、副作用，還有跟 AI 聊天。
老實說，我真的很享受用 AI 開發 App 的過程。看著它一點一點變成我想要的形狀，真的很開心。
但做一個 App，在 2025 年其實不算最難的。難的是接下來的事。P03 · 1:00–2:00
App 終於上架了！
但使用者
只有小貓兩三隻⋯
只有小貓兩三隻⋯
03 / 31
老實說，開發到上架這段其實滿順利的。
我用個人 Threads 帳號問有沒有人想試，開了 Google 表單，用永久免費當誘因。三週，140 個人報名封測，真正有在測的大概 80 個，每天都會打開 App 的？30 個。
開發那幾個月，用這個 App 的人就只有我自己。所以某天突然看到 30 個人同時在線上，我又恐慌又興奮。恐慌跟興奮是同一個原因，天啊，真的有人在用了。
我還在 LINE 開了群組，30 幾個人每天聊打針的心情。族群夠精準，這個群組才有價值。那時候我對這個數字很滿意。上線當天更是，馬上就有 2 個人付費，我心想，穩了，要一炮而紅了。P04 · 2:00–3:00
上架 ≠ 有人用
50
TestFlight 封測者
2
付費使用者，應該是朋友
7
天內沒有新增付費
04 / 31
然後，過了一週。DAU 還是 30。付費的還是那 2 個人。
過了兩週。還是一樣。
我才發現：上架不等於有人用。報名 140 個很漂亮，但真正每天回來的就 30 個，而且再也沒往上。這 30 個人，全部是我自己一個一個邀來的。P06 · 3:30–5:00
自動化內容工作流
01
分析
/analysis02
策略
/strategy03
素材
/scout04
規劃
/planner05
撰寫
/writing06
品檢
/review07
配圖
/image08
定稿
/finalize09
排程
/schedule月度
週度
單篇
= human in the loop
06 / 31
先講內容這條 loop 是怎麼長出來的。
我自己是打針的人，滑 Threads 的時候發現一件事：很多人在討論猛健樂，副作用、劑量、心得，一大堆。這個話題本來就有人在聊，我只是還沒加入進去。
所以我開了一個 Threads 帳號，決定每天發一篇。
【Reveal：agent 動筆前的參考】
每天一篇，但動筆的不是我，是 agent。它動筆之前，手上攤開的是這些：我定義的語氣光譜，該溫柔還是機靈、坦率到什麼程度；三個使用者 persona，小安、阿莉、小真，每一篇都先想好寫給誰；還有幾條鐵律，同理心優先、不做醫療診斷。它不是空手在生成，是帶著一整套我設計的品味在寫。
實際的內容 pipeline，拆成九個步驟：分析、策略、素材、規劃、撰寫、品檢、配圖、定稿到排程。
看到那些空心圓圈嗎？那是 human-in-the-loop，需要我點頭才會往下走。月度規劃跑全套，週度從素材開始，單篇從規劃開始。
【Reveal：真實貼文】
這是它跑完整條流程、我簽核後發出去的一則貼文。不是我寫的，是 AI 寫的，但品味是我把關的。P12 · 8:30–10:00
但其實，我好像才是那個 Agent
12 / 31
300 個人在用。但每天早上醒來第一件事，是打開後台看昨天的數字。有時候 20 個人付費，覺得今天可以活。有時候 0 個，完蛋了，要倒閉了。
【reveal：後台數字】
然後你一邊盯著那個數字，一邊要回客服信、想今天 Threads 要發什麼、處理有人在洗邀請碼。
【reveal：StoreKit bug】
然後你發現——有 3 個使用者付了錢，但沒升級成 premium。StoreKit transaction 狀態有 bug。只有 1 個人寫信來問，另外 2 個默默忍受。你根本不知道他們付了錢卻什麼都沒拿到。
【reveal：Threads 封鎖截圖】
然後某天，Threads 把我封了。1000 個粉絲，一夜之間不見。Meta 沒給任何理由。
我去問人，得到的回應是——「Threads 本來就不能商用啊」、「一定是你寫了什麼奇怪的內容吧」、「你是不是偷偷做了什麼違反規範的事」。你們做 iOS 開發的一定懂，Apple 至少告訴你 Guideline 幾點幾被拒。Meta 連原因都不給，然後身邊的人還覺得是你的問題。
被封兩個禮拜都沒解鎖。最後我想，算了，放棄 1000 個粉絲，換新帳號從零開始。
那段時間我開始做下一個 App 了。因為做 App 比經營 App 快樂多了。P13 · 10:00–10:45
由 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 / 31
但 mojo 的使用者還在，我後來還是回來了。
前面在社群聽的是還沒用 mojo 的人，人進來之後，要聽的變成已經在用的人。
人多了之後，麻煩也變多，客服是第一個扛不住的。這次我不只接水管，我把整條流程接成閉環：信進來、查資料庫、草擬回覆、發出去，水從頭流到尾，中間不用經過我搬。技術型問題像查訂閱狀態，幾乎全自動。
比較有趣的是這位英國用戶。她停經了但覺得 mojo 好用，只是希望把月經追蹤藏起來。下一版我們就加了 toggle。這種 case 不只是客服，它直接進了 roadmap，同一個 loop，不同的 gate 位置：一個全自動回覆，一個進產品需求。P15 · 11:30–12:20
自動化 Email 行銷
/mojo-plunk
15 / 31
上一頁是使用者告訴我，這一頁換我主動推。
許願池解決了「做什麼」，但轉換率還是要靠溝通去衝。這條我交給 Email。
mojo 的自然轉換大概 9%，就是使用者自己想升級的比例。Drip marketing 不會憑空生出使用者，但可以在這 9% 之上，多撬出一些原本會流失的轉換機會。
使用者記錄到第幾天、該推什麼、用什麼語氣，我寫成一條工作流。
【reveal：行銷信模板】
這封「你已經記錄 4 天，現在升級有早鳥價」就是 agent 全自動產出的。從觸發、撈數據、寫文案到排版，我沒有一封一封手寫。做一次，之後每個使用者都跑得到。P17 · 13:35–14:35
因為一個 bug，它們開始互相講話
17 / 31
然後有一天，出了一個 bug。訊息路由壞了——本來每個 agent 只能看到自己的任務，結果它們突然看到彼此的對話。
我一開始覺得完蛋了，趕快去修。但修之前我看了一眼它們在幹嘛。
寫作 agent 寫完，品管 agent 直接接過去看，改完自己丟給排程。沒有人叫它這樣做，它只是看到了前面的工作，就知道下一步該做什麼。
那一刻我才懂，這就是第三階：不是我把每條水管接好，是讓它們互相把水接過去。這不是 bug，這是 feature。P21 · 15:50–16:35
期望
結果
21 / 31
然後現實打臉了。這是圖片 review 的案例。左邊是我期望的審核品質，右邊是實際結果。
reviewer agent 看起來有 review，但它沒拿原始 brief 對照、沒有我的偏好、沒有明確的 fail criteria。結果就是多了一個很有禮貌的點頭觀眾。P22 · 16:35–17:20
Support 收到問題
→
轉給 Engineer
→
Fix?
→
22 / 31
第二個失敗更可怕：客服 case 死在半路。客服 agent 發現問題、tag 了工程師，工程師也真的查了、甚至可能修了。然後呢？case 靜靜停在半路。使用者永遠沒收到回覆，客服沒有 close。
這種失敗不會爆炸，它是安靜的。安靜比爆炸更危險。P23 · 17:20–18:20
讓他們真的可以溝通
Identity
要和誰溝通？
Visibility
誰看得到訊息？
Triggering
如何呼叫對方？
Suppression
如何停止回應？
Delivery
哪些頻道可溝通？
≠ Collaboration
23 / 31
踩過這些坑之後我把整套系統拆成三層。
第一層 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 · 18:20–18:50
建立組織架構
/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 / 31
有了三層架構，agents 就形成一個真正的組織。我在最上面，負責 intent、taste、風險判斷和最終決策。下面四個 PM 各帶團隊：mojo 管品牌社群，nana 是我的數位分身管文章和簡報，innie 管開發，solo 管產品。底下還有 doctor，跨團隊負責修 harness，哪條水管壞了，來修的也是 AI。