Solo Builder 宣言：一個人 + AI 就是一支團隊
本篇是「一個人做產品」系列的第 1 / 18 篇。你可以從系列總覽開始閱讀，也可以直接接著看本文。
那些永遠做不完的 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 章 — 點子驗證：用 AI 在一天內完成市場調查和競品分析
- 第 3 章 — 技術選型：建立一套決策框架，選對一個人能掌控的技術棧
- 第 4 章 — MVP 設計：砍掉所有不必要的功能，只留最核心的假設
第二階段：建造（第 5-8 章）
用 AI 加持，在最短時間內把產品做出來。
- 第 5 章 — AI 驅動開發：從 Vibe Coding 到 Agentic Workflow，讓 AI 成為你的開發團隊
- 第 6 章 — 部署上線：選對平台，省下不少維運時間
- 第 7 章 — Landing Page 與 SEO：讓產品被目標用戶找到
- 第 8 章 — 付費機制：一個人怎麼串接金流開始收錢
第三階段：成長（第 9-12 章）
產品上線之後，怎麼讓它活得更久、長得更大。
- 第 9 章 — 用戶回饋循環：系統化收集和分析用戶回饋
- 第 10 章 — 客服與社群：用 AI 省下日常客服時間
- 第 11 章 — 監控與維運：讓產品在你睡覺時也穩定運行
- 第 12 章 — 從 Side Project 到 Micro SaaS：什麼時候該認真？怎麼定價？
第四階段：實戰（第 13-14 章）
看真實案例，然後檢查你自己的產品。
- 第 13 章 — 實戰案例：完整拆解我的四個產品
- 第 14 章 — Solo Builder Checklist：你的產品及格了嗎？
每一章都不是純理論。每一章都有「傳統做法 vs. AI 加持做法」的對比，讓你清楚看到 AI 在每個階段能幫你省多少時間。
這本書適合誰
✅ 適合你，如果你是：
- 有正職但一直想做 side project 的工程師
- 做過 side project 但總是做不完的開發者
- 想從接案轉做自己產品的 freelancer
- 想了解「一個技術產品從 0 到 1 長什麼樣」的 PM 或設計師
- 對 AI 輔助開發有興趣，但不知道怎麼系統化使用的人
❌ 不適合你，如果你是：
- 想找「不用寫程式就能做產品」的方法（這本書假設你會寫程式碼）
- 想做大型 SaaS、募資、組團隊（這本書專注在一個人的規模）
- 期待「AI 按一個按鈕就做好產品」的魔法（AI 是強大的工具，但判斷和決策還是你的事）
Solo Builder 宣言
在開始之前，我想跟你分享我對 Solo Builder 的信念。這不是教條，而是我踩過很多坑之後得到的心得：
- 先 ship，再完美。 一個上線的 80 分產品，勝過一個永遠在做的 100 分 side project。
- 時間是最稀缺的資源。 每一個決策都要問：「這值得我花寶貴的下班時間嗎？」
- AI 是隊友，不是魔法。 AI 處理繁瑣的事，你負責方向和判斷。
- 正職不是阻礙。 正職是你的收入保障、學習來源、和免費的市場調查。
- 一個人不代表什麼都自己來。 用 AI、用開源工具、用現成服務。「一個人」是指決策者只有你，不是執行者只有你。
- 做自己會用的東西。 你就是你自己最好的第一個用戶。
下一步
準備好了嗎？
下一章，我們從最關鍵的第一步開始：怎麼在一天之內驗證你的點子值不值得做。
大多數 side project 死在「花了三個月做一個沒人要的東西」。我們要用 AI 確保你不會犯這個錯。
