上線、收集回饋、持續改版

這是單元的最後一堂。你已經有一個能安裝、能離線、能備份的「小習慣」。但到現在為止，它只活在你的電腦和你的手機上。

一個 App 真正開始成長，是從別人開始用它的那一天。這堂課要做三件事：把它放上網路、請朋友試用、根據回饋持續改版。

上線之後，你會一直繞著這個圈走。每繞一圈，App 就更貼近使用者一點。

部署：把 App 放上網路

部署（deploy）就是把你的檔案放到一台 24 小時開著的電腦上，讓任何人都能用網址打開。

「小習慣」是靜態網站：只有 HTML、CSS、JS 和圖片檔，不需要伺服器執行程式，也不需要建置步驟。這類網站有很多免費的地方可以放，而且都自動提供 HTTPS，剛好符合 PWA 的條件。

服務	適合	怎麼上傳
GitHub Pages	程式碼已經在 GitHub 上的人	在儲存庫設定裡開啟 Pages，選擇要發布的分支
Cloudflare Pages	想要速度快、之後可能綁自己網域的人	連結 GitHub 儲存庫，每次 push 自動部署
Netlify	想要最簡單的人	連結 GitHub 儲存庫，或直接把資料夾拖進網頁上傳

三個都有適合個人專案的免費方案，額度和規定以各家官網為準。介面和按鈕位置也常調整，所以下面只講流程，實際操作時可以請 Claude 一步一步帶你。

以 GitHub Pages 為例

1. 在 GitHub 建立一個新的儲存庫（repository），例如 tiny-habits。

2. 把你的專案推上去。GitHub 建立儲存庫後會顯示指令，大致是：

   git remote add origin https://github.com/你的帳號/tiny-habits.git
   git branch -M main
   git push -u origin main

3. 到儲存庫的設定（Settings）找到 Pages，來源選擇 main 分支、根目錄。

4. 等一兩分鐘，你會拿到一個網址：https://你的帳號.github.io/tiny-habits/。

還記得我們在 manifest.json 把 start_url 設成 ./ 嗎？就是為了這種「放在子資料夾」的網址。用 Cloudflare Pages 或 Netlify 的話，連結 GitHub 儲存庫時「建置指令」留空、「輸出資料夾」填根目錄即可。

部署好之後，回到上一堂課的「方法 B」：用手機打開 HTTPS 網址，加到主畫面，開飛航模式測試。全部通過，就可以邀請朋友了。

git tag v1.0.0
git push origin v1.0.0

這兩行替「現在這個版本」貼上一個標籤 v1.0.0。版本標籤（tag）就像書籤，以後想回頭看「第一版長什麼樣子」，或是新版出了大問題想退回，都能直接找到它。

邀請三位朋友

為什麼是三位？一個人的意見可能只是個人喜好；三個人都卡在同一個地方，那就是真的問題。而且三位剛好是你能一一好好聊的數量。

挑選時，盡量找真的有這個需求的人：想多喝水的同事、正在準備考試的朋友、想規律運動的家人。不要只找會說「很棒啊」的人。

邀請訊息可以寫得溫暖又具體：

嗨！我最近自己做了一個很簡單的習慣打卡 App，叫「小習慣」，想請你幫我試用一週 🙏

網址：https://你的網址/
用法：打開後加到主畫面，新增一兩個你想養成的習慣，每天睡前點一下打卡就好。
資料只會存在你的手機裡，我看不到。

一週後我會傳一個 2 分鐘的小問卷給你。任何「卡住」「看不懂」「好麻煩」的地方都超級有用，不用客氣！

最有價值的回饋：看他第一次用

如果可以，請其中一位朋友在你面前第一次打開 App。你不要說話、不要解釋，只是看。他在哪裡停頓、點錯了什麼、皺眉頭了嗎？這幾分鐘看到的，常常比問卷還多。

忍住不解釋很難，但請記得：之後的使用者身邊不會有你。

一週後的回饋表單

用 Google 表單或任何你習慣的表單工具，做一份只有五題的問卷。題目越少，大家越願意認真回答：

1. 這一週你打開了幾天？（0–7）
2. 第一次使用時，有沒有哪裡讓你卡住或看不懂？
3. 用起來最順手的一個地方是什麼？
4. 最想改掉的一個地方是什麼？
5. 如果只能再加一個功能，你希望是什麼？

