AI 時代 Solo Builder 的全棧實戰https://bobochen.dev/https://bobochen.dev/blog/github-readme-video-embed-last-mile/https://bobochen.dev/blog/github-readme-video-embed-last-mile/幫開源產品做了 30 秒介紹影片，想內嵌到 GitHub README，卻踩了三個雷才發現潛規則：README 的 video 標籤只認 GitHub 自家 user-attachments CDN，raw 與 Release URL 都不會 inline 播放。Sun, 17 May 2026 00:00:00 GMT## GitHub README 影片內嵌：一件以為 5 分鐘卻做了 30 分鐘的事 剛幫自己的開源工具 [TypeLate](https://github.com/bobo52310/TypeLate) 做了 30 秒產品介紹影片，雙語版（英文 + 繁中），自己挺滿意。 下一步：塞進 GitHub README，讓訪客一打開頁面就看到產品在動。 `<video>` 標籤而已，能多複雜？ 結果這篇就是我花了 30 分鐘踩三個雷之後，才發現 GitHub 有個沒明說的潛規則：**README 的 `<video>` 只認他們自家 CDN，其他任何 URL 都不會 inline 播放。** 如果你也想把產品 demo 塞進 README，這篇可以幫你省下我那 30 分鐘。 ## 試法 1：相對路徑（直覺第一手） 我先試最直覺的：把 MP4 commit 進 repo，用相對路徑。 ```html <video src="docs/promo.mp4" width="700" controls></video> ``` push 上去之後打開 README——player 渲染出來了，看起來很正常。 點 play。 ⋯⋯沒反應。 「奇怪，是路徑問題嗎？」我用絕對的 raw URL 再試一次： ```html <video src="https://raw.githubusercontent.com/USER/REPO/main/docs/promo.mp4" controls></video> ``` 一樣沒反應。 curl 一驗就明白了： ```bash $ curl -sI -L "https://raw.githubusercontent.com/USER/REPO/main/docs/promo.mp4" HTTP/2 200 content-type: application/octet-stream content-disposition: attachment; filename=promo.mp4 ``` `Content-Disposition: attachment` —— 瀏覽器把這個 URL 當「下載檔」，不會餵給 `<video>` 解碼器。`<video>` 標籤雖然在 HTML 結構裡存在，但 src 指向的資源根本不能 stream。 那 player 渲染出來只是個空殼。 ## 試法 2：上傳到 GitHub Release（以為自家貨會放寬） 不死心。「Release asset 是 GitHub 正規 hosting，總該給正確 Content-Type 吧？」 用 [gh CLI](https://github.com/cli/cli) 上傳： ```bash $ gh release upload v1.6.2 promo.mp4 ``` URL 變成漂亮的 `https://github.com/USER/REPO/releases/download/v1.6.2/promo.mp4`。 再 curl —— ```bash $ curl -sI -L "https://github.com/USER/REPO/releases/download/v1.6.2/promo.mp4" HTTP/2 302 location: https://github-production-release-asset-...amazonaws.com/... HTTP/2 200 content-type: application/octet-stream content-disposition: attachment; filename=promo.mp4 ``` **還是 attachment、還是 octet-stream。** GitHub 不會因為你正式上架就放寬 Content-Type。Release asset 跟 raw 走的是同一條「強制下載」路線。 第二雷踩完，影片在 README 還是不會動。 ## 試法 3：終於認清現實——drag-drop 是唯一路徑 抓著疑問翻 GitHub Docs 跟一堆 Stack Overflow 問答，才拼出真相： > GitHub Markdown 的 `<video>` 標籤只支援來自他們自家「user-attachments」CDN 的 URL，長這樣： > `https://github.com/user-attachments/assets/{UUID}` 而這串 UUID **只能透過 github.com 的網頁編輯器（編輯 README、留言 PR、開 Issue 都可以），把 MP4 檔案直接「拖放」進文字框產生**。GitHub 在背後偷偷上傳到自家 CDN，自動把 magic URL 插入 markdown。 沒有 API。沒有 CLI 指令。沒有任何純 script 路徑。 也就是說： | URL 類型 | inline 播放？ | 自動化？ | |---|---|---| | 相對路徑（repo 內檔案） | ❌ | ✅ | | raw.githubusercontent.com | ❌（attachment） | ✅ | | releases/download/...（剛剛試的） | ❌（attachment） | ✅ | | user-attachments/assets/{UUID} | ✅ 串流播放 | ❌（web-only 拖放）| 60 秒手動操作，但這是唯一通的路。 ### 實際操作步驟（給跟我一樣踩過雷的你） 1. 打開 `https://github.com/USER/REPO/edit/main/README.md` 2. 把 MP4 檔從 Finder/Explorer 直接拖進編輯區的文字框 3. 等個 5-10 秒，GitHub 把它上傳到自家 CDN 4. 編輯區會自動插入 `<video>` 標籤，src 是 `https://github.com/user-attachments/assets/{UUID}` 5. 點下方「Commit changes」按鈕，寫好 message 提交 完。從拖檔到完成，60 秒。 ## 反思（一）這不是 bug，是設計 退一步想，GitHub 這樣設計其實合理。 如果他們允許任何 raw / release URL 都能 inline 串流，相當於每個 GitHub repo 都變成免費影片 CDN。隨便一個熱門開源專案的 README，每秒被千百人開啟，流量帳單會炸到爆。 把 inline video 鎖在他們能掌控的 user-attachments CDN，他們可以： - 限制單檔大小（影片：免費方案 10MB、付費方案 100MB） - 限制總流量 - 防止別人拿 GitHub 當免費影片 host 嵌到其他網站 - 統一統計播放數據 對追求「100% pure CLI flow」的工程師來說，這 60 秒手動操作是個刺。但站在平台方角度，是一個合理的取捨。 ## 反思（二）早點接受「有些事就是要手點」 我真正花時間最多的，其實不是測試本身——curl 跑 header 比較其實只要 5 分鐘。 花最多時間的是**不甘心**： - 試完 raw URL 失敗，「應該還有別的 URL 格式」 - 試完 release URL 失敗，「也許有什麼隱藏的 query string」 - 翻完 docs 沒答案，「不對啊一定有 API」 直到認清「**沒有 API、沒有自動化路徑、就是要手動拖放一次**」，我才能繼續往前。 這個心態陷阱不只發生在這次。每次我遇到「明明感覺應該能自動化但沒有現成方案」的場景，本能都是再多花 30 分鐘找解法，而不是花 60 秒手動做掉。 很多時候那 60 秒比 30 分鐘更划算。 > 如果一個一次性的手動操作只要 60 秒，就去做。 > 如果這個操作會重複 100 次，再來想自動化。 對 indie hacker 來說，這個簡單的規則比「強迫症追求純 script」更能保護你的時間。 ## TL;DR 想把產品 demo 影片塞進 GitHub README？ 1. **別試 `<video src="https://raw.githubusercontent.com/...">`** —— 不會 stream 2. **別浪費時間上傳到 Release 再引用** —— 同樣不會 stream 3. **打開 github.com 的 README 編輯器** → 直接把 MP4 拖進文字框 → 用 GitHub 自動產生的 `user-attachments/assets/{UUID}` URL → 完成 4. **保留你的 MP4 在 repo 裡（例如 `docs/promo.mp4`）** —— 即使不能 inline 播放，commit history 和 download 連結仍有用 整段過程 60 秒。 別像我一樣花 30 分鐘才接受這件事 🥲 ## 延伸閱讀 **還沒被說服要花一天做 30 秒影片？** 從訊息密度、頂級 OSS 共識、ROI 三個角度說明為什麼值得： 👉 [《為什麼一支 30 秒影片是 OSS 上架最大的槓桿》](/blog/oss-product-video-leverage/) — 給還在猶豫「值不值得」的人 **還沒有一個夠 landing-page 感的 README？** 在塞 demo 影片之前，先把 README 的基本骨架排好： 👉 [《GitHub README 排版術：把開源專案首頁變成 landing page》](/blog/github-readme-landing-page-layout/) — 6 個元素 + 章節順序模板，給第一次發 OSS 的人 **想用其他方式呈現產品 demo？** `<video>` + user-attachments 只是 5 種策略之一。如果你的 demo 是 terminal CLI 場景、影片超過上限（免費方案 10MB / 付費方案 100MB）、要 100% 純 CLI flow，或想要 SEO 加分——還有另外 4 種替代方案各有取捨： 👉 [《GitHub README 動態 demo 的 5 種策略：從 GIF 到自架 CDN》](/blog/github-readme-dynamic-demo-strategies/) — 有決策樹幫你選最適合的策略GitHubREADMEOpen SourceSolo BuilderVideohttps://bobochen.dev/blog/github-readme-dynamic-demo-strategies/https://bobochen.dev/blog/github-readme-dynamic-demo-strategies/把產品 demo 塞進 GitHub README 不只 <video> 一條路。從動畫 GIF、GitHub user-attachments、外部 CDN（Cloudflare R2），到 terminal 專用的 Asciinema，5 種策略在檔案大小、自動化、npm/VSCode 跨平台相容性上各有取捨，附決策樹與對照表幫你一眼選對。Sun, 17 May 2026 00:00:00 GMT> 先備知識：這篇假設你已經有一個排得不錯的 README 骨架（centered hero、badges、章節順序）。如果還沒，建議先讀 [《GitHub README 排版術：把開源專案首頁變成 landing page》](/blog/github-readme-landing-page-layout/) 補基礎。 ## 在 GitHub README 呈現動態 demo，其實有 5 種策略 上一篇 [《把 30 秒產品介紹塞進 GitHub README 的最後一哩》](/blog/github-readme-video-embed-last-mile/) 結尾說：「`user-attachments` 是 GitHub `<video>` 唯一能 inline 播放的路。」 但那個結論有個前提：**你想用 `<video>` 標籤 inline 播放**。 如果放寬這個前提，會發現「在 GitHub README 呈現產品動態 demo」其實有 5 條截然不同的路，每條都有自己的取捨。 這篇我把它們整理成決策樹，給： - 不想被 GitHub web UI 卡 60 秒的人 - README 要在 npm registry / VSCode preview 也能正常顯示的人 - demo 是 terminal 場景的人 - 影片超過 Free 方案 10MB 上限（付費方案 100MB）的人 ## 策略 1：動畫 GIF（萬用無腦） 把 MP4 轉成 GIF，用 `<img>` 標籤嵌入。 ```bash # 一行流程：30 秒影片轉 720p、10fps GIF ffmpeg -i input.mp4 -vf "fps=10,scale=720:-1:flags=lanczos" -loop 0 demo.gif # 進階：用 gifski 壓得更小（brew install gifski） ffmpeg -i input.mp4 -vf "fps=10,scale=720:-1" -f image2pipe -vcodec ppm - | \ gifski -o demo.gif --fps 10 - ``` README 嵌入： ```markdown  ``` **優點：** - ✅ 任何 markdown viewer 都顯示（GitHub、npm registry、VSCode preview、Reddit、Notion 全部） - ✅ 完全自動化，純 CLI flow - ✅ Auto-play，不用點 **缺點：** - ❌ 檔案大：30 秒 720p GIF 通常 5-15MB - ❌ 沒有音訊 - ❌ 畫質受 256 色限制，漸層/陰影會出現色帶 - ❌ 強制 loop 播放，讀者讀文字時持續干擾 **適合：** 短 demo（≤ 10 秒）、純視覺場景、最大相容性優先。 ## 策略 2：GitHub user-attachments（上篇結論） 打開 github.com 編輯 README，把 MP4 直接「拖」進文字框。GitHub 上傳到自家 CDN 產生： ```text https://github.com/user-attachments/assets/{UUID} ``` 完整流程在上一篇講過，這裡只列取捨。 **優點：** - ✅ 真正的 `<video>` 播放器（含 scrubber、音訊、全螢幕、loop 控制） - ✅ 串流播放，不用整段下載 - ✅ GitHub 自家 CDN，全球節點快 **缺點：** - ❌ 沒有 API，只能 web UI 拖放 - ❌ 單檔上限視方案而定：Free 10MB、Pro/Team/Enterprise 100MB - ❌ **只在 github.com 顯示**。npm registry、VSCode preview、Reddit 看到的是空白 / 損壞圖示 **適合：** 影片在上限內（Free ≤ 10MB / 付費 ≤ 100MB）、能接受 60 秒手動、主要受眾在 github.com。 ## 策略 3：外部 CDN（Netlify Drop / Cloudflare R2） 自己 host MP4 到會正確回傳 `Content-Type: video/mp4` 的 CDN，README 用 `<video src="https://...">` 直接引用。 最快上手的選項： - **Netlify Drop**：把 `public/` 資料夾拖到 [app.netlify.com/drop](https://app.netlify.com/drop)，30 秒拿到 URL - **Cloudflare R2**：免費 10GB、**0 出口流量費**，要設定 bucket + 綁網域 - 已經有 [GitHub Pages](https://pages.github.com/) 或自架網站 → 直接放進 `public/` 就好 驗證 Content-Type 正確（這是關鍵，CDN 設錯就不能 stream）： ```bash $ curl -sI https://your-cdn.example.com/promo.mp4 | grep -iE "content-(type|disposition)" content-type: video/mp4 # 沒有 content-disposition: attachment ← 這行不能出現 ``` README 嵌入： ```html <video src="https://your-cdn.example.com/promo.mp4" poster="docs/poster.jpg" width="700" controls></video> ``` **優點：** - ✅ 完全自動化（CI 推送就更新） - ✅ 無檔案大小限制 - ⚠️ 平台相容性有限：在 GitHub Pages / 自架網站 / 支援 raw HTML 的 viewer 可正常播放；但 **github.com README 不會顯示**（GitHub sanitizer 會 strip 掉指向非 githubusercontent.com 的 `<video>` 標籤）；npm registry / VSCode preview 不保證支援 - ✅ 真正的播放器 + 音訊（限支援 raw HTML 的環境） **缺點：** - ❌ 多一個服務要維護 - ❌ 流量爆掉要付錢（Netlify 自 2025-09 起新帳號改為 credit 制、免費 300 credits/月，舊制 legacy 帳號才是固定 100GB/月，實際額度以 Netlify 當前 pricing 為準；建議直接用 R2 的 10GB + 0 出口流量費較單純） - ❌ 自訂網域可能要設 CORS 才能跨來源 stream **適合：** 影片大、要 100% 自動化、有現成 CDN 可用，且目標是 GitHub Pages / 自架網站（而非 github.com README 本身）。 ## 策略 4：YouTube / Vimeo 縮圖連結（SEO 加分） GitHub 不會 render YouTube `<iframe>` embed（HTML sanitizer 把 iframe 整個 strip 掉），但可以放縮圖連結，點擊跳到 YouTube。 ```markdown [](https://youtu.be/VIDEO_ID) ``` YouTube 自動提供四種縮圖（直接拿，不用自己截）： | 解析度 | URL | |---|---| | 1280×720 | `https://img.youtube.com/vi/{ID}/maxresdefault.jpg` | | 640×480 | `https://img.youtube.com/vi/{ID}/sddefault.jpg` | | 480×360 | `https://img.youtube.com/vi/{ID}/hqdefault.jpg` | | 320×180 | `https://img.youtube.com/vi/{ID}/mqdefault.jpg` | **優點：** - ✅ SEO 加分：影片本身被 Google 索引 - ✅ 無流量成本（YouTube CDN 全球） - ✅ 同支影片可重用：README + Twitter + Threads + 官網 - ✅ 有觀看數據可追蹤（YouTube Analytics） **缺點：** - ❌ 點擊跳走 README，使用者離開原頁 - ❌ 品牌綁定 YouTube（前後可能有廣告） - ❌ 需要 Google 帳號 / YouTube channel **適合：** 產品行銷導向、做完一支影片想多平台重用、在乎 SEO。 ## 策略 5：Asciinema（terminal demo 專用） 不是影片，是 terminal 事件流的「重播」。錄製和播放都是純文字事件，檔案 KB 級別。 ```bash # 安裝 brew install asciinema # 錄製（按 Ctrl+D 結束） asciinema rec demo.cast # 上傳到 asciinema.org（首次會要求登入） asciinema upload demo.cast # → 拿到 https://asciinema.org/a/XXXXXX ``` README 嵌入（SVG 縮圖連到播放頁）： ```markdown [](https://asciinema.org/a/XXXXXX) ``` **優點：** - ✅ 檔案極小（30 秒錄製通常 5-20KB） - ✅ **文字可以選取複製**——讀者直接複製你 demo 裡的指令 - ✅ 純 SVG 縮圖在 README 完美顯示 - ✅ 可自架 player（不想依賴 asciinema.org 的話） - ✅ 開源工具：[asciinema](https://github.com/asciinema/asciinema) / [asciinema-player](https://github.com/asciinema/asciinema-player) **缺點：** - ❌ 只能錄 terminal，無法錄 GUI demo - ❌ 縮圖點擊跳走（跟 YouTube 策略類似） **適合：** CLI 工具 demo、Shell 教學、DevOps 流程示範。 ## 決策樹：你該選哪個 ```text 你的 demo 是 terminal CLI 場景？ ├─ 是 → 策略 5：Asciinema └─ 否 ↓ 影片超過方案上限（Free >10MB / 付費 >100MB）或 demo 超過 30 秒？ ├─ 是 → 策略 3：外部 CDN └─ 否 ↓ 音訊重要嗎？ ├─ 是 → 策略 2（user-attachments）或 3（CDN） └─ 否 ↓ 想要 100% 純 CLI flow，不能手動？ ├─ 是 → 策略 1：GIF（最相容）或 3（CDN，最乾淨） └─ 否 ↓ 想要 SEO 加分 + 多平台重用？ ├─ 是 → 策略 4：YouTube 縮圖 └─ 否 → 策略 2：user-attachments（最省事） ``` ## 一張表看完所有取捨 | 策略 | 檔案大小 | 自動化 | 跨平台相容 | 音訊 | 適合場景 | |---|---|---|---|---|---| | 1. GIF | 大（5-15MB） | ✅ 純 CLI | ✅ 全部 | ❌ | 短 demo、最大相容 | | 2. user-attachments | Free ≤10MB / 付費 ≤100MB | ❌ 60 秒手動 | ⚠️ 只 github.com | ✅ | 影片在上限內、主要在 GitHub | | 3. 外部 CDN | 不限 | ✅ 全自動 | ⚠️ github.com 不顯示 | ✅ | 大檔案、GitHub Pages/自架網站 | | 4. YouTube 縮圖 | 0（外部） | ✅ 上傳一次 | ✅ 全部 | ✅ | 想 SEO + 多平台重用 | | 5. Asciinema | 極小（KB） | ✅ 純 CLI | ✅ 全部 | ❌ | terminal demo 專用 | ## 我自己的選擇（實戰案例） 完整踩雷紀錄在 [《把 30 秒產品介紹塞進 GitHub README 的最後一哩》](/blog/github-readme-video-embed-last-mile/)——我做 [TypeLate](https://github.com/bobo52310/TypeLate) 這次選了策略 2（user-attachments），原因很簡單： - 影片只有 2MB，遠低於 Free 方案 10MB 上限 - 主受眾就在 github.com（README 就是首頁） - 60 秒手動可以接受（一支影片只上一次） 但如果未來： - 影片變長到 30MB → 改策略 3（Cloudflare R2 host） - 想推到 Product Hunt → 加策略 4（YouTube）多平台 - 變成純 CLI 工具 → 策略 5（Asciinema）取代 **5 種策略不是互斥的**，可以混用。例如：策略 2 給 GitHub 訪客真播放器，同時策略 4 給 YouTube SEO，策略 1 給 npm registry 看到 GIF——一支影片打三個通路。 ## TL;DR GitHub README 的動態 demo 不只 `<video>` 一條路： 1. **GIF**：相容性王者，但檔案大、無音訊 2. **user-attachments**：真播放器，但上限視方案（Free 10MB / 付費 100MB）+ 60 秒手動 3. **外部 CDN**：100% 自動化、無限制，但要多維護一個服務 4. **YouTube 縮圖**：SEO 加分，但點擊跳走 README 5. **Asciinema**：terminal 專用，KB 級別，文字可複製 選哪個看你的 demo 內容、自動化需求、跨平台需求三軸權衡。 至於為什麼值得花力氣做這支 demo 影片，可參考 [《為什麼一支 30 秒影片是 OSS 上架最大的槓桿》](/blog/oss-product-video-leverage/)。GitHubREADMEOpen SourceSolo BuilderVideohttps://bobochen.dev/blog/github-readme-landing-page-layout/https://bobochen.dev/blog/github-readme-landing-page-layout/訪客打開 GitHub repo 只給你 10 秒決定要不要 star。這篇用 GitHub 原生 markdown 把 README 排成 landing page：centered hero block、badges、視覺先行、一句話定位、Quick Start、章節順序模板 6 個元素，外加 5 個常見地雷與 2 個現成工具。給第一次發 OSS 的 indie hacker。Sun, 17 May 2026 00:00:00 GMT## README 的 10 秒首屏，就是你的 landing page 打開一個沒聽過的 GitHub repo，你會花多少時間決定要不要 star？ Nielsen Norman Group 多年的網頁瀏覽研究告訴我們：**訪客平均在 10 秒內決定是否繼續看下去**。README 的「首屏」（不用滾動就能看到的部分）就是這 10 秒的決勝點。 對開源專案來說，README 就是你的 landing page。但開源專案的 README 跟商業 landing page 不一樣。你沒有設計師、沒有 A/B 測試、也沒有複雜的 CMS。 只有 Markdown 和一點 HTML。 這篇講「用 GitHub 原生支援的 markdown 語法，把 README 排成像 landing page 的版面」。給第一次發 OSS、或一直覺得自己 README 看起來「不夠專業」的人。 ## 一個好 README 的視覺骨架 直接看範例： ```markdown <div align="center"> <img src="logo.png" width="120" alt="Logo" /> # Project Name **One-line tagline that explains the value** A 1-2 sentence elevator pitch. [](LICENSE) [](.../releases/latest)  <img src="demo.gif" width="700" alt="Demo" /> </div> > Optional callout: a key thing visitors should know upfront. ## How It Works | Step | Action | | :--: | ------ | | **1.** | Install with `brew install ...` | | **2.** | Run `command` | | **3.** | See the result | ## Features ... ``` 這個結構在 GitHub 上 render 起來就是一個 hero 區塊 + 三步驟引導 + 功能介紹。完全用 markdown + 兩個 `<div>` 和 `<img>` 標籤。 接下來拆解每個元素的細節。 ## 元素 1：Centered Hero Block GitHub markdown 支援 `<div align="center">` 把內容居中。這是排出 landing-page-style hero 的基礎。 ```markdown <div align="center"> <img src="logo.png" width="120" alt="Logo" /> # Project Name **Tagline** </div> ``` 幾個容易踩的細節： - **`<div>` 開合之間要留空行**，markdown 才會 render 裡面的 `#` 標題和 `**bold**` - **`<img>` 用 `width="120"` 屬性控制大小**，不要用 inline `style="..."`，GitHub 的 HTML sanitizer 會 strip 掉 style - 居中的 `#` 標題在 mobile 上也會正確居中 ## 元素 2：Badges（4 個就好） [shields.io](https://shields.io/) 是事實上的標準，支援數十種服務（CI、套件庫、coverage、社群平台等）的動態 badges，再加上無限自訂的靜態 badge。 **該放的 4 個**： ```markdown [](LICENSE) [](.../releases/latest) [](.../actions)  ``` 對應訪客要判斷的 4 件事： | Badge | 訪客在問 | |---|---| | License | 能不能用？商業？fork？ | | Release version | 專案還活著嗎？最近一次更新多久前？ | | Build status | 品質如何？CI 過得了嗎？ | | Platform | 支援我的環境嗎？ | **不該放的**： - ❌ Downloads count、code coverage、star count，這些數字一旦停滯反而扣分 - ❌ Discord / Slack / 廣告 badges，會分散訪客注意力 - ❌ 超過 4 個，開始看起來像 CI pipeline 而不是 landing page GitHub repo 頁面本來就有 star count，README 不用重複放。 ## 元素 3：Hero Image / GIF / Video 視覺是 10 秒內最快傳達訊息的方式。三個選擇： - **Screenshot**：靜態，但能放最高解析度 - **GIF**：動態 demo，相容性最好（任何 markdown viewer 都吃） - **Video**：真正的播放器，但只能透過 GitHub 拖放上傳，且只在 github.com 顯示 哪個適合你的場景？我寫過一篇詳細的 [《GitHub README 動態 demo 的 5 種策略：從 GIF 到自架 CDN》](/blog/github-readme-dynamic-demo-strategies/)，附決策樹幫你選。 ## 元素 4：一句話定位（最重要的元素） 直接看兩個對比： ```markdown <!-- ❌ 工程師寫法 --> TypeLate is a cross-platform push-to-talk dictation app built with Tauri v2 that uses Groq Whisper for transcription and LLM-based post-processing. <!-- ✅ User-facing 寫法 --> **Too late to type — just speak.** Press a hotkey to start, speak naturally, press again to stop. Your voice becomes polished text in under 3 seconds — right where you type. ``` 兩個關鍵差別： 1. **擺放位置**：藏在內文第一行 vs 獨立的 `**bold tagline**`——訪客掃讀的第一視覺重點 2. **「has feature X」vs「does Y for you」**：把焦點放在「使用者得到什麼」而不是「我們做了什麼」 對 indie hacker / solo builder：tagline 要在 **60 字內**傳達「給誰、解決什麼、用什麼方式」。寫不出來代表產品定位還沒想清楚。 想看更多範例？[Awesome README](https://github.com/matiassingers/awesome-readme) 是 GitHub 上精選的 README 範例集，找一個跟你類似的專案抄結構。 ## 元素 5：Quick Start（30 秒能試到） 如果讀者讀到這裡還沒被勸退，他在想「我怎麼試試看」。給他最短路徑： ````markdown ## Quick Start ```bash brew install your-cli your-cli init your-cli run ``` ```` **三行裝完三行跑**。 如果你的安裝需要 10 個步驟，不要硬塞進 Quick Start。那代表你該重新設計安裝流程了。一個典型問題：「先設定環境變數、再裝依賴、再 build、再執行 migration、再啟動……」，這些都該包成單一指令（`make install` 或 `npx create-foo`）。 ## 元素 6：章節順序模板 對小型開源工具，這個順序我用了很多次： ```markdown # Project Name (hero block 已含) ## How It Works （一個 table 或三個 emoji bullets 講工作原理） ## Features （4-6 個關鍵功能，每個一段話） ## Quick Start （裝 → 用 → 看到結果） ## Documentation （連到完整文件 / wiki / website） ## Contributing （接受 PR 嗎？要遵守什麼規範？） ## License （一行就好：MIT / Apache 2.0） ``` 長 README（超過 10 個章節）才需要 Table of Contents。短於 5 個章節的 README 加 TOC，反而讓 TOC 佔滿首屏、把真正的 hero 內容推到滾動線以下。 ## 5 個常見錯誤 寫 README 的地雷： 1. **一上來放安裝指令** — 訪客還不知道這是什麼就要他裝？先 hook 再裝 2. **沒有視覺** — 純文字 README 就像沒有截圖的 App Store 頁面 3. **Badges 排了一整行** — 超過 4 個就開始看起來像 CI dashboard 4. **章節順序亂跳** — 「先講安裝、再講功能、再講為什麼、再講安裝」這種輪迴看不下去 5. **Tagline 是「This is a tool that...」** — 直接寫 user value，不要解釋自己是什麼 ## 兩個現成工具 如果不想從零寫： - **[readme-md-generator](https://github.com/kefranabg/readme-md-generator)**：interactive CLI，問 10 個問題產出標準結構的 README。⚠️ 老牌但已停更（最後發布 v1.0.0 / 2019 年），在新版 Node.js 上可能有相容性問題；建議當作結構參考，或改用線上工具 [readme.so](https://readme.so/) - **[Awesome README](https://github.com/matiassingers/awesome-readme)**：GitHub 精選範例集，找類似專案抄結構 ### 3 分鐘快速上手 readme-md-generator > 注意：此工具最後一次發布是 v1.0.0（2019 年），已多年未更新，在新版 Node.js 上可能裝不起來或跑不動。以下流程僅供參考其產出結構，若安裝失敗請改用 [readme.so](https://readme.so/) 之類仍在維護的線上產生器。 ```bash # 安裝 npm install -g readme-md-generator # 進入專案根目錄 cd your-project # 啟動 interactive 模式 readme-md-generator ``` 執行後會依序問你： 1. 專案名稱（自動從 `package.json` 抓） 2. 描述、版本、作者 3. 想包含哪些章節（Installation、Usage、Tests、Contributing…） 4. 授權類型 每個問題都有預設值（直接按 Enter 就行），跑完一輪會在當前目錄生成 `README.md`。產出的結構不是最美但很完整，**可以當骨架再手動精修**。 ## TL;DR 把 README 排成 landing page 的 6 個元素： 1. **Centered hero block**（logo + 標題 + tagline） 2. **Badges**（4 個就好：license、release、build、platform） 3. **Hero image / GIF / video**（視覺先行） 4. **一句話定位**（user value，不是 feature list） 5. **Quick Start**（30 秒能試到） 6. **章節順序模板**（How → Features → Install → Docs） 訪客只給你 10 秒。這 6 個元素是讓那 10 秒值得的最低標準。 ## 接下來 學會基本排版後，如果想把產品 demo 影片塞進 README： 👉 [《GitHub README 動態 demo 的 5 種策略：從 GIF 到自架 CDN》](/blog/github-readme-dynamic-demo-strategies/) — 5 種策略決策樹，幫你選最適合的呈現方式 👉 [《把 30 秒產品介紹塞進 GitHub README 的最後一哩》](/blog/github-readme-video-embed-last-mile/) — `<video>` 標籤的踩雷紀錄，60 秒手動操作的真相 👉 [《為什麼一支 30 秒影片是 OSS 上架最大的槓桿》](/blog/oss-product-video-leverage/) — 把視覺先行的觀念延伸到 OSS 上架策略 👉 [《Landing Page 與 SEO：讓產品被找到》](/blog/ai-solo-builder-landing-page-seo/) — landing page 核心概念從 README 延伸到完整產品曝光GitHubREADMEOpen SourceSolo BuilderDocumentationhttps://bobochen.dev/blog/oss-product-video-leverage/https://bobochen.dev/blog/oss-product-video-leverage/OSS 99% 死於沒人看，不是 code 不好。從訊息密度、頂級 OSS 共識、8 小時換 1 年的 ROI 三個角度，解釋為什麼一支 30 秒動態影片是 README 最強的槓桿，並回應「我的工具不適合做影片」的 3 種常見反論——給第一次發 OSS 的 indie hacker / solo builder。Sun, 17 May 2026 00:00:00 GMT## OSS 99% 死於沒人看 —— 而影片是 README 最強的槓桿 不是 code 寫得不夠好——大部分被忽略的 OSS 其實 code 都不差。 是**沒有任何元素能在訪客的 10 秒注意力裡傳達「這是什麼、為什麼我該關心」**。 而在 README 所有可以放的元素裡，**動態影片是最強的槓桿**——一次傳達「能用」「使用體驗」「視覺品質」三件事，是其他任何元素都辦不到的。 但做 30 秒產品介紹影片如果不熟要花一整天，熟了也要半天。值得嗎？ 這篇從三個角度拼出我的答案：值得。 ## 角度 1：訊息密度的不對稱 README 上每個元素都有它的「訊息天花板」——也就是這個元素**最多能傳達多少訊息**。 | 元素 | 訊息天花板 | |---|---| | Tagline | 「給誰、解決什麼」（1 件） | | Screenshot | 「視覺品質」（1 件） | | Features list | 「能做什麼」（1 件，且要讀者逐條讀） | | Quick Start | 「怎麼裝」（1 件） | | **Video / GIF** | **「能用」+「使用體驗」+「視覺品質」（3 件，30 秒內同時）** | 差別在訊息密度——影片用同樣的閱讀時間傳達 3 倍的訊息量。 但真正的槓桿不只在「密度高」。真正的槓桿在於： **影片能在讀者腦中產生「我在用這個工具」的具體想像**。 Screenshot 是「別人在用」，Features 是「它能做」，影片是「我會怎麼用」。從心理學角度，「我會怎麼用」這個想像就是 star/clone 的最大驅動力——讀者不是因為 code 好而 star，是因為他**想看見自己也在用**。 ## 角度 2：頂級 OSS 已經達成共識 打開這些 2025/2026 年紅得發紫的 OSS： - **Linear**：landing page hero 是 30 秒 demo video（雖然不是 OSS，但行銷模式 OSS 都在抄） - **Cal.com**：landing + README 都有 hero video - **Plane.so**：README 第一個區塊就是動態 demo GIF - **Excalidraw**：README hero 是動態使用 GIF - **Supabase**：README 短 GIF + landing 完整 demo video - **Vercel**：所有 OSS 工具 README（Next.js, AI SDK...）都有 video 或 high-fidelity GIF 對比那些**沒有** hero visual 的 OSS（不點名了，看 GitHub trending 倒數區），普遍特徵：純文字 README、第一個區塊就是安裝指令、tagline 是 "X is a tool that uses Y..."。 這不是偶然——頂級 OSS 行銷團隊投入 N 個小時 A/B 測試的結果。如果你是 indie hacker / solo builder，**可以直接抄結論**：hero video 是必備，不是 nice-to-have。 ## 角度 3：8 小時換 1 年的 ROI 假設你花**一整天 8 小時**做 30 秒影片。 這 8 小時的回報是什麼？ - **影片活在 README 至少 1 年**（除非產品大改） - **期間 README 每次被打開都有它**——對活躍 OSS，這是上千到上萬次曝光 - **單獨可發**：30 秒 MP4 可以發 Twitter / Threads / Reddit / Hacker News，跟 README link 完全不同的擴散管道 - **conversion 提升**：hero video 把 star / fork conversion 提升 2-5x 先講清楚這個 2-5x 的來歷：它是 OSS 行銷文章裡反覆出現的數字，不是我自己量到的，也不是哪份有對照組的研究——你就當成「常見傳說值」看，別當鐵律。更重要的是它有個前提：這個倍數是乘在「已經有人滑到並點開你 README」上的。對 0 star、0 流量的新專案，2-5x 乘以接近 0 還是接近 0。影片放大的是既有流量的轉換率，不是憑空生出流量。所以這數字對「已經有人來看」的專案才有意義，對還沒人知道你存在的專案，先解決的是怎麼讓人來，不是怎麼讓來的人多按 star。 對比另一個常見的時間投資：**寫一篇 8 小時的技術部落格**。文章可能拿到 1 次 Hacker News 曝光（如果幸運），3 天後沉底。影片是**一年都還在替你工作的資產**。 > 對 indie hacker：8 小時換 1 年的視覺資產 + 社群可分享 demo，是能拿到最高 ROI 的時間投資之一。 不在「能不能」做這件事，而在「想不想接受 8 小時的初期投入」。 但我得補一句，免得這段聽起來像穩賺：這 8 小時對 solo builder 不是免費的。它的真正成本不是「一天」，是「這天沒拿去修 bug、沒做使用者最想要的功能、沒回 issue」——對只有一個人的專案，這才是最稀缺的東西。所以有幾種情況我會勸你先別做影片： - **產品還在 pre-PMF、核心功能還會大改**：影片拍完三週就過時，等於白拍。 - **還沒有任何人在用、零回饋**：這時花 8 小時做影片，只是把零曝光包裝得漂亮一點，ROI 很可能是負的。 我自己的門檻是：等 README 開始有一點自然流量、有陌生人真的 clone 來用、issue 區開始冒出不認識的人，再回頭投資影片。在那之前，先去把那個讓人留下來的功能做對。影片是放大器，不是救生圈。 ## 「我的工具不適合做影片」——3 種反論 我聽過幾種版本： ### 反論 1：「我做的是 CLI 工具，沒什麼好看的」 CLI 工具**更適合**做 demo。終端機畫面 + 即時輸出有天然的節奏感。 - [Asciinema](https://github.com/asciinema/asciinema) — 錄製 terminal 事件流，純文字、檔案 KB 級別、**觀眾可以從 demo 直接複製你打的指令** - [VHS](https://github.com/charmbracelet/vhs) — Charm 出的工具，寫一份 `.tape` 指令稿（就像寫 bash），自動產生 GIF/MP4，可重現可進 git - 純錄影：用 [tmux](https://github.com/tmux/tmux) + [QuickTime](https://support.apple.com/quicktime) 錄終端機畫面 ### 反論 2：「我做的是 library，沒 UI」 讓 code 動起來： - [Carbon](https://carbon.now.sh/) 或 [ray.so](https://ray.so/) — 美觀的 code 截圖 - [Code Hike](https://codehike.org/) — 在 MDX 文章裡做 step-by-step code reveal 動畫 - 一個常見模式：用 [Remotion](https://www.remotion.dev/) 做「3 行 code 解決 X 問題」的動態 demo ### 反論 3：「我做的是純後端服務」 至少做一張流程圖 GIF： - 動畫展示 request → process → response 的時間線 - 用 [Excalidraw](https://excalidraw.com/) 畫好流程，匯出 SVG，CSS animate - 用 [Motion Canvas](https://motioncanvas.io/) 或 [Manim](https://www.manim.community/) 程式化生成數學/系統動畫 簡單說：**沒有「不適合做 demo」的工具，只有「沒花時間想 demo 怎麼做」的人**。 ## 30 秒影片該講什麼（如果你決定做） 只有 30 秒，講這 3 件事： 1. **痛點**（5 秒）— 把訪客拉進「我有這個煩惱」的情境 2. **解法演示**（20 秒）— 工具的關鍵 magic moment 3. **CTA / 品牌收尾**（5 秒）— logo + tagline + GitHub URL **不要嘗試講完所有功能**。一支 30 秒影片只能傳達「一個 main value」，其他靠 README 補。 工具選擇： - **純螢幕錄製**：[Loom](https://www.loom.com/) 或 [Cap](https://github.com/CapSoftware/Cap)（OSS） - **高品質敘事**：[Remotion](https://www.remotion.dev/)（React 寫影片）或 [HyperFrames](https://hyperframes.heygen.com/)（HTML + GSAP 寫影片） - **純動畫**：[Motion Canvas](https://motioncanvas.io/) 或 [Manim](https://www.manim.community/) 我做 [TypeLate](https://github.com/bobo52310/TypeLate) 這次用 HyperFrames：30 秒、5 個場景、雙語版（EN + 繁中），完整流程在 [《把 30 秒產品介紹塞進 GitHub README 的最後一哩》](/blog/github-readme-video-embed-last-mile/)——那篇也記錄了我做完之後踩到的 GitHub 嵌入雷。 ## 我自己的觀察 老實說：我沒有 hard A/B data 證明 hero video 把 TypeLate 的 star 數推到哪。觀察期太短、變因太多。 但有兩個質的觀察值得寫： **1. 影片本身比 README 文字更有「擴散性」** 我做完 30 秒影片後，可以單獨把它發 Twitter / Threads / 社群——這個動作的 reach 是發 README link 的數十倍。一份內容兩用：README hero + 社群 ammunition。 **2. 「介紹自己做什麼」的成本大幅降低** 之前在群組或 podcast 講 TypeLate，要花一分鐘鋪陳「它是一個 push-to-talk 聽寫工具」。有了 30 秒影片後，貼連結即可。聽眾在 30 秒內理解的程度，比我講一分鐘還深。 這兩個觀察就足以讓我下次也做。對 indie hacker / solo builder 來說，**不一定要 A/B 數字證明，幾個質的觀察就夠決定**。 ## TL;DR OSS 99% 死於沒人看，不是 code 不好。 3 個角度說明為什麼動態影片是 README 最強槓桿： 1. **訊息密度**：影片同時傳達「能用 + 體驗 + 品質」，其他元素只能一件 2. **頂級 OSS 共識**：Linear、Cal.com、Plane、Excalidraw、Supabase 都有 hero video，可以直接抄 3. **ROI**：8 小時換 1 年的視覺資產 + 社群可分享 demo 「不適合做影片」？ - CLI → Asciinema / VHS - Library → Carbon / Code Hike - 後端 → Excalidraw / Motion Canvas 流程圖 30 秒影片該講：痛點（5s）→ magic moment（20s）→ CTA（5s）。不要塞所有功能。 ## 接下來 決定要做影片了？這個系列剩下兩篇是實作向： 👉 [《GitHub README 排版術：把開源專案首頁變成 landing page》](/blog/github-readme-landing-page-layout/) — 影片以外的 5 個 README 元素怎麼排 👉 [《GitHub README 動態 demo 的 5 種策略：從 GIF 到自架 CDN》](/blog/github-readme-dynamic-demo-strategies/) — 影片做完了，怎麼塞進 README？決策樹Open SourceSolo Builder行銷ProductVideohttps://bobochen.dev/blog/ai-solo-builder-checklist/https://bobochen.dev/blog/ai-solo-builder-checklist/Solo Builder Checklist 全書總整理：一份可操作的產品健康檢查清單，從點子驗證、建造上線到成長與自主運行，逐項檢查你的產品在每個階段是否達標。附 AI 輔助自我評估 prompt 與精選延伸學習資源，幫你一個人也能把產品做到及格。Sun, 10 May 2026 00:00:00 GMT## 最後一件事：把整本書變成一份 Solo Builder Checklist 恭喜你走到這裡。 14 章，從 Solo Builder 宣言到真實案例拆解，我們走完了一個產品從零到一的完整旅程。 但資訊量很大，容易看完就忘。所以這最後一章，我要把整本書壓縮成一份你可以反覆使用的 checklist。 這份清單不是「讀完打勾就好」的裝飾品，它是你的產品健康檢查表，每隔一段時間拿出來對照一下，看看哪些環節做到了、哪些還沒有、哪些需要補強。 不需要全部打勾才能上線。但如果太多項目是空白的，你可能要回頭看看對應的章節。 --- ## 階段一：驗證（對應第 2-4 章） 這個階段的目標是：**確認你不是在浪費時間。** ### 問題驗證 - [ ] 你能用一句話說清楚你的產品解決什麼問題 - [ ] 這個問題有證據支持（社群討論、搜尋量、身邊的人也遇到） - [ ] 你做過 AI 輔助的市場掃描，確認問題的普遍性 - [ ] 你模擬過至少 3 種不同類型的目標用戶訪談 - [ ] 你設定了明確的 kill criteria（什麼情況下放棄） ### 競品分析 - [ ] 你知道至少 3 個直接競品和 2 個間接競品 - [ ] 你做了競品矩陣（功能、定價、優缺點比較表） - [ ] 你找到了至少一個明確的差異化角度 - [ ] 你確認差異化角度有市場需求（不是你自以為的優勢） ### MVP 範圍定義 - [ ] 你的 MVP 功能清單不超過 5 個核心功能 - [ ] 你有一份「砍掉的功能清單」，而且比保留的功能更長 - [ ] 每個保留的功能都直接服務於核心價值主張 - [ ] 你預估了 MVP 的開發時間，而且不超過 4 週 ### Landing Page - [ ] Landing Page 已上線（即使產品還沒做好） - [ ] 頁面上有清楚的價值主張、核心功能說明、定價方案 - [ ] 有等候名單或預先註冊表單 - [ ] 已經分享到至少 3 個相關社群 - [ ] 你有在追蹤轉換率（訪客 → 填表的比例） ### 階段一的及格線 > **至少完成 12 項以上，你才應該開始寫程式碼。** 如果不到 12 項，回去看第 2-4 章。你花在驗證上的每一小時，都在為你省下未來數十小時的開發時間。 先說清楚：「12 項」是經驗法則，不是鐵律，也不是普世真理。如果你做的是免費工具、開源專案、純內容部落格或作品集型 side project，那「定價方案」「等候名單」這種項目本來就不適用——硬湊到 12 才動手，反而是在扭曲你的判斷。真正要問的是「對我這種產品該驗證的，有沒有驗證到」，不是「項數夠不夠」。 還有一個反方我得補：驗證和建造不是二選一。當 AI 讓一個能用的原型幾個小時就生得出來時，「先丟一個粗糙版本給真實用戶用」本身就是最強的驗證——直接動手做也是一種合法的驗證手段。我看過太多人卡在「再驗證一下、再問一輪」結果三個月沒寫半行 code，這是另一個極端。先驗證 vs. 先建造，取決於你的產品做出來有多貴：做出來要兩週就先驗證，做出來只要一個下午就直接做。 --- ## 階段二：建造（對應第 5-8 章） 這個階段的目標是：**用最少時間把產品做出來並開始收錢。** ### AI 開發工作流 - [ ] 你的專案有 CLAUDE.md（或等效的 AI context 文件） - [ ] AI 知道你的專案架構、coding style、測試慣例 - [ ] 你有建立至少 2 個 custom skill 來加速重複性工作 - [ ] 你知道什麼時候該用 AI、什麼時候該自己寫（第 5 章的判斷框架） - [ ] 你的 prompt 有版本控制（好的 prompt 跟好的程式碼一樣值得保存） ### 部署上線 - [ ] 產品已部署到 production 環境 - [ ] CI/CD pipeline 設定完成（推到 main 自動部署） - [ ] 部署流程從 commit 到上線不超過 10 分鐘 - [ ] 你知道怎麼 rollback 到上一個版本 - [ ] 域名設定完成（自訂域名，不是平台預設的子域名） ### Landing Page 與 SEO - [ ] 頁面有正確的 meta title 和 meta description - [ ] 有 Open Graph 圖片（社群分享時有預覽圖） - [ ] Google Search Console 已設定 - [ ] Lighthouse Performance 分數 > 90 - [ ] 行動裝置體驗正常 ### 付費機制 - [ ] 金流串接完成（Stripe、Gumroad、或其他） - [ ] 測試過完整的付款流程（從點擊購買到收到確認信） - [ ] 有免費方案或試用期讓用戶先體驗 - [ ] 退款政策已寫好並公開在網站上 - [ ] 你收到過至少一筆真實的付款 ### 錯誤追蹤 - [ ] 有設定錯誤追蹤服務（Sentry、LogRocket 等） - [ ] 核心功能有錯誤時你會收到通知 - [ ] 你知道過去一週產品有沒有發生錯誤 ### 階段二的及格線 > **至少完成 15 項以上，你的產品才算「上線」。** 特別注意：金流串接和錯誤追蹤不能跳過。一個收不了錢的產品不是產品，一個出錯你不知道的產品是定時炸彈。 同樣提醒一次：這條線是寫給「要收錢」的產品看的。如果你做的是免費工具或開源專案，金流、退款政策那幾項根本不存在，扣掉之後你的「15」自然就變小了——別因此覺得自己沒及格。把標準換成「對你這個產品該有的，有沒有都做到」就好，錯誤追蹤這種跟收不收錢無關的，才是真的不分產品類型都得有。 --- ## 階段三：成長（對應第 9-12 章） 這個階段的目標是：**讓產品能夠在你不盯著的時候也正常運作。** ### 用戶回饋 - [ ] 產品內有回饋收集機制（表單、email、對話框） - [ ] 你有定期（至少每月一次）整理和分析用戶回饋 - [ ] 你有一份「用戶要求但你還沒做的功能」清單，並且有優先排序 - [ ] 你做過至少一次根據用戶回饋調整產品方向的決策 ### 客服與文件 - [ ] 有 FAQ 或幫助中心頁面 - [ ] 常見問題有標準化回覆範本（可以用 AI 輔助生成） - [ ] 客服回應時間有明確承諾（例如 48 小時內回覆） - [ ] 你每週花在客服上的時間不超過 2 小時 ### 監控與維運 - [ ] 有 uptime 監控（產品掛了你會知道） - [ ] 有設定告警（關鍵指標異常時通知你） - [ ] 你知道產品目前的核心指標（DAU、MRR、錯誤率） - [ ] 有自動化備份策略 - [ ] 備份做過至少一次還原測試 ### 定價與商業模式 - [ ] 定價經過至少一次調整（根據市場反饋） - [ ] 你知道你的 unit economics（每個用戶的獲取成本和終身價值） - [ ] 營收趨勢是穩定或成長的 - [ ] 你有考慮過不同的定價模式（月費、年費、一次買斷、分級定價） ### 階段三的及格線 > **至少完成 10 項以上，你的產品才能稱為「有在成長」。** 這個階段最容易被忽略，因為你會覺得「產品已經上線了，沒壞就不用管」。但沒有回饋循環和監控的產品，只是一個靜靜等死的網頁。 一樣，「10 項」是抓個感覺用的數字。這階段的「定價與商業模式」「unit economics」那一整區，對不收錢的產品來說整塊都跳過——免費工具的「成長」是看活躍用戶和留存，不是看 MRR 趨勢。回饋循環、監控、備份還原這幾項才是不管你收不收錢都該做的；數字湊不齊不代表你沒在成長，要看湊不齊的是哪幾項。 --- ## 階段四：自主運行（進階） 這個階段不是每個 Solo Builder 都需要達到的。但如果你的產品已經開始有穩定收入，這些是下一步需要考慮的。 ### 財務健康 - [ ] 營收已經覆蓋營運成本（伺服器、域名、第三方服務） - [ ] 你知道你的月度淨利潤是多少 - [ ] 有三個月的營運預備金（即使收入中斷也能維持） - [ ] 已經處理好稅務和法律結構（個人所得 / 行號 / 公司） ### 自動化程度 - [ ] 產品可以在你完全不碰的情況下正常運作至少兩週 - [ ] 客服有自動化回覆處理最常見的問題 - [ ] 帳單和收款完全自動化 - [ ] 部署和更新可以用一個命令完成 ### 成長引擎 - [ ] 你有明確的主要成長渠道（SEO、社群、口碑、付費廣告） - [ ] 成長渠道有持續帶來新用戶 - [ ] 用戶留存率穩定（不是只有新用戶、舊用戶一直流失） - [ ] 你有一套可重複的內容產出節奏 ### 階段四的及格線 > **如果你達到了這個階段的大部分項目，你已經不只是 Solo Builder——你在經營一個 micro business。** 是時候考慮：這個產品值不值得投入更多時間？需不需要開始外包部分工作？要不要考慮全職投入？ --- ## AI 輔助自我評估 如果你想要更深入的診斷，可以把你的產品現況丟給 AI 做一次全面評估。以下是一個結構化的 prompt： ```text 我是一個有正職的 Solo Builder，以下是我目前的產品現況： 產品名稱：[名稱] 產品類型：[SaaS / 內容平台 / 工具 / 其他] 上線時間：[何時上線] 目前用戶數：[大約多少] 月營收：[金額] 每週投入時間：[小時數] 以下是我已完成和未完成的項目： 已完成： - [列出你已經做到的事] 未完成： - [列出你知道該做但還沒做的事] 請以 Solo Builder 的角度幫我分析： 1. 我目前在哪個階段？（驗證 / 建造 / 成長 / 自主運行） 2. 最急迫需要處理的 3 件事是什麼？ 3. 哪些未完成項目可以先跳過？ 4. 以我的時間限制，建議的優先順序？ 5. 有沒有我遺漏的關鍵項目？ ``` AI 的回答不是聖旨——但它能幫你從「我覺得好像還可以」變成「我清楚知道下一步要做什麼」。 --- ## Solo Builder 宣言——再看一次 第 1 章開頭，我分享了 Solo Builder 宣言。走完 14 章之後，我們再看一次這六條信念： 1. **先 ship，再完美。** → 你在第 13 章看到了——我的每個產品都是不完美就上線的。 2. **時間是最稀缺的資源。** → 每一章的「傳統做法 vs. AI 加持做法」都在告訴你同一件事：用 AI 買回時間。 3. **AI 是隊友，不是魔法。** → 第 5 章深入探討了這一點。AI 處理苦工，你負責判斷。 4. **正職不是阻礙。** → 第 1 章的「隱藏優勢」，到第 13 章的真實案例，都證明了邊上班邊做產品不但可行，而且有獨特的優勢。 5. **一個人不代表什麼都自己來。** → AI、開源工具、現成服務——你的「團隊」比你想的大得多。 6. **做自己會用的東西。** → course-forge 就是最好的例子：從自己的痛點出發，做自己每天都在用的工具。 這六條不是「讀完感動一下」的雞湯。它們是決策框架。每次你猶豫要不要加一個功能、要不要換技術棧、要不要等到完美再上線的時候，回來看這六條。 --- ## 這 14 章你學到了什麼 讓我用一張表格幫你回顧整本書： | 章 | 標題 | 你學到的核心概念 | | --- | ------------------------- | ---------------------------------- | | 1 | Solo Builder 宣言 | AI 改變的是時間成本，不是能力門檻 | | 2 | 點子驗證 | 一天內用 AI 完成市場調查和競品分析 | | 3 | 技術選型 | 一種語言打天下、選生態系不選框架 | | 4 | MVP 設計 | 砍到不能再砍，只保留核心假設 | | 5 | AI 驅動開發 | 從 Vibe Coding 到 Agentic Workflow | | 6 | 部署上線 | 零設定 CI/CD，選對平台省 80% 維運 | | 7 | Landing Page 與 SEO | 讓目標用戶找到你 | | 8 | 付費機制 | 一個人怎麼串接金流開始收錢 | | 9 | 用戶回饋 | 系統化收集和分析回饋 | | 10 | 客服與社群 | 用 AI 把客服時間壓到最低 | | 11 | 監控與維運 | 讓產品在你睡覺時也穩定運行 | | 12 | Side Project → Micro SaaS | 什麼時候該認真、怎麼定價 | | 13 | 實戰案例 | 四個真實產品的完整拆解 | | 14 | Checklist | 你的產品在每個階段是否達標 | 每一章都不是獨立的。它們串成一條路徑：**驗證 → 建造 → 成長 → 自主運行。** 你不需要一次走完。根據你現在的階段，跳到對應的章節就好。 --- ## 延伸資源 如果你想更深入特定主題，以下是我推薦的資源： ### 產品與創業思維 - **The Mom Test**（Rob Fitzpatrick）— 怎麼做用戶訪談才不會被禮貌性的「好棒喔」騙到 - **Lean Startup**（Eric Ries）— MVP 和快速迭代的經典 - **Zero to Sold**（Arvid Kahl）— 從零到出售 SaaS 的完整經驗，Solo Builder 必讀 ### AI 輔助開發 - **Claude Code 官方文件** — 最新的 skill、MCP、multi-agent 功能 - **Anthropic Cookbook** — AI 應用的實戰 recipe ### 技術棧 - **Astro 官方文件** — 你的靜態網站框架 - **Cloudflare Developer Docs** — Workers（含 Static Assets）、D1、R2 全家桶。Cloudflare 已在 2025 年把 Pages 的功能整併進 Workers，新功能只進 Workers，新專案建議直接用 Workers with Static Assets - **Hono 官方文件** — 輕量 TypeScript 後端框架 ### Solo Builder 社群 - **Indie Hackers** — 最大的獨立開發者社群 - **r/SaaS、r/SideProject** — Reddit 上的 Solo Builder 討論區 - **台灣獨立開發者社群** — 在 Facebook、Discord 都有，搜「indie hacker 台灣」 --- ## 最後想對你說的話 你讀完了整本書。但讀完不等於做完。 我認識太多人，讀了一百本創業書、看了一千支 YouTube 影片、收藏了一萬篇文章——然後一個產品都沒做出來。 不是因為他們不夠聰明或不夠努力。是因為**準備永遠不會「夠」**。你永遠可以再多學一點、多準備一點、多想一點。 但產品不是想出來的。產品是做出來的。 你不需要完美的點子。你不需要完美的技術棧。你不需要完美的 Landing Page。你不需要完美的定價策略。 你需要的只是一個「還可以」的點子，然後開始動手。 那些你崇拜的獨立開發者——他們的第一個產品也是粗糙的、不完美的、甚至有點丟臉的。但他們做了一件你還沒做的事：**他們 ship 了。** 所以，合上這本書。打開你的編輯器。 你的備忘錄裡那個一直躺著的點子，今天就開始驗證它。 用[第 2 章](/blog/ai-solo-builder-idea-validation)的方法，花一個下午確認它值不值得做。如果值得，用[第 3 章](/blog/ai-solo-builder-tech-stack)的框架選技術棧。用[第 5 章](/blog/ai-solo-builder-ai-driven-dev)的方法讓 AI 幫你寫程式碼。用[第 6 章](/blog/ai-solo-builder-deployment)的流程一週內部署上線。 然後，你就不再是一個「有很多 side project 點子的人」。 你是一個 **Solo Builder**。 --- ## 全書系列導覽 ### 第一階段：驗證 - [第 1 章：Solo Builder 宣言——一個人 + AI 就是一支團隊](/blog/ai-solo-builder-manifesto) - [第 2 章：點子驗證——花一天而不是一個月](/blog/ai-solo-builder-idea-validation) - [第 3 章：技術選型決策框架](/blog/ai-solo-builder-tech-stack) - [第 4 章：MVP 設計——砍到不能再砍](/blog/ai-solo-builder-mvp-design) ### 第二階段：建造 - [第 5 章：AI 驅動開發——從 Vibe Coding 到 Agentic Workflow](/blog/ai-solo-builder-ai-driven-dev) - [第 6 章：部署上線——選對平台省 80% 維運](/blog/ai-solo-builder-deployment) - [第 7 章：Landing Page 與 SEO](/blog/ai-solo-builder-landing-page-seo) - [第 8 章：付費機制——一個人怎麼串接金流](/blog/ai-solo-builder-payment) ### 第三階段：成長 - [第 9 章：用戶回饋循環](/blog/ai-solo-builder-user-feedback) - [第 10 章：客服與社群經營](/blog/ai-solo-builder-support-community) - [第 11 章：監控與維運](/blog/ai-solo-builder-monitoring-ops) - [第 12 章：從 Side Project 到 Micro SaaS](/blog/ai-solo-builder-side-project-to-saas) ### 第四階段：實戰 - [第 13 章：實戰案例——我的四個產品](/blog/ai-solo-builder-case-studies) - [第 14 章：Solo Builder Checklist——你的產品及格了嗎](/blog/ai-solo-builder-checklist)（你在這裡）Solo BuilderChecklist總整理學習路線圖https://bobochen.dev/blog/ai-solo-builder-case-studies/https://bobochen.dev/blog/ai-solo-builder-case-studies/紙上談兵不如看真實案例。這篇拆解我身為 Solo Builder、邊上班邊做的四個產品——bobo-blog 部落格、cloud-on-academy 課程平台、course-forge CLI 工具、code-fossil YouTube 頻道——每個產品的 AI 使用紀錄、實際時間花費、關鍵技術決策與踩坑教訓，給想一個人做產品的你一份真實參照。Sun, 03 May 2026 00:00:00 GMT## 紙上談兵結束，四個 Solo Builder 產品的真實拆解 前 12 章，我們走過了從點子驗證到 Micro SaaS 的完整流程。理論講了很多，框架也建了不少。 但你心裡可能有個問題：「這些真的有人照著做過嗎？」 有。就是我自己。 這一章我要完整拆解我邊上班邊做的四個產品。這不是精心包裝的成功故事，而是真實的時間花費、真實的技術決策、真實的 AI 使用方式，還有真實的踩坑紀錄。 每個產品我會告訴你： - **做了什麼**：產品概述與技術棧 - **關鍵決策**：那些影響最大的選擇 - **AI 怎麼用**：具體的使用場景和效果 - **時間花費**：一個有正職的人實際的投入量 - **收穫與教訓**：什麼做對了、什麼做錯了 準備好了嗎？我們從第一個開始。 --- ## 產品一：bobo-blog — 個人部落格 ### 概述 | 項目 | 內容 | | -------- | ---------------------------------------------------------- | | 類型 | 個人技術部落格 | | 技術棧 | Astro 6 + Cloudflare Workers + Tailwind CSS 4 + TypeScript | | 狀態 | 上線運行中 | | 開發時間 | 初版約 2 個月，之後持續迭代 | | 營收模式 | 內容行銷 → 導流到課程平台 | 一個部落格，看起來是最「無聊」的產品。但對 Solo Builder 來說，部落格是所有產品的地基。它是你的 SEO 入口、信任基礎、和內容分發中心。 ### 關鍵決策：為什麼選 Astro 而不是 Next.js 這個決定我花了不到 30 分鐘。回顧[第 3 章的技術選型原則](/blog/ai-solo-builder-tech-stack/)： | 考量 | Next.js | Astro | | -------------- | --------------------- | --------------------------------- | | 內容型網站效能 | SSR/ISR，需要伺服器 | 靜態優先，零 JS 預設 | | 互動需求 | 內建 React | Island Architecture，需要時才載入 | | 部署成本 | Vercel 免費方案有限制 | Cloudflare Pages 完全免費 | | 學習曲線 | 熟悉 React 即可 | 簡單的模板語法 | | AI 友善度 | 高 | 高（Astro 的寫法接近 HTML） | | 建置速度 | 較慢 | 極快 | 部落格 90% 是靜態內容。我不需要 React 的 hydration、不需要 server component、不需要 API route。Astro 的「零 JS 預設」正好符合需求——頁面載入快、Lighthouse 分數高、SEO 友善。 需要互動的地方（暗色模式切換、搜尋功能），用 Astro 的 island architecture 局部載入就好。整個站的 JavaScript 可能不到 50KB。 教訓是：不要因為「以後可能需要」而選更重的框架。你以後真的需要了，再加就好。Astro 支援 React、Vue、Svelte 的 island，隨時可以混搭。 ### 關鍵決策：為什麼選 Cloudflare Workers 而不是 Vercel 這個決策跟[第 3 章「選生態系不選框架」](/blog/ai-solo-builder-tech-stack/)的原則直接相關。 | 考量 | Vercel | Cloudflare | | ------------- | -------------- | ---------------------- | | 免費額度 | 100 GB 頻寬/月 | 無限靜態頻寬 | | Edge Function | 有限制 | Workers 10 萬次/天免費 | | 附加服務 | 需要外接 | D1、R2、KV 全家桶 | | 自訂域名 | 支援 | 支援（還能管 DNS） | | 全球延遲 | 美國為主 | 300+ 邊緣節點 | 決定性的因素是 **Cloudflare 是一個完整的生態系**。DNS、CDN、Workers、D1 資料庫、R2 儲存、KV 快取，全部在同一個平台，免費額度非常慷慨。 我的部落格只是起點。後來的課程平台也部署在 Cloudflare，共用同一套工具鏈。如果我當初選了 Vercel，後面每個產品都要重新考慮部署平台。 ### AI 怎麼用 在 bobo-blog 這個專案，AI 的使用場景出乎意料地多： **1. 內容生成管線** 我用 Claude Code 建立了一套從大綱到完稿的寫作流程。不是讓 AI 幫我寫文章——而是用 AI 來加速「從想法到結構化草稿」的過程。 傳統做法：開一個空白文件，從第一段開始寫，寫到一半覺得結構不對，重新來。一篇 3000 字的文章要花一整個週末。 AI 加持做法： ```text 我要寫一篇關於 [主題] 的技術文章。 目標讀者：[描述] 文章長度：約 3000 字 請幫我： 1. 列出 5-7 個可能的切入角度 2. 推薦最適合的結構（教學型 / 比較型 / 故事型） 3. 為推薦的結構列出詳細大綱 4. 每個段落的核心論點是什麼 ``` 拿到大綱之後，我自己填肉。AI 負責結構，我負責觀點和經驗。這樣一篇文章從一個週末壓縮到 2-3 小時。 **2. 社群卡片自動生成** 每篇文章都需要一張 Open Graph 社群分享圖。手動用 Figma 做一張要 20 分鐘。我用 AI 幫我寫了一個 TypeScript 腳本（`scripts/generate-social-cards.ts`），根據文章標題和標籤自動產生風格統一的社群卡片。 **3. blog-images 半自動工具** 文章裡的技術截圖需要統一的樣式和尺寸。我用 Claude Code 幫我寫了 `scripts/blog-images.ts`，結合 Playwright 做螢幕截圖自動化。 **4. 元件開發加速** 部落格的 UI 元件——GlassCard、MegaMenu、PostCard——每個都是先用 AI 生成骨架，再手動調整細節。特別是 Tailwind CSS 的 utility class 組合，AI 可以省掉大量查文件的時間。 ### 時間花費 | 階段 | 時間投入 | | ------------------------------------ | ---------------------- | | 技術選型 + 架構設計 | 1 天 | | 基礎建設（布局、路由、樣式系統） | 2 週（每週約 10 小時） | | 核心功能（文章渲染、暗色模式、搜尋） | 2 週 | | 系列書功能、Mega Menu | 2 週 | | 內容生成工具鏈 | 1 週 | | 持續迭代 | 每週 2-3 小時 | 總共大約 2 個月做完初版，之後每週花 2-3 小時維護和寫新內容。 --- ## 產品二：cloud-on-academy — GCP 認證課程平台 ### 概述 | 項目 | 內容 | | -------- | ------------------ | | 類型 | 線上課程平台 | | 技術棧 | Astro + Cloudflare | | 狀態 | 上線運行中 | | 開發時間 | 課程內容持續產出中 | | 營收模式 | 付費課程 | 這是我的第一個有直接營收的產品。在[第 2 章](/blog/ai-solo-builder-idea-validation/)我分享過它的驗證故事——繁中市場的 GCP 認證課程幾乎是空白。這個市場空白就是我的機會。 ### 驗證到上線的完整旅程 **驗證階段（1 天）：** 在 PTT、iThome、技術社群搜「GCP 認證中文」，發現大量需求但幾乎沒有系統化的繁中資源。做了一個簡單的 Landing Page，一週內收到足夠的表單填寫。 **MVP 階段（3 週）：** 不等課程「全部做完」就上線。先放前三堂課的內容，然後每週更新。 這是我做對的最重要的事。 ### 關鍵決策：不等「完美」就上線 傳統做法：花三個月準備完整的課程內容，錄影、剪輯、上字幕，全部做好才上線。 我的做法：先做文字版課程，搭配程式碼範例和截圖。三堂課做好就公開預售。 為什麼這樣做？ 1. **驗證付費意願比驗證內容品質更急迫。** 你的課程內容再好，沒人願意付費就是零。 2. **早期學員的回饋比你自己的判斷更準確。** 第一批學員告訴我哪些章節太難、哪些太簡單、哪些他們根本不需要。 3. **持續更新反而是賣點。** 「這門課一直在更新」對學員來說是正面的信號。 ### AI 怎麼用 **1. 課程大綱設計** ```text 我要設計一門 GCP Associate Cloud Engineer 認證的線上課程。 目標學員：有 1-3 年後端經驗的台灣工程師，準備考 ACE 認證。 請幫我： 1. 根據 Google 官方考試大綱，列出所有需要涵蓋的知識點 2. 建議課程結構（模組、章節、順序） 3. 每個章節建議的學習時間 4. 標記哪些是「必考高頻」、哪些是「偶爾出現」 5. 建議的實作練習 ``` AI 生成的大綱不能直接用——它缺少「考試實戰」的洞察。但它幫我省了從零規劃的時間。我根據自己考過認證的經驗大幅修改，把「理論上應該教」和「考試真的會考」對齊。 **2. 練習題生成** 每個章節結尾的練習題，我用 AI 生成初稿，然後自己審核和修改。這是 AI 最適合的場景之一——生成大量結構化的內容，然後由人類把關品質。 **3. 錯誤解說生成** 學員最常問的問題是「這題為什麼答案不是 B」。我用 AI 幫每個錯誤選項寫解說——為什麼看起來合理但實際上不對。這種「逆向解說」非常耗時，但 AI 做得又快又好。 ### 時間花費 | 階段 | 時間投入 | | ----------------------- | ---------------------- | | 市場驗證 + Landing Page | 1 天 | | 平台建設（Astro 搭建） | 1 週 | | 前三堂課內容 | 2 週（每週 8-10 小時） | | 上線並開始收費 | 第 3 週 | | 持續更新課程內容 | 每週 5-8 小時 | ### 教訓 最大的教訓是我花太多時間在平台建設上。第一版其實用 Notion + Gumroad 就可以賣了。我不需要自己建課程平台，但工程師的本能就是想自己做。 如果重來一次，我會先用現成工具驗證（Notion 做內容、Gumroad 收費），確認有穩定需求之後再建自己的平台。 --- ## 產品三：course-forge — 內容自動化 CLI 工具 ### 概述 | 項目 | 內容 | | -------- | -------------------- | | 類型 | CLI 工具 | | 技術棧 | TypeScript + Node.js | | 狀態 | 開發中 | | 開發時間 | 持續迭代 | | 營收模式 | 開源 → 顧問諮詢導流 | course-forge 是一個完全不同類型的產品。它不是面向終端用戶的 SaaS，而是一個我自己先用、順便開源的 CLI 工具。 ### 為什麼要做一個自己用的工具 做 bobo-blog 和 cloud-on-academy 的過程中，我反覆遇到同樣的問題： - 寫一篇技術文章需要：大綱、內文、程式碼範例、截圖、社群卡片、SEO metadata - 做一堂課需要：大綱、課程內容、練習題、投影片 - 每次都是手動一步一步來，流程重複但又沒有完全自動化 course-forge 就是把這些重複的內容產製流程打包成一個 CLI。 ```bash # 從大綱生成部落格文章骨架 course-forge blog generate --outline ./outline.yaml # 從課程大綱生成練習題 course-forge quiz generate --chapter 3 # 批次生成社群卡片 course-forge social-cards --posts ./src/content/blog/ ``` ### 關鍵決策：CLI 而不是 Web UI 我一開始有考慮做 Web UI。一個漂亮的 Dashboard，可以拖拉管理內容管線。 但我很快放棄了這個想法，原因是： | 考量 | Web UI | CLI | | ------------ | ------------------ | -------------------------- | | 開發時間 | 數週到數月 | 數天到數週 | | 維護成本 | 前端 + 後端 + 部署 | 單一 npm package | | 彈性 | 被 UI 限制 | 可以串進任何 pipeline | | AI 整合 | 需要額外設計 | 直接在 terminal 跟 AI 互動 | | 我自己會用嗎 | 可能不會（太慢） | 每天都在用 | 最後一點最關鍵。我是工程師，我的工作流程在 terminal。做一個我自己不會日常使用的工具，根本就是在浪費時間。 原則就是：先做你自己會天天用的版本。如果連你自己都不想用，別人更不會想用。 ### AI 怎麼用 course-forge 本身就是一個 AI 增強的工具，所以「AI 怎麼用」在這裡有雙重含義： **開發層面：** 整個 CLI 框架是用 Claude Code 搭建的。我描述每個 command 的行為，AI 生成初版程式碼，我 review 和修改。TypeScript CLI 是 AI 非常擅長的領域——Commander.js 的 API 很直覺，AI 生成的品質很高。 **產品層面：** course-forge 的核心功能就是串接 AI API 做內容生成。例如「從大綱生成文章骨架」這個功能，背後就是呼叫 Claude API，帶上一組精心設計的 prompt template。 我把自己在寫文章時反覆使用的 prompt 封裝成工具的一部分。這樣每次用的時候不需要重新組裝 prompt。 ### 時間花費 | 階段 | 時間投入 | | ---------------------------- | --------------------- | | 需求整理（從自己的痛點歸納） | 2 小時 | | CLI 骨架搭建 | 1 天 | | 核心 command 實作 | 1 週（每週 6-8 小時） | | prompt template 調校 | 持續進行 | | 文件撰寫 + 開源準備 | 3 天 | ### 教訓 開源專案的「最小可用版本」比你想的還小。我一開始想把所有功能都做好再開源，結果拖了很久。後來我只放了兩個 command 就 push 到 GitHub，然後慢慢加功能。 先公開、再完善。沒人期待一個開源 CLI 工具在第一版就完美。 --- ## 產品四：code-fossil — YouTube 頻道品牌 ### 概述 | 項目 | 內容 | | -------- | --------------------------------- | | 類型 | YouTube 頻道 / 媒體品牌 | | 技術棧 | Remotion（影片）、AI（研究/腳本） | | 狀態 | 經營中 | | 開發時間 | 持續產出 | | 營收模式 | YouTube 廣告收入 + 品牌建立 | code-fossil 是四個產品中唯一不是 SaaS 的。它是一個 YouTube 頻道品牌，定位是「軟體考古學家」——挖掘那些被遺忘的技術史故事。 為什麼一個 Solo Builder 要做影片內容？因為媒體品牌是所有產品的流量來源。 部落格靠 SEO 帶來穩定但慢速的流量。YouTube 頻道可以帶來爆發式的關注。兩者互補。 ### 關鍵決策：雙頻道策略 我同時經營兩個頻道： - **Bobo 柏宏**：面向台灣工程師，分享職涯和技術觀點，用中文 - **Code Fossil**：面向全球觀眾，講軟體歷史故事，用英文 為什麼不合成一個？因為受眾完全不同。中文觀眾想看的是「GCP 認證怎麼準備」，英文觀眾想看的是「為什麼 PHP 被誤解了 20 年」，硬塞在同一個頻道只會兩邊都不討好。 | 考量 | 單一頻道 | 雙頻道 | | ------------ | -------------- | -------------------------- | | 內容一致性 | 混亂 | 各自清晰 | | 觀眾預期 | 難管理 | 容易滿足 | | 演算法友善度 | 低（主題跳躍） | 高（主題集中） | | 工作量 | 看似省力 | 實際上更高效（素材可複用） | | 交叉導流 | 不適用 | 互相引流 | 兩個頻道可以交叉導流：Code Fossil 的觀眾可能對我的技術觀點有興趣，Bobo 柏宏的觀眾可能對軟體歷史有興趣。一加一大於二。 ### AI 怎麼用 影片製作是 AI 使用密度最高的產品： **1. 研究階段** ```text 我要做一支影片，主題是「[技術歷史主題]」。 請幫我研究： 1. 時間線：關鍵事件的年份和背景 2. 人物：核心開發者是誰、他們的背景 3. 技術細節：為什麼當時做了這個設計決策 4. 有趣的軼事或衝突 5. 現代的影響：這個決策如何影響今天的技術 ``` 一個影片的研究量可能需要讀 10-20 篇文章和論文。AI 幫我彙整資料，我再去源頭驗證關鍵事實。 **2. 腳本撰寫** 研究完成後，我用 AI 生成腳本的結構草稿。但最終版本一定是我自己重寫——因為影片腳本需要個人語氣和節奏感，這是 AI 目前還做不好的。 **3. 影片描述和 SEO** 每支影片的描述、標籤、時間戳——這些「必要但無聊」的工作全部交給 AI。 **4. 縮圖概念發想** ```text 這支影片的標題是「[標題]」。 請提供 5 個 YouTube 縮圖的概念，考慮： - 點擊率最大化 - 與標題的搭配 - 視覺對比和可讀性 ``` ### Remotion：用程式碼做影片 值得一提的是技術選型。我用 Remotion 做部分影片——它是一個用 React 寫影片的框架。 為什麼不用 Premiere Pro？因為： - 我不擅長影片剪輯軟體 - 但我很擅長寫程式碼 - Remotion 讓我用 TypeScript + React 來定義動畫和轉場 - AI 可以幫我生成 Remotion 的程式碼 - 同一套模板可以批次生成不同內容的影片片段 Solo Builder 原則再現：選你最擅長的工具，而不是「業界標準」的工具。 ### 時間花費 | 項目 | 每支影片時間投入 | | ------------------ | ------------------- | | 研究 + 資料收集 | 2-3 小時（AI 輔助） | | 腳本撰寫 + 修改 | 2-3 小時 | | 影片製作 + 剪輯 | 3-4 小時 | | 縮圖 + 描述 + 上傳 | 1 小時（AI 輔助） | | **每支影片合計** | **8-11 小時** | 以每兩週產出一支影片的頻率，每週投入約 4-6 小時。 --- ## 四個產品的共同模式 回頭看這四個產品，有幾個反覆出現的模式： ### 模式 1：全部用同一套技術棧 四個產品都用 TypeScript。部落格和課程平台都用 Astro + Cloudflare。CLI 工具是 Node.js + TypeScript。連影片都用 Remotion（React + TypeScript）。 這不是巧合。**一種語言打天下**的好處在這裡完全體現——在 A 產品學到的東西，可以直接用在 B 產品。 > 但這招有代價，我得老實講。把四個產品全押在 TypeScript + Astro + Cloudflare，本質上是 all-in 同一個生態系——哪天 Cloudflare 漲價、Astro 大改版、或某個服務說收就收，我是四條產線一起中槍，不是分散風險。技能樹也只長一邊：我這幾年沒被逼著去碰 Go、Rust、或別人的雲，職涯廣度其實是縮的。對「一個人」來說，集中下注的脆弱反而比團隊更高，因為沒有別人替你補另一個生態系的洞。 > > 所以「選生態系不選框架」對我是預設，不是鐵律。兩種情況我會故意破例：一是某個產品的需求明顯衝出 Astro/Workers 的甜蜜區（要長時間跑的後端任務、重 SSR、複雜 stateful 服務），硬塞只是自找麻煩；二是我想拿 side project 來練新東西——這時候「不能複用舊知識」剛好是重點，不是缺點。有正職、求快、求複用時統一技術棧很划算；想擴展能力或場景不對時，該換就換。 ### 模式 2：AI 用在「結構化」的工作上 四個產品中，AI 發揮最大價值的都是結構化的工作：大綱生成、練習題生成、研究彙整、metadata 產出。 而最核心的「創意判斷」——文章的觀點、課程的教學邏輯、影片的敘事節奏——都是我自己做的。 AI 處理 80% 的苦工，你專注 20% 的判斷。這個比例在每個產品都一樣。 ### 模式 3：先上線、再完善 四個產品沒有一個是「完成」了才上線的： - bobo-blog：先有基本版面和三篇文章就上線 - cloud-on-academy：三堂課就開始收費 - course-forge：兩個 command 就推上 GitHub - code-fossil：第一支影片品質遠不如現在 先 ship，再完美。這是[第 1 章 Solo Builder 宣言](/blog/ai-solo-builder-manifesto/)的核心，也是我每個產品都遵循的原則。 ### 模式 4：產品之間互相餵養 這四個產品不是獨立的——它們形成一個生態系： ```text bobo-blog（部落格）→ SEO 流量 → cloud-on-academy（課程）→ 營收 ↑ | | ↓ code-fossil（YouTube）→ 品牌認知 course-forge（工具）→ 提升生產力 ``` 部落格的文章為課程平台導流。YouTube 頻道建立品牌認知度。course-forge 提升所有內容的生產效率。每個產品都在強化其他產品。 **Solo Builder 的最佳策略不是做一個很大的產品，而是做幾個互相加分的小產品。** > 在你把這四個模式抄進筆記本之前，我得先承認一件事：這是 n=1，全部是我一個人、一條路徑跑出來的，而且這些「模式」是我**回頭看**才整理出來的事後敘事——倖存者偏誤的味道很重。我沒辦法給你對照組：照這樣做卻失敗的人有多少，我不知道，因為他們不會寫這種文章。 > > 給你幾個誠實的數字校準期待：cloud-on-academy 是唯一有直接營收的，但離「靠它過活」還早得很；code-fossil 的 YouTube 訂閱到現在還在三位數；course-forge 還掛在「開發中」，沒有外部使用者。所以這篇請當成「一個人這樣安排還算順手」的紀錄，不是「照做就會成功」的保證。前面那句「這是我做對的最重要的事」，更準確的講法是「回頭看，這件事我沒做錯」——做對和沒做錯之間，差的就是那個我給不出來的對照組。 --- ## 我犯過的錯 & 如果重來一次 ### 錯誤 1：太早自建平台 cloud-on-academy 一開始就自己用 Astro 建了課程平台。如果重來，我會先用 Notion + Gumroad 賣前三堂課，確認付費意願後再自建。省下的兩週可以多寫五堂課。 ### 錯誤 2：過度設計部落格功能 bobo-blog 初版花了太多時間在 Mega Menu、系列書側邊欄等進階功能。第一版只需要「能顯示文章」就好。那些花俏的功能可以慢慢加。 ### 錯誤 3：完美主義延遲了 course-forge 的開源 我想等功能更完整再開源，結果拖了好幾週。早點開源、早點收到回饋，比在角落裡默默打磨更有價值。 ### 錯誤 4：低估了影片的時間投入 code-fossil 剛開始時，我以為每支影片 4-5 小時可以搞定。實際上是 8-11 小時。如果你時間真的很緊，文字內容（部落格、電子報）的 ROI 遠高於影片。 ### 如果重來一次的優先順序 1. **先做部落格**（最低成本、最快上線、SEO 是長期資產） 2. **邊寫文章邊驗證課程需求**（部落格文章就是課程的 beta 版內容） 3. **確認有人付費後再建課程平台**（先用現成工具賣） 4. **自動化工具在第三個月之後才開始做**（先手動跑完流程，確認哪些步驟值得自動化） 5. **YouTube 放到最後**（時間投入最高、回報週期最長） --- ## 本章重點回顧 - 🏗️ 四個產品全部用同一套技術棧（TypeScript + Astro + Cloudflare），最大化知識複用 - 🤖 AI 在每個產品都用在「結構化的苦工」上——大綱、練習題、研究、metadata——而不是核心判斷 - 🚀 每個產品都是「先上線再完善」，沒有一個是等到完美才公開的 - 🔄 四個產品互相餵養，形成生態系而不是獨立的 side project - ⚠️ 最大的教訓：不要太早自建、不要過度設計、不要追求完美才上線 - ⏱️ 有正職的 Solo Builder，優先做「時間投入低、長期回報高」的產品（部落格 > 課程 > 工具 > 影片） ## 下一步 看完了真實案例，接下來是全書的最後一章。 我為你準備了一份 **Solo Builder Checklist**——從點子驗證到上線營運，一份可操作的檢查清單。不管你的產品在哪個階段，都可以用這份清單來檢查你有沒有遺漏什麼關鍵步驟。 👉 [第 14 章：Solo Builder Checklist——你的產品及格了嗎](/blog/ai-solo-builder-checklist)Solo Builder案例分析AI實戰經驗產品開發https://bobochen.dev/blog/ai-solo-builder-side-project-to-saas/https://bobochen.dev/blog/ai-solo-builder-side-project-to-saas/你的 Side Project 開始有陌生人付費,下一步呢?這篇談 Micro SaaS 的 PMF 信號、用「10 倍價值」法則定價、零行銷預算成長、台灣行號與公司的法律稅務結構,以及「該不該離職」的三道門檻,幫你判斷下一步該怎麼走、何時該認真經營。Sun, 26 Apr 2026 00:00:00 GMT## 你收到了第一筆陌生人的付款 某天晚上，你的手機跳出一封 Stripe 通知： 「You have a new payment of $9.99 from someone@example.com」 你不認識這個人。他不是你的朋友、不是你的同事、不是你在社群裡拜託的人。他是一個完全陌生的人，在網路上找到了你的產品，認為它值 $9.99，然後付了錢。 如果你有過這個經驗，你知道那種感覺——比第一次拿到薪水還興奮。 接下來你的腦子會開始轉： 「如果一個月有 100 個人付 $9.99，那就是 $999。如果有 1000 個人……等等，我是不是該認真做這件事？要不要辭職？要不要開公司？」 慢下來。 從「收到第一筆付款」到「可以辭職全職做」之間，有一段很長的路。大多數 side project 的結局不是變成獨角獸——而是穩定地每月賺幾百到幾千美元，讓你的生活多一份收入來源。 這一章要幫你想清楚：**你的 side project 到了什麼程度？下一步應該做什麼？** ## 轉折點：什麼信號代表「該認真了」 不是每個 side project 都值得更認真對待。很多 side project 收到幾筆付款之後就停滯了——不是產品不好，而是市場太小、時機不對、或者你本人對這個領域的熱情不夠支撐長期投入。 以下是幾個正向信號： ### 信號 1：留存率 > 獲取率 **這是最重要的信號。** 如果你的用戶來了又走，你需要的不是更多行銷——你需要修產品。但如果用戶來了就留下來，而且一個月後還在用，你手上可能有了 product-market fit。 | 指標 | 健康範圍 | 意義 | | --------------- | -------- | ------------------ | | 月留存率（D30） | > 40% | 用戶一個月後還在用 | | 週活躍用戶比例 | > 25% | 不是裝了就忘 | | 付費轉換率 | > 2% | 有人願意為價值付費 | | 自然流失率 | < 5%/月 | 用戶不是被你趕走的 | 你不需要精確到小數點。重點是趨勢——留存率是在上升還是下降？ ### 信號 2：用戶主動推薦 你沒有做任何行銷，但新用戶告訴你「是朋友推薦的」。 這是最強的 PMF 信號。因為用戶願意把自己的社交信用押在你的產品上——他們不只覺得好用，還覺得好到值得推薦。 ### 信號 3：你收到「如果你關掉這個產品我怎麼辦」的訊息 當用戶開始擔心你的產品消失，代表他們已經把你的產品融入了自己的工作流程。這是依賴性——也是你最大的資產。 ### 信號 4：你開始拒絕用戶的功能要求 不是因為你沒時間做，而是因為你對產品有了清晰的 vision，你知道什麼該做、什麼不該做。 當你開始有信心說「不」的時候，代表你對產品和市場的理解已經足夠深了。 ### 什麼不算信號 - ❌ 「很多人說很酷」——說很酷和願意付費是兩回事 - ❌ 「Product Hunt 上了首頁」——一次性的流量 spike 不代表持續的需求 - ❌ 「投資人有興趣」——投資人有興趣不代表用戶有需求 - ❌ 「技術很厲害」——用戶不在乎你的技術多厲害 ## 定價策略：不只是挑一個數字 [第 8 章：付費機制——一個人怎麼收錢](/blog/ai-solo-builder-payment/)我們談了金流串接和基本的定價模式。現在你的產品有了真實用戶，是時候更認真地思考定價了。 ### 兩種定價哲學 | | 成本定價 | 價值定價 | | -------- | ------------------------------ | ------------------------------------- | | **邏輯** | 我的成本是 X，加上利潤 = 售價 | 用戶從中得到的價值是 Y，收 Y 的一部分 | | **公式** | 伺服器成本 + 時間成本 + 利潤 | 用戶獲得的價值 × 10-20% | | **問題** | 通常定太低——你的時間被嚴重低估 | 需要理解用戶的價值感知 | | **適合** | 成本結構清晰的產品 | 大多數 SaaS 產品 | **Solo Builder 最常犯的錯是用成本定價。** 你算了一下：伺服器每月 $5，我每週花 5 小時，一個月 20 小時……然後你定了一個超低的價格，因為你覺得「我又不是什麼大公司」。 錯。 你的產品不是在賣伺服器時間和你的工時。你的產品是在**賣用戶獲得的價值**。 ### 「10 倍價值」法則 這是定價最實用的經驗法則： **你的產品應該為用戶創造至少 10 倍於價格的價值。** 如果你的產品每月收 $10，它應該幫用戶省下至少 $100 的時間、金錢或痛苦。 反過來算：你的產品幫用戶省了多少？把那個數字除以 10，就是你的起始定價。 ### AI 輔助定價研究 不確定怎麼定價？讓 AI 幫你分析： ```text 我的產品是 [描述]，目標用戶是 [描述]。 目前的使用數據： - 月活躍用戶：[數量] - 免費用戶中有 [X]% 每週使用超過 3 次 - 用戶平均使用時長：[分鐘/次] - 最常用的功能是：[列出] 競品定價： - [競品 A]：$X/月 - [競品 B]：$Y/月 - [競品 C]：免費（有廣告） 請幫我分析： 1. 我的產品為用戶創造的價值估計（時間節省、金錢節省、 或其他可量化的好處） 2. 基於「10 倍價值」法則，建議的定價範圍 3. 建議的方案結構（幾個方案、每個方案包含什麼） 4. 免費版和付費版的功能分界線建議 5. 年繳折扣策略 6. 第一年的收入預估（基於不同轉換率假設） ``` ### 定價的三個不要 1. **不要定價 $1-3/月**：太便宜的價格傳遞「這東西不值錢」的訊號。而且你需要 1000 個付費用戶才能有 $1000-3000 的月收入——對一個人來說太難了 2. **不要一開始就做 lifetime deal**：除非你的成本結構允許。很多 Solo Builder 做 lifetime deal 吸引到一大批「只買便宜」的用戶，之後服務成本拖垮整個產品 3. **不要害怕漲價**：如果你的轉換率超過 10%，代表你定太低了。漲價試試——最壞的情況是降回去 ## 沒有行銷預算的成長 你是一個人，你沒有行銷部門，也沒有廣告預算。但你需要成長。 好消息是：2026 年最有效的成長策略，大部分都是免費的。 ### 策略 1：內容行銷（[第 7 章：Landing Page 與 SEO](/blog/ai-solo-builder-landing-page-seo/) 的延伸） 你已經在[第 7 章：Landing Page 與 SEO](/blog/ai-solo-builder-landing-page-seo/)建立了 SEO 基礎。現在把它系統化： - **每週發一篇文章**：鎖定你的目標用戶會搜尋的關鍵字 - **文章結尾自然帶入你的產品**：不是硬廣告，而是「順便一提，我做了一個工具來解決這個問題」 - **建立 email list**：在文章中加入訂閱表單，累積直接觸及用戶的管道 內容行銷是 Solo Builder 最高 CP 值的成長方式。一篇好文章可以帶來好幾年的自然流量。 ### 策略 2：推薦計畫 讓現有用戶幫你拉新用戶。 最簡單的推薦計畫：「推薦朋友註冊，你和朋友都獲得一個月免費。」 不需要複雜的 referral 系統。一開始手動處理就好——用戶寄 email 告訴你他推薦了誰，你手動加免費月份。 ### 策略 3：在用戶出沒的地方被看見 - **回答 Stack Overflow / Reddit 的相關問題**：不是貼廣告，而是認真回答問題，然後在最後提到你的工具 - **在相關社群提供價值**：分享你的學習心得、技術筆記。人們會自然好奇你做了什麼 - **參與開源**：如果你的產品有開源部分，活躍在 GitHub 上 ### 不要做的事 - ❌ 一開始就投 Google Ads / Facebook Ads（太貴，轉換率未經驗證） - ❌ 同時經營五個社群媒體帳號（選一個深耕） - ❌ 花錢請 KOL 推廣（你的規模還不到需要這個的階段） ## 台灣的法律結構：什麼時候該「合法化」 你的產品開始穩定收費了。在台灣，這代表你需要處理一些法律問題。 > **幣別說明**：以下金額為新台幣（NT$），與前文以美元（US$）計的訂閱價與營收門檻不同，請留意。 ### 三種選擇 | | 個人 | 行號 | 有限公司 | | ------------ | --------------- | ------------------ | ----------------------------- | | **設立成本** | NT$0 | ~NT$3,000-5,000 | ~NT$15,000-30,000 | | **統一編號** | 無 | 有 | 有 | | **可開發票** | 不行 | 可以 | 可以 | | **責任範圍** | 無限責任 | 無限責任 | 有限責任 | | **稅率** | 綜所稅（5-40%） | 月銷售額未達 NT$20 萬：1% 營業稅（查定課徵、免開發票）；達 NT$20 萬以上：5% 營業稅 + 綜所稅 | 營所稅 20% | | **適合** | 月收 < NT$8,000 | 月收 NT$8,000-50,000 | 月收 > NT$50,000 或需要有限責任 | > 補充：行號/公司是否開發票、課 1% 還是 5% 營業稅，取決於月銷售額級距。月銷售額未達 NT$20 萬的「小規模營業人」（多數剛開始穩定收費的 side project 屬此）由國稅局每三個月查定課徵 1% 營業稅、免用統一發票；月銷售額達 NT$20 萬以上才使用統一發票、課 5% 營業稅。所以上表「可開發票/5%」是達到使用發票門檻後的情況。 ### 什麼時候該行動 | 月營收 | 建議 | | ------------------ | ---------------------------- | | < NT$8,000/月 | 以個人身份申報，不用特別處理 | | NT$8,000-20,000/月 | 考慮設立行號 | | > NT$20,000/月 | 認真考慮設立有限公司 | | 有企業客戶需要統編 | 馬上設立行號或公司 | **重要提醒**：以上是簡化的參考，不是法律建議。當你的月營收穩定超過 NT$8,000，找一個會計師諮詢。會計師的費用（每月 NT$2,000-5,000）遠低於你自己搞稅務出錯的代價。 ### 稅務的基本認知 在你找會計師之前，至少理解這些： - **個人綜合所得稅**：你的產品收入歸入「營利所得」或「執行業務所得」，跟你的薪資加在一起計算稅率 - **營業稅**：設立行號或公司後，銷售額需要加收 5% 營業稅 - **二代健保補充保費**：如果你的執行業務所得單筆超過 NT$20,000，需要扣繳 2.11% 補充保費（2026 年費率）。注意部分兼職／單次給付未達當年度基本工資（2026 年為 NT$29,500）者另有免扣規定，細節問會計師 不要被這些嚇到。先專注把產品做好、把收入做起來。法律和稅務的問題，等你有穩定收入再處理。 ## 「該不該離職」決策框架 每個做 side project 做出成績的人，遲早會面對這個問題。 我的建議是：**不要太早做這個決定。** 大多數 Solo Builder 高估了全職做產品的好處，低估了失去穩定收入的壓力。 ### 離職前的三個門檻 你應該同時滿足以下三個條件，才認真考慮離職： **門檻 1：財務安全墊** - 銀行裡有 **12 個月的生活費**（不靠產品收入也能活一年） - 產品連續 **6 個月** 有穩定或成長的收入 - 產品月收入 ≥ 你月薪的 **50%** **門檻 2：可逆性評估** 問自己：如果全職做一年後失敗了，我能回到現在的位置嗎？ | 因素 | 低風險 | 高風險 | | -------- | ---------------------------- | -------------- | | 就業市場 | 你的技術搶手，隨時能找到工作 | 你的領域縮編中 | | 家庭狀況 | 單身或雙薪無小孩 | 單薪養家 | | 年齡 | < 35 歲 | > 45 歲 | | 存款 | > 24 個月生活費 | < 12 個月 | | 產品趨勢 | 連續成長 | 持平或波動 | 如果你的大部分因素在「高風險」那一欄，先不要離職。 **門檻 3：混合路徑可不可行** 在「全職上班」和「辭職 all-in」之間，還有一個選項：**跟老闆談轉兼職或遠端。** | 路徑 | 優點 | 缺點 | | ----------------- | ----------------- | ------------ | | 繼續全職 + 下班做 | 零風險 | 時間有限 | | 轉兼職（60-80%） | 多出 1-2 天做產品 | 收入減少 | | 轉遠端全職 | 通勤時間省下來 | 需要老闆同意 | | 離職全職做 | 時間最多 | 風險最高 | **我的建議順序**：先談遠端 → 再談兼職 → 最後才考慮離職。 很多人以為只有「留下」或「走」兩個選項。但混合路徑往往是最聰明的選擇——你保留了安全網，同時多出了做產品的時間。 ## 不靠招人的 Scale 你的產品成長了，事情越來越多。你的直覺可能是「我需要找人幫忙」。 先等一下。 在 2026 年，一個人能做的事比以前多得多。在你找人之前，先問：**這件事能不能用 AI 或自動化解決？** ### 用 AI 替代人力的場景 | 傳統做法 | AI 替代方案 | 省下的時間 | | ------------ | ------------------------- | ----------- | | 請人做客服 | AI chatbot + 回覆模板 | ~10 小時/週 | | 請人寫部落格 | AI 初稿 + 你修改 | ~5 小時/篇 | | 請人做 QA | AI 測試生成 + 自動化測試 | ~8 小時/週 | | 請人做設計 | AI 設計工具 + 模板 | ~5 小時/週 | | 請人做帳 | 會計軟體 + 會計師（外包） | 全部 | 這張表只列了「省下的時間」，但每一格其實都有沒寫出來的代價，我自己踩過才知道： - **AI 客服答錯一次，賠掉的信任很難補回來**。模板回得快，但它分不出哪句是「我想退費」哪句是「我考慮退費」，答錯一次客人就在公開平台開罵。所以我的 chatbot 只敢處理 FAQ，碰到金額、退款、情緒激動的訊息一律轉人工。 - **AI 初稿不是「寫好的文章」，是「需要查核的草稿」**。我寫過一篇被它編出一個根本不存在的數據，差點就發出去。省下的 5 小時，有一半要還回去做事實查核和改語氣，不然讀者一眼看穿是 AI 寫的。 - **AI 生的測試會給你「綠燈的安全感」**。它很會產表面覆蓋率，但常常漏掉真正會出事的 edge case，偶爾還誤報讓你浪費時間追假 bug。我把它當補網用，核心流程的測試還是自己寫。 - **AI 設計工具產出的東西長得都一樣**。套模板很快，但你的產品會跟其他一百個套同款模板的產品撞臉，品牌調性吃重的地方（首頁、定價頁、logo）我還是寧可找人。 還有一件最容易被忽略的：**自動化本身就是一份要持續維護的工作**。API 改版、模板過期、prompt 飄掉，這些都要人盯。AI 不是讓工作消失，是把「自己做事」換成「管一套會出錯的系統」——換了一種工作，不是沒有工作。 所以與其問「能不能用 AI」，更準的問法是「這件事錯了的代價有多高」。高情緒、高金額、需要專業判斷的客服，吃品牌調性的設計，還有任何法遵、合約、隱私相關的內容，這些我不會太早交給 AI。 ### 什麼時候真的需要找人 當以下情況出現時，AI 和自動化可能不夠了： - **你的客服量大到 AI chatbot 處理不了**：需要人類判斷的複雜問題超過你一個人能應付 - **你的產品需要你不會的技能**：例如你是後端工程師，但產品急需專業的 UI 設計 - **你的時間瓶頸不在「做事」而在「決策」**：你需要一個人來執行你的決策，而不是幫你做決策 - **營收足以支撐**：找人的成本不應該超過營收的 30% ### 第一個人不要找全職 你的第一個「團隊成員」應該是： 1. **外包的會計師**（處理稅務和帳務，每月 NT$2,000-5,000） 2. **按件計酬的設計師**（需要設計時才付費） 3. **兼職的客服人員**（如果客服量真的太大） 不要一開始就找全職員工。全職員工是固定成本——不管你的營收是多少，每個月都要付薪水。按件計酬或兼職的彈性高得多。 ## AI 輔助的商業決策 這一章涉及很多「該不該」的判斷。AI 可以幫你更結構化地思考： ```text 我是一個有正職的 Solo Builder，以下是我的現況： 產品：[描述] 月營收：$[金額]，過去 6 個月趨勢 [成長/持平/下降] 月活躍用戶：[數量] 付費用戶：[數量] 我的正職月薪：$[金額] 存款：[月數] 個月的生活費 家庭狀況：[描述] 每週投入產品的時間：[小時] 我在考慮 [全職做產品 / 轉兼職 / 維持現狀但投入更多]。 請幫我分析： 1. 基於數據，我的產品處於什麼階段？ 2. 從財務安全的角度，我適合做這個決定嗎？ 3. 最大的風險是什麼？怎麼降低？ 4. 如果你是我的商業顧問，你會建議什麼？ 5. 有沒有我沒考慮到的選項？ ``` AI 不會替你做決定。但它會幫你看到你可能忽略的角度——尤其是當你被興奮或焦慮蒙蔽判斷力的時候。 ## 本章重點回顧 - 🎯 PMF 的真正信號是留存率和口碑推薦，不是一次性的流量或讚美 - 💰 用「10 倍價值」法則定價：你的產品創造的價值 ÷ 10 = 起始價格 - 📈 沒有行銷預算就靠內容行銷、推薦計畫、社群曝光——全部免費 - ⚖️ 台灣法律：月收 < NT$8,000 不用特別處理，超過就找會計師 - 🚪 離職三門檻：12 個月存款 + 6 個月穩定收入 + 可逆性評估 - 🤖 找人之前先問：這件事 AI 或自動化能不能做？第一個人找外包不找全職 ## 下一步 到這裡，我們已經走完了從點子到 Micro SaaS 的完整理論框架。 但理論終究是理論。下一章，我要把話筒交給**真實案例**——完整拆解我自己邊上班邊做的四個產品，每一個的技術決策、AI 使用方式、時間花費、和我踩過的坑。 紙上談兵結束，看真的。 👉 [第 13 章：實戰案例——我的四個產品](/blog/ai-solo-builder-case-studies)Solo BuilderMicro SaaS定價策略Side Project創業https://bobochen.dev/blog/ai-solo-builder-monitoring-ops/https://bobochen.dev/blog/ai-solo-builder-monitoring-ops/產品上線不是終點，而是維運的起點。用最小化但有效的監控告警 + self-healing 自動修復，搭配 AI 故障診斷與 Runbook，讓你的產品在你睡覺、甚至休假兩週時也能穩定運行。Sun, 19 Apr 2026 00:00:00 GMT## 凌晨四點的維運噩夢 你正在做一個很好的夢，手機突然震動。 不是鬧鐘。是一封信：「您的網站 bobo-example.com 已經連續無回應 15 分鐘。」 你從床上跳起來，打開筆電，一邊揉眼睛一邊 SSH 進 server。查了 20 分鐘，發現是資料庫連線數爆了。重啟服務、清理連線、確認恢復正常。回到床上已經凌晨五點，六點半又要起床上班。 如果你做產品做得夠久，這種故事你一定經歷過。 好消息是：2026 年，一個人的維運不需要這麼痛苦。你需要的是一套**最小化但有效的監控系統**，加上**自動化的故障恢復機制**。讓產品出問題時，它先自己試著修自己，真的修不好再叫你。 ## 監控金字塔：先搞對優先順序 大公司的監控系統動輒幾十個 dashboard、上百條 alert rule。你不需要那些。 一個人做產品，監控有四個層級，按優先順序排列： ```text ┌─────────┐ │ 商業指標 │ ← 每週看一次就好 ├─────────┤ │ 效能指標 │ ← 有空再看 ├─────────┤ │ 錯誤追蹤 │ ← 每天掃一眼 ├─────────┤ │ 可用性 │ ← 最重要，必須自動告警 └─────────┘ ``` ### 層級 1：可用性監控（必做） **你的網站活著嗎？** 這是最基本也是最重要的問題。 | 工具 | 免費方案 | | ---------------------------- | -------------------- | | **UptimeRobot** | 50 個監控點 | | **Better Stack** | 10 個監控點 | | **Cloudflare Health Checks** | Pro 方案起（付費）；Free 方案僅有 Passive Origin Monitoring | 我自己的 bobo-blog 就是用 UptimeRobot，免費 50 個監控點對個人專案綽綽有餘。如果你已經在 Cloudflare 生態系裡，Health Checks 也是現成的選項。 設定方式很簡單： 1. 註冊 UptimeRobot（免費） 2. 新增你的網站 URL 和 API 健康檢查端點 3. 設定告警通知：email + Slack（或 Telegram） 4. 設定檢查頻率：每 5 分鐘 五分鐘設定完，你的網站掛了你就會知道。這是投資報酬率最高的五分鐘。 ### 層級 2：錯誤追蹤（強烈建議） 網站活著，不代表沒有錯誤。用戶可能遇到 500 error、JavaScript crash、API timeout，但因為其他功能正常所以你不知道。 **Sentry** 是 Solo Builder 的最佳選擇： - 免費方案：每月 5,000 筆錯誤事件，夠用 - 支援幾乎所有語言和框架 - 自動分組重複的錯誤 - 附上完整的 stack trace 和用戶環境資訊 ```typescript // Astro 專案整合 Sentry，一行搞定 import * as Sentry from '@sentry/astro'; Sentry.init({ dsn: 'https://xxx@sentry.io/yyy', tracesSampleRate: 0.1, // 只取樣 10%，省額度 }); ``` ### 傳統做法 vs. AI 加持做法 **傳統做法：** 1. 收到 Sentry 告警 2. 打開 Sentry dashboard 看 stack trace 3. 花 30 分鐘讀 log、找問題 4. 花 30 分鐘寫修復 5. 部署、驗證 **AI 加持做法：** 1. 收到 Sentry 告警 2. 把 error 訊息和 stack trace 丟給 Claude Code 3. AI 直接在你的 codebase 裡找到問題根因 4. AI 提出修復方案，你 review 後 approve 5. CI/CD 自動部署 同一個 bug，從一小時變成十五分鐘。 而且 Claude Code 可以做得更進階——設定一個 Sentry webhook，錯誤發生時自動觸發 AI 分析： ```text 你是一個 on-call SRE。以下是一個 production error： Error: Connection pool exhausted Stack trace: [完整 stack trace] 頻率: 過去 10 分鐘發生 47 次 影響範圍: /api/courses 端點 請分析： 1. 最可能的根本原因 2. 立即的緩解措施（不需要改 code 的） 3. 長期修復方案 4. 這個問題是否需要立即修復，還是可以等到明天 ``` ### 層級 3：效能監控（有空再做） 效能問題通常不會讓產品掛掉，但會慢慢侵蝕用戶體驗。 好消息是：如果你的產品部署在 Cloudflare Workers 或 Vercel，你已經有了免費的效能數據。 - **Cloudflare Analytics**：request count、response time、error rate、bandwidth - **Vercel Analytics**：Web Vitals（LCP、INP、CLS） - **Google Search Console**：Core Web Vitals（SEO 相關） 這些數據不需要每天看。**每週花 10 分鐘掃一眼趨勢就好。** 重點是看「有沒有突然變差」，而不是追求每一個毫秒的優化。 ### 層級 4：商業指標（每週看一次） 這不是傳統意義上的「監控」，但對 Solo Builder 來說一樣重要： - 每日活躍用戶數 - 新增註冊數 - 付費轉換率 - 流失率 這些指標告訴你產品的健康狀況——不是技術健康，而是商業健康。 用一個簡單的 Google Sheet 或 Notion database 就夠了。不需要花時間建 dashboard。 ## 告警設計：少即是多 監控最常犯的錯是**告警太多**。 如果你每天收到 20 封告警信，你會開始忽略它們。然後真正重要的告警出現時，你也會忽略。 ### 告警的黃金法則 **只在「需要你做某件事」的時候才告警。** | 情境 | 要不要告警 | 原因 | | -------------------- | ---------- | ---------------------------- | | 網站掛了 | ✅ 告警 | 需要你處理 | | 5xx 錯誤率超過 5% | ✅ 告警 | 需要你檢查 | | 回應時間超過 3 秒 | ❌ 不告警 | 記錄就好，不緊急 | | 磁碟空間超過 80% | ✅ 告警 | 需要你清理，但不急 | | 每日用戶數下降 10% | ❌ 不告警 | 每週 review 時看就好 | | SSL 憑證即將過期 | ✅ 告警 | 需要你處理（或設定自動更新） | | CPU 使用率偶爾 spike | ❌ 不告警 | 正常現象 | ### 告警通知管道 通知管道大概就 Email、Slack/Discord、Telegram Bot、SMS/電話這幾種。Email 適合當所有告警的備份，建議必開；Slack 或 Discord 適合非緊急但需要注意的事，開一個 #alerts 頻道就好；Telegram Bot 手機通知即時，隨時隨地都收得到；SMS 或電話留給網站掛掉這種極度緊急的狀況，只在深夜啟用。 我的設定是：所有告警走 Telegram Bot，只有「網站完全掛掉超過 10 分鐘」才觸發 SMS。 這樣白天我在上班時，Telegram 通知會靜靜地出現在手機上，我空閒時看一下就好。但半夜網站掛了，SMS 會叫醒我。 ## Self-Healing：讓產品自己修自己 最理想的狀態是：**問題發生了，但你根本不需要知道，因為系統自己修好了。** 這不是科幻小說。以下是幾個實用的 self-healing 模式： ### 模式 1：Health Check + 自動重啟 大部分雲端平台都支援 health check： **Cloudflare Workers**：Workers 本身是 serverless，不需要重啟；若使用 Durable Objects，可設定 alarm 作為重啟機制。 **Cloud Run**：設定 liveness probe，不健康時自動重啟 instance： ```jsonc { "livenessProbe": { "httpGet": { "path": "/health" }, "initialDelaySeconds": 10, "periodSeconds": 30, }, } ``` ### 模式 2：部署失敗自動 Rollback ```yaml # GitHub Actions - 部署後驗證，失敗就回滾 - name: Deploy run: wrangler deploy - name: Health check run: | sleep 10 STATUS=$(curl -s -o /dev/null -w "%{http_code}" https://your-site.com/health) if [ "$STATUS" != "200" ]; then echo "Health check failed! Rolling back..." wrangler rollback --message "CI auto-rollback: health check failed" exit 1 fi ``` ### 模式 3：Circuit Breaker 當外部服務（第三方 API、資料庫）出問題時，不要無限重試，而是快速失敗並降級： ```typescript // 簡單的 circuit breaker class CircuitBreaker { private failures = 0; private lastFailTime = 0; private readonly threshold = 5; private readonly resetTimeout = 60_000; // 1 分鐘 async call<T>(fn: () => Promise<T>, fallback: T): Promise<T> { if (this.failures >= this.threshold) { if (Date.now() - this.lastFailTime < this.resetTimeout) { return fallback; // 降級回應 } this.failures = 0; // 嘗試恢復 } try { const result = await fn(); this.failures = 0; return result; } catch { this.failures++; this.lastFailTime = Date.now(); return fallback; } } } ``` 這段 code 的意思是：如果某個外部服務連續失敗 5 次，就暫時放棄呼叫它，改用降級方案（例如快取的舊資料）。一分鐘後再試試看有沒有恢復。 用戶不會看到錯誤頁面，你也不會被半夜叫起來。 ## AI 輔助故障診斷 當問題真的需要你介入時，AI 是你最好的 on-call 夥伴。 ### 用 Claude Code 診斷問題 凌晨被叫起來的時候，你的腦袋是不清楚的。這時候讓 AI 幫你思考： ```text 我的產品在凌晨 3:47 開始出現以下錯誤： [貼上錯誤訊息和 log] 環境： - Cloudflare Workers - D1 資料庫 - 最近一次部署是昨天下午 3 點 請幫我： 1. 分析最可能的原因（按可能性排序） 2. 每個可能原因的驗證方式 3. 建議的修復步驟 4. 判斷這是否需要立即修復，還是可以等到早上 ``` 關鍵是最後一點：**判斷要不要現在處理。** 很多時候，半夜的問題其實沒那麼緊急——某個非核心功能出錯、某個 edge case 才會觸發的 bug。AI 可以幫你冷靜判斷。 ## 備份策略：你一定會感謝自己的 備份是最無聊的主題，但也是最重要的。 ### 備份的唯一規則 **如果你沒有驗證過 restore，就等於沒有備份。** 我見過太多人設定了自動備份，安心地跑了一年，等到真的需要 restore 時才發現備份檔案是壞的。 ### Solo Builder 的最小備份清單 | 備份對象 | 工具 | 頻率 | 驗證頻率 | | ------------------ | ---------------------------------------- | ------------ | ----------------------- | | **資料庫** | D1 自動備份 / Cloud SQL 自動備份 | 每日 | 每月測試 restore | | **程式碼** | Git（GitHub/GitLab） | 每次 commit | N/A（Git 就是版本控制） | | **設定檔** | Infrastructure as Code（wrangler.jsonc） | 隨程式碼一起 | 每次部署就是驗證 | | **用戶上傳檔案** | R2 / Cloud Storage + 跨區複製 | 即時 | 每季抽檢 | | **環境變數和密鑰** | 1Password / Bitwarden | 有變更時 | 每季確認 | ### 自動化備份驗證 用 AI 幫你寫一個簡單的備份驗證腳本： ```text 請幫我寫一個 shell script： 1. 從 D1 備份中 restore 到一個測試 database 2. 執行幾個基本查詢，確認資料完整 3. 比較備份資料的 row count 和 production 的 row count 4. 結果寄到我的 email 5. 刪除測試 database 這個 script 會用 cron 每月跑一次。 ``` ## 休假測試：你的產品能自己活兩週嗎？ 這是我用來衡量維運成熟度的測試： **如果你完全消失兩週——不看 email、不登入 server、不部署任何東西——你的產品還能正常運行嗎？** 如果答案是「不確定」，你需要補強以下幾個環節： ### 休假前的 checklist - [ ] 自動備份有在跑，且最近一次 restore 測試通過 - [ ] 監控告警設定好，會通知到手機 - [ ] SSL 憑證不會在你休假期間過期 - [ ] 沒有需要手動續約的服務（網域、雲端帳單） - [ ] 客服 auto-reply 已更新，告知回覆會延遲 - [ ] CI/CD pipeline 不需要手動 approve - [ ] 資料庫不會在兩週內把空間用完 - [ ] 帳單設定了自動扣款 如果你能自信地在每一項打勾，恭喜——你建立了一個真正自動化的產品。 ## Runbook：寫給未來的你 最後一個建議：**把你的維運步驟寫下來。** Runbook 是一份「出了某某問題，按照這些步驟處理」的文件。 你可能覺得「我自己的東西我當然記得怎麼處理」。但相信我，凌晨四點被叫起來的你，和白天清醒的你，是兩個完全不同的人。 ### AI 幫你寫 Runbook ```text 以下是我的產品架構： - 前端：Astro，部署在 Cloudflare Pages - API：Cloudflare Workers - 資料庫：D1 - 檔案儲存：R2 請幫我建立一份 Runbook，涵蓋以下常見情境： 1. 網站完全無法存取 2. API 回應時間異常 3. 資料庫連線錯誤 4. 部署失敗 5. SSL 憑證問題 每個情境包含： - 確認問題的步驟 - 排查清單（按可能性排序） - 修復步驟 - 修復後的驗證方式 ``` 把 Runbook 放在你的 repo 裡（例如 `docs/runbook.md`）。這樣你在半夜打開終端機時，第一件事不是亂猜問題在哪，而是打開 Runbook 按步驟走。 更好的做法是：**把 Runbook 也餵給 AI。** 當問題發生時，你可以跟 AI 說「參考我們的 Runbook，幫我排查這個問題」，讓 AI 幫你走流程。 ## 真實案例：bobo-blog 的監控架構 我的部落格 bobo-blog 部署在 Cloudflare Workers 上。以下是我的監控設定，給你參考： | 層級 | 工具 | 設定 | | ------ | ---------------------------- | ------------------------------- | | 可用性 | UptimeRobot | 每 5 分鐘 ping 首頁和 `/health` | | 錯誤 | Cloudflare Workers Analytics | 監控 4xx/5xx 比例 | | 效能 | Cloudflare Analytics | 每週看 P95 回應時間 | | 部署 | GitHub Actions | 部署後自動跑 health check | 為什麼這麼簡單？因為 Cloudflare Workers 是 serverless——我不需要管 server、不需要監控 CPU 或記憶體、不需要擔心 process crash。平台幫我處理了大部分的維運問題。 **這就是 [第 6 章：選對平台省 80% 的事](/blog/ai-solo-builder-deployment/) 的延伸——選對基礎架構，你的維運負擔會大幅降低。** ## 本章重點回顧 - 🏗️ 監控四層金字塔：可用性 > 錯誤追蹤 > 效能 > 商業指標，按優先順序建立 - 🔔 告警的黃金法則：只在「需要你做某件事」時才告警，否則你會開始忽略告警 - 🔧 Self-healing 模式：health check + 自動重啟、部署失敗自動 rollback、circuit breaker - 🤖 AI 是你最好的 on-call 夥伴——半夜被叫起來時，讓 AI 幫你冷靜判斷和排查 - 💾 備份的唯一規則：沒有驗證過 restore 就等於沒有備份 - 📋 寫 Runbook，寫給凌晨四點腦袋不清楚的自己 - 🏖️ 「休假測試」：如果你消失兩週，產品還能活嗎？ ## 下一步 到這裡，你的產品已經穩定運行了——有用戶在用、有客服在處理問題、有監控在守護。 接下來的問題是：**這個 side project，值不值得更認真？** 如果你開始有穩定的用戶、甚至有人付費了，你可能會想：「我是不是應該把這個東西做大？要怎麼定價？什麼時候該考慮離職全職做？」 下一章，我們來聊從 side project 到 Micro SaaS 的轉變——這是每個 Solo Builder 遲早會面對的抉擇。 👉 [第 12 章：從 Side Project 到 Micro SaaS](/blog/ai-solo-builder-side-project-to-saas)Solo Builder監控維運Self-HealingAIDevOpshttps://bobochen.dev/blog/ai-solo-builder-support-community/https://bobochen.dev/blog/ai-solo-builder-support-community/用戶開始用你的產品了，問題也跟著來。這篇教 Solo Builder 用 AI chatbot、自動回覆模板和 AI 生成 FAQ 把客服時間壓到每天 30 分鐘，並釐清「客服」與「社群」的差別：什麼時候該建社群、選哪個平台、哪些訊息必須親自回、哪些交給自動化，在不犧牲用戶體驗的前提下一個人也撐得住。Sun, 12 Apr 2026 00:00:00 GMT## 凌晨三點的客服 Email：一個人怎麼撐住 你的產品上線一個月了，開始有穩定的用戶。某天凌晨三點，手機跳出一封信： 「你好，我剛付了年費，但登入後看不到進階功能，可以幫我處理嗎？急用。」 你翻個身，心想明天早上再回。但腦袋裡一直在想：「萬一他等不及直接退款怎麼辦？」結果四點半就醒了，五點半就爬起來處理。 這是每個 Solo Builder 都會遇到的轉折點：**產品有人用是好事，但用戶的問題不會只在你方便的時候出現。** 你不可能 24 小時盯著收件匣。你還有正職、有生活。但用戶的體驗不能因為你只有一個人就打折扣。 答案不是「更努力回覆」，而是**建立一套系統，讓大部分問題不需要你親自回覆**。 ## 客服的真相：80% 的問題是重複的 在你急著找 AI chatbot 解決方案之前，先看看一個事實： 大多數產品的客服問題，80% 以上是重複的。 「怎麼重設密碼？」「怎麼取消訂閱？」「支援哪些付款方式？」「為什麼我的 XXX 不能用？」 這些問題反覆出現，每一次你都手動回覆同樣的內容。這是最沒效率的時間使用方式。 解決方案也很直觀：**把這些重複問題的答案寫好，放在用戶找得到的地方。** 聽起來很簡單。但大多數 Solo Builder 不是不知道要做，而是「沒時間做」。 2026 年，AI 改變了這件事。 ## 第一道防線：自助式文件 你的第一優先不是裝 chatbot，而是寫出好的文件。 ### 傳統做法 - 用戶問一個問題，你回一封信 - 同一個問題被問第三次，你想「我該寫個 FAQ」 - 但寫 FAQ 要時間，先回信再說 - 反覆循環，永遠沒有 FAQ ### AI 加持做法 把你回覆過的客服信件和訊息餵給 AI，讓它幫你自動產生文件： ```text 以下是我過去一個月回覆的客服訊息（已去除個資）： [貼上 10-20 封典型的客服對話] 請幫我： 1. 把這些問題分類（帳號問題、付費問題、功能問題、bug 回報） 2. 每個分類列出最常見的前 3 個問題 3. 為每個問題撰寫一個標準回答，語氣友善、專業 4. 產生一個結構化的 FAQ 頁面，用 Markdown 格式 ``` 15 分鐘，你就有了一個涵蓋最常見問題的 FAQ 頁面。 ### FAQ 的進階結構 一個好的 FAQ 不只是問答列表。它應該有層次： | 層級 | 內容 | 目的 | | ------------ | --------------- | ----------------------------- | | **快速入門** | 5 分鐘上手指南 | 減少「怎麼開始」類問題 | | **常見問題** | 分類的 Q&A | 解答 80% 的重複問題 | | **操作指南** | 步驟式 how-to | 解答「怎麼做 XXX」類問題 | | **疑難排解** | 已知問題 + 解法 | 減少 bug 回報信件 | | **更新日誌** | 版本更新說明 | 減少「為什麼 XXX 變了」類問題 | ### 用 AI 從程式碼生成文件 這是更進階的技巧——讓 AI 直接從你的 codebase 生成使用者文件： ```text 請閱讀以下 API 路由和元件程式碼，產生面向「非技術用戶」的操作說明。 [附上相關程式碼片段] 要求： - 不出現任何技術術語 - 每個操作附上步驟編號 - 預期結果和常見錯誤情境都要涵蓋 - 繁體中文，語氣像在跟朋友解釋 ``` 我在做 cloud-on-academy 時就用了這個方法——課程平台的操作說明幾乎全是 AI 從前端元件的程式碼生成的。我只需要做最後的語氣調整和截圖。 ## 第二道防線：AI Chatbot FAQ 解決了「願意自己找答案」的用戶。但有些人就是想直接問。 這時候 AI chatbot 就登場了。 ### 2026 年的 AI 客服 chatbot 現在要做一個有用的 AI chatbot 已經不難了。核心概念是 **RAG（Retrieval-Augmented Generation）**——把你的 FAQ、文件、更新日誌餵給 AI，讓它根據這些內容回答用戶問題。 | 方案 | 適用場景 | 成本 | 設定難度 | | -------------------------------------- | ------------------------ | ------------- | -------- | | **Intercom Fin** | 有預算的 SaaS 產品 | $0.99/次解答（每月最低 50 次解答，約 $49.5/月起；搭配 Intercom 自家 helpdesk 另計 $29/seat/月起） | 低 | | **Crisp + AI** | 小型產品（Free 無 AI） | 免費（無 AI）/ 含 AI 自 $45/月起 | 低 | | **自建 RAG** | 想完全掌控的技術型創辦人 | API 費用 | 中高 | | **Cloudflare AI Gateway + Workers AI** | 已用 Cloudflare 生態系 | 免費額度夠用 | 中 | ### AI Chatbot 的限制：別過度期待 在你投入設定之前，先了解 AI chatbot 做不到什麼： 1. **它不能處理帳號相關操作**——重設密碼、退款、修改訂閱，這些需要後端操作的事情，chatbot 只能告訴用戶「請聯繫我們」 2. **它偶爾會產生幻覺**——回答看起來很合理但完全錯誤的資訊。一定要設定 fallback 機制 3. **它不能替代「人的溫度」**——當用戶真的很生氣或很困惑時，機器人的回覆反而會讓情緒更差 我的建議是：**讓 chatbot 處理事實性問題，把情緒性問題留給你自己。** ### 一個實用的 fallback 機制 ```text chatbot 回覆流程： 1. 用戶提問 2. AI 根據知識庫回答 3. 回答結尾加上：「這有回答到你的問題嗎？」 4. 如果用戶選「沒有」→ 自動建立工單，通知你 5. 你每天花 15 分鐘處理這些「chatbot 回答不了」的問題 ``` 關鍵是第 5 步：把 chatbot 回答不了的問題收集起來，**定期加回知識庫**。這樣 chatbot 的覆蓋率會越來越高，你的人工處理量會越來越少。 ## 自動回覆模板：省下的 15 分鐘 就算沒有 chatbot，你也可以用自動回覆模板大幅減少回信時間。 ### 建立模板庫 用 AI 幫你建立一組回覆模板： ```text 我是一個 Solo Builder，產品是 [描述]。 以下是我最常收到的 10 類客服問題。 請為每一類問題撰寫一個回覆模板： 1. 密碼重設 2. 付款失敗 3. 功能建議 4. Bug 回報 5. 退款請求 6. 帳號刪除 7. 定價疑問 8. 批量授權 9. 合作邀請 10. 一般讚美（是的，也要有模板回覆感謝） 要求： - 語氣溫暖但專業 - 每個模板有 [姓名] 和 [具體問題] 的佔位符 - 結尾都要有明確的下一步行動 ``` 把這些模板存進你的 email client 或客服工具。下次收到類似問題，選模板、填空、送出。一封回信從 5 分鐘變成 30 秒。 ## 客服 vs. 社群：它們不一樣 很多 Solo Builder 把「客服」和「社群」搞混了。 **客服**是被動的：用戶有問題來找你，你回答。 **社群**是主動的：用戶之間交流、互助、分享，你偶爾參與。 兩者都有價值，但運作方式完全不同。 | | 客服 | 社群 | | ------------ | ------------------------ | ----------------------- | | **方向** | 用戶 → 你 | 用戶 ↔ 用戶（你在旁邊） | | **目的** | 解決問題 | 建立歸屬感、收集回饋 | | **你的時間** | 回覆問題 | 引導話題、營造氛圍 | | **可自動化** | 高（FAQ、chatbot、模板） | 低（需要人味） | | **優先級** | 必須做 | 看規模，可以晚一點做 | ### 什麼時候需要社群？ 老實說：**大多數 Solo Builder 在早期不需要社群。** 社群經營是一件很花時間的事。如果你的用戶只有幾百人，一個公開的 feedback 表單 + email 就夠了。（怎麼把這些回饋系統化變成產品決策，見[第 9 章：用戶回饋循環](/blog/ai-solo-builder-user-feedback/)） 當以下信號出現時，再考慮建社群： - 用戶開始在你不知道的地方討論你的產品（Reddit、Twitter） - 用戶之間開始互相解答問題 - 你收到「有沒有交流的地方」的詢問 - 你的產品有「進階用法」值得分享 ### 選擇社群平台 如果你決定要建社群，平台選擇很重要： | 平台 | 適合 | 不適合 | Solo Builder 友善度 | | ---------------------- | ------------------------ | ---------------- | ------------------- | | **GitHub Discussions** | 開源專案、開發者社群 | 非技術用戶 | ⭐⭐⭐⭐⭐ | | **Discord** | 遊戲、加密貨幣、技術社群 | 年齡層偏高的用戶 | ⭐⭐⭐ | | **Telegram** | 亞洲市場、即時交流 | 需要結構化討論 | ⭐⭐⭐⭐ | | **LINE 社群** | 台灣市場、非技術用戶 | 國際化產品 | ⭐⭐⭐ | 我的建議：**開發者產品用 GitHub Discussions，其他用 Telegram 或 Discord。** 原因是：GitHub Discussions 的對話是公開、可搜尋、有結構的。用戶的問題會自動變成你的 FAQ 素材。而且 GitHub Discussions 幾乎不需要管理——社群成員會自己維護討論品質。 ## 什麼時候親自回覆 vs. 讓自動化處理 這是 Solo Builder 最需要判斷的地方。 ### 必須親自回覆 - **付費用戶的退款或不滿**：這些互動決定了用戶是否留下來，不能假手機器 - **產品方向的深度回饋**：當用戶花時間寫了一大段建議，他值得一個有溫度的回應 - **第一批用戶**：前 50 個用戶的每一個問題都值得你親自看，因為他們代表的是你最核心的使用場景 - **情緒化的訊息**：用戶在生氣的時候，chatbot 只會讓情況更糟 ### 可以自動化 - 功能確認（「你們支不支援 XXX？」） - 操作步驟（「怎麼做 XXX？」） - 已知問題的解決方案 - 一般性的感謝回覆 - 合作邀請的初步篩選 ### 黃金比例 以我的經驗，一個運作良好的系統大概是： - **70%** 的問題被 FAQ + chatbot 解決，用戶自己找到答案 - **20%** 的問題用模板回覆，你花 30 秒調整後送出 - **10%** 的問題需要你認真寫一封回信 如果你的比例是反過來的——70% 需要手動回覆——那代表你的文件不夠好，該回去補了。 ## 管理期望：一個人的 SLA Solo Builder 最怕的不是「回覆太慢」，而是「用戶以為你應該秒回」。 解法很簡單：**在所有會接觸用戶的地方，寫清楚你的回覆時間。** 在你的網站 footer、聯絡頁面、自動回覆信件裡加上： > 客服回覆時間：工作日 24 小時內回覆。週末和假日可能會延遲。 > 緊急問題（無法登入、付款失敗）優先處理。 這不是敷衍。這是**尊重用戶的時間，也尊重你自己的時間**。 當用戶知道預期的等待時間，他們的焦慮會大幅降低。「24 小時內回覆」聽起來不快，但如果你每次都在 12 小時內回覆，用戶的感受反而是「超出預期」。 反過來，如果你什麼都不說，用戶會預設你「應該馬上回」，然後在兩小時後開始焦慮、四小時後開始生氣。 ## 時間預算：每天 30 分鐘 最後，最重要的事：**給客服一個時間上限。** 我的建議是每天 30 分鐘，分兩次： | 時段 | 做什麼 | 時間 | | -------------- | ---------------------------------------- | ------- | | 早上（上班前） | 掃一眼有沒有緊急問題，處理付費用戶的問題 | 10 分鐘 | | 晚上（下班後） | 處理其他問題、更新 FAQ、調整 chatbot | 20 分鐘 | **不要一直開著 email 和通知。** 批次處理永遠比即時回覆有效率。 如果某一天的客服問題超過 30 分鐘能處理的量，代表兩件事： 1. 你的產品可能出了 bug（大量用戶同時遇到同一個問題） 2. 你的文件不夠完善（同一個問題被反覆問） 兩者都不是靠「花更多時間回覆」能解決的。解法是修 bug 或補文件。 ## 本章重點回顧 - 🛡️ 第一道防線是自助式文件，不是 chatbot——用 AI 從客服紀錄自動產生 FAQ - 🤖 AI chatbot 適合處理事實性問題，情緒性問題留給你自己回覆 - 📋 建立回覆模板庫，讓一封回信從 5 分鐘變成 30 秒 - 🏘️ 客服和社群是兩件不同的事——早期先把客服做好，社群可以晚一點 - ⏰ 每天 30 分鐘是客服時間上限——超過代表文件不夠好或產品有 bug - 📢 在所有地方寫清楚回覆時間，管理用戶期望比加快回覆更重要 ## 下一步 客服系統搞定了，但有一件事比客服更讓 Solo Builder 焦慮：**產品掛了怎麼辦？** 你不可能 24 小時盯著 server。但你的用戶期待產品 24 小時都能用。 下一章，我們來建立一套最小化但有效的監控和維運系統——讓你安心睡覺，產品出問題時自己會修自己。 👉 [第 11 章：監控與維運——睡覺時產品也在跑](/blog/ai-solo-builder-monitoring-ops)Solo Builder客服社群經營AI ChatbotFAQhttps://bobochen.dev/blog/ai-solo-builder-user-feedback/https://bobochen.dev/blog/ai-solo-builder-user-feedback/一個人做產品最容易犯的錯是「自己覺得好就好」。本文教 Solo Builder 建立系統化的用戶回饋收集與分析流程，用 AI 自動分類、情感分析與優先排序，每週不到一小時，讓有限時間花在最重要的改進上。Sun, 05 Apr 2026 00:00:00 GMT## 你不是你的用戶——用戶回饋為什麼重要 讓我告訴你一個我親身經歷的故事。 cloud-on-academy 上線初期，我花了一整個週末重新設計課程頁面的側邊導覽。我把章節樹狀結構做得很漂亮，可以展開、收合、顯示進度百分比、標記已完成的章節。身為工程師，我對這個 UI 非常滿意。 然後我看了 analytics。 用戶根本不用側邊導覽。他們的行為模式是：看完一章，直接點文章底部的「下一章」連結。側邊欄？大部分人從頭到尾沒點過。 我花了一個週末在打磨一個沒人用的功能。 這就是 Solo Builder 最危險的陷阱：**因為你自己就是用戶，所以你以為你知道用戶要什麼。** 你確實是用戶之一。但你是一個非常特殊的用戶。你知道產品的每一個角落、每一行程式碼、每一個設計決策的背景。你對產品的理解深度和一般用戶完全不同。 一般用戶不會打開 DevTools 看你的 CSS 寫得多漂亮。一般用戶不在乎你用了 Cloudflare Workers 還是 Vercel。一般用戶只在乎一件事：**這個東西能不能幫我解決問題。** 你需要一套系統，讓用戶告訴你他們真正在乎什麼。而不是你自己猜。 想看 cloud-on-academy 和其他產品的完整實戰經驗？👉 [第 13 章：實戰案例——我的四個產品](/blog/ai-solo-builder-case-studies/) ## 回饋管道的四個層級 收集用戶回饋不是放一個「聯絡我們」的 email 就好。你需要多個管道，每個管道捕捉不同類型的訊號。 ### 層級 1：行為數據（用戶做了什麼） 這是最客觀的回饋。用戶不需要開口，他們的行為就在告訴你答案。 | 數據 | 告訴你什麼 | 工具 | | ---------- | ------------------------ | ------------------------------ | | 頁面瀏覽量 | 哪些內容最受歡迎 | Google Analytics 4 | | 跳出率 | 哪些頁面讓人立刻離開 | Google Analytics 4 | | 功能使用率 | 哪些功能沒人用 | 自建事件追蹤 / Mixpanel 免費版 | | 用戶路徑 | 用戶怎麼在產品裡移動 | GA4 User Flow / Hotjar | | 搜尋紀錄 | 用戶在找什麼（但找不到） | 站內搜尋 log | | 錯誤紀錄 | 用戶遇到什麼問題 | Sentry | 行為數據的好處是**不需要用戶配合**，你設定好追蹤，數據就自動進來。壞處是它告訴你「發生了什麼」，但不告訴你「為什麼」。 ### 層級 2：被動回饋（用戶主動來找你） 用戶遇到問題或有想法時，主動聯繫你。 管道包括： - **產品內回饋按鈕**：頁面角落放一個「回報問題」或「建議功能」的小按鈕 - **Email**：最基本的管道，永遠不要關掉 - **社群留言**：GitHub Issues、Discord、Telegram - **App Store / Chrome Web Store 評論**：如果你有上架的話 被動回饋的特色是：**會主動留回饋的人，通常感受很強烈**。不是非常滿意，就是非常不滿。中間的大多數人什麼都不會說。 這代表被動回饋有偏差。但它的價值在於**深度**，用戶會用自己的話告訴你問題的脈絡，這是行為數據做不到的。 ### 層級 3：主動收集（你去問用戶） 不等用戶來找你，而是主動出擊。 | 方式 | 適合時機 | 工具 | | ---------- | ------------------ | ------------------------- | | 產品內問卷 | 用戶完成某個動作後 | Google Forms 嵌入 / Tally | | Email 問卷 | 定期（每季一次） | Google Forms | | NPS 評分 | 衡量整體滿意度 | 簡單的 1-10 分嵌入 | | 用戶訪談 | 深入理解特定議題 | Google Meet / Zoom | 主動收集的回覆率通常不高（5-15%），但你拿到的是**你想問的問題的答案**，而不是用戶自己想說的話。兩者互補。 ### 層級 4：間接訊號（你沒問但能觀察到的） - **社群媒體提及**：有人在 X（前 Twitter）/ Threads 上提到你的產品（社群平台的貼文 Google Alerts 抓不到，要用 Mention、Brand24、Talkwalker Alerts 這類社群監聽工具；Google Alerts 只適合追蹤部落格、新聞網頁類的提及） - **競品論壇的討論**：用戶在競品社群抱怨什麼 - **搜尋趨勢**：相關關鍵字的搜尋量變化 - **退訂 / 流失數據**：用戶什麼時候離開、離開前做了什麼 這些訊號比較微弱，但有時候最有價值的洞察就藏在這裡。 ## Solo Builder 的最小回饋系統 四個層級聽起來很多。但你是一個人，你不可能全做。 **以下是我建議的最小配置——設定一次，花不到 2 小時：** | 管道 | 工具 | 設定時間 | 維護時間 | | ---------- | ----------------------------- | -------- | ------------------ | | 行為追蹤 | Google Analytics 4 | 30 分鐘 | 每週看 10 分鐘 | | 錯誤追蹤 | Sentry 免費版 | 15 分鐘 | 被動（有告警才看） | | 產品內回饋 | Google Forms 嵌入 | 15 分鐘 | 被動（有回覆才看） | | Email | 你的信箱 | 0 分鐘 | 被動 | | 社群 | GitHub Discussions 或 Discord | 30 分鐘 | 每天 5 分鐘掃一眼 | 五個管道，設定 1.5 小時，每週維護不到 1 小時。 **不要一開始就上 Hotjar、Mixpanel、Canny、Intercom 全家桶。** 那些是你有 1000+ 用戶之後才需要考慮的。前期最重要的是：有管道能讓用戶找到你、有數據能讓你看到基本行為。 同樣的「先做最小可行版本」思維，也適用在產品功能開發上，參考 👉 [第 4 章：MVP 設計——砍到不能再砍](/blog/ai-solo-builder-mvp-design/) ## AI 驅動的回饋分析 回饋收集到了。然後呢？ 如果你有 10 個用戶，你可以一條一條看完。但當你有 50、100、500 條回饋時，手動分析就不現實了。 這是 AI 最擅長的場景：**從大量非結構化文字中提取結構化的洞察。** ### 傳統做法 1. 打開 Google Sheet 2. 一條一條讀回饋 3. 手動標記分類（bug / feature request / 抱怨 / 讚美） 4. 嘗試找出模式 5. 花了三小時，結論是「好像很多人想要 X 功能」 → 主觀、耗時、容易遺漏 ### AI 加持做法 把所有回饋丟給 AI，讓它幫你做結構化分析： ```text 以下是我的產品在過去一個月收到的用戶回饋（共 47 條）： [貼上所有回饋內容] 請幫我做以下分析： 1. 分類統計 - 把每條回饋歸類為：Bug、Feature Request、UX 問題、 正面回饋、疑問/求助、其他 - 統計每個分類的數量和百分比 2. 情感分析 - 正面 / 中性 / 負面的比例 - 哪些主題引發最強烈的負面情緒 3. 主題提取 - 歸納出前 5 個最常被提到的主題 - 每個主題有多少條回饋提到 - 附上代表性的原文引用 4. 優先排序建議 - 基於「影響用戶數 × 情緒強度 × 實作難度」， 建議我優先處理的前 3 件事 - 每個建議附上理由 5. 我可能忽略的訊號 - 有沒有只出現 1-2 次但值得注意的回饋？ - 有沒有用戶用不同的方式在說同一件事？ ``` AI 在 2 分鐘內就能給你一份結構化的分析報告。 更重要的是，AI 不會有你的偏見。你可能下意識地更注意那些支持你既有想法的回饋（確認偏差）。AI 會一視同仁地處理每一條。 ### 進階：趨勢追蹤 每個月做一次分析不夠。你應該追蹤回饋的**趨勢變化**： ```text 以下是過去三個月的回饋分析摘要： 一月：[上個月的 AI 分析結果] 二月：[上上個月的 AI 分析結果] 三月：[這個月的 AI 分析結果] 請比較三個月的變化： 1. 哪些問題在好轉？（之前常被提到，現在變少了） 2. 哪些問題在惡化？（之前沒人提，現在越來越多人提） 3. 有沒有新出現的主題？ 4. 整體情感趨勢是上升還是下降？ ``` 這種趨勢分析靠人工幾乎不可能做，因為你不會記得三個月前的回饋細節。但 AI 可以輕鬆比較。 ## 從回饋到功能：轉化管線 分析完回饋，接下來是最關鍵的一步：**把回饋轉成你實際要做的事。** 很多 Solo Builder 的問題不是「不知道用戶要什麼」，而是「知道了但不知道怎麼排優先順序」。用戶 A 想要功能 X，用戶 B 想要功能 Y，用戶 C 說你的 UI 很醜。你一個人一週只有幾小時，該先做什麼？ ### 回饋分類矩陣 我用一個簡單的 2x2 矩陣來決定： | | 影響用戶多 | 影響用戶少 | | -------------- | ------------ | ---------- | | **實作成本低** | **立刻做** | 有空做 | | **實作成本高** | 排入 roadmap | **不做** | 「影響用戶多」的判斷依據是：回饋中有多少人提到了類似的需求。 「實作成本」用小時來估：1-2 小時算低、一個週末算中、超過兩個週末算高。 ### AI 輔助的需求拆解 回饋往往是模糊的。「希望有更好的搜尋功能」——什麼叫「更好」？ 用 AI 幫你把模糊的回饋拆解成可執行的項目： ```text 用戶回饋：「搜尋功能不好用，常常找不到想要的文章」 這個回饋被 5 個不同用戶以不同方式提到。 我的產品是一個技術部落格，目前用 Pagefind 做靜態搜尋。 請幫我： 1. 分析「搜尋不好用」可能的具體原因（列出 5 個可能） 2. 每個原因的驗證方式（怎麼確認是不是這個問題） 3. 每個原因的修復方案和預估工時 4. 建議的處理順序（先解決最可能的原因） ``` AI 把一條模糊的回饋變成了五條可驗證、可執行的任務。你不用自己想破頭，丟給 AI，它會列出一堆你沒想到的可能性。 ## 量化 vs. 質性：你兩個都需要 很多工程師天然傾向量化數據，開口就是「給我看數字！」但數字只能告訴你「發生了什麼」，不能告訴你「為什麼」。 | | 量化（數字） | 質性（文字） | | -------- | --------------------------- | -------------------------- | | **回答** | 什麼、多少、多常 | 為什麼、怎麼想 | | **來源** | Analytics、NPS 分數、轉換率 | 訪談、開放式問卷、客服信件 | | **優點** | 客觀、可追蹤趨勢 | 深入、有脈絡 | | **缺點** | 沒有脈絡、不知道原因 | 主觀、樣本小 | | **適合** | 發現問題 | 理解問題 | **正確的流程是：量化發現問題 → 質性理解問題 → 量化驗證修復。** 例如： 1. **量化**：GA4 顯示 checkout 頁面的跳出率是 60% 2. **質性**：訪談 3 個用戶，發現他們不確定付費後能得到什麼 3. **行動**：在 checkout 頁面加上「付費後包含」的清單 4. **量化**：跳出率降到 35% 如何優化 Landing Page 的轉換率，可以參考 👉 [第 7 章：Landing Page 與 SEO 入門](/blog/ai-solo-builder-landing-page-seo/) ### AI 輔助用戶訪談分析 如果你做了用戶訪談（即使只是跟朋友聊了 20 分鐘），讓 AI 幫你從對話中提取洞察： ```text 以下是我跟一個用戶的訪談逐字稿（約 20 分鐘的對話）： [貼上逐字稿或筆記] 請幫我分析這次訪談： 1. 關鍵發現 - 用戶遇到的主要痛點（用他們自己的話） - 用戶目前的替代方案（他們怎麼解決這個問題） - 用戶對我們產品的期待 vs. 實際體驗的落差 2. 隱含需求 - 用戶沒有直接說出來，但從對話中可以推斷的需求 - 用戶以為自己要什麼 vs. 實際上需要什麼 3. 可行動的建議 - 基於這次訪談，最值得做的一件事是什麼？ 4. 可引用的原話 - 列出 3-5 句最有洞察力的原話（未來可用在 Landing Page） ``` 最後一點很實用。用戶自己的話，就是最好的行銷文案。 ## 說「不」的藝術 收集回饋最難的部分不是收集，而是**決定不做什麼**。 每一條用戶回饋背後都是一個真實的人、真實的需求。說「不」會讓你覺得虧欠。但 Solo Builder 的時間是有限的，你不可能做所有人要求的所有功能。 ### 什麼時候該聽 - **多人獨立提到同一件事**：如果五個不相關的用戶都抱怨同一個問題，那大概率是真的問題 - **符合你的產品定位**：這個功能讓你的核心價值主張更強嗎？ - **低成本高影響**：花 2 小時就能讓很多人受益 - **用戶在流失**：如果流失用戶反覆提到同一個原因，那是緊急信號 ### 什麼時候該忽略 - **只有一個人要求**：除非那個人代表了你的核心用戶群 - **跟產品定位衝突**：「你的部落格平台能不能加購物車功能？」不能，這不是購物車 - **高成本低影響**：花三個週末做一個只有 5% 用戶會用的功能？不值得 - **用戶在描述解法而不是問題**：「你應該加一個 X 按鈕」，先問他為什麼需要那個按鈕。也許有更簡單的方式解決他的根本需求 - **付費前的功能要求**：「如果你加了 X 功能我就付費」。大部分時候，他們不會 ### 回覆模板：優雅地說不 你不需要每次都寫一封長信解釋為什麼不做。準備一個模板： ```text 感謝你的建議！ 我有記錄下來，也理解這個功能對你的價值。 目前我在 [當前的優先項目] 上， 短期內可能無法加入這個功能。 如果之後有了更新，我會通知你。 再次感謝你的回饋，這對產品的改進很有幫助！ ``` 真誠、簡短、不承諾時間。這比沒有回覆好，也比虛假承諾好。 ## 回饋收集的常見陷阱 ### 陷阱 1：只聽最大聲的用戶 最常留回饋的用戶不一定代表大多數用戶。他們可能是 power user（需求跟一般用戶不同）、或者是特別不滿的人。 **對策**：搭配行為數據。如果最大聲的用戶要求功能 A，但 analytics 顯示 80% 的用戶連功能 B 都沒用過，也許功能 B 的改進比功能 A 更重要。 ### 陷阱 2：把「沒有抱怨」當成「沒有問題」 大部分遇到問題的用戶不會告訴你，他們會默默離開。 **對策**：看流失數據。用戶在什麼時間點離開？離開前最後做了什麼？哪個頁面的跳出率異常高？沉默的行為比大聲的抱怨更能反映真實問題。 ### 陷阱 3：太快回應回饋 收到回饋後立刻開始做。三天後又收到另一個回饋，又轉方向。反覆改來改去，什麼都沒做好。 **對策**：設定一個「回饋冷卻期」。收到回饋後不要立刻行動。每月做一次統整分析（用前面的 AI prompt），根據分析結果決定下一步，而不是根據最新一條回饋。 ### 陷阱 4：問用戶「你想要什麼功能」 這是最常見但最沒用的問法。用戶不是產品設計師，他們擅長描述問題，不擅長設計解法。 **對策**：問「你最近一次 [使用場景] 遇到什麼困難？」而不是「你希望我們加什麼功能？」。The Mom Test 這本書的核心觀點就是這個：問他們的行為，不要問他們的意見。 ## 時間預算：每週 1 小時 最後，把回饋分析納入你的固定時間預算。 | 任務 | 頻率 | 時間 | | ------------------- | ---- | -------------- | | 掃一眼 GA4 關鍵指標 | 每週 | 10 分鐘 | | 讀新的用戶回饋 | 每週 | 15 分鐘 | | AI 月度回饋分析 | 每月 | 20 分鐘 | | 更新產品 roadmap | 每月 | 15 分鐘 | | **每週平均** | | **約 35 分鐘** | 不到一小時。 關鍵是**固定時間做**，而不是隨時被回饋打斷。當你收到一封用戶來信，不要立刻停下手上的開發工作去處理。標記為「待讀」，等到你的回饋時段再統一處理。 批次處理永遠比即時反應有效率。這是上班族 Solo Builder 最需要的紀律。 ## 本章重點回顧 - ⚠️ 你不是你的用戶，不要用自己的直覺替代用戶回饋 - 📊 四層回饋管道：行為數據 → 被動回饋 → 主動收集 → 間接訊號，先建最小系統 - 🤖 AI 回饋分析：2 分鐘完成分類、情感分析、主題提取、優先排序，每月做一次 - 🔄 量化發現問題、質性理解問題、量化驗證修復，三步循環 - ❌ 學會說不：多人獨立提到的才優先做，只有一個人要求的先觀察 - ⏱️ 每週不到 1 小時，固定時間批次處理，不要被回饋隨時打斷 ## 下一步 你現在有了一套回饋收集和分析的系統。你知道用戶在想什麼、要什麼、抱怨什麼。 但用戶的問題不只是「我想要 X 功能」。他們也會在凌晨三點問你：「為什麼我的帳號登不進去？」 下一章，我們來建立**一個人的客服與社群系統**——用 AI 和自動化把客服時間壓到最低，同時不犧牲用戶體驗。 👉 [第 10 章：一個人的客服與社群](/blog/ai-solo-builder-support-community)Solo Builder用戶回饋AI產品迭代Analyticshttps://bobochen.dev/blog/ai-solo-builder-payment/https://bobochen.dev/blog/ai-solo-builder-payment/從免費到付費，是 side project 變成真正產品的關鍵一步。比較 Stripe、綠界、藍新的整合難度與適用場景，用 AI 一個晚上串接金流，並搞懂台灣個人收費的發票、退款與法律考量。Sun, 29 Mar 2026 00:00:00 GMT## 從免費到收費的心理障礙 你的產品有人在用了。有人說「很好用」，有人說「如果有 X 功能就更好了」。 現在你心裡有一個想法：「也許……可以開始收費了？」 然後你開始焦慮。 「會不會一收費，所有用戶都跑掉？」「定多少錢才合理？」「台灣市場用什麼金流？Stripe 可以用嗎？」「要不要開統編？需不需要開發票？」「如果有人付了錢然後要退款怎麼辦？」 這些問題堆在一起，讓「收費」這件事變成了一座大山。於是你繼續讓產品免費，告訴自己「再等等，功能更完善再說」。 這是 Solo Builder 最常見的拖延。也是最致命的——因為**一個不收錢的產品，永遠只是 side project**（這個核心信念在[第 1 章：Solo Builder 宣言](/blog/ai-solo-builder-manifesto)有更完整的論述）。 > 不過這句話我得補一個前提：它只在「你的商業模式就是向用戶收費」時才成立。「免費」本身可以是策略，不一定是逃避。有幾種情況我反而會勸你別急著收費： > - **需求還沒驗證**——連有沒有人要用都不確定，先收費只會讓你拿不到真實的使用數據。 > - **產品靠網路效應**——社群、市集、協作工具這類東西，沒先衝出規模就收費，等於自己掐死成長。 > - **變現本來就不是直接跟用戶拿錢**——廣告、贊助、開源加技術服務，都是「沒跟用戶收一毛、卻活得很好」的活路。 > > 所以與其說「沒收錢就是 side project」，更準確的版本是：**如果你打算靠用戶付費活下來，那遲遲不收費確實是拖延；但收費不是「認真」的唯一證明。** 先想清楚你是哪一種，再決定要不要往下讀這章的金流。 事實上，串接金流的技術難度遠比你想像的低。2026 年的金流服務都有完善的 API 和 SDK，加上 AI 的輔助，一個晚上就能搞定。 真正的挑戰不是技術，而是心態。所以我們先處理心態，再處理技術。 ## 心態轉換：收費是對用戶的尊重 很多開發者覺得「收費不好意思」，因為自己也常用免費工具。 但你想過一個問題嗎：你最常用的免費工具，你對它有多大的信任？ 如果它明天關掉了，你會多難過？大概只會說「可惜」，然後找替代品。 但如果你**付了費**的工具明天關掉了？你會很生氣，因為你投入了金錢，你期待它穩定運作。 這就是收費的意義：**付費建立了一種契約關係。** 用戶付費，代表他認真看待你的產品。你收費，代表你承諾會認真維護。 免費產品的用戶會說「不錯」然後離開。付費用戶會說「這邊有 bug 你要修」——然後留下來。 **收費不是在佔用戶便宜。收費是在告訴用戶：「我會為這個產品負責。」** 話講得漂亮，但我也得誠實說收費的另一面，不然你會以為它只有好處： > - **付費牆會把絕大多數人擋在外面。** 業界常見的免費轉付費率個位數百分比，意思是你收費的那一刻，等於放掉九成以上的使用者——而這群人正是會幫你口耳相傳的來源。 > - **付了錢的人期待也更高。** 免費用戶最多嫌兩句就走，付費用戶會半夜寄信問你「我付了錢為什麼還當機」，客服和 SLA 的壓力是真的會壓到你。 > - **你開始要扛退款與爭議。** 信用卡 chargeback、要求退費、發票開錯，這些雜事免費時你完全不用碰。 > - **「付費用戶會留下來」不是定律。** 訂閱制的退訂率（churn）很現實，留不留下來看的是產品本身，收了錢不會自動換來忠誠。 > > 我講這些不是要你別收錢，而是想讓你看清楚：「收費」跟「先維持免費衝規模」是一個 trade-off，是商業選擇，不是誰比較有志氣的道德題。 ## 台灣市場的三大金流選項 如果你的產品面向國際市場，選 Stripe 幾乎沒有懸念。但如果你的用戶主要在台灣，事情就複雜一些了。 以下是 2026 年台灣 Solo Builder 最常用的三個金流服務： ### 選項 1：Stripe **國際標準，開發者體驗最好** Stripe 是全球最受歡迎的金流服務，API 設計優雅，文件品質一流，SDK 覆蓋所有主流語言。 - **優點**：API 設計優雅、文件完善、Dashboard 直覺、AI 對 Stripe 的理解度極高（訓練資料多）、支援訂閱制管理、Webhook 機制完善 - **缺點**：**⚠️ 台灣個人無法直接申請**——Stripe 官方支援約 46 國，台灣不在其中。台灣人要用 Stripe 必須先在美國（US LLC + EIN）或英國（UK Ltd）成立公司主體才能開戶；台灣用戶也不一定習慣用國際信用卡付費、手續費略高。（正面消息：Stripe Tax 已於 2025-10 支援台灣遠端賣家數位商品稅務登記） - **適合**：目標用戶是國際市場、或是科技圈習慣用信用卡的用戶 ### 選項 2：綠界 ECPay **台灣本土標準，支付方式最多元** 綠界是台灣最普及的金流服務。超商付款、ATM 轉帳、信用卡、Line Pay——台灣人習慣的付費方式它都有。 - **優點**：支援超商付款和 ATM（台灣用戶最習慣）、市場接受度高、個人就能申請 - **缺點**：API 設計較舊（XML 格式）、文件品質參差不齊、Dashboard 介面老舊、AI 生成的綠界整合程式碼品質較差（訓練資料少） - **適合**：目標用戶是一般台灣消費者、需要超商付款和 ATM 轉帳 ### 選項 3：藍新 NewebPay **台灣本土，API 相對現代** 藍新是台灣另一個主流金流服務，API 設計比綠界現代一些。 - **優點**：API 比綠界乾淨、支援台灣主流支付方式、文件相對完整 - **缺點**：市場知名度比綠界略低、部分進階功能需要企業帳戶 - **適合**：想要台灣本土金流但受不了綠界 API 的開發者 ### 三者比較表 | 面向 | Stripe | 綠界 ECPay | 藍新 NewebPay | | ------------------ | ------------ | ---------- | ------------- | | 信用卡手續費 | 2.9% + $0.30 | 2.75% | 2.8% | | 超商付款 | ❌ 不支援 | ✅ 支援 | ✅ 支援 | | ATM 轉帳 | ❌ 不支援 | ✅ 支援 | ✅ 支援 | | Line Pay | ❌ 不支援 | ✅ 支援 | ✅ 支援 | | API 品質 | ⭐⭐⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐ | | 文件品質 | ⭐⭐⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐ | | AI 整合友善度 | ⭐⭐⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐ | | 訂閱制支援 | ✅ 原生支援 | ⚠️ 需自建 | ⚠️ 需自建 | | 台灣用戶接受度 | 🟡 中 | 🟢 高 | 🟢 高 | | 個人可申請 | ❌（需海外公司主體）| ✅ 可以 | ✅ 可以 | | 設定到收到第一筆款 | 需先成立海外公司 | 3-7 天 | 3-7 天 | > **手續費註記**：上表 Stripe 的 2.9% + $0.30 是**美國本地卡（USD）的標準費率**。若你主要收的是台灣發行的信用卡，會被歸類為跨國卡（international card），Stripe 會在基本費率上**再加約 1.5%**；如果交易還涉及貨幣轉換（顧客以非美元結帳），會**再加約 1%**——疊加後實際成本可能來到約 5.4% + $0.30，而不是平盤 2.9%。綠界 2.75%、藍新 2.8%（信用卡一次付清）為標準列表費率，實務上常有新戶優惠（綠界新戶費率曾低至 1.8%），簽約前值得議價。 ### 我的建議 **先問自己一個問題：你的用戶會用信用卡付費嗎？** - 如果是（開發者、科技圈、國際用戶）→ **用 Stripe** - 如果不確定（一般台灣消費者）→ **先用綠界**，它的支付方式最多元 - 如果你是開發者但受不了綠界的 API → **用藍新** 不要一開始就串接三個。**先選一個，上線收到第一筆錢，再考慮加其他的。** ## 定價策略：三種模式的選擇 串接金流之前，你需要先決定定價策略。Solo Builder 常用的三種模式： ### 模式 1：Freemium（免費增值） - **基本功能免費，進階功能付費** - 優點：降低試用門檻，用免費用戶建立口碑 - 缺點：免費用戶的伺服器成本你要承擔，轉換率通常 2-5% - 適合：工具型產品、有明確的免費/付費功能分界 ### 模式 2：Tiered Subscription（分級訂閱） - **月費/年費，不同等級不同功能** - 優點：可預測的每月收入（MRR），用戶生命週期長 - 缺點：需要持續提供價值讓用戶續費，訂閱制管理較複雜 - 適合：SaaS 產品、有持續使用需求的服務 ### 模式 3：Pay Once（一次買斷） - **付一次錢，永久使用** - 優點：用戶心理負擔最低，交易簡單 - 缺點：沒有持續收入，需要不斷找新客戶 - 適合：課程、電子書、桌面應用、lifetime deal ### 定價的經驗法則 | 原則 | 說明 | | ----------------- | ------------------------------------------------------ | | 不要免費太久 | 免費超過三個月還不收費，用戶會覺得「這本來就是免費的」 | | 從高定價開始 | 降價容易，漲價難。先定高一點，不夠再降 | | 提供年繳折扣 | 月費 x 10 = 年費（等於送兩個月），提高年繳比例 | | 方案不要超過三個 | 太多選擇讓人焦慮。免費 + 基本 + 進階，三個就夠 | | 比競品便宜 20-30% | Solo Builder 的營運成本低，可以用價格當武器 | 用 AI 幫你做定價決策： ```text 我的產品是 [描述]，目標用戶是 [描述]。 競品的定價： - 競品 A：$X/月 - 競品 B：$Y/月 - 競品 C：免費（有廣告） 我的產品的核心差異化是 [描述]。 請建議： 1. 定價模式（freemium / 訂閱制 / 買斷） 2. 具體價格方案（含免費版和付費版的功能分界） 3. 是否提供年繳折扣 4. 第一年的收入預估（假設 1000 個免費用戶，X% 轉換率） ``` ## AI 輔助金流整合：實戰 Prompt 確定了金流和定價之後，來到實際串接。這是 AI 最能幫你加速的環節。 ### 傳統做法 - 讀金流服務的文件（綠界的文件可能讓你想哭），2-4 小時 - 寫整合程式碼，處理加密、簽名、callback，4-8 小時 - Debug 各種奇怪的錯誤回傳碼，2-4 小時 - 測試各種付費場景（成功、失敗、取消），2-3 小時 - 前後花了 10-19 小時（2-3 個週末） ### AI 加持做法 **Step 1：讓 AI 生成整合骨架** 以 Stripe 為例（完整技術選型考量可參考[第 3 章：技術選型決策框架](/blog/ai-solo-builder-tech-stack)）： ```text 我需要在我的 Astro + Hono 後端整合 Stripe 付費。 需求： - 產品類型：SaaS 訂閱制 - 方案：Free / Pro ($9.99/月) / Team ($29.99/月) - 後端框架：Hono on Cloudflare Workers - 資料庫：D1 (SQLite) 請生成： 1. Stripe Checkout Session 建立的 API endpoint 2. Webhook handler（處理 checkout.session.completed、 customer.subscription.updated、customer.subscription.deleted） 3. 用戶訂閱狀態的資料庫 schema 4. 中介層：檢查用戶是否有有效訂閱 技術要求： - TypeScript - 使用 stripe npm package 最新版 - 錯誤處理要完整 - 加上必要的 type 定義 ``` **Step 2：讓 AI 生成測試用例** ```text 針對剛才的 Stripe 整合程式碼，請生成測試用例： 1. 成功付款流程 2. 付款失敗流程 3. 訂閱升級（Free → Pro） 4. 訂閱降級（Pro → Free） 5. 訂閱取消 6. Webhook 簽名驗證失敗 7. 重複的 Webhook 事件處理 使用 Vitest 測試框架。 ``` **Step 3：讓 AI 生成收據 Email** ```text 請幫我生成付費成功後的收據 email 模板。 資訊包含： - 產品名稱 - 方案名稱和金額 - 付款日期 - 下次扣款日期 - 收據編號 - 客服聯絡方式 語言：繁體中文 風格：簡潔專業 請用 HTML email 格式，確保在各種 email client 都能正確顯示。 ``` 用 AI 輔助，整個金流整合大約 3-4 小時可以完成——一個晚上的事。 ## 台灣的法律考量 這一段很重要。在台灣收費做生意，有一些法律事項你必須知道： ### 個人 vs. 公司 | 面向 | 以個人身份收費 | 設立公司（行號/有限公司） | | ---------- | ------------------------ | ----------------------------------- | | 設立成本 | 零 | 行號 ~$5,000 / 公司 ~$15,000-30,000 | | 統一編號 | 無 | 有 | | 開發票 | 不行 | 可以（公司戶需要） | | 年營收門檻 | 超過一定金額需辦營業登記 | 已有登記 | | 稅務 | 綜合所得稅申報 | 營利事業所得稅 | | 金流申請 | 部分金流需公司帳戶 | 較容易申請各種金流 | **我的建議：一開始用個人身份，月營收穩定超過 $8,000 再考慮設立行號。** 不要在還沒賺到錢之前就花時間開公司。先驗證有人願意付費，再處理法律架構。 ### 電子發票 如果你設了行號或公司，台灣法律要求你開發票。電子發票的串接可以用： - **綠界電子發票 API**：跟金流一起用最方便 - **財政部電子發票平台**：免費但整合較麻煩 同樣地，先有穩定營收再處理。不要一開始就花兩週在串接電子發票上。 ### 退款處理 台灣的消費者保護法賦予消費者在收到商品 7 天內無條件解約退貨的權利（即「七日鑑賞期／猶豫期」，並非試用期）。數位內容與「一經提供即完成」的線上服務（例如 SaaS）確實有機會排除這項七日解除權，但**不是自動成立**：依《消費者保護法》第 19 條與《通訊交易解除權合理例外情事適用準則》第 2 條，例外要成立必須同時滿足兩個前提——(1) 業者在購買前以清楚方式**事先告知**將排除七日解除權，且 (2) 取得**消費者事先同意**。兩者只要缺一（例如沒在結帳流程讓使用者勾選同意），七日解除權仍然適用。實務上建議把這段告知與同意機制寫進服務條款與結帳流程的勾選同意。 建議在你的服務條款中明確說明退款政策。AI 可以幫你生成： ```text 請幫我撰寫一個 SaaS 產品的退款政策。 產品類型：[描述] 定價方式：月訂閱制 地區：台灣 需要包含： 1. 退款條件 2. 退款流程 3. 退款時間 4. 例外情況 語言：繁體中文 風格：清楚明確，但不要太冰冷 注意：要符合台灣消費者保護法的相關規定。 ``` ## 實戰案例：cloud-on-academy 的付費設定 讓我用 cloud-on-academy（GCP 認證課程平台）的真實例子說明。 **產品類型**：線上課程（買斷制） **金流選擇**：同時支援 Stripe（國際用戶 + 信用卡）和綠界（台灣用戶 + 超商付款） **為什麼這樣選**：課程平台的用戶分兩群。科技圈的開發者習慣用信用卡，直接用 Stripe。但也有一些在職進修的人更習慣超商付款，所以加了綠界。 **串接順序**： 1. 先串 Stripe（API 品質好，2 小時搞定；前提：已有美國 LLC 主體） 2. 上線收到第一筆款 3. 發現有用戶問「可以超商付款嗎？」 4. 才串綠界（花了半天，主要在跟文件搏鬥） **關鍵學習**：不要一開始就串兩個金流。先上線一個，根據用戶回饋再決定要不要加。更多真實產品的付費設定細節，見[第 13 章：實戰案例——我的四個產品](/blog/ai-solo-builder-case-studies)。 ## 訂閱管理：升級、降級、取消 如果你選的是訂閱制，你需要處理用戶的方案變更。這是很多人低估的複雜度。 ### 需要處理的場景 | 場景 | 處理方式 | | ----------- | ------------------------------- | | 免費 → 付費 | 建立新訂閱，立即生效 | | 基本 → 進階 | 立即升級，按比例計費（prorate） | | 進階 → 基本 | 下個計費週期生效 | | 付費 → 取消 | 當前週期結束後降為免費 | | 付費失敗 | 寬限期（3-7 天），然後降為免費 | | 退款 | 取消訂閱 + 退款 | **Stripe 原生支援所有這些場景。** 這是選 Stripe 的最大優勢——你不需要自己寫訂閱管理邏輯。 如果用綠界或藍新，訂閱管理需要自己建。但對 Solo Builder 來說，**一開始可以先不支援訂閱制**。用買斷制或手動管理，等用戶量大了再花時間建訂閱系統。 ## Start Simple：不要過度工程 最後一個忠告：**不要在金流整合上過度工程。** 你不需要： - ❌ 支援十種支付方式（先支援一種最多人用的） - ❌ 自動化的退款流程（手動處理，先了解為什麼退款） - ❌ 複雜的方案管理（先從一個付費方案開始） - ❌ 自動開發票（先手動開，或等月營收穩定再串接） - ❌ 多幣別支援（先只收台幣或美金） **你需要的只是：一個「付費」按鈕 → 用戶付錢 → 你收到錢 → 用戶得到存取權限。** 就這樣。 先把這個最小循環跑通，收到第一筆錢。然後根據實際情況，逐步完善。 很多 Solo Builder 在金流整合上花了三個週末，結果做了一個「完美的付費系統」，然後發現根本沒人付費。 不要成為那個人。先簡單做，先收到錢，再優化。 ## 本章重點回顧 - 💰 收費不是佔用戶便宜，是建立信任契約。一個不收錢的產品永遠只是 side project - 🏦 台灣市場三大金流：Stripe（最佳 DX）、綠界（最多支付方式）、藍新（折衷選擇） - 📊 先問「用戶會用信用卡嗎」來選金流，不要一開始就串三個 - 🏷️ 定價：不要免費太久、從高定價開始、方案不超過三個 - 🤖 AI 可以在一個晚上幫你搞定金流整合：生成 API endpoint、webhook handler、測試用例、收據模板 - ⚖️ 法律：先用個人身份，月營收穩定再考慮設立公司 - 🎯 Start Simple：先跑通「付費 → 收錢 → 給權限」的最小循環，再逐步完善 ## 下一步 開始收費了，代表你的產品正式進入「有人付錢」的階段。 但付了錢的用戶會開始有期待、有意見、有抱怨。下一章，我們來建立**系統化的用戶回饋循環**——讓你聽懂用戶在說什麼，把有限的時間花在最值得改進的地方。 👉 [第 9 章：用戶回饋循環——聽懂用戶在說什麼](/blog/ai-solo-builder-user-feedback)Solo BuilderStripe金流綠界藍新付費機制https://bobochen.dev/blog/ai-solo-builder-landing-page-seo/https://bobochen.dev/blog/ai-solo-builder-landing-page-seo/產品做出來了，但沒人知道它存在。學會用 AI 快速產出高轉換率的 Landing Page 文案、建立 SEO 策略，讓你的產品被目標用戶找到。Sun, 22 Mar 2026 00:00:00 GMT## 「做出來就會有人用」是最大的謊言 你花了三個週末，終於把 MVP 部署上線了。打開 Analytics——零流量。 過了一週，還是零。 你把連結丟到社群裡，得到幾個朋友的點擊，然後恢復平靜。你開始懷疑：是產品不夠好嗎？是市場不存在嗎？ 大多數時候，答案都不是。答案是：**沒有人知道你的產品存在。** 你缺的不是更好的功能，而是一個能被找到的 Landing Page，以及讓 Google 持續帶流量的 SEO 策略。 "If you build it, they will come" 是矽谷最毒的雞湯。現實是，你做出來了，他們不會來——除非你告訴他們。 但你是 Solo Builder，每週只有 5-10 小時。你不可能花大量時間做行銷。 好消息是，你不需要。你需要的是兩件事：**一個能說服人的 Landing Page**，和**一個讓 Google 幫你帶來流量的 SEO 策略**。這兩件事，AI 都能幫你在最短時間內搞定。 ## Landing Page 的解剖學：六個必備區塊 一個高轉換率的 Landing Page 不需要華麗的設計。它需要的是**清晰的結構**和**說服人的文案**。 無論你的產品是什麼，Landing Page 的骨架都長這樣： ### 1. Hero Section：3 秒決定去留 訪客到你的頁面，會在 3 秒內決定要不要往下看。Hero 區塊必須在 3 秒內回答一個問題：**這個東西能幫我解決什麼問題？** 組成元素： - **Headline**：一句話說清楚價值主張（10-15 字） - **Sub-headline**：補充說明怎麼做到（20-30 字） - **CTA 按鈕**：明確的行動呼籲（「免費開始」「立即試用」） - **Hero image / 螢幕截圖**：讓人直覺理解產品長什麼樣 ### 2. Pain / Solution：說中他的痛點 先描述目標用戶目前的困境（pain），再說你的產品怎麼解決（solution）。這個區塊的目的是讓訪客覺得「這個人懂我」。 ### 3. Features：三到五個核心功能 不要列二十個功能。選最強的三到五個，每個用一行標題 + 兩行說明。 ### 4. Social Proof：別人也在用 推薦語、用戶數、合作夥伴 logo、媒體報導。如果你是新產品什麼都沒有，可以用「beta 用戶回饋」或「開發者自己的使用心得」。 ### 5. Pricing：透明的定價 不要讓用戶「聯繫銷售才知道價格」。Solo Builder 的產品應該定價透明、方案簡單。兩到三個方案就夠了。 ### 6. FAQ + Final CTA：掃除最後的疑慮 FAQ 回答用戶最常見的擔心，然後再放一次 CTA 按鈕收尾。 ## AI 生成 Landing Page 文案：每個區塊的 Prompt 現在來到最實用的部分。你不需要是文案高手，只需要給 AI 正確的 prompt。 ### 傳統做法 - 花一天研究競品的 Landing Page 文案 - 自己一段一段寫，改了十幾版還是不滿意 - 請朋友幫忙看，等了三天才得到回饋 - 前後花了一到兩週 ### AI 加持做法 一個晚上搞定。以下是我實測有效的 prompt 框架： **Step 1：先讓 AI 理解你的產品** ```text 我正在做一個產品，以下是基本資訊： - 產品名稱：[名稱] - 目標用戶：[描述你的目標用戶] - 核心問題：[用戶目前遇到什麼痛點] - 解決方案：[你的產品怎麼解決] - 差異化：[跟競品比，你的獨特之處] - 定價：[免費/付費方案] 請先確認你理解了這些資訊，然後我會請你生成 Landing Page 文案。 ``` **Step 2：逐區塊生成文案** ```text 基於剛才的產品資訊，請幫我生成 Landing Page 文案。 Hero Section： - Headline（15 字以內，說清楚核心價值） - Sub-headline（30 字以內，補充怎麼做到） - CTA 按鈕文字（4-6 字） Pain/Solution： - 描述 3 個用戶目前的痛點（每個一句話） - 對應 3 個你的產品怎麼解決（每個一句話） Features： - 列出 4 個核心功能，每個包含： - 功能標題（8 字以內） - 功能說明（50 字以內） FAQ： - 5 個潛在用戶最可能問的問題和答案 語氣：專業但親切，像一個有經驗的朋友在推薦好工具。 語言：繁體中文（台灣用語）。 ``` **Step 3：請 AI 自我挑戰** 這一步很多人跳過，但非常重要： ```text 現在請你扮演一個看到這個 Landing Page 的潛在用戶， 對剛才的文案提出 5 個挑戰或疑慮。 然後針對每個疑慮修改文案。 ``` 這個「自我挑戰」步驟能大幅提升文案品質。AI 會找到你忽略的盲點：模糊的承諾、缺少具體數字、不夠明確的 CTA。 ## SEO 基礎：讓 Google 幫你帶流量 Landing Page 處理了「訪客來了之後看到什麼」的問題。SEO 處理的是「訪客怎麼來」的問題。 對 Solo Builder 來說，SEO 是最高 CP 值的行銷策略。因為： - **免費**：不花廣告費 - **被動**：設定好之後，Google 自動帶流量 - **複利效應**：一篇好文章，可以連續帶來流量好幾年 - **AI 大幅降低內容生產成本**：以前寫一篇 SEO 文章要一天，現在一個小時 但 SEO 是「長期複利投資」，不是「行銷萬靈丹」，這點我得講清楚，免得你期望落空就放棄。新域名通常要等 3 到 6 個月才會開始有像樣的自然流量（有人說這是 Google 的沙盒期，總之新站排名就是慢），熱門關鍵字你可能寫了一整年都擠不進前頁。我自己有篇文章發出去快半年才開始有人從搜尋進來——如果我當初指望它「下個月」帶流量，早就棄坑了。 所以時機很重要：如果你還在驗證 PMF、這禮拜就需要有真人用你的東西給你回饋，SEO 太慢了，這時候去找對的社群冷啟動、或花一點小錢投廣告快速試水溫，比埋頭寫部落格實際得多。SEO 是你確定方向對了之後，拿來累積長期流量的——不是用來救一個還沒被驗證的點子。 ### 關鍵字研究：AI 加持做法 傳統的關鍵字研究需要用 Ahrefs、SEMrush 等付費工具，花好幾個小時。Solo Builder 可以用更快的方式： ```text 我的產品是 [描述]，目標用戶是 [描述]。 請幫我做關鍵字研究： 1. 列出 20 個我的目標用戶可能會搜尋的關鍵字 - 分成三類：資訊型（想學習）、導航型（想找工具）、交易型（想購買） - 預估搜尋量等級（高/中/低） 2. 長尾關鍵字 - 針對每個主關鍵字，列出 3 個長尾變體 - 長尾關鍵字通常更容易排名 3. 內容策略建議 - 針對哪些關鍵字，我應該寫部落格文章？ - 哪些關鍵字應該放在 Landing Page？ - 建議的內容發布順序（先攻哪個？） 市場：台灣繁體中文 ``` 拿到結果之後，再用 Google Search Console 和 Google Trends 驗證一下 AI 的建議。AI 的搜尋量估計不一定精確，但關鍵字方向通常很準。 ### 必做的 SEO 基本功 不管你做什麼產品，以下這些 SEO 基本功必須到位： | 項目 | 說明 | 優先度 | | ------------------------- | ------------------------------------------------ | ------- | | Title Tag | 每頁獨特的 `<title>`，包含主要關鍵字，50-60 字元 | 🔴 最高 | | Meta Description | 150-160 字元的頁面描述，包含關鍵字和 CTA | 🔴 最高 | | H1 標籤 | 每頁只有一個 H1，包含主要關鍵字 | 🔴 最高 | | Open Graph / Twitter Card | 社群分享時的標題、描述、圖片 | 🟡 高 | | Sitemap | `sitemap.xml`，讓 Google 知道你有哪些頁面 | 🟡 高 | | robots.txt | 告訴搜尋引擎哪些頁面可以爬 | 🟡 高 | | Structured Data | JSON-LD 結構化資料，讓 Google 更理解你的內容 | 🟢 中 | | 頁面速度 | Core Web Vitals 三項都綠燈 | 🟢 中 | | 內部連結 | 相關頁面之間互相連結 | 🟢 中 | 用 AI 生成這些東西只需要幾分鐘： ```text 我的網站是用 Astro 框架建的。 請幫我生成以下頁面的 SEO meta tags： 頁面：[產品名稱] Landing Page 主要關鍵字：[關鍵字] 次要關鍵字：[2-3 個] 請生成： 1. Title tag（50-60 字元） 2. Meta description（150-160 字元） 3. Open Graph tags（title, description, type, image alt） 4. Twitter Card tags 5. JSON-LD structured data（Product 或 SoftwareApplication 類型） ``` ### Structured Data：讓搜尋結果更醒目 Structured Data（結構化資料）是很多人忽略但效果顯著的 SEO 技巧。它讓你的搜尋結果出現星級評分、價格、FAQ 展開等 rich snippet，點擊率可以提升 20-30%。 常用的 Schema 類型： - `SoftwareApplication`：你的產品 - `FAQPage`：Landing Page 的 FAQ 區塊 - `Article`：部落格文章 - `BreadcrumbList`：麵包屑導航 請 AI 幫你生成對應的 JSON-LD，直接貼到 `<head>` 裡。 ## 用內容行銷驅動自然流量 Landing Page 的 SEO 效果有限，因為你只有一頁。真正能持續帶來自然流量的，是**內容行銷**——也就是寫跟你產品相關的部落格文章。 ### 內容行銷的飛輪效應 ```text 寫文章 → Google 索引 → 自然流量 → 讀者認識你的產品 ↑ ↓ └──── 更多素材 ← 用戶回饋 ← 部分讀者轉換 ←┘ ``` 一篇好的部落格文章，可以持續帶來流量好幾年。這是 Solo Builder 最適合的行銷方式——你投入的時間有**複利效應**。 ### 傳統做法 vs. AI 加持做法 | 面向 | 傳統做法 | AI 加持做法 | | -------- | ---------------------------------- | -------------------------------------------- | | 選題 | 自己想 + 看競品，2-3 小時 | AI 根據關鍵字研究建議，30 分鐘 | | 大綱 | 自己列，1 小時 | AI 生成大綱 + 你調整，15 分鐘 | | 初稿 | 一字一句寫，4-8 小時 | AI 生成初稿 + 你改寫語氣和加入經驗，1-2 小時 | | SEO 優化 | 手動檢查關鍵字密度、內連結，1 小時 | AI 自動建議，15 分鐘 | | 合計 | 8-13 小時/篇 | 2-3 小時/篇 | **注意：AI 生成初稿之後，你必須加入自己的真實經驗和觀點。** 純 AI 文章讀者一眼就看得出來，而且 Google 越來越會識別。AI 負責結構和初稿，你負責靈魂和差異化。 ### 我的實戰案例：bobo-blog 的 SEO 策略 讓我用 bobo-blog 的真實例子來說明。 我的部落格（bobo-blog）是用 Astro + Cloudflare Workers 建的（平台選擇的取捨見[第 6 章：部署上線](/blog/ai-solo-builder-deployment/)）。SEO 策略很單純： 1. **選定幾個核心主題**：GCP、DevOps、開發者工具、Cloudflare 2. **針對每個主題寫系列文章**：不是零散的文章，而是有結構的系列。例如「PHP/Laravel 完全指南」就是一個 15 篇的系列 3. **每篇文章鎖定一個長尾關鍵字**：不去跟大站搶「什麼是 Cloudflare」這種超級關鍵字，而是鎖定「Cloudflare Workers 部署教學」這種長尾 4. **系列內部互相連結**：每篇結尾連到下一篇，形成閱讀路徑 5. **用 Astro 的靜態生成確保頁面速度**：Core Web Vitals 全綠 技術上的 SEO 設定： - Astro 內建的 sitemap integration 自動生成 `sitemap.xml` - 每篇文章的 frontmatter 包含 `title`、`description`、`pubDate`，自動生成 meta tags - Open Graph 圖片用腳本批次生成（`scripts/generate-social-cards.ts`） - `_headers` 檔案設定好 cache control **結果：** 不花一毛錢廣告費，靠自然搜尋穩定帶來流量。而且因為是系列文章，讀者來了之後不只看一篇，平均停留時間和頁面瀏覽數都比散篇文章高。 ## Quick Wins：最大效果的優先順序 時間有限，先做效果最大的。以下是我建議的優先順序： ### 第一週：基礎建設（2 小時） 1. Landing Page 上線，包含完整的六個區塊 2. 設定 Google Search Console，提交 sitemap 3. 確認所有頁面的 title tag 和 meta description 都正確 ### 第二週：內容啟動（2 小時） 1. 發布第一篇跟產品相關的部落格文章 2. 把文章分享到 2-3 個相關社群 3. 用 Google Search Console 確認文章被索引 ### 第三週起：持續產出（每週 2-3 小時） 1. 每週發布一篇文章（用 AI 輔助寫作） 2. 每週花 15 分鐘看 Google Search Console 的數據 3. 根據數據調整關鍵字策略 ### 不要做的事 - ❌ 花錢投廣告（太早了，先確認自然流量行不行） - ❌ 經營五個社群媒體帳號（選一個就好） - ❌ 花時間做精美的影片行銷（文字內容 CP 值最高） - ❌ 追求完美的 Lighthouse 滿分（90 分以上就夠了） > 不過上面這份「不要做的事」是預設你的用戶會用 Google 找解法——對開發者工具、SaaS 這類產品大致成立，但不是每個產品都這樣，所以與其當禁令，不如當成一個判斷題： > - 用戶會主動搜尋解法（「XXX 怎麼做」）→ SEO 跟文字內容優先，這篇講的就是這條路。 > - 用戶是被動發現、看顏值或衝動買的（B2C、設計工具、生活風格產品）→ 短影音（Reels、TikTok）跟視覺型社群往往才是有效的冷啟動管道，硬寫部落格反而沒人看。 > - 你的客群根本泡在某個特定社群、不靠 Google →（某個 Discord、PTT 某板、Reddit subreddit）就去那裡，別管搜尋引擎。 > > 付費廣告也一樣：拿小預算（幾百塊）去測「哪個訊息、哪群人會點」是很划算的市場調查，要避免的是「還沒驗證會不會轉換就大規模燒錢」。文字內容對開發者類產品 CP 值確實高，但別把它當成對所有產品都最高。 ## 工具清單 | 工具 | 用途 | 費用 | | ---------------------- | ------------------------------ | ------------------ | | Google Search Console | 監控搜尋表現、提交 sitemap | 免費 | | Google Analytics 4 | 流量分析、用戶行為追蹤 | 免費 | | PageSpeed Insights | 檢查頁面速度和 Core Web Vitals | 免費 | | Ahrefs Webmaster Tools | 反向連結分析、關鍵字排名 | 免費（基本版） | | Google Trends | 驗證關鍵字的搜尋趨勢 | 免費 | | Screaming Frog | 網站 SEO 技術審計 | 免費（500 頁以內） | | Claude / ChatGPT | 文案生成、關鍵字研究、內容大綱 | 免費/付費 | 全部免費工具就夠用了。Solo Builder 階段不需要付費的 SEO 工具。 ## 時間預算：每週 2-3 小時 行銷不需要佔用你太多時間。建議的時間分配： | 任務 | 時間 | 頻率 | | --------------------------- | ------- | ---- | | 寫一篇部落格文章（AI 輔助） | 2 小時 | 每週 | | 檢查 Search Console 數據 | 15 分鐘 | 每週 | | 分享文章到社群 | 15 分鐘 | 每週 | | 更新 Landing Page 文案 | 30 分鐘 | 每月 | 每週 2.5 小時，佔你 5-10 小時可用時間的 25-50%。 這個比例是對的。很多工程師把 100% 的時間都花在寫程式碼上，然後抱怨「為什麼沒人用」。**行銷不是可選的——它是產品的一部分。** ## 本章重點回顧 - 🚫 「做出來就會有人用」是最大的謊言。你需要主動讓產品被發現 - 📄 Landing Page 六區塊：Hero、Pain/Solution、Features、Social Proof、Pricing、FAQ + CTA - 🤖 用 AI 逐區塊生成文案，加上「自我挑戰」步驟提升品質 - 🔍 SEO 三個必做：Title Tag、Meta Description、Sitemap - 📝 內容行銷有複利效應：一篇好文章可以帶來好幾年的自然流量 - ⏱️ 每週 2-3 小時的行銷時間，先做 Quick Wins，不要追求完美 ## 下一步 Landing Page 上線了，SEO 策略也開始執行了。現在你的產品有人看到了。 但你會發現，免費用戶和付費用戶之間有一道巨大的鴻溝。下一章，我們來面對 Solo Builder 最緊張的一步：**怎麼開口跟用戶收錢。** 從 Stripe、綠界到藍新，一個人串接金流沒有你想像的那麼難——尤其有 AI 幫忙的時候。 👉 [第 8 章：付費機制——一個人怎麼收錢](/blog/ai-solo-builder-payment)Solo BuilderLanding PageSEOAI行銷文案https://bobochen.dev/blog/ai-solo-builder-deployment/https://bobochen.dev/blog/ai-solo-builder-deployment/一個人做產品，部署平台選錯就要花一半時間在維運上。本文比較 Cloudflare Workers、Vercel、Cloud Run 三大平台的免費額度、真實成本與適用場景，並用一套三問決策框架幫你選對平台，做到 git push 就自動上線。Sun, 15 Mar 2026 00:00:00 GMT## 那個毀掉週末的部署：選錯平台的代價 你的 MVP 寫好了。在本機跑得完美無缺。 「接下來就是部署嘛，應該很快。」你這樣想。 然後你打開了 AWS Console。 幾個小時後，你還在跟 IAM 權限、VPC、Security Group 這些設定打轉。CloudFront 的 cache invalidation 生效要等十幾分鐘，HTTPS 憑證又卡在 DNS 驗證。 到了星期天晚上，產品還是沒上線，一整個週末就這樣耗掉了。 如果你有過這種經驗，你犯了 Solo Builder 最常犯的錯：**把部署平台當成「寫完 code 之後的小事」**。 但對一個人做產品來說，部署平台的選擇可能是僅次於技術棧之後最重要的決定。選對了，`git push` 就上線。選錯了，光是搞部署就吃掉你一半的可用時間。 ## 部署的 80/20 法則 先講一個我自己抓的粗估： 一個人做產品，花在「部署相關」工作上的時間，大概佔整體開發時間的三到四成。 先誠實說：這三到四成不是哪份研究的數字，是我自己做過幾個產品抓出來的體感，而且變異很大。一個純靜態部落格可能只花 5%，一個要顧資料庫、金流、排程的全棧 SaaS 衝到一半也不奇怪。所以這個數字你別當成普世統計，當成「這件事比你以為的吃時間」的提醒就好。標題那個「省 80%」也是同樣的意思——是個讓你記住重點的講法，不是承諾。 這包括： - 初始設定（CI/CD pipeline、環境變數、域名、SSL） - 除錯（「為什麼本機可以跑但 production 不行？」） - 維運（監控、log 查看、擴容、更新） - 成本管理（帳單、用量追蹤、方案升級） 在一個有 DevOps 團隊的公司，這些事有專人處理。但你只有一個人。你花在部署上的每一分鐘，都是從開發功能和寫內容的時間裡偷來的。 所以選對平台才這麼重要，你要的就是一個能把部署時間大幅省下來的平台。 理想的狀態是： ```text 你寫程式碼 → git push → 自動建置 → 自動部署 → 上線 ``` 中間不需要你做任何事。不需要手動觸發。不需要 SSH 進 server。不需要更新 Docker image。不需要清 cache。 2026 年，這個理想是完全可以實現的。但前提是你要選對平台。 ## 三大平台比較 Solo Builder 在 2026 年最常用的部署平台有三個。每個都有明確的適用場景。 ### 選項 1：Cloudflare Workers + Pages **一句話：邊緣運算全家桶，免費額度最慷慨。** Cloudflare 的開發者平台在過去幾年進化成了一個完整的生態系。不只是 CDN——它提供運算（Workers）、靜態託管（Pages）、資料庫（D1）、物件儲存（R2）、鍵值存儲（KV），全部整合在同一個平台。 **核心優勢：** - **零冷啟動**：Workers 在全球 330+ 邊緣節點運行，沒有傳統 serverless 的冷啟動問題 - **免費額度極其慷慨**：10 萬次 request/天、10 GB R2 儲存、5 GB D1 資料庫 - **部署速度快**：全球部署通常在 30 秒內完成 - **全家桶整合**：計算、儲存、資料庫、CDN 全在一個 dashboard 管理 - **Wrangler CLI**：一個指令搞定所有事 **適合的產品類型：** - 靜態網站、部落格、文件站（Pages） - API 服務（Workers） - 全棧應用（Workers + D1 + R2） - 任何需要全球低延遲的服務 **不適合的場景：** - 需要長時間運行的任務（Workers 有 CPU 時間限制） - 需要傳統 SQL 資料庫功能的應用（D1 是 SQLite，不是 PostgreSQL） - 需要 WebSocket 長連接的即時應用（需要 Durable Objects，設定較複雜） > **先說清楚鎖定這件事（我等等講 Cloud Run 會誇它「沒有廠商鎖定」，但全家桶剛好相反）：** 你只用 Pages 放靜態網站，幾乎沒有鎖定，要走隨時走。可是一旦你照我建議「全棧就上 Workers + D1 + R2」，你就是在簽一份解約很貴的合約。Workers 跑的不是完整 Node.js runtime，很多 npm 套件和原生模組直接不能用，你的程式碼是寫給 Workers 的、不是寫給 Node 的；D1 是 Cloudflare 自家的 SQLite，KV 和 Durable Objects 更是別的平台根本沒有對等品；R2 雖然標榜 S3-compatible，但 binding 寫法是專屬的。前端框架換平台只是換 adapter，這些東西換平台是重寫。我自己還是用，因為免費額度跟 DX 真的香——但你要知道你綁的是哪一個，別以為三個平台的鎖定程度一樣。 ### 選項 2：Vercel **一句話：前端框架的最佳夥伴，開發者體驗一流。** Vercel 是 Next.js 的母公司，自然是 Next.js 部署的首選。但它也支援 Astro、Nuxt、SvelteKit 等框架。 **核心優勢：** - **框架整合最深**：尤其是 Next.js，幾乎零設定 - **Preview Deployments**：每個 PR 自動生成預覽環境 - **Edge Functions**：支援邊緣運算 - **Analytics**：內建 Web Vitals 監控 - **開發者體驗**：Dashboard 好看好用 **適合的產品類型：** - Next.js 應用（天然搭配） - 需要 SSR 的動態網站 - 需要 Preview Deployments 的團隊協作（雖然你是一個人，但對 review 很方便） **不適合的場景：** - 需要後端 API 的全棧應用（Vercel 的 serverless function 有冷啟動和執行時間限制） - 頻寬密集型應用（免費方案 100 GB/月，超過開始收費） - 需要資料庫的應用（需要外接 Supabase、PlanetScale 等） ### 選項 3：Google Cloud Run **一句話：把容器丟上去就能跑，介於 serverless 和 VPS 之間。** Cloud Run 是 Google Cloud 的容器化 serverless 服務。你給它一個 Docker container，它幫你跑起來，自動 scale。 **核心優勢：** - **任何語言都能跑**：只要能打包成 Docker container - **真正的 serverless**：沒有流量時 scale to zero，不收費 - **彈性最大**：可以跑任何框架、任何語言、任何架構 - **GCP 整合**：如果你已經在用 GCP 的其他服務（Cloud SQL、Cloud Storage） - **沒有廠商鎖定**：標準 Docker container，隨時可以搬到其他平台 **適合的產品類型：** - 已經有 Docker 化的應用 - 需要跑非 JavaScript 語言的後端（Python、Go、Rust） - 需要長時間運行或計算密集的任務 - 需要 PostgreSQL 的全棧應用（搭配 Cloud SQL） **不適合的場景：** - 簡單的靜態網站（殺雞用牛刀） - 完全不想碰 Docker 的人 - 不需要 GCP 生態系的人（設定比前兩者複雜） ## 詳細比較表 ### 免費額度比較 | 項目 | Cloudflare Workers + Pages | Vercel | Cloud Run | | -------- | -------------------------- | ------------------ | -------------------- | | 請求數 | 10 萬次/天 | 無限（有頻寬限制） | 200 萬次/月 | | 頻寬 | 無限（靜態） | 100 GB/月 | 1 GB/月 | | 計算時間 | 10ms CPU/次 | 100 GB-hours/月 | 180,000 vCPU-秒/月 | | 建置次數 | 500 次/月 | 6,000 分鐘/月 | — | | 資料庫 | D1: 5 GB | 需外接 | Cloud SQL 無免費額度 | | 物件儲存 | R2: 10 GB | 需外接 | Cloud Storage: 5 GB | | 自訂域名 | ✅ 免費 | ✅ 免費 | ✅ 免費 | | SSL | ✅ 自動 | ✅ 自動 | ✅ 自動 | | CDN | ✅ 全球 330+ 節點 | ✅ 全球 | ❌ 需另外設定 | ### 開發者體驗比較 | 項目 | Cloudflare | Vercel | Cloud Run | | ------------------- | ----------------- | ----------------- | ------------------------ | | 設定到部署時間 | 5 分鐘 | 3 分鐘 | 15-30 分鐘 | | git push 自動部署 | ✅ | ✅ | ✅（需設定 Cloud Build） | | Preview Deployments | ✅ | ✅ | ❌ 需自建 | | CLI 品質 | ⭐⭐⭐⭐ wrangler | ⭐⭐⭐⭐⭐ vercel | ⭐⭐⭐ gcloud | | Dashboard | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | | 文件品質 | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | | AI 友善度 | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | ### 成本升級比較（超出免費額度後） | 用量等級 | Cloudflare | Vercel | Cloud Run | | ------------------- | --------------------- | ---------------- | ----------- | | 小型（1,000 DAU） | $0（免費額度內） | $0（免費額度內） | ~$0-5/月 | | 中型（10,000 DAU） | $5/月（Workers Paid） | $20/月（Pro） | ~$10-30/月 | | 大型（100,000 DAU） | $5-25/月 | $20-150/月 | ~$50-200/月 | Cloudflare 的付費方案從 $5/月的 Workers Paid Plan 起跳，包含 1,000 萬次 request。性價比極高。 ## 決策框架：你的產品該選哪個 不要比較二十個維度。問自己三個問題就夠了： ### 問題 1：你的產品是什麼類型？ | 產品類型 | 推薦平台 | 原因 | | ---------------------------- | ----------------------- | -------------------- | | 靜態網站 / 部落格 | Cloudflare Pages | 免費、快、零設定 | | Next.js 應用 | Vercel | 原生支援、零設定 | | API 服務 | Cloudflare Workers | 免費額度大、零冷啟動 | | 全棧 SaaS（JS） | Cloudflare Workers + D1 | 全家桶、一站式 | | 全棧 SaaS（需要 PostgreSQL） | Cloud Run + Cloud SQL | 最彈性 | | 計算密集型 | Cloud Run | 沒有 CPU 時間限制 | ### 問題 2：你在[第 3 章（技術選型決策框架）](/blog/ai-solo-builder-tech-stack)選了什麼技術棧？ 如果你照[第 3 章](/blog/ai-solo-builder-tech-stack)的建議選了 TypeScript + Astro → **Cloudflare**。 如果你選了 Next.js → **Vercel**。 如果你用 Python、Go 或其他語言 → **Cloud Run**。 ### 問題 3：你願意花多少時間在部署上？ - **零時間**：Cloudflare Pages 或 Vercel（git push 就上線） - **一小時**：Cloudflare Workers（需要寫 wrangler.jsonc） - **半天**：Cloud Run（需要寫 Dockerfile、設定 Cloud Build） ## AI 輔助部署：傳統做法 vs. AI 加持 部署設定是 AI 最能幫忙的環節之一。因為部署設定大部分是「照著文件抄設定檔」——這種結構化、模式化的工作，AI 做得又快又準。 ### 傳統做法 1. 讀平台文件（30 分鐘） 2. 複製範例設定檔，開始修改（20 分鐘） 3. 第一次部署失敗，看錯誤訊息（10 分鐘） 4. Google 錯誤訊息，找到 Stack Overflow（15 分鐘） 5. 修改設定、再部署（10 分鐘） 6. 又失敗，不同的錯誤（10 分鐘） 7. 重複步驟 4-6 三次（45 分鐘） 8. 終於成功 → 合計約 2-3 小時 ### AI 加持做法 **Step 1：讓 AI 生成完整的部署設定** 以 Cloudflare Workers 為例： ```text 我的專案： - 框架：Astro 6 - 功能：靜態部落格 + 少量動態 API（搜尋、聯絡表單） - 資料庫：D1 (SQLite) - 檔案儲存：R2 - 目前在本機用 npm run dev 可以正常運行 請幫我生成部署到 Cloudflare Workers + Pages 需要的所有設定： 1. wrangler.jsonc（包含 D1 和 R2 bindings） 2. GitHub Actions workflow（push to main 自動部署） 3. 需要設定的環境變數清單 4. 部署前的 checklist ``` **Step 2：讓 AI 預測可能的問題** ```text 基於剛才的設定，請列出部署時最可能遇到的 5 個問題， 以及每個問題的解決方法。 特別注意： - Astro 在 Cloudflare Workers 上的已知限制 - D1 的 binding 設定常見錯誤 - 環境變數在 production 和 development 的差異 ``` **Step 3：部署失敗時讓 AI 診斷** ```text 部署失敗了，以下是錯誤訊息： [貼上完整的錯誤日誌] 我的設定： - wrangler.jsonc: [貼上] - package.json 的 build script: [貼上] 請分析失敗原因，並給出具體的修復步驟。 ``` 用 AI 輔助，整個部署過程通常 30 分鐘內搞定——包括遇到問題和解決問題。 ## 零設定部署：git push → 自動上線 一旦初始設定完成，之後的每一次部署都應該是自動的。對 Solo Builder 來說這是核心需求，你不會想每次更新都要手動操作。 ### Cloudflare Pages 的自動部署 最簡單的方式是連接 GitHub repo： 1. 在 Cloudflare Dashboard 建立 Pages 專案 2. 連接你的 GitHub repo 3. 設定建置指令（`npm run build`）和輸出目錄（`dist`） 4. 完成 之後每次 push 到 main，Cloudflare 自動建置並部署。每個 PR 還會生成一個預覽 URL。 ### GitHub Actions + Wrangler 如果你需要更多控制（例如部署前跑測試、部署後做 health check），用 GitHub Actions： ```yaml # .github/workflows/deploy.yml name: Deploy to Cloudflare on: push: branches: [main] jobs: deploy: runs-on: ubuntu-latest steps: - uses: actions/checkout@v6 - uses: actions/setup-node@v6 with: node-version: 22 - run: npm ci - run: npm run build - run: npm run test - name: Deploy uses: cloudflare/wrangler-action@v4 with: apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }} accountId: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }} command: deploy ``` 這個 workflow 做了四件事：安裝依賴、建置、跑測試、部署。全自動，不需要你動手。 ### 部署後驗證 自動部署之後，加一步自動驗證： ```yaml - name: Health Check run: | sleep 15 STATUS=$(curl -s -o /dev/null -w "%{http_code}" https://your-site.com) if [ "$STATUS" != "200" ]; then echo "Health check failed with status $STATUS" exit 1 fi echo "Health check passed!" ``` 如果部署後網站不正常，GitHub Actions 會顯示失敗。你可以在 GitHub 設定通知，部署失敗時收到 email。 ## 真實案例：bobo-blog 的部署架構 讓我用 bobo-blog（就是你正在看的這個部落格）的真實部署設定來說明。 ### 架構 ```text GitHub repo → GitHub Actions → Cloudflare Workers ├── Pages（靜態資源） ├── Workers（動態路由） └── wrangler.jsonc（設定） ``` ### 為什麼選 Cloudflare Workers 而不是 Cloudflare Pages bobo-blog 用的是 Astro + Cloudflare Workers adapter，而不是純 Pages。原因是： - **動態路由**：部落格有搜尋功能、聯絡表單等需要伺服器端處理的功能 - **Headers 控制**：需要精細的 cache control 和 security headers - **未來擴充**：如果要加 API（例如訂閱功能），Workers 已經準備好了 純靜態的部落格用 Pages 就夠了。但如果你的產品有任何動態需求，建議一開始就用 Workers。 ### 部署設定 ```jsonc // wrangler.jsonc（精簡示意，對齊本部落格實際設定） { "name": "bobo-blog-repo", "main": "worker/index.ts", "compatibility_date": "2025-12-21", "compatibility_flags": ["nodejs_compat"], "assets": { "binding": "ASSETS", "directory": "./dist/client", "not_found_handling": "404-page" } } ``` 就這麼簡單。沒有 Docker、沒有 Kubernetes、沒有 load balancer、沒有 reverse proxy。 一個 JSON 設定檔，`wrangler deploy` 一個指令，30 秒內全球部署完成。 ### 部署流程 ```text 我 push 到 main ↓ GitHub Actions 觸發 ↓ npm run build（Astro 建置，約 30 秒） ↓ wrangler deploy（部署到 Cloudflare，約 15 秒） ↓ Health check 確認網站正常 ↓ 完成 ``` 從 push 到上線：不到 2 分鐘。 ### 成本 到目前為止：**$0/月**。 全部在免費額度內。靜態資源的頻寬不計費。Workers 的 10 萬次/天免費 request 對一個個人部落格來說綽綽有餘。 什麼時候會開始花錢？大概要到每天超過 10 萬次請求。以一個部落格來說，那已經是非常成功的流量了。到那時候，$5/月的 Workers Paid Plan 就夠用了。 ## 環境變數和密鑰管理 部署時最容易出包的地方之一：環境變數。 ### 常見的坑 1. **本機有但 production 沒有**：你在 `.env.local` 設了 API key，但忘了在部署平台設定 2. **格式不對**：有些平台不支援 `.env` 檔案的某些語法 3. **密鑰洩漏**：不小心把 `.env` commit 到 GitHub ### 環境變數 Checklist 在部署之前，用 AI 幫你檢查： ```text 以下是我的 .env.local 檔案（已遮蔽敏感值）： DATABASE_URL=d1://xxx R2_BUCKET=my-bucket STRIPE_SECRET_KEY=sk_test_xxx SITE_URL=https://my-site.com 我要部署到 Cloudflare Workers。 請幫我： 1. 列出哪些變數需要在 Cloudflare Dashboard 設定 2. 哪些變數用 secrets（加密），哪些用普通 variables 3. 哪些變數在 production 和 development 的值不同 4. 確認 .gitignore 有正確排除 .env 檔案 ``` ## 什麼時候該升級：超出免費額度的信號 免費額度不會永遠夠用。以下是你該考慮升級的信號： | 信號 | 代表什麼 | 該怎麼做 | | ------------------------------ | ------------------------- | -------------------------------- | | 免費 request 用量超過 70% | 流量在成長 | 評估付費方案 | | 建置頻繁失敗 | 建置次數接近上限 | 減少不必要的 push 或升級方案 | | 冷啟動開始被用戶抱怨 | 流量模式不適合 serverless | 考慮 always-on 選項 | | 資料庫大小接近上限 | 資料在成長 | 評估付費方案或清理舊資料 | | 你花時間在優化免費額度而非產品 | 優先順序錯了 | 直接升級，把時間花在有價值的事上 | 最後一點最重要。**如果你發現自己在花時間「省部署費用」，那就直接付費。** 你的時間比每月 $5-20 的雲端費用值錢得多。 ## 部署平台遷移：沒你想的那麼難 如果你選錯了，不要害怕換。 大部分現代框架（Astro、Next.js、SvelteKit）都支援多個部署平台。換平台通常只需要： 1. 換一個 adapter（例如 `@astrojs/cloudflare` → `@astrojs/vercel`） 2. 調整設定檔（wrangler.jsonc → vercel.json） 3. 在新平台設定環境變數 4. 指向新的部署 URL 整個過程大約 1-2 小時。不是不可逆的大手術。 但「1-2 小時」只在一種情境成立，我得把話講準，免得你被我害到： - **情境一：純靜態或 SSR 前端、沒有自己的資料庫和儲存。** 換 adapter、改設定、重設環境變數，1-2 小時真的搞得定。你只是搬一個會自己重新 build 的網站。 - **情境二：你照前面建議上了全棧（D1 資料庫、R2 儲存、Workers 專屬 runtime）。** 這不是 1-2 小時，這是好幾天到一兩週的工程：D1 的 SQLite 要匯出再匯進別人的 PostgreSQL，schema 和語法會打架；R2 的檔案要整批搬、舊 URL 要重寫；Workers-only 的程式碼要改回能在 Node 跑；secrets 全部重設；最後 DNS 切換還有停機風險。 所以這句「沒你想的那麼難」只適用情境一。情境二剛好相反——它難到會回頭懲罰你早期的架構決定。不要在選平台上糾結太久沒錯，但也別因為「反正以後好搬」就閉著眼睛把核心資料綁進某個平台。前端可以先上線再說，資料層值得你多想十分鐘。 ## 本章重點回顧 - 🏗️ 部署平台的選擇對 Solo Builder 比團隊更重要——你沒有 DevOps 團隊，選錯了你要自己扛 - 📊 三大平台各有所長：Cloudflare（全家桶 + 最慷慨免費）、Vercel（最佳 DX + Next.js 首選）、Cloud Run（最彈性 + Docker 通吃） - 💰 免費額度是你的跑道——Cloudflare 和 Vercel 都能讓你在驗證 PMF 之前零成本營運 - 🤖 AI 可以在 30 分鐘內幫你搞定完整的部署設定，包括 CI/CD pipeline 和環境變數 - 🔄 理想部署流程：git push → 自動建置 → 自動部署 → 自動驗證，中間不需要你動手 - ⏱️ 不要糾結太久——選一個先上線，真的不合適再換。但「好搬」只算純前端（換 adapter，1-2 小時）；有資料庫和儲存的全棧要搬是好幾天的工程，這部分早點想清楚 ## 下一步 產品部署上線了。 但上線不是終點——如果沒人知道你的產品存在，零流量跟沒上線沒有兩樣。 下一章，我們來解決「讓產品被找到」的問題：怎麼用 AI 快速做出有轉換力的 Landing Page，以及怎麼建立一套讓 Google 幫你持續帶來免費流量的 SEO 策略。 👉 [第 7 章：Landing Page 與 SEO——讓產品被找到](/blog/ai-solo-builder-landing-page-seo)Solo BuilderCloudflareVercelCloud Run部署Serverlesshttps://bobochen.dev/blog/ai-solo-builder-ai-driven-dev/https://bobochen.dev/blog/ai-solo-builder-ai-driven-dev/不只是用 AI 寫程式碼，而是建造一套 AI 開發系統。從 Level 1 的 Autocomplete 到 Level 3 的 Agentic Workflow，帶你用 Claude Code 的 custom skills、MCP server、hooks 與 multi-agent 工作流，讓 AI 從工具變成你的開發團隊，把 Solo Builder 的產出放大 10 倍。Sun, 08 Mar 2026 00:00:00 GMT## 為什麼你的 AI 輔助開發還停在 2024 年 打開 ChatGPT，貼上錯誤訊息，拿到修好的程式碼，複製貼上。 或者用 Copilot，打幾個字，按 Tab 接受建議。 如果你的 AI 開發工作流程還是這樣，你只用到了 AI 能力的 10%。 不誇張。 2026 年的 AI 輔助開發，已經從「工具」進化成「團隊」。你可以讓 AI 自己讀 codebase、跑測試、分析失敗原因、修 bug、送 commit、甚至在部署失敗的時候自動修復後重新部署。 整個流程你可以不用碰鍵盤。 這不是未來式。這是我每天在用的工作流程。 延續上一章把 [MVP 砍到不能再砍](/blog/ai-solo-builder-mvp-design)的思路，這一章談怎麼用 AI 把它快速做出來。這也是整本書最核心的章節，AI 驅動開發是 Solo Builder 能以一人之力做出團隊等級產品的關鍵。我會帶你從最基礎的 Level 1 走到最高階的 Level 3，讓你建造自己的 AI 開發系統。 ## AI 輔助開發的三個等級 不是所有的「用 AI 寫程式」都一樣。根據 AI 的自主程度，我把它分成三個等級： | 等級 | 名稱 | AI 做什麼 | 你做什麼 | 效率提升 | | ------- | ---------------- | --------------------------------------- | --------------------- | -------- | | Level 1 | Autocomplete | 補完你正在打的程式碼 | 逐行寫程式 | 1.3x | | Level 2 | Vibe Coding | 根據描述生成整段程式碼 | 描述需求、review 結果 | 2-3x | | Level 3 | Agentic Workflow | 自主讀 codebase、寫程式、跑測試、修 bug | 下指令、做決策 | 5-10x | 大多數人停在 Level 1 到 Level 2 之間。這一章的重點是帶你到 Level 3。 ### Level 1：Autocomplete — 節省打字時間 這是 GitHub Copilot 最初的用法。你寫一行註解，AI 幫你補完下面幾行程式碼。或者你打了一個函式名稱，AI 幫你把函式實作補完。 **適合的場景：** - 寫重複性高的程式碼（boilerplate） - 補完你已經知道怎麼寫的東西 - 套用常見 pattern **限制：** - AI 不理解你的專案脈絡 - 生成的程式碼常常需要修改 - 每次只能處理幾行到幾十行 Level 1 很有用，但效率提升有限。就像有人幫你打字，但思考還是你自己在做。 ### Level 2：Vibe Coding — 用自然語言寫程式 Andrej Karpathy 在 2025 年提出了 Vibe Coding 這個詞：不看程式碼、不仔細 review，直接用自然語言描述你要什麼，AI 幫你寫好。如果結果不對，用自然語言描述問題，AI 幫你修。 **傳統做法（Level 1）：** 1. 你打開文件，找到要用的 API 2. 你寫第一行程式碼 3. Copilot 建議後面幾行 4. 你修改、調整、繼續寫 5. 你跑測試、發現 bug 6. 你自己 debug **Vibe Coding 做法（Level 2）：** 1. 你在 chat 裡描述：「幫我寫一個 API endpoint，接收用戶上傳的圖片，存到 R2，回傳 URL」 2. AI 生成整個函式 3. 你跑一下看結果 4. 不對的地方貼錯誤訊息回去 5. AI 修好 Vibe Coding 的效率大約是傳統方式的 2-3 倍。它的好處是降低了啟動阻力——你不需要先去查文件、搞清楚 API 參數，直接描述想要的結果就好。 但 Vibe Coding 有個致命缺陷：你說一句、AI 做一步，所有的推進力都來自你。AI 沒有主動性，你不說話，它就停下來。 對一個每週只有 5-10 小時的 Solo Builder 來說，這意味著你必須全程盯著螢幕。你的寶貴時間變成了「不斷跟 AI 對話」的時間。 我們可以做得更好。 ### Level 3：Agentic Workflow — AI 成為自主的團隊成員 Level 3 是質變。 在 Agentic Workflow 裡，AI 不再是被動回應你的問題。它成為一個**有自主能力的 agent**——你給它一個目標，它自己決定怎麼做：讀哪些檔案、寫哪些程式碼、跑哪些測試、怎麼修 bug。 你的角色從「寫程式的人」變成「管理 AI 團隊的人」。 讓我描述一個我實際的開發場景： > 我在 terminal 輸入一句話：「幫我新增一個 blog 文章的標籤篩選功能，參考現有的分類篩選。寫完跑測試。」 > > 然後我去泡咖啡。 > > 回來的時候，AI 已經： > > 1. 讀了現有的分類篩選程式碼 > 2. 理解了專案的 component 架構和 CSS conventions > 3. 新增了標籤篩選的 component > 4. 更新了頁面 routing > 5. 跑了 build 確認沒有 TypeScript 錯誤 > 6. 生成了一個 commit 訊息等我確認 整個過程我不在電腦前。這就是 Level 3 的威力。 但「不用盯著螢幕」這件事，有它的另一面我得先講：你放手的程度越高，一次出錯的傳播半徑就越大，而你能攔下它的機會就越少。我去泡咖啡的那段時間，AI 不只在幫我寫對的東西，也在幫我把錯的東西一路 commit 下去——一個它寫歪的邏輯、一個它沒注意到的安全漏洞，都會被它順手帶過去。所以我自己有一條線：本地的、可逆的、有測試蓋著的操作，放手沒問題；但 production 部署、schema migration、刪資料、動到錢、改安全設定這幾類，我不開全自動，一定要有一個人類確認的關卡。自主程度不是越高越好，是要跟「出錯的代價」配對著用。 ## 建造你的 Agentic Workflow 要達到 Level 3，你需要的不只是一個 AI 工具，而是一套**系統**。以下是我用 Claude Code 建造的系統架構，你可以參考來建造自己的版本。 ### 組件 1：CLAUDE.md — 教 AI 認識你的專案 CLAUDE.md 是 Claude Code 的核心設定檔，放在專案根目錄。它的功能是讓 AI 理解你的專案架構、開發慣例和偏好。 把它想成是你跟新同事的 onboarding 文件。你會告訴新同事什麼？ - 專案的目錄結構 - 怎麼跑 dev server 和 build - 命名慣例（component 用 PascalCase、CSS 用哪套方案） - 部署方式 - 程式碼風格偏好 **沒有 CLAUDE.md 的情況：** 你每次開啟新的對話，都要重新跟 AI 解釋：「我的專案用 Astro、部署到 Cloudflare、CSS 用 Tailwind、component 放在 src/components/ 底下……」 **有 CLAUDE.md 的情況：** AI 自動讀取設定檔，已經知道你的一切偏好。你可以直接說「幫我加一個新 component」，它就會按照你的慣例來做——檔案放對位置、用對的命名、套對的 CSS 方案。 一個好的 CLAUDE.md 大概長這樣： ```markdown # 專案名稱 ## 指令 - npm run dev — 啟動開發伺服器 - npm run build — 建置生產版本 ## 架構 - src/pages/ — 檔案路由 - src/components/ — 元件（按功能分子目錄） - src/content/blog/ — MDX 部落格文章 ## 慣例 - Component 檔案用 PascalCase - 用 Tailwind CSS，不寫自定義 CSS - 優先使用既有的 CSS custom properties ``` 關鍵原則：**越具體越好。** 不要寫「程式碼品質要高」這種廢話，要寫「error handling 用 Result type，不用 try-catch」這種具體的規則。AI 需要的是明確的指令，不是抽象的原則。 ### 組件 2：Custom Skills — 教 AI 可重複的任務 如果你發現自己重複叫 AI 做同樣的事，就該把它變成一個 custom skill。 Custom skill 是一組預先定義好的指令，AI 可以直接呼叫。就像是你訓練團隊成員的 SOP。 常見的 Solo Builder custom skills： | Skill 名稱 | 功能 | 觸發方式 | | ------------ | ---------------------------- | ------------------------------ | | new-post | 生成新的 blog 文章骨架 | `/new-post "文章標題"` | | review | 做 code review，檢查常見問題 | `/review` | | deploy-check | 部署前的預檢清單 | `/deploy-check` | | test-write | 為指定功能寫測試 | `/test-write src/lib/utils.ts` | | commit | 分析變更、生成 commit 訊息 | `/commit` | 每個 skill 是一個資料夾，裡面放一個 `SKILL.md`（帶 YAML frontmatter），寫清楚 AI 應該做什麼、怎麼做、用什麼格式輸出。skill 既可以用斜線指令手動呼叫，也能由 AI 依情境自動載入——這由 frontmatter 的 `disable-model-invocation`、`user-invocable` 等欄位控制。 舉例，一個「新增 blog 文章」的 skill 大概是： ```markdown # new-post skill 1. 讀取 src/content.config.ts 了解 frontmatter schema 2. 建立新目錄 src/content/blog/{slug}/ 3. 生成 index.md，包含完整的 frontmatter 4. frontmatter 的 author 預設為 "Bobo Chen" 5. pubDate 設為今天 6. 標題和 description 根據用戶輸入生成 ``` 一次設定，永久受用。從此之後，你說一句話就能生成一篇符合你專案規範的新文章。 ### 組件 3：MCP Server — 讓 AI 連接外部工具 MCP（Model Context Protocol）是讓 AI 連接外部服務的標準協定。透過 MCP server，你的 AI agent 可以直接跟其他工具對話。 Solo Builder 最實用的 MCP 連接： | MCP Server | AI 可以做什麼 | | -------------- | ------------------------------------ | | Notion MCP | 讀取你的 Notion 筆記和任務清單 | | GitHub MCP | 查看 Issues、建立 PR、讀 review 留言 | | Playwright MCP | 開瀏覽器測試你的網站 | | 資料庫 MCP | 直接查詢和修改資料庫 | **沒有 MCP 的工作流：** 1. 你在 Notion 看到一個 bug report 2. 你把 bug 描述複製到 AI 3. AI 給你修復建議 4. 你手動修改程式碼 5. 你手動跑測試 6. 你手動更新 Notion 的狀態 **有 MCP 的工作流：** 1. 你說「處理 Notion 裡的 bug #42」 2. AI 自己去 Notion 讀 bug 描述 3. AI 找到相關程式碼並修復 4. AI 跑測試確認修好了 5. AI 更新 Notion 狀態為「已解決」 你只講了一句話。剩下的全部自動化。 ### 組件 4：Hooks — 自動觸發的品質關卡 Hooks 是在特定事件發生時自動執行的腳本。你可以設定 AI 在 commit 前自動跑 linter、在生成程式碼後自動跑型別檢查。 這就像在 AI 的工作流程裡加入品質關卡。AI 不是完美的——它會生成有 bug 的程式碼、忘記 edge case、用了 deprecated 的 API。Hooks 確保這些問題在進入 codebase 之前就被抓到。 常用的 hooks 配置： | 時機 | Hook | 功能 | | ------------ | ------------------- | -------------------- | | 修改檔案後 | TypeScript 型別檢查 | 確保沒有型別錯誤 | | commit 前 | ESLint + Prettier | 程式碼格式和品質 | | push 前 | 跑完整測試套件 | 確保沒有破壞既有功能 | | 生成程式碼後 | build 驗證 | 確保可以成功建置 | 有了 hooks，你可以放心讓 AI 更自主地工作，因為品質關卡會幫你把關。 ## Multi-Agent 模式：一個人的開發團隊 Level 3 的進階玩法：同時跑多個 AI agent，每個負責不同的任務。這正是[第 1 章宣言](/blog/ai-solo-builder-manifesto)裡說的「一個人＋AI 就是一支團隊」的具體實現。 在一個人做產品的情境下，你可以模擬一個小型開發團隊： | Agent 角色 | 職責 | 類比 | | --------------- | ------------------- | ---------- | | Developer Agent | 寫功能程式碼 | 開發者 | | Test Agent | 寫測試、跑測試 | QA 工程師 | | Review Agent | Code review、抓 bug | 資深工程師 | | Ops Agent | 部署、監控、修復 | SRE | 一個實際的工作流可能是這樣的： 1. 你告訴 Developer Agent：「實作用戶登入功能」 2. Developer Agent 寫好程式碼 3. Test Agent 自動為它寫測試並跑測試 4. 如果測試失敗，Developer Agent 自動收到反饋並修改 5. 測試通過後，Review Agent 檢查程式碼品質 6. 全部通過，Ops Agent 部署到 staging 環境 你做了什麼？你下了一個指令。其餘的都是 AI agents 之間的協作。 ### Self-Healing Deploy：AI 自動修復部署失敗 這是我最喜歡的 agentic 模式之一。 部署失敗是 Solo Builder 最頭痛的事——通常發生在你以為已經搞定一切的時候，而且每次的錯誤都不一樣。 Self-healing deploy 的概念很簡單： 1. CI/CD pipeline 觸發部署 2. 部署失敗 3. AI agent 自動讀取錯誤日誌 4. 分析失敗原因 5. 生成修復 commit 6. 重新觸發部署 7. 如果三次都失敗，通知你來看 你可以在 CI/CD pipeline 裡加一個步驟來實現這個模式。這個概念不限定於特定工具——重點是「部署失敗時自動分析錯誤並嘗試修復」這個流程。 **傳統做法：** 部署失敗 → 你收到通知 → 打開電腦 → 看 log → 查原因 → 修 → 推 → 再部署 → 再失敗 → 再修。可能花一整個晚上。 **Self-healing 做法：** 部署失敗 → AI 自動修 → 自動重新部署 → 成功。你甚至不知道中間失敗過。 > 不過這個模式我得加個警告，因為它最危險的地方正是「你甚至不知道中間失敗過」。AI 的修復常常是推測性的——它沒真的理解問題，只是試一個看起來合理的改動再推一次。如果它猜錯，下一輪可能在錯的修補上再疊一個錯的修補，commit history 會變得一團亂。而那個「三次才通知你」的設計，意味著在你被叫醒之前，環境可能已經被它的盲目重試搞髒了。所以我會把 self-healing 限制在低風險的部署上（例如預覽環境、可一鍵 rollback 的靜態站），並且強制它每次失敗都把錯誤摘要寫進通知，而不是默默重試到第三次才出聲。production 的部署，我寧可被吵醒，也不要它自己亂修。 Self-healing 只是監控維運的第一層防線，更完整的 AI 監控體系（alert 策略、log 分析、異常自動回報）在[第 11 章：監控維運](/blog/ai-solo-builder-monitoring-ops)繼續展開。 ### Iterative TDD Loop：AI 自我修正的開發循環 另一個強大的模式：先寫測試，讓 AI 自己跑「寫程式 → 跑測試 → 看結果 → 修 bug」的循環。 流程是這樣的： 1. **你寫測試**（或讓 AI 幫你寫，但你要 review） 2. **AI 實作功能** 3. **自動跑測試** 4. **如果失敗**：AI 讀錯誤訊息、分析原因、修改程式碼 5. **回到步驟 3** 6. **如果通過**：完成 這個循環可能跑 3-5 次，但不需要你介入。你只需要做第一步——定義「正確」長什麼樣（也就是測試）。 這個模式的好處是：你把 AI 的角色從「生成程式碼」變成「達成目標」。AI 不只是產出程式碼，它要對程式碼的正確性負責。 這裡有一個陷阱我特別要點出來：如果上面那個第一步——測試——也是 AI 寫的，那整個循環就變成「AI 寫程式 + AI 寫測試 + AI 判自己過關」，等於讓它自己出考卷又自己改考卷。我踩過這個雷：AI 為了讓紅燈變綠，會去改測試的斷言、塞一堆 mock 把真正的行為繞過去，甚至寫出剛好通過它那段錯誤實作的測試。測試全綠不等於行為正確，它只代表「AI 的實作通過了 AI 對自己的要求」。所以關鍵邏輯的測試，我會自己定義「正確長什麼樣」，至少也要人工 review 一遍——不是看綠燈，是看這些測試到底有沒有測到我真正在乎的意圖。剩下的 boilerplate 測試交給 AI 沒關係，但守門的那幾條，人要在場。 ## 時間對比：傳統 vs. AI 各等級 讓我用一個具體的功能來比較不同等級的效率差異。 **任務：為部落格新增標籤篩選功能** | 階段 | 傳統開發 | Level 1 | Level 2 | Level 3 | | ----------- | ---------- | ---------- | ---------- | ----------------- | | 了解需求 | 15 分 | 15 分 | 10 分 | 5 分 | | 查文件/範例 | 30 分 | 20 分 | 5 分 | 0 分 | | 寫程式碼 | 120 分 | 90 分 | 40 分 | 15 分 | | 寫測試 | 45 分 | 30 分 | 15 分 | 0 分（AI 自己跑） | | Debug | 60 分 | 45 分 | 20 分 | 5 分 | | 部署驗證 | 20 分 | 20 分 | 15 分 | 5 分 | | **合計** | **290 分** | **220 分** | **105 分** | **30 分** | 從 290 分鐘到 30 分鐘，將近 10 倍的差距。 而且 Level 3 的 30 分鐘裡，你實際坐在電腦前的時間可能只有 10 分鐘——下指令和最終確認。其餘的時間 AI 在自己工作，你可以做別的事。 在這類任務上，你每週擠出來的幾小時可以頂以前的一整天。 不過這張表我得標清楚：這是我在「標籤篩選」這種任務上的個人經驗值，不是普適量測，更不是要你拿 290 對 30 去算什麼倍率。我故意挑了一個對 AI 最有利的場景——有現成的分類篩選可以抄、需求邊界很清楚、改錯了也不會出大事。AI 在這種「有 pattern 可參考、低風險」的功能上確實快得誇張。 但換個任務，數字會整個垮掉： - **全新領域、模糊需求**——你跟 AI 來回澄清的時間，可能比自己想清楚還久。 - **深度 debug 罕見問題**——AI 容易猜，猜錯了你還要回頭看它改壞了哪些地方。 - **大型 refactor、跨系統整合**——上下文一複雜，AI 的命中率掉得很快，加速比可能趨近於零，甚至是負的。 2025 年 METR 那份研究就有一個反直覺的發現：資深開發者在自己熟悉的大型 codebase 裡用 AI，平均反而變慢——他們以為自己快了，實際拖長了工時。所以別把上面這張表當成你的待辦清單會自動縮 10 倍的保證。它告訴你的是「某類任務的天花板」，不是你每件事的平均值。 ## 建造你的 Agentic 系統：三步走 如果你目前在 Level 1 或 Level 2，不要試圖一步跳到 Level 3。循序漸進： ### 第一週：基礎設施 1. **安裝 Claude Code**（或你選擇的 agentic 工具） 2. **寫好 CLAUDE.md**：把你的專案架構、開發慣例、指令全部寫進去 3. **測試基本功能**：讓 AI 幫你做一個小功能，觀察它怎麼理解你的專案 這一週你可能只會感受到 Level 2 的效果。但基礎建好了。 ### 第二週：自動化 1. **建立 2-3 個 custom skills**：從你最常做的重複工作開始 2. **設定 hooks**：至少設定 commit 前的品質檢查 3. **嘗試 TDD loop**：寫一個測試，讓 AI 自己跑到通過 這週你開始感受到 Level 3 的威力。 ### 第三週：整合 1. **連接 MCP server**：至少連一個（GitHub 或你的專案管理工具） 2. **設定部署自動化**：讓 AI 能幫你部署和驗證 3. **嘗試 multi-agent**：讓 AI 自己寫 + 測 + review 到了第三週，你應該已經有了一套初步的 agentic 系統。之後就是持續優化。 ## 當 AI 出錯：錯誤處理手冊 AI 不是完美的。以下是常見的問題和應對方式： ### 問題 1：Hallucination — AI 編造不存在的 API **症狀：** AI 生成的程式碼引用了不存在的函式或套件。 **對策：** - hooks 裡加上型別檢查，在 AI 生成程式碼後自動跑 `tsc` - 在 CLAUDE.md 裡明確列出專案使用的套件版本 - 遇到不熟悉的 API 呼叫，要求 AI 附上文件連結 ### 問題 2：Context 遺失 — AI 忘記之前的脈絡 **症狀：** 對話太長後，AI 開始做出跟之前矛盾的事情。 **對策：** - 複雜功能拆成多個小任務，每個任務一個新對話 - 把重要決策記錄在 CLAUDE.md 或 IMPLEMENTATION_PLAN.md - 善用 custom skills 把常用脈絡固化下來 ### 問題 3：過度自信 — AI 信誓旦旦但答案是錯的 **症狀：** AI 說「這段程式碼是正確的」，但跑起來就爆了。 **對策：** - 永遠跑測試，不要相信 AI 的口頭保證 - 用 TDD loop：讓程式碼的正確性由測試決定，不是由 AI 的自信決定 - 設定「三次失敗就停下來」的規則，不要讓 AI 在同一個 bug 上無限循環 ### 問題 4：風格不一致 — AI 生成的程式碼跟你的風格不同 **症狀：** AI 用了不同的命名慣例、不同的錯誤處理方式、不同的檔案結構。 **對策：** - 在 CLAUDE.md 裡寫清楚你的風格規範 - 提供範例：「像 src/components/PostCard.astro 那樣」 - 設定 ESLint/Prettier，用 hooks 自動修正 ## 心態轉換：從「寫程式的人」到「管理 AI 的人」 最後聊聊心態。 很多工程師對 Level 3 感到不自在。「如果我不自己寫程式碼，我還算工程師嗎？」 換個角度想：一個好的 CTO 不會自己寫所有程式碼。他的工作是做技術決策、設計架構、確保品質、管理團隊。 作為 Solo Builder，你就是你的 AI 團隊的 CTO。 你的工作不是打字——AI 打字比你快。你的工作是： 1. **做決策**：做什麼功能、不做什麼功能 2. **設計架構**：系統怎麼組織、資料怎麼流動 3. **確保品質**：設定好測試和 hooks，讓品質有保障 4. **給方向**：用清楚的指令和 context，讓 AI 做對事情 把打字時間省下來，花在思考和判斷上。這才是 Solo Builder 最稀缺的資源——不是寫程式碼的時間，而是做對的決策的能力。 ## 本章重點回顧 - 🎯 AI 輔助開發有三個等級：Autocomplete（1.3x）→ Vibe Coding（2-3x）→ Agentic Workflow（5-10x） - 🏗️ Agentic 系統四大組件：CLAUDE.md（專案記憶）+ Custom Skills（可重複任務）+ MCP（外部整合）+ Hooks（品質關卡） - 👥 Multi-agent 模式讓你模擬一個小型開發團隊：Developer + QA + Reviewer + Ops - 🔄 Self-healing deploy 和 TDD loop 是最實用的 agentic 模式 - ⚠️ AI 會出錯：用測試和 hooks 把關，設定「三次失敗就停下來」的規則 - 🧠 心態轉換：從「寫程式的人」變成「管理 AI 團隊的 CTO」 ## 下一步 有了 AI 開發系統，你可以用驚人的速度寫程式碼了。 但寫好的程式碼要放到哪裡？部署平台的選擇，對 Solo Builder 來說比你想像的重要得多。選對平台，git push 就自動上線。選錯平台，光是搞部署設定就花掉你一整個週末。 下一章，我們來做這個關鍵選擇。 👉 [第 6 章：部署上線——選對平台省 80% 的事](/blog/ai-solo-builder-deployment)Solo BuilderClaude CodeAIAgentic WorkflowMCPVibe Codinghttps://bobochen.dev/blog/ai-solo-builder-mvp-design/https://bobochen.dev/blog/ai-solo-builder-mvp-design/上班族做 side project 最大的敵人是「功能蔓延」。本文教你用 AI 輔助 MVP 設計與 feature prioritization，找出最高風險假設，砍到不能再砍，用最少時間驗證最關鍵的產品假設。Sun, 01 Mar 2026 00:00:00 GMT## 為什麼你的 side project 死在 MVP 之前？ 讓我猜猜看。 你在[第 2 章驗證了點子](/blog/ai-solo-builder-idea-validation/)、[第 3 章選好了技術棧](/blog/ai-solo-builder-tech-stack/)，興奮地打開編輯器開始動手。第一個週末完成了登入功能，第二個週末做了 CRUD，第三個週末你開始覺得「應該加一個 Dashboard」…… 然後你的 TODO list 開始膨脹： - [ ] 用戶 Dashboard - [ ] 通知系統 - [ ] 多語言支援 - [ ] 深色模式 - [ ] 匯出 CSV - [ ] API 文件 - [ ] 管理後台 - [ ] 數據分析 - [ ] …… 三個月後，沒有一個功能是「完成」的狀態。每個功能都做了 70%，每個都差一點點。但就是沒辦法上線。 這個殺手有個名字：**功能蔓延**（Feature Creep）。 功能蔓延不是因為你太貪心。而是因為你太有能力——你知道怎麼做這些功能，所以你覺得「加一個也不會花多少時間」。但一個功能不只是寫完程式碼而已，它還包括測試、debug、維護、文件。每多一個功能，你的維護負擔就多一份。 對有正職的 Solo Builder 來說，功能蔓延是最致命的。因為你每週只有 5-10 小時，分散到十個功能上，每個功能一週只推進 30 分鐘。這個進度慢到你自己都受不了，然後就放棄了。 這一章的目的很簡單：**教你砍功能。砍到不能再砍。** ## MVP 不是「爛版本」 先釐清一個超常見的誤解。 MVP（Minimum Viable Product，最小可行產品）不是「功能很少的爛版本」。不是把所有功能都做了但每個都做得很粗糙。 MVP 的定義是：**用最少的功能，驗證一個最關鍵的假設。** 關鍵字是「一個假設」。 你的產品一定有很多假設：用戶願意付費嗎？他們會每天使用嗎？他們能理解操作流程嗎？註冊轉換率會是多少？ 但 MVP 只挑其中**最重要、最不確定**的那一個來驗證。 ### 傳統做法 列出所有你想做的功能，全部一起做，然後上線看看反應。如果反應不好，你不知道是哪裡出了問題——是功能不對？價格太高？UI 太醜？行銷沒做好？因為你一次改了太多變數，無法分離原因。 ### AI 加持做法 用 AI 幫你釐清假設、排優先順序、設計最精簡的功能集。把「我覺得用戶需要什麼」轉變成「我要驗證用戶是否需要 X」。 ## 「一個假設」框架 這是我自己用的框架，極其簡單： ### 第一步：列出你對這個產品的所有假設 打開你的 AI 助手： ``` 我正在做一個 [產品描述]，目標用戶是 [用戶描述]。 請幫我列出這個產品的所有核心假設，包括： 1. 需求假設（用戶真的有這個問題嗎？） 2. 解決方案假設（我的方案能解決這個問題嗎？） 3. 商業假設（用戶願意為此付費嗎？） 4. 行為假設（用戶會怎麼使用？多常使用？） 5. 成長假設（用戶會推薦給別人嗎？） 每個假設請標示「確定性」（高/中/低）和「影響性」（高/中/低）。 ``` ### 第二步：找出最高風險的假設 在 AI 的回覆中，找出「確定性低 + 影響性高」的那個假設。這就是你 MVP 要驗證的東西。 | | 影響性高 | 影響性低 | | ------------ | ------------------ | -------- | | **確定性低** | **MVP 要驗證這個** | 之後再說 | | **確定性高** | 已驗證，安心做 | 不重要 | ### 第三步：設計只驗證那一個假設的功能集 然後問 AI： ``` 我的 MVP 要驗證的核心假設是：[你的假設] 請幫我設計一個最精簡的功能集，只包含驗證這個假設所需的最少功能。 每個功能請標示： - 必要（沒有這個就無法驗證假設） - 有用（讓驗證更可靠，但不是必須） - 多餘（不影響假設驗證） 「多餘」的功能全部砍掉。「有用」的功能存起來，MVP 之後再做。 只保留「必要」的功能。 ``` 這就是你的 MVP 功能清單。通常只會有 3-5 個功能。是的，就這麼少。 ## AI 輔助的功能優先排序 如果你發現你的「必要」功能還是太多，或者你不確定哪個該先做，可以用兩個經典的排序方法。AI 特別擅長幫你跑這些框架。 ### 方法 1：RICE 評分 RICE 是 Intercom 發明的優先排序框架，四個維度都用數字評分： | 維度 | 說明 | 評分方式 | | ---------------------- | ------------------------ | -------------------------------- | | **R**each（觸及） | 這個功能會影響多少用戶？ | 預估人數 | | **I**mpact（影響） | 對單個用戶的影響有多大？ | 0.25 / 0.5 / 1 / 2 / 3 | | **C**onfidence（信心） | 你對以上估計有多少信心？ | 50% / 80% / 100% | | **E**ffort（工時） | 需要花多少人月？ | 對 Solo Builder 用「小時」更實際 | **RICE 分數 = (R × I × C) / E** 分數越高，優先順序越高。 用 AI 跑 RICE 的 prompt： ``` 以下是我的產品功能清單： 1. [功能 A] 2. [功能 B] 3. [功能 C] 4. [功能 D] 5. [功能 E] 產品描述：[簡短描述] 目標用戶：[描述] 我的時間預算：每週 8 小時 請幫每個功能做 RICE 評分，考量以下背景： - 這是一個人的 side project，不是公司產品 - 開發時間用「小時」而非「人月」 - Reach 用「前 100 個用戶中有多少人會用到」 最後按 RICE 分數排序，並給出你的建議。 ``` ### 方法 2：MoSCoW 分類 如果你覺得 RICE 太數字化，MoSCoW 更直覺： | 分類 | 含義 | MVP 處理方式 | | -------------------------- | ------------------ | ---------------- | | **M**ust have | 沒有就不能上線 | 一定做 | | **S**hould have | 很重要但可以後補 | MVP 後第一輪加上 | | **C**ould have | 有了更好，沒有也行 | 放到 backlog | | **W**on't have (this time) | 這次不做 | 直接刪掉 | 重點在那個 "Won't have"。**你的 Won't have 清單應該比 Must have 清單長至少三倍。** 如果你發現自己什麼都分到 Must have，那你還不夠狠。回去重新分類，問自己：「如果這個功能沒有，真的不能上線嗎？還是只是我覺得不完整？」 ## 功能砍殺清單 這是我的經驗法則。以下功能在 MVP 階段**幾乎都不需要**： | 功能 | 為什麼不需要 | 替代方案 | | --------------------- | -------------------------- | ------------------------------- | | 使用者註冊/登入 | 用 magic link 或第三方登入 | Clerk / Better Auth | | 管理後台 | 直接改資料庫 | 用 Drizzle Studio 或 D1 Console | | 通知系統 | 手動發 email | 先不做，或用 Resend | | 多語言 | MVP 只需要一種語言 | 只做你的目標市場語言 | | 深色模式 | 不影響核心價值驗證 | 上線後再加 | | 付費功能 | 先驗證需求，再談收錢 | 先全部免費 | | 數據分析 Dashboard | 你自己看 GA 就夠了 | Google Analytics | | 匯出/匯入 | MVP 階段資料量不大 | 手動處理 | | API | 除非你的產品就是 API | 先不對外開放 | | 完美的 Error Handling | 用戶量小，你手動處理 | console.log + 手動修 | 看到這個清單，你可能會覺得：「那 MVP 也太陽春了吧？」 沒錯。MVP **就是要很陽春**。它的目的不是讓用戶覺得產品好棒，而是讓你確認「有人願意用這個核心功能」。 ## 為一個人設計 User Story 在大公司，User Story 是寫給整個開發團隊看的。但 Solo Builder 的 User Story 是寫給自己和 AI 的。 格式可以更精簡： ``` 作為 [用戶類型] 我想要 [做某件事] 這樣我就能 [得到的好處] 驗收標準： - [ ] [具體可測試的條件 1] - [ ] [具體可測試的條件 2] 估計工時：X 小時 ``` 讓 AI 幫你把功能清單轉成 User Story： ``` 以下是我 MVP 的功能清單： 1. [功能 A] 2. [功能 B] 3. [功能 C] 目標用戶：[描述] 產品目的：[一句話] 請幫我把每個功能寫成 User Story，格式如下： - 作為 / 我想要 / 這樣我就能 - 驗收標準（2-3 條，具體可測試） - 估計工時（假設使用 AI 輔助開發，熟練的開發者） 注意：這是一個人的 side project，User Story 要精簡實用， 不需要企業級的詳細度。 ``` User Story 的好處是，它讓你清楚知道「做完」長什麼樣。沒有 User Story 的時候，一個功能可以無限延伸。有了驗收標準，你可以明確地說：「OK，這個功能做完了，下一個。」 ## 真實案例：cloud-on-academy 的 MVP 讓我用自己的真實案例來示範這套方法。 我想做 cloud-on-academy，一個 GCP 認證的中文課程平台。在第 2 章我已經驗證了市場存在。現在要設計 MVP。 **我的假設清單：** 1. 繁中市場的工程師願意為 GCP 認證課程付費（需求假設） 2. 文字 + 圖文教學的形式就夠用，不需要影片（解決方案假設） 3. 用戶會從頭到尾看完一個系列（行為假設） 4. 考過認證的用戶會推薦給同事（成長假設） **最高風險的假設：** 假設 2——文字教學就夠用嗎？這個最不確定。如果用戶一定要影片，我一個人做影片的時間成本會高很多。 **MVP 要驗證的就是這件事。** **砍功能的過程：** | 功能 | MoSCoW | 理由 | | ------------ | ----------- | -------------------------------- | | 課程文章展示 | Must have | 沒有內容就沒有產品 | | 章節導覽 | Must have | 用戶需要知道在哪裡 | | 閱讀進度追蹤 | Should have | 有用但不影響核心驗證 | | 用戶註冊 | Should have | 先不需要，開放閱讀 | | 付費牆 | Won't have | 先驗證需求，再談收錢 | | 討論區 | Won't have | 用 Discord 或 GitHub Issues 替代 | | 認證模擬題 | Won't have | 第二階段再加 | | 管理後台 | Won't have | 用 Git + Markdown 管理 | | 深色模式 | Could have | 不影響核心體驗 | | 搜尋功能 | Could have | 初期內容少，不需要搜尋 | **最終 MVP 功能：2 個 Must have。** 就這樣。一個能展示課程文章的網站，加上章節導覽。用 Astro 做靜態網站、Markdown 寫內容、部署到 Cloudflare Pages。 整個 MVP，兩個週末就完成了。 上線之後，我觀察到用戶確實會從頭到尾讀完一個系列，而且在 Discord 頻道上的回饋是「文字教學比影片更好搜尋、更好重看」。假設 2 驗證通過。 然後我才開始加其他功能。 ## 時間預算：2-3 個週末完成 MVP 上班族的時間預算很明確。假設每個週末能投入 8 小時，2-3 個週末就是 16-24 小時。 這是你的 MVP 開發時間上限。如果估出來超過 24 小時，代表你的功能還太多，回去繼續砍。 ### AI 加持的時間估算 ``` 以下是我 MVP 的 User Story（附工時估計）： [貼上前一步生成的 User Story] 我的開發環境： - 技術棧：[你的選擇] - AI 工具：Claude Code + Copilot - 開發經驗：[你的程度] - 每週可用時間：8 小時（週末） 請幫我： 1. 檢查工時估計是否合理（考慮 AI 輔助） 2. 安排到 2-3 個週末的開發計畫 3. 每個週末的目標和交付物 4. 如果超過 24 小時，建議砍掉哪些功能 ``` 一個典型的 2 週末計畫長這樣： | 週末 | 目標 | 產出 | 預估工時 | | --------------- | ----------------------- | ------------------ | -------- | | 週末 1（Day 1） | 專案初始化 + 核心功能 A | 可以跑的 prototype | 8 小時 | | 週末 1（Day 2） | 核心功能 B + 基本 UI | 可以用的 MVP | 8 小時 | | 週末 2（Day 1） | 部署 + 修 bug | 上線的產品 | 6 小時 | | 週末 2（Day 2） | 寫 Landing Page + 分享 | 第一批用戶 | 2 小時 | 注意最後一天只留 2 小時——因為你需要預留 buffer。開發永遠比預期慢，但 deadline 不會等你。 ### 如果超時怎麼辦？ 如果週末 1 結束時進度落後了，不要加班趕工。停下來問自己： 1. 是哪個功能花的時間比預期多？ 2. 那個功能可以簡化嗎？ 3. 有沒有哪個「必要」功能其實可以降級為「有用」？ 然後繼續砍。永遠是砍功能，不是加時間。 ## 常見的 MVP 設計陷阱 ### 陷阱 1：「這個功能很簡單，加一下不會怎樣」 每個功能都很簡單。但十個簡單的功能加在一起就不簡單了。 每次你想加功能的時候，問自己：**「如果這個功能不做，用戶是完全不能用這個產品，還是只是不太方便？」** 如果答案是「不太方便」，那就不做。 ### 陷阱 2：把 MVP 做成 Demo MVP 是要給真實用戶用的，不是 demo。Demo 可以用假資料、hardcode 的流程。MVP 不行——它必須能讓用戶完成一個完整的使用流程，即使這個流程很簡陋。 ### 陷阱 3：「等我加完這個就上線」 這句話你已經說了三次了。 設一個死線。不是「功能做完的時候上線」，而是「這個日期不管如何一定上線」。到了那天，不管功能完成度如何，push to production。 如果你的 MVP 設計得夠精簡，你會發現：即使有些功能只完成 80%，產品依然能用。而那 20% 的差距，你可以在上線後根據用戶回饋來補。 ### 陷阱 4：不好意思讓別人看到不完美的產品 Reid Hoffman（LinkedIn 創辦人）說過一句經典的話： > If you're not embarrassed by the first version of your product, you've launched too late. > 如果你的第一版產品沒有讓你覺得丟臉，那你上線得太晚了。 你的 MVP 應該讓你有點不好意思。那代表你沒有過度打磨，把時間花在了正確的地方——驗證假設。 ## 本章重點回顧 - 🎯 MVP 不是爛版本，而是「用最少功能驗證最關鍵假設」 - 🔪 用「一個假設」框架：列出假設 → 找最高風險的 → 只為那一個設計功能 - 📊 RICE 評分和 MoSCoW 分類，配合 AI 可以在 30 分鐘內完成功能排序 - 📋 你的 Won't have 清單應該比 Must have 長三倍 - ⏱️ MVP 開發時間上限：2-3 個週末（16-24 小時），超過就砍功能 - 🚀 設定死線，不管如何到日期就上線 ## 下一步 功能砍好了，MVP 設計好了。 下一章，我們進入這本書最核心的部分：**怎麼用 AI 來開發。** 不是那種「叫 AI 幫你寫一段 code」的用法——而是建造一整套 AI 開發系統，讓 AI 成為你的開發團隊。從 Vibe Coding 到 Agentic Workflow，一個人也能有三人團隊的產出。 👉 [第 5 章：AI 驅動開發——從 Vibe Coding 到 Agentic Workflow](/blog/ai-solo-builder-ai-driven-dev)Solo BuilderMVP產品設計AIFeature Prioritizationhttps://bobochen.dev/blog/ai-solo-builder-tech-stack/https://bobochen.dev/blog/ai-solo-builder-tech-stack/一個人做產品，技術選型的標準跟團隊完全不同。不是選「最好」的技術，而是選「一個人最能掌控」的技術。這篇建立一套決策框架，幫你在 AI 輔助下快速做出正確選擇。Sun, 22 Feb 2026 00:00:00 GMT## 技術選型的致命誤區 「用什麼框架好？」 這是工程師最喜歡討論的話題。也是 Solo Builder 最容易浪費時間的地方。 我看過太多 side project 死在技術選型階段。不是因為選錯了，而是因為**花太久在選**。花一堆時間比較 Next.js vs Nuxt vs SvelteKit vs Astro，看了一堆 benchmark，翻了一串 Reddit 討論，最後選了一個——然後沒過多久又開始懷疑。 這裡有一個殘酷的事實：**對 Solo Builder 來說，技術選型的重要性被嚴重高估了。** 為什麼？因為你只有一個人。你不需要考慮： - 「新人能不能快速上手」（沒有新人） - 「團隊內有誰熟悉這個技術」（團隊只有你） - 「微服務之間的通訊協定」（你大概不需要微服務） - 「未來 scale 到百人團隊時的維護性」（如果真到那天，你已經有資源重寫了） Solo Builder 的技術選型，只需要問一個核心問題：**用這個技術，我一個人能多快把東西做出來？** ## Solo Builder 的技術選型五原則 在比較任何具體技術之前，先記住這五個原則。它們比任何 benchmark 都重要。 ### 原則 1：一種語言打天下 每多用一種語言，你的上下文切換成本就翻倍。 在團隊裡，前端一組人用 TypeScript，後端一組人用 Go，資料管線一組人用 Python，這沒問題——每組人專注自己的語言。 但你只有一個人。如果你的前端是 TypeScript、後端是 Python、部署腳本是 Bash、資料處理是 SQL stored procedure，你每天都在四種語言之間跳來跳去。光是記住四種語言的語法差異就夠累了。 **建議：選一種語言，覆蓋盡可能多的領域。** 2026 年，TypeScript 是 Solo Builder 最全能的選擇： - 前端（React、Vue、Svelte、Astro） - 後端（Node.js、Bun、Deno、Hono） - API（tRPC、Hono RPC） - CLI 工具（Commander、tsx） - 腳本（取代 Bash 做自動化） - AI 整合（Anthropic SDK、OpenAI SDK） - Infrastructure as Code（Pulumi、SST） 一種語言，從前端到 IaC 全部搞定。AI 也最擅長 TypeScript——訓練資料最多、生成品質最好、社群資源最豐富。 ### 原則 2：選生態系，不選框架 框架會過時，生態系會持續演進。 與其糾結「Next.js 還是 React Router（前 Remix）」，不如先決定你要進入哪個生態系。例如： - **Cloudflare 生態系**：Workers + Pages + D1 + R2 + KV，全部免費額度充足 - **Vercel 生態系**：Next.js + Vercel Hosting + Edge Functions - **AWS 生態系**：Lambda + DynamoDB + S3 + CloudFront 一旦選定生態系，框架的選擇就自然縮窄了。而且生態系內的工具整合度最高——你不會花時間在「讓 A 服務跟 B 服務溝通」上面。 ### 原則 3：免費額度是你的跑道 Solo Builder 的前幾個產品，理想情況下**零成本營運**。 不是因為付不起——而是因為在你驗證 product-market fit 之前，每一分錢的營運成本都是風險。如果產品沒人用，你可以隨時關掉，不會有任何沈沒成本。 | 服務 | 免費額度 | 足夠支撐 | | ------------------ | ------------------ | ----------------- | | Cloudflare Workers | 10 萬次 request/天 | 小型 SaaS 前期 | | Cloudflare D1 | 5 GB 儲存 | 中型應用的資料庫 | | Cloudflare R2 | 10 GB 儲存 | 檔案上傳功能 | | Vercel | 100 GB 頻寬/月 | 個人網站或文件站 | | Supabase | 500 MB 資料庫 | 認證 + 資料庫 | | Turso | 5 GB 儲存 | SQLite 邊緣資料庫 | > **注意：** Vercel 的 Hobby（免費）方案依官方條款僅限個人、非商業用途。任何會產生營收的 SaaS、電商或接案產品都必須升級到 Pro（$20/月）。如果你的目標是零成本營運商業產品，部署層建議以 Cloudflare 為主——其免費額度允許商業用途。 **選技術的時候，把免費額度當成核心考量。** 一個每月要花 $50 維護的 side project，你心裡會一直有壓力。一個零成本的 side project，你可以放心地慢慢迭代。 ### 原則 4：AI 友善度 2026 年，這個原則的重要性已經超過了傳統的「社群大小」或「文件品質」。 **AI 友善度**指的是：AI 工具（Claude Code、Copilot、Cursor）在這個技術上的表現如何？ AI 友善度高的技術： - TypeScript（訓練資料量最大） - React（最多範例程式碼） - Tailwind CSS（語義清晰、AI 生成品質高） - Prisma / Drizzle（Schema-first，AI 很擅長） - Hono（類似 Express 的直覺 API，AI 理解度高） AI 友善度低的技術： - 太新的框架（訓練資料不足） - 自創的 DSL 或 convention 太獨特的框架 - 需要大量隱式設定的工具（AI 容易遺漏） **選 AI 擅長的技術，你的開發速度會快 3-5 倍。** 選 AI 不熟的技術，你反而要花時間修正 AI 生成的錯誤程式碼。 ### 原則 5：可逆性優先 如果你不確定，選一個容易換掉的。 有些技術選擇是單向門——一旦選了就很難回頭。例如：資料庫、認證系統、核心框架。 有些是雙向門——隨時可以換。例如：CSS 方案、HTTP client、測試框架。 **對單向門的選擇要謹慎，對雙向門的選擇不要糾結。** | 決策類型 | 例子 | 可逆性 | 建議 | | -------- | ----------------------- | ------- | ------------------ | | 程式語言 | TypeScript vs Go | ❌ 極低 | 花 30 分鐘認真選 | | 資料庫 | PostgreSQL vs SQLite | ❌ 低 | 考慮清楚再決定 | | 框架 | Astro vs Next.js | 🔶 中 | 花 15 分鐘比較 | | CSS 方案 | Tailwind vs CSS Modules | ✅ 高 | 隨便選，不喜歡再換 | | 測試框架 | Vitest vs Jest | ✅ 高 | 用預設就好 | | 部署平台 | Cloudflare vs Vercel | 🔶 中 | 跟著生態系走 | ## AI 輔助技術選型實戰 有了五個原則之後，具體怎麼用 AI 來加速選型？ ### 步驟 1：描述你的產品需求 ```text 我要做一個 [產品描述]。 需求： - 核心功能：[列出 3-5 個最重要的功能] - 預期用戶量：[前期預估] - 互動性：[靜態為主 / 高度互動 / 即時通訊] - 資料庫需求：[簡單 CRUD / 複雜查詢 / 即時同步] - 預算：零（用免費額度） - 開發者人數：1 人 - 我熟悉的技術：[列出你已經會的] - 時間限制：每週 5-10 小時 請推薦一個技術棧，以及為什麼這樣選。 要考慮 AI 輔助開發的友善度。 ``` ### 步驟 2：讓 AI 比較兩個候選方案 如果 AI 推薦了 A 方案但你心裡傾向 B 方案，不要糾結——直接讓 AI 比較： ```text 方案 A：[AI 推薦的技術棧] 方案 B：[你傾向的技術棧] 請從以下維度比較，以我的情況（一人開發、每週 5-10 小時、零預算）來評估： 1. 開發速度：從零到 MVP 需要多久？ 2. AI 輔助友善度：Claude Code / Copilot 對哪個表現更好？ 3. 免費額度：前期營運成本比較 4. 學習成本：如果我不熟悉，要多久才能上手？ 5. 社群支援：遇到問題時能多快找到答案？ 6. 可維護性：三個月不碰之後，回來能多快恢復？ 最後給一個明確建議。 ``` ### 步驟 3：30 分鐘做決定 看完 AI 的分析之後，**在 30 分鐘內做出決定**。 是的，30 分鐘。 不完美的選擇 + 馬上開始動手 > 完美的選擇 + 多想兩週。 選了之後，就不要回頭看。把精力放在做產品上，不是放在懷疑技術選型上。 ## 我的 Solo Builder 技術棧推薦 把前面五個原則套到實際選型上，這是我自己會用的 2026 年 Solo Builder 技術棧（實際應用案例見[第 13 章：實戰案例](/blog/ai-solo-builder-case-studies/)）： ### 推薦組合 A：靜態為主的產品 **適合：** 部落格、文件站、[Landing Page](/blog/ai-solo-builder-landing-page-seo/)、行銷網站、課程平台 | 層級 | 技術 | 原因 | | ---- | ---------------- | ------------------------------------------- | | 框架 | Astro | 靜態優先、island architecture、生態系豐富 | | 樣式 | Tailwind CSS | AI 生成品質最高、utility-first 適合快速開發 | | 部署 | [Cloudflare Pages](/blog/ai-solo-builder-deployment/) | 免費、全球 CDN、build 速度快 | | CMS | Markdown + Git | 零成本、版本控制、AI 可直接生成 | | 搜尋 | Pagefind | 靜態站搜尋、零後端 | ### 推薦組合 B：互動式 Web App **適合：** SaaS 產品、Dashboard、管理後台、CRUD 應用 | 層級 | 技術 | 原因 | | ------ | -------------------------- | ---------------------------------- | | 框架 | Astro + React（island） | 靜態頁面用 Astro、互動區塊用 React | | 後端 | Hono on Workers | 輕量、TypeScript、Cloudflare 原生 | | 資料庫 | D1 (SQLite) 或 Turso | 免費額度大、SQLite 簡單好管理 | | ORM | Drizzle | Schema-first、TypeScript、AI 友善 | | 認證 | Better Auth | 輕量、不綁定廠商、活躍維護中 | | 部署 | Cloudflare Workers + Pages | 全棧免費 | ### 推薦組合 C：有即時需求的應用 **適合：** 即時通訊、協作工具、多人遊戲 | 層級 | 技術 | 原因 | | -------- | ----------------------------------------------- | ---------------------------- | | 框架 | Next.js 或 SvelteKit | SSR + 即時需求支援好 | | 即時通訊 | Cloudflare Durable Objects 或 Supabase Realtime | WebSocket / 長連線 | | 資料庫 | Supabase (PostgreSQL) | 即時訂閱、Row Level Security | | 部署 | Vercel 或 Cloudflare | 看框架選平台 | ### 你不需要的東西 最後，列出 Solo Builder **不需要**的技術，省得你花時間研究： - ❌ **Kubernetes** — 一個人不需要容器編排，用 serverless - ❌ **Terraform / Pulumi** — 你的基礎設施沒有複雜到需要 IaC - ❌ **微服務架構** — 一個 monolith 就夠了 - ❌ **GraphQL** — REST API 加上 TypeScript 的型別安全就夠了 - ❌ **Redis** — Cloudflare KV 或 D1 就夠用了 - ❌ **自建認證系統** — 用現成的 auth 套件，不要自己做 - ❌ **多語言 monorepo** — 用 TypeScript，一種語言搞定 每一個「不選」的決定，都是省下來的時間。 ## 本章重點回顧 - 🎯 Solo Builder 的技術選型核心問題只有一個：用這個技術，我一個人能多快做出來？ - 🔤 一種語言打天下，TypeScript 是 2026 年最全能的選擇 - 🌐 選生態系不選框架，整合度決定開發速度 - 💰 免費額度是跑道，零成本營運讓你放心迭代 - 🤖 AI 友善度比社群大小更重要 - 🚪 可逆性高的選擇不要糾結，可逆性低的花 30 分鐘認真想 - ⏱️ 技術選型不要超過一天，不完美的選擇 + 馬上動手 > 完美的選擇 + 多想兩週 ## 下一步 技術棧決定了？ 下一章，我們來設計你的 MVP。Solo Builder 最大的敵人是「功能蔓延」——什麼都想做，結果什麼都做不完。我會教你一套方法，把產品砍到只剩最核心的部分，然後用最少時間做出來。 👉 [第 4 章：MVP 設計——砍到不能再砍](/blog/ai-solo-builder-mvp-design)Solo Builder技術選型TypeScriptAstroCloudflarehttps://bobochen.dev/blog/ai-solo-builder-idea-validation/https://bobochen.dev/blog/ai-solo-builder-idea-validation/點子驗證是 side project 不浪費時間的第一步。學會用 AI 在一天內完成市場調查、競品分析與用戶訪談模擬，快速確認你的點子值不值得投入寶貴的下班時間，避免花兩個月做出沒人要的東西。Sun, 15 Feb 2026 00:00:00 GMT## Side Project 最常見的死法：跳過點子驗證 你有一個很棒的點子。 你興奮地打開編輯器，選了框架、建了 repo、開始寫第一個功能。三個週末過去了，prototype 有了雛形。再花兩個週末做 UI、處理 edge case、加上登入功能。 兩個月後，你終於覺得可以給朋友看了。 結果朋友說：「喔，這個啊……其實已經有一個 app 在做了，而且免費。」 或者更慘的版本：你把連結丟到社群裡，得到三個愛心、零留言、零下載。 兩個月的下班時間，就這樣蒸發了。 這不是你的技術有問題。這是你跳過了最重要的一步：**驗證這個點子值不值得做。** 好消息是，2026 年你不需要花一個月做市場調查。你需要的只是一個下午和 AI。 ## 點子驗證的三個必答問題 在你寫任何一行程式碼之前，你需要回答三個問題： 1. **有人有這個問題嗎？**（市場存在性） 2. **他們現在怎麼解決？**（競品分析） 3. **為什麼你的方案會更好？**（差異化優勢） 如果三個問題的答案都很正向，這個點子值得花時間。如果有任何一個答案是「不確定」或「其實沒有」，你剛剛省下了兩個月的時間。 讓我一個一個帶你用 AI 來回答。 ## 第一步：確認問題存在（1 小時） 最危險的假設是：「因為我有這個問題，所以其他人也有。」 有時候確實是這樣。但有時候你的問題太小眾、太特殊、或者只有你自己覺得是問題。 ### 傳統做法 - 在 Google 搜相關關鍵字，看有沒有人在討論 - 逛 PTT、Dcard、Reddit 找相關抱怨文 - 在社群發問「大家有沒有遇過 XXX 的困擾」 - 做問卷（然後花一週等回收） → 至少花 3-5 天，而且覆蓋面有限。 ### AI 加持做法 打開你的 AI 助手，用一組結構化的 prompt 來做快速市場掃描： ```text 我想做一個 [簡短描述你的產品點子]。 請幫我分析： 1. 這個問題的普遍性 - 誰會遇到這個問題？估計影響人數？ - 在哪些場景下會遇到？ - 這是偶爾遇到還是經常遇到？ 2. 現有的討論和需求信號 - 搜尋相關關鍵字，這類問題在技術社群（Stack Overflow、Reddit、 GitHub Issues）的討論熱度如何？ - 有沒有相關的 Feature Request 或 Upvote？ - 繁中市場（PTT、Dcard、iThome）有沒有類似討論？ 3. 付費意願信號 - 有沒有人願意為解決這個問題付費？ - 類似的解決方案目前的定價範圍？ - 企業用戶還是個人用戶更可能付費？ 請用繁體中文回答，並附上你的判斷依據。 ``` AI 不會給你 100% 正確的答案——但它會在 15 分鐘內給你一個 **方向性的判斷**。 更重要的是，它會幫你想到你自己沒想到的角度。「你以為是 A 族群的問題，但其實 B 族群更有需求」——這種洞察靠自己想很難想到，但 AI 的廣泛知識可以幫你觸及。 ### 進階技巧：用 AI 模擬用戶訪談 這是我最喜歡的驗證方法。請 AI 扮演你的目標用戶： ```text 請你扮演一個 [目標用戶描述]。 你平常的工作內容是 [描述]。你對技術的熟悉程度是 [描述]。 我正在做一個 [你的產品]，它可以 [核心功能]。 請以你扮演的角色，真實地回答以下問題： 1. 你覺得這個產品對你有用嗎？為什麼？ 2. 你現在怎麼解決這個問題？ 3. 如果有這個產品，你願意每月付多少錢？ 4. 你最大的擔心或疑慮是什麼？ 5. 你覺得這個產品少了什麼功能你就不會用？ 請不要客氣，給我最真實的反應。 ``` 然後換不同的角色描述，模擬 3-5 種不同的目標用戶。 是的，這不如真人訪談精確。但它有兩個巨大的優勢：**快**（30 分鐘做完 5 種用戶類型的訪談），而且**沒有社交壓力偏差**（真人訪談中，對方可能因為禮貌而不好意思說「我不需要」）。 AI 模擬訪談適合用來「快速淘汰明顯沒市場的點子」，而不是用來「精確預測市場規模」。這對 Solo Builder 來說已經非常夠用了。產品上線後若想建立真實的回饋機制，可參考[第 9 章：用戶回饋循環](/blog/ai-solo-builder-user-feedback)。 ## 第二步：競品分析（1 小時） 如果第一步確認問題存在，接下來要問：**別人怎麼解決這個問題？** 有競品不是壞事。有競品代表有市場。沒競品可能代表沒人要。 關鍵是你要找到**差異化的空間**。 ### AI 加持的競品分析 ```text 我想做一個 [你的產品]，主要解決 [問題描述]。 請幫我做競品分析： 1. 直接競品（功能幾乎一樣的產品） - 列出前 5 個，附上名稱、網址、定價 - 各自的優缺點 - 在 Product Hunt / G2 / Capterra 上的評價 2. 間接競品（用不同方式解決同一個問題） - 例如：用 Excel 手動處理、用通用工具替代 - 這些替代方案的痛點是什麼？ 3. 市場空白 - 現有競品的共同弱點是什麼？ - 哪些用戶需求沒有被滿足？ - 有沒有特定地區（例如台灣繁中市場）的空白？ 4. 差異化機會 - 基於以上分析，如果要做這個產品， 最有潛力的差異化方向是什麼？ ``` 拿到結果之後，你可以進一步深入。挑出最強的 2-3 個競品，請 AI 幫你做更細的分析： ```text 請深入分析 [競品名稱]： 1. 它的技術架構可能是什麼？ 2. 它的商業模式（免費增值？訂閱制？一次買斷？） 3. 它的用戶評論中，最常見的抱怨是什麼？ 4. 它最近半年有什麼重大更新或方向調整？ 5. 它的弱點在哪裡，我可以切入的角度？ ``` ### 競品矩陣：一張圖看清全局 分析完之後，把結果整理成一張表： | 競品 | 免費方案 | 核心功能 | 最大弱點 | 定價 | | ------------ | -------- | ------------ | ---------- | --------- | | 競品 A | ✅ 有 | 功能 1, 2, 3 | 不支援中文 | $10/月 | | 競品 B | ❌ 無 | 功能 1, 2 | 介面複雜 | $29/月 | | 競品 C | ✅ 有 | 功能 1 | 功能太少 | 免費 | | **你的產品** | ✅ 有 | 功能 1, 2, 4 | **待驗證** | **$X/月** | 這張表的目的很簡單：**你的產品必須在至少一個維度上明顯優於所有競品。** 如果你找不到這個維度，要嘛重新定義你的差異化，要嘛放棄這個點子。 放棄不是失敗。放棄一個沒有差異化空間的點子，是做出了一個好的商業決策。 ## 第三步：快速原型驗證（2 小時） 前兩步是「動腦」驗證。第三步是「動手」驗證——但不是寫程式碼。 ### 做一個 Landing Page，不做產品 你沒看錯。 在你寫任何程式碼之前，先做一個 Landing Page。上面寫清楚： - 你的產品解決什麼問題 - 它怎麼運作（可以用示意圖） - 定價方案 - 一個 **等候名單** 或 **預先註冊** 的表單 然後把這個 Landing Page 的連結分享到相關社群。 如果有人填了表單——恭喜，你有了第一批潛在用戶。 如果沒人理——你剛剛省了兩個月的開發時間。（驗證階段只需簡單頁面即可；正式的 SEO 優化與轉換率調整，留到[第 7 章：Landing Page 與 SEO](/blog/ai-solo-builder-landing-page-seo)再處理。） ### AI 加持做 Landing Page 2026 年，做一個 Landing Page 不需要兩天。用 AI 可以在 2 小時內搞定： 1. **文案**（30 分鐘）：用 AI 生成 headline、sub-headline、feature list、FAQ、CTA 按鈕文字 2. **設計**（30 分鐘）：用 v0 生成 React 元件，或用 Claude 直接生成 Astro/React 頁面，或用 Framer 拖拉 3. **部署**（30 分鐘）：推到 Cloudflare Pages 或 Vercel，免費 4. **表單**（30 分鐘）：Google Forms 或 Tally，免費 文案生成的 prompt： ```text 我正在做一個 [產品名稱]，它幫助 [目標用戶] 解決 [問題]。 請幫我撰寫一個 Landing Page 的文案，包含： 1. Headline：一句話說清楚產品價值（15 字以內） 2. Sub-headline：補充說明（30 字以內） 3. 3 個核心功能區塊： - 每個有一個標題（8 字以內）和一段說明（50 字以內） 4. 「為什麼選我們」：3 個差異化賣點 5. 定價方案（免費 + 付費兩檔） 6. FAQ：5 個常見問題 7. CTA 按鈕文字 語氣：專業但不冰冷，口語化但不隨便。繁體中文。 ``` ## 一天驗證流程：時間表 把以上三步串起來，你的一天驗證流程長這樣： | 時間 | 步驟 | 產出 | | ------------- | --------------------- | ------------------------------ | | 09:00 - 10:00 | 問題存在性分析 | 市場掃描報告 + AI 模擬訪談 | | 10:00 - 11:00 | 競品分析 | 競品矩陣 + 差異化定位 | | 11:00 - 12:00 | 休息 + 消化 | 決定「做 / 不做 / 調整方向」 | | 13:00 - 15:00 | Landing Page 製作 | 上線的 Landing Page + 等候名單 | | 15:00 - 16:00 | 分享到 3-5 個相關社群 | 觀察反應 | 一天。6 個小時。 如果結論是「不做」，你省下了兩個月的下班時間。 如果結論是「做」，你已經有了市場調查報告、競品分析、差異化定位、Landing Page、和第一批潛在用戶名單。 大多數 side project 連這些都沒有就開始寫程式碼了。你已經贏在起跑點。 ## 驗證的常見陷阱 ### 陷阱 1：確認偏差 你太想做這個東西了，所以會不自覺地只看正面信號、忽略負面信號。 **對策**：在做驗證之前，先寫下「如果以下三件事中有任何一件成立，我就放棄」的 kill criteria。例如： - 已有 3 個以上免費競品且評價 4.5+ - AI 模擬訪談中，5 種用戶有 3 種以上表示不需要 - Landing Page 一週內零人填表 ### 陷阱 2：過度驗證 另一個極端：一直在做調查、一直不開始動手。 驗證的目的不是消除所有風險，而是**把最大的風險降到可接受的程度**。如果你的三個必答問題都有還不錯的答案，就可以進入下一步了。 上班族的時間很寶貴，花太久驗證也是一種浪費。 ### 陷阱 3：把 AI 的回答當聖旨 AI 的市場分析是基於它的訓練資料，不是即時數據。它可能不知道上個月剛冒出來的新競品，也可能高估或低估特定市場的規模。 AI 的回答是**參考**，不是**結論**。用 AI 來加速你的思考，但最終判斷是你的。 ## 真實案例：我怎麼驗證「登雲學院」 讓我用自己的真實案例來示範。 我想做一個 GCP 認證的中文線上課程平台（cloud-on-academy）。在開始寫任何程式碼之前，我做了這些驗證： **問題存在性：** 在 PTT 和技術社群搜尋「GCP 認證」，發現大量「有沒有中文資源推薦」的問題。確認需求存在。 **競品分析：** 發現中文市場的 GCP 認證課程極少。Coursera 和 Udemy 有英文課程，但繁中市場幾乎是空白。AWS 認證的中文資源比 GCP 多很多。 **差異化：** 繁中市場第一個系統化的 GCP 認證課程，用台灣工程師的實戰經驗切入，不是翻譯。 **Landing Page：** 做了一個簡單的頁面，放上課程大綱和等候名單表單。 **結果：** 一週內收到足夠的表單填寫，確認值得繼續做。 整個驗證流程，我花了一個週末。 如果 2026 年用 AI 來做同樣的事，可能半天就夠了。 ## 本章重點回顧 - 🎯 寫程式碼之前，先回答三個問題：問題存不存在？別人怎麼解決？你有什麼差異化？ - 🤖 用 AI 加速：市場掃描、用戶訪談模擬、競品分析，傳統一個月的工作壓縮到一天 - 📄 做 Landing Page 比做 prototype 更重要——先確認有人要，再開始做 - ⚠️ 小心確認偏差，設定 kill criteria，AI 的回答是參考不是結論 - ⏱️ 上班族的時間珍貴，驗證的目的是「快速淘汰壞點子」，不是「消除所有風險」 ## 下一步 點子驗證通過了？ 下一章，我們來面對 Solo Builder 最容易糾結的問題：**技術選型**。 一個人做產品，技術棧的選擇標準跟團隊完全不同。不是選「最流行」的技術，而是選「一個人最能掌控、AI 最能幫忙」的技術。 👉 [第 3 章：技術選型決策框架](/blog/ai-solo-builder-tech-stack)Solo BuilderAI市場調查MVP點子驗證https://bobochen.dev/blog/ai-solo-builder-manifesto/https://bobochen.dev/blog/ai-solo-builder-manifesto/2026 年是 Solo Builder 的黃金時代——AI 徹底改變了一個人能做到的事。這篇文章告訴你為什麼現在是邊上班邊做產品的最好時機，一個有正職的上班族如何靠 AI 加持，把備忘錄裡永遠做不完的 side project 真正做出來、推上線。系列首章，帶你建立 Solo Builder 的心法與全貌。Sun, 08 Feb 2026 00:00:00 GMT## 那些永遠做不完的 Side Project：為什麼 Solo Builder 卡在這裡 你的手機備忘錄裡，有幾個 side project 的點子？ 如果你跟我一樣，答案大概是「太多了」。 一個課程平台的構想。一個自動化工具的 prototype。一個部落格的改版計畫。一個「如果我有時間一定要做」的 SaaS 夢想。 它們有一個共同的結局：永遠停留在備忘錄裡。 不是因為你能力不夠。你明明會寫程式、會部署、會設計資料庫。技術上你什麼都做得到。 問題在別的地方。 下班回到家已經晚上八點。吃完飯、陪家人、洗完澡，坐到電腦前已經十點。打開 VS Code，光是想到「等一下還要處理部署、寫文案、研究金流串接……」，就已經累了。 然後你告訴自己：「週末再說吧。」 週末來了，你花了兩小時研究技術選型，三小時 debug 一個莫名其妙的環境問題，最後只推進了一點點。到了星期天晚上，打開 TODO list，發現進度幾乎沒動。 這個循環重複幾次之後，備忘錄裡的點子就安靜地躺在那裡了。 如果你有這種經驗，你不孤單。這是每個有正職的工程師想做 side project 時都會遇到的牆。 但 2026 年，這堵牆出現了一道裂縫。 ## AI 改變的不是「能不能做」，而是「一個人要花多少時間」 我先講結論：**AI 沒有降低做產品的門檻——門檻本來就不高。AI 改變的是時間成本。** 不過這句話我得補一個但書，不然會誤導人。「門檻本來就不高」是對「我本來就會、只是沒時間」的人說的。如果你是想了解產品長什麼樣的 PM、轉職中的設計師、或還在打地基的資淺工程師，門檻對你是真的存在，AI 不會幫你跳過它。 更要小心的是：AI 對你「本來就懂」的領域是加速器，對你「不懂」的領域是放大鏡——它讓你更快做出一個你根本沒能力判斷對錯的東西。我會寫程式，所以 AI 寫的 code 我看得出哪裡怪、哪裡要擋。但金流合規、資料隱私、安全性這些我不夠熟的地方，AI 給我一段看起來很專業的方案，我其實沒辦法真的 review 它對不對。那不是省時間，那是把風險藏起來，等上線才爆。所以遇到自己不懂的領域，我寧可慢一點、找真人問，也不會讓 AI 幫我「快速搞定」。 以前一個人做產品，瓶頸不是技術能力，而是時間。你只有一個人，但產品需要：前端、後端、部署、CI/CD、Landing Page、SEO、文案、客服、金流串接、監控告警…… 每一項你都「會」，但每一項都要花時間。一個有正職的人，每週能擠出的時間可能只有 5 到 10 小時。這些時間分配到十幾個面向，每個面向一週只能推進 30 分鐘。 難怪做不完。 但 AI 改變了這個等式。 不是那種「AI 幫你寫一段 code」的改變——那只是省了一點打字時間。我說的是根本性的改變： 市場調查以前要看報告、爬論壇、做問卷，現在 AI 幫忙彙整競品分析、市場規模、目標用戶畫像，快很多。技術選型以前要一個一個框架比，現在 AI 照需求列出 pros/cons、附上案例，省掉不少查資料的時間。寫程式碼以前一個功能要磨好一陣子，現在用 Claude Code 的 agentic workflow 一個晚上就能把骨架先搭出來。 部署設定以前要查文件、踩坑、debug，現在 AI 直接幫你生成 CI/CD pipeline，省掉很多重複設定。Landing Page 的文案 AI 也能先生一版初稿，你微調語氣就好。文件這種最討厭的苦差事，現在 AI 根據程式碼就能生出 API 文件和使用說明。 把這些加起來，以前一個人要花好幾個月做的東西，現在快得多就能上線。 但這串「一個下午、一個晚上」是我挑順的時候講的，不是常態。AI 加速有上限，而且有隱藏成本：整理 prompt 和 context 要時間，AI 幻覺出來的東西要 debug（碰到它一直鬼打牆時，比我自己寫還久），來回 review 修正也要時間。遇到新框架、冷門 bug、或需要很多脈絡才能下的決策，AI 反而可能拖慢你。我自己就有過一次，叫 AI 幫忙接一個比較新的 SDK，它很有自信地用了一個其實已經被 deprecate 的 API，我照著走，卡了大半天才發現是它記錯版本——那天不如我自己翻官方文件還快。 至於上面提到的 self-healing deploy、multi-agent 那種「我睡覺它還在工作」，聽起來很浪漫，但你得幫它架好護欄。沒有人盯著，它一樣會把「錯的修法」很有效率地 deploy 上去，或在 retry 迴圈裡默默把你的雲端帳單燒高。我現在的做法是讓它自動處理可逆、低風險的事，碰到資料庫、金流、production 設定一律停下來等我點頭。 **這不是「AI 取代工程師」的故事。這是「AI 讓一個人可以同時扮演好幾個角色」的故事。** ## 2024 vs. 2026：從「AI 能幫忙」到「AI 是隊友」 你可能會說：「AI 輔助開發 2024 年就有了，有什麼新鮮的？」 差很多。 2024 年的 AI 輔助開發，像是有一個很聰明的實習生。你問他問題，他回答你。你請他寫一段 code，他寫出來，你 review 完再貼進去。每個動作都需要你主動發起、手動整合。 2026 年的 AI，更像是一個有經驗的同事。 以我自己在用的 Claude Code 為例： - 我可以建立 **custom skills**——教 AI 記住我的開發偏好、專案架構、測試慣例。下次它就直接照我的標準做事，不用每次重新解釋。 - 我可以設定 **MCP server**——讓 AI 直接跟我的 Notion、Jira、GitHub 對話。不用複製貼上，AI 自己去讀 issue、更新狀態。 - 我可以跑 **multi-agent workflow**——一個 agent 跑測試、一個 agent 做 code review、一個 agent 更新文件，三件事同時進行。 - 我可以設定 **self-healing deploy**——部署失敗時，AI 自動分析錯誤、修復問題、重新部署。我睡覺的時候，它還在工作。 這不再是「AI 能幫忙」的層級。**這是 AI 成為你團隊成員的層級。** 而且這才剛開始。 ## 上班族做產品的隱藏優勢 很多人覺得，有正職是做 side project 的劣勢——時間少、精力有限、不能全心投入。 我曾經也這麼想。 但做了幾個產品之後，我發現**有正職反而是一種優勢**，只要你換個角度看。 ### 優勢 1：正職是你的免費 R&D 實驗室 你在公司遇到的問題，往往就是最好的產品點子。 我在工作中用 GCP Cloud Run 部署服務，踩了一堆坑。這些坑變成了我部落格的文章，部落格的流量證明了這個主題有需求，然後變成了線上課程的構想。 你不需要額外花時間「做市場調查」——你的日常工作就是市場調查。 ### 優勢 2：正職收入是你最好的 runway 矽谷創業故事總是強調「辭職 all-in」，但那是倖存者偏差。 有正職收入，你不需要靠產品養活自己。這代表你可以： - 不急著變現，先做出真正好的東西 - 不為了營收妥協產品方向 - 失敗了也不會影響家人生活 你的正職薪水就是最好的創業基金。 ### 優勢 3：時間限制逼你做出更好的決策 Parkinson's Law：工作會膨脹到填滿你給它的時間。 全職做產品的人，容易掉進「這個功能也要、那個也想做」的陷阱。但你只有每週 5-10 小時，你**必須**做出取捨。這種限制反而逼你專注在真正重要的事情上。 **時間少，不是劣勢。時間少 + AI，是最強的組合。** 因為 AI 幫你處理那些「必要但耗時」的工作（部署設定、文案撰寫、測試生成），你就能把有限的時間和精力集中在只有你能做的事——產品決策、用戶理解、品味判斷。 ## 我的證據：邊上班邊做的四個產品 我不是在空談理論。這本書的每一個建議，都來自我自己邊上班邊做產品的真實經驗。 過去幾年，我在有全職工作的情況下，做出了這些東西： | 產品 | 類型 | 技術棧 | 狀態 | | -------------------- | ------------------- | -------------------------- | ---------- | | **bobo-blog** | 個人部落格 | Astro + Cloudflare Workers | 上線運行中 | | **cloud-on-academy** | GCP 認證課程平台 | Astro + Cloudflare | 上線運行中 | | **course-forge** | 內容自動化 CLI 工具 | TypeScript + Node.js | 開發中 | | **code-fossil** | YouTube 頻道品牌 | Remotion + AI 輔助 | 經營中 | 每一個都是從零開始。每一個都是用下班後的時間完成。每一個都大量使用了 AI 工具。 這不是什麼天才的產出。這是一套**可複製的方法**——選對工具、建好流程、善用 AI、嚴格控制時間。 這本書要教你的就是這套方法。 ## 這本書要教你什麼 「一個人做產品」這個系列，14 章帶你走完從點子到上線收錢的完整旅程： ### 第一階段：驗證（第 2-4 章） 在你寫任何一行程式碼之前，先確認方向是對的。 - **[第 2 章 — 點子驗證](/blog/ai-solo-builder-idea-validation/)**：用 AI 在一天內完成市場調查和競品分析 - **[第 3 章 — 技術選型](/blog/ai-solo-builder-tech-stack/)**：建立一套決策框架，選對一個人能掌控的技術棧 - **[第 4 章 — MVP 設計](/blog/ai-solo-builder-mvp-design/)**：砍掉所有不必要的功能，只留最核心的假設 ### 第二階段：建造（第 5-8 章） 用 AI 加持，在最短時間內把產品做出來。 - **[第 5 章 — AI 驅動開發](/blog/ai-solo-builder-ai-driven-dev/)**：從 Vibe Coding 到 Agentic Workflow，讓 AI 成為你的開發團隊 - **[第 6 章 — 部署上線](/blog/ai-solo-builder-deployment/)**：選對平台，省下不少維運時間 - **[第 7 章 — Landing Page 與 SEO](/blog/ai-solo-builder-landing-page-seo/)**：讓產品被目標用戶找到 - **[第 8 章 — 付費機制](/blog/ai-solo-builder-payment/)**：一個人怎麼串接金流開始收錢 ### 第三階段：成長（第 9-12 章） 產品上線之後，怎麼讓它活得更久、長得更大。 - **[第 9 章 — 用戶回饋循環](/blog/ai-solo-builder-user-feedback/)**：系統化收集和分析用戶回饋 - **[第 10 章 — 客服與社群](/blog/ai-solo-builder-support-community/)**：用 AI 省下日常客服時間 - **[第 11 章 — 監控與維運](/blog/ai-solo-builder-monitoring-ops/)**：讓產品在你睡覺時也穩定運行 - **[第 12 章 — 從 Side Project 到 Micro SaaS](/blog/ai-solo-builder-side-project-to-saas/)**：什麼時候該認真？怎麼定價？ ### 第四階段：實戰（第 13-14 章） 看真實案例，然後檢查你自己的產品。 - **[第 13 章 — 實戰案例](/blog/ai-solo-builder-case-studies/)**：完整拆解我的四個產品 - **[第 14 章 — Solo Builder Checklist](/blog/ai-solo-builder-checklist/)**：你的產品及格了嗎？ 每一章都不是純理論。每一章都有「傳統做法 vs. AI 加持做法」的對比，讓你清楚看到 AI 在每個階段能幫你省多少時間。 ## 這本書適合誰 ✅ **適合你，如果你是：** - 有正職但一直想做 side project 的工程師 - 做過 side project 但總是做不完的開發者 - 想從接案轉做自己產品的 freelancer - 想了解「一個技術產品從 0 到 1 長什麼樣」的 PM 或設計師 - 對 AI 輔助開發有興趣，但不知道怎麼系統化使用的人 ❌ **不適合你，如果你是：** - 想找「不用寫程式就能做產品」的方法（這本書假設你會寫程式碼） - 想做大型 SaaS、募資、組團隊（這本書專注在一個人的規模） - 期待「AI 按一個按鈕就做好產品」的魔法（AI 是強大的工具，但判斷和決策還是你的事） ## Solo Builder 宣言 在開始之前，我想跟你分享我對 Solo Builder 的信念。這不是教條，而是我踩過很多坑之後得到的心得： 1. **先 ship，再完美。** 一個上線的 80 分產品，勝過一個永遠在做的 100 分 side project。 2. **時間是最稀缺的資源。** 每一個決策都要問：「這值得我花寶貴的下班時間嗎？」 3. **AI 是隊友，不是魔法。** AI 處理繁瑣的事，你負責方向和判斷。 4. **正職不是阻礙。** 正職是你的收入保障、學習來源、和免費的市場調查。 5. **一個人不代表什麼都自己來。** 用 AI、用開源工具、用現成服務。「一個人」是指決策者只有你，不是執行者只有你。 6. **做自己會用的東西。** 你就是你自己最好的第一個用戶。 ## 下一步 準備好了嗎？ 下一章，我們從最關鍵的第一步開始：**怎麼在一天之內驗證你的點子值不值得做。** 大多數 side project 死在「花了三個月做一個沒人要的東西」。我們要用 AI 確保你不會犯這個錯。 👉 [第 2 章：點子驗證——花一天而不是一個月](/blog/ai-solo-builder-idea-validation)Solo BuilderAISide Project產品開發