不熟悉 Swift 與 Kotlin 的人，也可以用 AI 做出有真實使用者的雙平台 App，但要維持品質，靠的不是一次寫得好，而是一套讓 AI 每次都照著做的工作制度。我訪談的獎金獵人共同創辦人 Hana，在 AI 協助下完成了 GLP-1（猛健樂）使用者專用的 App「mojo」。她的核心做法是：每修完一個 bug 或完成一個功能，就要求 AI 回顧原因，把學到的規則寫進專案設定檔，或把正確流程封裝成 Skill，讓專案「記得」這次教訓。
mojo 是什麼？Hana 做到了什麼？
mojo 是 Hana 做的 GLP-1 用藥者 App；她不熟 Swift 與 Kotlin，仍靠 AI 完成 iOS 與 Android 版本。
Hana 是獎金獵人的共同創辦人，後來加入加密貨幣公司擔任營運長，負責 DeFi 相關產品。2025 年，她停掉手邊大部分工作，全心鑽研 AI 開發與創作。
mojo 可以自動抓取 Apple 健康的資料，包括體重、體脂、飲食、運動、睡眠與生理期，並用 AI 分析目前的減重狀況，每次偵測到新資料時主動給回饋與調整建議。受訪時（2025 年底），iOS 與 Android 版都已推出。她自述註冊使用者約一萬多人，付費用戶約一千人（受訪當時訂閱中的人數）。
依 App Store 頁面，mojo 的開發者署名為 Hana Chang，支援英文、簡體中文與繁體中文，頁面並聲明這是獨立開發的應用程式，與 GLP-1 藥物製造商沒有關聯或背書關係（App Store，mojo 頁面）。App Store 頁面沒有顯示使用者或付費人數，因此上述人數仍只是受訪者的自述。
她形容第一次用 Vibe Coding 做出 mojo 的感覺：「就像突然長出翅膀。原本不會飛，但現在可以飛了。」
她也說明了 AI 的占比：mojo 第一個版本約有 90% 由 AI 撰寫，最新版本接近 99%。本文不評論 App 的醫療效果，只整理她的開發方式。
她用哪些 AI 工具？各自負責什麼？
Claude Code 負責開發、測試與部署；OpenAI Codex 與 Cursor 專做 code review；社群發文另用 Antigravity。
| 用途 | 工具 | 做什麼 |
|---|---|---|
| 主力開發 | Claude Code | 前後端開發、測試與測試撰寫、code review（程式碼審查）、CI/CD（持續整合與持續部署）建立、查 log、伺服器部署管理 |
| Code review | OpenAI Codex、Cursor | 沿著新增或修改的程式碼，探索現有程式碼中可能相關、受影響的邏輯 |
| 社群文章 | Antigravity、Claude、Gemini | Claude 負責內容策略與文案，Gemini 負責圖片生成 |
她最信任 Codex 與 Cursor 做 code review，原因是它們能順著這次修改，去找現有程式裡可能受影響的邏輯，甚至找出「改 A 壞 B」，或因多執行緒執行順序造成的偶發錯誤。Anthropic 的官方文件也有類似的觀察：在全新的上下文中審查，AI 不會偏向自己剛寫的程式碼（Anthropic，Claude Code Best practices）。Hana 沒有說明她選擇不同工具的完整理由，這裡只引用她對 Codex 與 Cursor 能力的描述。
她怎麼把 AI 的工作流程變成制度？
Hana 把常用的開發流程寫成標準化指令，讓 AI 在適當時機自動執行，而不是每次從零開始思考，藉此降低失誤、提高效率、減少反覆溝通。
她在產品開發上的做法如下。
| 階段 | 制度化的做法 |
|---|---|
| 規劃新功能 | 先由 AI 做結構化分析，釐清影響範圍與實際價值，避免衝動開發 |
| 功能確定後 | AI 同步推進不同平台版本的開發，並自動檢查程式品質，減少返工 |
| 每次更新後 | AI 自動確認各平台版本是否正常運作，避免上線後才發現問題 |
| 系統出現異常 | AI 快速彙整各種紀錄資料，協助定位問題，不需要人工逐一排查 |
| 專案待辦 | 自動分類任務、標記完成狀態、移除重複或過時項目、重新排序優先順序 |
這些流程的共同點，是把「該做的檢查」寫在流程裡，而不是靠記得。
「不要只是修好問題，而是把問題制度化」是怎麼做的？
每完成功能或修完 bug，Hana 都要求 AI 回顧真正的成因與最佳做法，再把規則寫入 CLAUDE.md，或把正確流程封裝成 Skill，讓未來自動觸發。
這是她最核心的原則。回顧分四步：
- 分析這次問題的真正成因。
- 整理過程中學到的最佳做法。
- 把這些最佳實踐寫入 CLAUDE.md（專案設定檔）。
- 或把正確的流程封裝成一個 Skill，讓未來自動觸發。
她舉過一個例子。有些技術工具更新得非常快，規則常常改變，AI 有時會引用舊做法，雖然看起來能運作，卻已經不是最新、最安全的方式。她的做法不是每次人工檢查，而是把「如何查到最新官方做法」寫成自動流程，之後只要開發涉及相關技術，AI 就會先查最新官方文件，而不是憑印象或舊資料回答。每一次回顧都在強化專案的最佳實踐，下次遇到類似問題，AI 就不會從零開始犯同樣的錯。
要寫在 CLAUDE.md，還是做成 Skill？Anthropic 的官方文件對兩者有分工建議。
| 比較項目 | CLAUDE.md | Skill |
|---|---|---|
| 載入時機 | 每次對話開始都會載入 | 內容用到時才載入，平時成本很低 |
| 適合放什麼 | 廣泛適用、簡短的事實與規則，例如指令、程式風格、工作流程規則 | 一段已經變成流程的程序，或同樣的步驟一再貼給 AI |
| 官方的提醒 | 要精簡；太長時，真正重要的規則會被淹沒 | 當 CLAUDE.md 的某一段變成流程而不是事實時，改成 Skill |
| 是否強制 | 屬於上下文，不是強制設定 | 由 Claude 依描述判斷何時使用，或用指令直接呼叫 |
（Anthropic，Claude Code 的 Memory、Skills 與 Best practices 文件）
官方也提醒，CLAUDE.md 與 Skill 都是「讓 AI 照著做的上下文」，不是強制機制；若某件事一定要每次執行、不能有例外，要用 hook（在固定時機自動執行的腳本）這類確定性的設定（Anthropic，Claude Code Best practices）。Hana 的做法與這個分工吻合：事實與規則放 CLAUDE.md，反覆執行的流程做成 Skill。
社群經營也做成流程：五個階段怎麼運作？
Hana 把社群經營做成五階段流程：撰寫草稿、生成配圖、三層審核、多平台排程發布，以及回收成效並優化，每一步都有可檢查的標準。
| 階段 | 做什麼 | 把關方式 |
|---|---|---|
| 一、撰寫草稿 | 依素材或主題先做內容策略分析，產出中英雙語貼文、各平台語氣調整與配圖提示詞 | 先思考怎麼寫比較有效，而不只是寫文案 |
| 二、生成配圖 | 由圖片模型生成，並比對既有角色設計與視覺風格 | 不符就重新生成，直到達標 |
| 三、審核 | 先查圖片角色，再查文案是否符合各平台規範，最後查是否符合品牌寫作規範（禁用詞、禁用句型、標點規則） | 三層檢查，相當於自動化的內容品管 |
| 四、排程發布 | 通過審核後，透過 Typefully API 排程到 Threads、X、LinkedIn、Bluesky 等五個平台，中英文帳號分開處理 | 發文變成可規劃、可批次管理的流程 |
| 五、成效回收 | 定期用 Threads API 抓取觀看數、互動率、最佳表現文章與發文時間差異，存成結構化資料，再交給 AI 分析 | 把洞察回饋到下一輪內容策略 |
社群經營的例子說明，Hana 對「制度化」的定義不限於寫程式：只要是會重複做的事，就拆成固定步驟，設定檢查點，並把結果回收到下一輪。
AI 讓開發變容易之後，最難的是什麼？
Hana 認為最難的不是寫程式，而是決定做什麼與不做什麼、介面怎麼呈現、產品怎麼定位與推廣；AI 能協助分析，但很少給出突破性的洞見。
回顧整個過程，Hana 認為開發本身在 AI 協助下已經越來越成熟。產品方向明確、規格清楚時，功能實作幾乎不再是瓶頸。真正困難的是產品決策與推廣：要做什麼、不做什麼？介面怎麼呈現？產品怎麼定位？怎麼讓人知道？這些問題 AI 可以協助分析，但方向仍然需要人決定。當 AI 讓實作門檻降低，真正被放大的，是人的判斷與決策能力。
哪些條件可以借鏡？
mojo 案例可借鏡的是把審查與寫作分開、把回顧寫成規則、把重複流程做成 Skill；但成果建立在清楚的產品方向與大量使用 AI 上，無法直接複製。
- 讓寫程式的 AI 與審查的 AI 分開，並在全新的上下文中審查（官方文件的建議）。
- 每次修完問題做一次回顧，並把結論寫進專案設定檔或 Skill。
- 規則要精簡，太長會讓重要規則被淹沒；一再重複的流程改成 Skill。
- 不可以強制的事，要用確定性的設定，而不是只靠提示。
- 把可重複的工作（包括社群經營）拆成固定步驟與檢查點。
常見問題
完全不熟 Swift 與 Kotlin，可以用 AI 做 iOS 與 Android App 嗎？
以這個案例來說可以。Hana 在不熟這兩種語言的情況下，靠 AI 完成了雙平台的 App，第一個版本約 90% 由 AI 撰寫。她的成果建立在清楚的產品方向、完整的審查與測試流程之上。
為什麼要用不同的 AI 做 code review？
Hana 最信任 Codex 與 Cursor 做審查，因為它們能沿著新修改的程式碼，找出現有程式中可能受影響的邏輯，包括「改 A 壞 B」與多執行緒造成的偶發錯誤。官方文件也指出，全新上下文的審查不會偏向剛寫的程式碼。
CLAUDE.md 與 Skill 有什麼不同？
依 Anthropic 官方文件，CLAUDE.md 每次對話都會載入，適合簡短且廣泛適用的規則；Skill 的內容用到才載入，適合已經變成流程的步驟。兩者都是上下文，不是強制設定。
怎麼讓 AI 不再犯同樣的錯？
Hana 的做法是每次修完問題都請 AI 回顧成因與最佳做法，再把規則寫入 CLAUDE.md 或封裝成 Skill。她還把「查最新官方文件」做成自動流程，避免 AI 引用過時的做法。
用 AI 做 App，最難的是寫程式嗎？
依 Hana 的經驗不是。她認為實作在 AI 協助下已很成熟，最難的是決定做什麼、不做什麼、怎麼定位與推廣。
資料來源與說明
本文整理自我在撰寫書稿期間對 Hana 的訪談，受訪時間為 2025 年底，內容為受訪者自述。註冊與付費人數、AI 撰寫的程式碼比例、各工具的使用心得，皆未經第三方查核。本文沒有 Hana 實際的回顧內容或 Skill 範例，因此只呈現她描述的做法；與官方文件的對照，引自下列頁面。
參考資料
- Hana Chang，〈mojo：猛健樂、週纖達、瘦瘦針、GLP-1 注射、體重紀錄〉，App Store，存取日期：2026 年 10 月 19 日。
- Anthropic，〈How Claude remembers your project〉，Claude Code 文件，現行文件，存取日期：2026 年 10 月 19 日。
- Anthropic，〈Skills〉，Claude Code 文件，現行文件，存取日期：2026 年 10 月 19 日。
- Anthropic，〈Best practices for Claude Code〉，現行文件，存取日期：2026 年 10 月 19 日。
延伸閱讀
- 一人公司用 AI 做產品，最難的為什麼是取捨？：另一位用 Claude Code 做產品的創辦人，如何管理規格、上下文與營運。
- 不會寫程式的需求分析師，如何用 AI 做出完整網站？三次卡關與他的處理方式：沒有程式背景者的卡關與停損規則。
關於作者
Claire Chang ｜ 企業 AI 導入與流程轉型顧問。專注於 AI Agent 架構設計、ERP 系統整合與企業 AI 治理。
首次發布：2026-10-19