第 1 題是最誠實的指標。如果大家都只打開一兩天，加再多功能也沒用，要先找出「為什麼沒有每天打開」。

排出優先順序

回饋回來後，你會有一長串意見。不可能全部做，也不應該全部做。先把它們分類，再用一張「影響 × 成本」的圖來排順序：

bug 永遠先修。其他改善，從左上角「影響大、成本小」的開始做。

• 影響：會讓多少人、多常用得更順？三個人都提到的，影響就大。
• 成本：你和 Claude 要花多少時間？會不會動到資料格式？

假設你收到這些回饋，可以這樣整理：

回饋	類型	決定
「我打錯卡不知道怎麼取消」（兩個人提到）	使用體驗	先做：在按鈕下加一行小字「再點一下可以取消」
「iPhone 匯出備份後找不到檔案」	bug 或說明不足	先做：查清楚原因，補上說明
「希望睡前提醒我」	新功能	規劃：要研究通知在 iPhone 上的限制
「想要深色模式」	新功能	有空再做
「想跟朋友比賽誰連續最久」	新功能	先不做：需要登入和後端，等確定大家每天都用再說

被列為「先不做」的建議，不代表它不好，只是現在不是時候。把它放回第一堂課的「之後再說」清單，並且記得回覆朋友：「謝謝你，這個很棒，我記下來了」。被認真對待的感覺，會讓他們願意繼續給你回饋。

每一次改版的固定流程

決定好要做什麼，就用第三堂課的節奏和 Claude 一起改：一次一件事、測試、commit。全部改完準備發布時，照著這份清單走：

1. 更新 sw.js 的快取版本號，例如 tiny-habits-v1 改成 tiny-habits-v2。忘了這一步，朋友的手機會一直用舊版。
2. 更新 CHANGELOG.md，寫下這一版改了什麼。
3. commit、打版本標籤、push。
4. 用手機實際打開新網址確認，包括離線測試。
5. 告訴朋友有新版，順便謝謝他們的建議。

CHANGELOG：寫給人看的改版紀錄

CHANGELOG.md 是一個放在專案根目錄的檔案，用人看得懂的話記錄每一版的變化。新的版本寫在最上面：

# 更新紀錄

## v1.1.0（2026-11-21）
### 新增
- 打卡按鈕下方加上「再點一下可以取消」的提示
### 修正
- iPhone 匯出備份時，補上「儲存到檔案」的說明
### 謝謝
- 小美、阿哲的建議

## v1.0.0（2026-11-14）
- 第一版上線：新增習慣、打卡、連續天數、一週小格子、備份、PWA

版本號用「主版本.次版本.修正版」三段數字，這種規則叫做語意化版本（Semantic Versioning）：

改了什麼	版本號怎麼變	例子
只修 bug	最後一段加一	v1.1.0 → v1.1.1
加了新功能，舊資料照樣能用	中間加一，最後歸零	v1.1.1 → v1.2.0
大改版，資料格式或用法不相容	第一段加一	v1.2.0 → v2.0.0

發布時的指令：

git add .
git commit -m "v1.1.0：取消打卡提示、iPhone 匯出說明"
git tag v1.1.0
git push
git push origin v1.1.0

如果你用 Cloudflare Pages 或 Netlify 連結了 GitHub，git push 之後幾分鐘內網站就會自動更新。

走完這一圈，你學會了什麼

回頭看這六堂課，你做的事情是：

1. 把一個生活困擾寫成規格。
2. 根據需求選擇技術，而不是選最潮的。
3. 帶著 Claude 一步一步實作，每一步都檢查、存檔。
4. 想清楚資料存在哪裡，以及隨之而來的責任。
5. 讓網頁變成可以安裝、離線的 App，並在真的手機上測試。
6. 上線、聽使用者的聲音、持續改版。

這套流程不只適用於習慣 App。換成記帳、分帳、植物澆水提醒、家庭冰箱庫存，步驟完全一樣。

當你的下一個 App 需要更多畫面，可以試試 React 這類前端框架；需要跨裝置同步或多人共用，可以加上 Supabase 或 Firebase；一定要上架商店，可以研究 Expo 或 Flutter。到那時候，你會帶著這次的經驗去問 Claude 更好的問題。