解鎖條件：當你開始問「為什麼需要這麼複雜？」
有一天我打開一個熱門的部落格教學，第一步是「安裝 Strapi」，第二步是「設定 PostgreSQL」，第三步是「建立 Docker Compose」——我還沒寫第一篇文章，就已經在管理基礎設施了。
這不是我要的路。
我要的是：寫 Markdown、推一下 git、三十秒後網站更新。就這樣。不需要後台登入介面，不需要資料庫，不需要 CDN 設定頁面。
這個「解鎖條件」很簡單：當你覺得工具的複雜度超過了你的問題本身，就是重新選型的時刻。
核心論述一：最小技術棧不是「偷懶」，是精準
「最小技術棧」這個詞容易被誤解成「隨便做做」，但實際上它要求你更清楚地回答一個問題：這個系統到底要解決什麼問題？
我的部落格需求清單：
- 支援 Markdown 撰寫
- 支援程式碼 syntax highlighting
- SEO 友善（meta tags、sitemap）
- 部署零成本或接近零
- 自己能看懂、改懂、不怕壞掉
基於這份清單，技術選型幾乎自己跑出來了：
Next.js 做靜態生成（output: 'export'），Astro 也是很好的選項，但我已經熟悉 Next.js 生態，切換成本不划算。
MDX 做內容格式，比純 Markdown 多了一個殺手鐧：你可以在文章裡直接嵌入 React 元件。這讓「互動式內容」成為可能，而不是說說而已。
Tailwind CSS 做樣式，因為我不想維護一份自訂的 CSS 命名系統，Tailwind 的 utility-first 哲學跟「最小認知負擔」高度吻合。
Vercel 做部署，push 即上線，無腦。
整套組合下來，沒有資料庫、沒有 CMS 後台、沒有 session 管理，本地跑起來就是生產環境的樣子。
核心論述二：靜態生成的邊界在哪裡
靜態網站有一個常見的誤解：「沒有後端，就什麼都做不了。」
這個說法在 2018 年可能還算對，但現在不是了。
Next.js 的 getStaticProps + getStaticPaths 讓你可以在 build time 把所有動態內容拉進來，生成完整的 HTML。以部落格來說，文章列表、標籤頁、作者頁，全部都可以靜態生成。
真正的邊界在於：需要即時使用者資料的功能。
評論系統？用 giscus，掛 GitHub Discussions，一行 script 搞定，完全不需要自己的後端。
搜尋？用 Pagefind，它在 build time 建立搜尋索引，客戶端直接查，零 API 請求。
訂閱信？用 Buttondown 或 ConvertKit，embed 一個表單，他們幫你管名單。
每次我遇到「這要怎麼做？」的問題，我都先問自己：有沒有不需要我自己維護後端的方案？ 答案多數時候是有的。
靜態生成的邊界，遠比你想像的更寬。
核心論述三：內容管道的設計才是長期護城河
技術棧選好之後，反而不是最難的部分。
真正決定部落格能不能長期運作的，是內容管道：從「有個想法」到「文章上線」這段路，有多少摩擦？
我的管道是這樣設計的：
- Obsidian 草稿：所有想法先在 Obsidian 裡發酵，不管格式，純粹把腦子裡的東西倒出來。
- AI 共同編輯：用 Claude 把草稿拉到可發表的狀態，這一步不是「讓 AI 寫文章」，而是用 AI 當編輯，幫我找邏輯漏洞、補充細節、調整節奏。
- Markdown push 到 git：確認好的文章直接推進
src/content/blog/，Vercel 自動部署。 - 自動化通知：部署成功後，Telegram Bot 通知我「上線了」。
這個管道有幾個設計原則：
- 沒有任何步驟需要登入某個後台
- 每個步驟都可以從任何裝置完成（Obsidian 有 iOS app，git push 可以從手機）
- 失敗的成本很低（push 壞了，rollback 一行指令）
管道設計好之後，「寫文章」這件事的心理阻力大幅下降。不是因為「更容易」，而是因為每個步驟都在我掌控之內，不需要記憶任何平台的操作邏輯。
收斂反思：Before / After
Before：開一個新部落格，我需要先選 WordPress 主機方案、安裝外掛、設定 Yoast SEO、搞清楚媒體庫在哪裡、擔心主機到期要不要續費。
After：npx create-next-app，選一個喜歡的主題，在 src/content/blog/ 建一個 .mdx 檔，git push，完成。
這不是說 WordPress 不好。WordPress 有它的適用場景，特別是需要讓非技術用戶更新內容的情況。但如果你是開發者，而且你只需要一個寫給自己看（順便給別人看）的部落格，最小技術棧是你的護城河，不是你的妥協。
最後說一件反直覺的事：
靜態部落格的「慢」——每次更新都要重新 build——其實是一種強迫你思考清楚再發布的機制。不像 CMS 那樣隨手改隨手存，build 的過程讓你有一個小小的停頓點。我把這個「慢」當成內容品質的守門員。
技術棧越簡單，你花在維護工具的時間就越少，花在真正內容上的時間就越多。這才是最小技術棧的核心價值。