技術選型決策框架
本篇是「一個人做產品」系列的第 3 / 18 篇。你可以從系列總覽開始閱讀，也可以直接接著看本文。
技術選型的致命誤區
「用什麼框架好？」
這是工程師最喜歡討論的話題。也是 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：描述你的產品需求
我要做一個 [產品描述]。
需求：
- 核心功能：[列出 3-5 個最重要的功能]
- 預期用戶量：[前期預估]
- 互動性：[靜態為主 / 高度互動 / 即時通訊]
- 資料庫需求：[簡單 CRUD / 複雜查詢 / 即時同步]
- 預算：零（用免費額度）
- 開發者人數：1 人
- 我熟悉的技術：[列出你已經會的]
- 時間限制：每週 5-10 小時
請推薦一個技術棧，以及為什麼這樣選。
要考慮 AI 輔助開發的友善度。步驟 2：讓 AI 比較兩個候選方案
如果 AI 推薦了 A 方案但你心裡傾向 B 方案，不要糾結——直接讓 AI 比較：
方案 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 章：實戰案例）：
推薦組合 A：靜態為主的產品
適合： 部落格、文件站、Landing Page、行銷網站、課程平台
| 層級 | 技術 | 原因 |
|---|---|---|
| 框架 | Astro | 靜態優先、island architecture、生態系豐富 |
| 樣式 | Tailwind CSS | AI 生成品質最高、utility-first 適合快速開發 |
| 部署 | Cloudflare Pages | 免費、全球 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 最大的敵人是「功能蔓延」——什麼都想做，結果什麼都做不完。我會教你一套方法，把產品砍到只剩最核心的部分，然後用最少時間做出來。
