為什麼我用 Astro 取代 WordPress 架設公司官網 — 編譯摘要

濃縮

1. 工具選擇應回歸使用場景，而非技術忠誠度：十五年 WordPress 經驗者選擇 Astro 架官網，原因不是 WordPress 不好，而是形象官網不需要 CMS 的動態功能。內容更新頻率低、唯一管理者是開發者自己，CMS 架構在此場景下是多餘負擔。
2. AI 時代佈景主題市場反而更有價值：AI 能快速改程式邏輯和替換內容，但 UI 設計的整體一致性（色彩、間距、字體比例）仍難以穩定產出。購買專業設計師主題 + AI 修改內容，比讓 AI 從零生成 UI 更高效且可控。
3. 終端機原生工作流是 AI 開發的最佳搭配：Astro 的靜態生成 + Cloudflare Pages 自動部署，讓整個流程（寫程式碼→git push→上線）完全在終端機內完成，消除了 WordPress 部署流程中的「體驗斷裂感」。

關鍵證據：WordPress 部署需五步（租主機→裝環境→部署程式碼→同步資料庫→設定 SSL/DNS），Astro + Cloudflare Pages 只需 git push，30 秒完成部署。

質疑

• 前提假設：假設網站管理者是技術人員。如果公司日後僱用非技術人員負責內容更新，Astro 的 Markdown + git 工作流會成為障礙，屆時可能需要額外建構 CMS 層（如 Decap CMS）。
• 邊界條件：「形象官網不需要 CMS」的判斷基於目前的業務規模。若網站需要加入會員專區、客戶入口、多語系自動化等功能，靜態生成的限制會逐漸浮現。
• 反例：文章提到 AI 產出的 UI 一致性不夠，但隨著多模態模型進步（如 Claude 的 Artifacts、GPT-4o 的圖像理解），AI 生成 UI 的品質正在快速提升。「買主題比 AI 生成好」的結論可能有時效性。

對標

• [[適切技術]]（Appropriate Technology）：選擇 Astro 而非 WordPress，本質上是「用恰好足夠的技術解決問題」——與發展中國家選擇適切技術而非最先進技術的思維相同。
• [[開發者體驗]]（DX）作為決策因子：部署流程的「體驗斷裂感」是純粹的 DX 問題，而非功能或效能問題。這反映了 AI 時代開發者越來越重視工作流的連貫性。
• [[靜態生成]]vs [[動態渲染]]的光譜：Astro 的 Island Architecture 實際上位於光譜中間——預設靜態，但可局部引入動態元件，這種漸進式策略與 [[漸進增強]] 的設計哲學一致。

關聯概念

• [[工具選擇策略]]
• [[靜態網站生成器]]
• [[開發者體驗]]
• [[AI 輔助 UI 開發]]
• [[終端機工作流]]