實戰案例：我的四個產品
本篇是「一個人做產品」系列的第 13 / 18 篇。你可以從系列總覽開始閱讀，也可以直接接著看本文。
紙上談兵結束，四個 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 章的技術選型原則：
| 考量 | 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 章「選生態系不選框架」的原則直接相關。
| 考量 | 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 加持做法：
我要寫一篇關於 [主題] 的技術文章。
目標讀者：[描述]
文章長度：約 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 章我分享過它的驗證故事——繁中市場的 GCP 認證課程幾乎是空白。這個市場空白就是我的機會。
驗證到上線的完整旅程
驗證階段（1 天）： 在 PTT、iThome、技術社群搜「GCP 認證中文」，發現大量需求但幾乎沒有系統化的繁中資源。做了一個簡單的 Landing Page，一週內收到足夠的表單填寫。
MVP 階段（3 週）： 不等課程「全部做完」就上線。先放前三堂課的內容，然後每週更新。
這是我做對的最重要的事。
關鍵決策：不等「完美」就上線
傳統做法：花三個月準備完整的課程內容，錄影、剪輯、上字幕，全部做好才上線。
我的做法：先做文字版課程，搭配程式碼範例和截圖。三堂課做好就公開預售。
為什麼這樣做？
- 驗證付費意願比驗證內容品質更急迫。 你的課程內容再好，沒人願意付費就是零。
- 早期學員的回饋比你自己的判斷更準確。 第一批學員告訴我哪些章節太難、哪些太簡單、哪些他們根本不需要。
- 持續更新反而是賣點。 「這門課一直在更新」對學員來說是正面的信號。
AI 怎麼用
1. 課程大綱設計
我要設計一門 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。
# 從大綱生成部落格文章骨架
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. 研究階段
我要做一支影片，主題是「[技術歷史主題]」。
請幫我研究：
1. 時間線：關鍵事件的年份和背景
2. 人物：核心開發者是誰、他們的背景
3. 技術細節：為什麼當時做了這個設計決策
4. 有趣的軼事或衝突
5. 現代的影響：這個決策如何影響今天的技術一個影片的研究量可能需要讀 10-20 篇文章和論文。AI 幫我彙整資料，我再去源頭驗證關鍵事實。
2. 腳本撰寫
研究完成後，我用 AI 生成腳本的結構草稿。但最終版本一定是我自己重寫——因為影片腳本需要個人語氣和節奏感，這是 AI 目前還做不好的。
3. 影片描述和 SEO
每支影片的描述、標籤、時間戳——這些「必要但無聊」的工作全部交給 AI。
4. 縮圖概念發想
這支影片的標題是「[標題]」。
請提供 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 宣言的核心，也是我每個產品都遵循的原則。
模式 4：產品之間互相餵養
這四個產品不是獨立的——它們形成一個生態系：
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 遠高於影片。
如果重來一次的優先順序
- 先做部落格（最低成本、最快上線、SEO 是長期資產）
- 邊寫文章邊驗證課程需求（部落格文章就是課程的 beta 版內容）
- 確認有人付費後再建課程平台（先用現成工具賣）
- 自動化工具在第三個月之後才開始做（先手動跑完流程，確認哪些步驟值得自動化）
- YouTube 放到最後（時間投入最高、回報週期最長）
本章重點回顧
- 🏗️ 四個產品全部用同一套技術棧（TypeScript + Astro + Cloudflare），最大化知識複用
- 🤖 AI 在每個產品都用在「結構化的苦工」上——大綱、練習題、研究、metadata——而不是核心判斷
- 🚀 每個產品都是「先上線再完善」，沒有一個是等到完美才公開的
- 🔄 四個產品互相餵養，形成生態系而不是獨立的 side project
- ⚠️ 最大的教訓：不要太早自建、不要過度設計、不要追求完美才上線
- ⏱️ 有正職的 Solo Builder，優先做「時間投入低、長期回報高」的產品（部落格 > 課程 > 工具 > 影片）
下一步
看完了真實案例，接下來是全書的最後一章。
我為你準備了一份 Solo Builder Checklist——從點子驗證到上線營運，一份可操作的檢查清單。不管你的產品在哪個階段，都可以用這份清單來檢查你有沒有遺漏什麼關鍵步驟。
