Table of Contents
1/ 🧩 最近很常看到這個說法：「AI 都能寫扣了，還把網站放在 WordPress 上幹嘛？」我同時經營一個小說站和一個部落格，答案是——看情況。而且差別大到不能混為一談。
2/ 📚 小說站：寫入一次、閱讀多次，結構固定，只在乎閱讀體驗。 純靜態＋Git＋AI 幾乎是最佳解，維護成本趨近於零。
3/ 📝 部落格完全相反。改兩行錯字、調分類、下架轉址、通勤時想到就發——這些事每週都在發生。CMS 二十秒搞定，純靜態要開終端機、確認沒破版、push 等部署 ⏳
4/ 🪤 而「寫個腳本自動化」是個陷阱：等你補完分頁、sitemap、轉址、搜尋，你只是親手做了一套沒有社群、沒有文件的 CMS。工具真正的價值，在於吸收那些你根本不想分心處理的摩擦 🔧
AI 會寫網頁之後，我們還需要 CMS 嗎？從 cqi365.net 的架構分工談起
最近在技術社群裡，很常看到一個很迷人的論點：
既然 Claude、Cursor 這些工具已經能讀寫程式碼、處理整個檔案結構，為什麼還要把網站架在肥重、常有安全更新、還得養一座資料庫的 WordPress 上？全部交給 AI 管理純靜態 HTML 不就好了？
這個方案在紙上很漂亮：沒有資料庫、沒有快取外掛、攻擊面接近於零、載入速度極快，還能讓 AI 順手做 SEO 檢查與內部連結串接。
但我手上剛好有兩個性質完全不同的站：一個是發布隨筆與知識整理的 blog.cqi365.net，另一個是專做章節連載的 novels.cqi365.net。把它們放在一起看之後，我的結論是：這題沒有通解。
「AI 能不能取代 CMS」從來不是是非題。真正的變數只有兩個：內容的更新頻率，以及每次更新要付出的摩擦力。
兩種站，兩種完全不同的維護日常
novels.cqi365.net：純靜態加 AI 工具鏈的主場
長篇創作的內容特性非常單純：
- 寫入一次，閱讀多次。章節發布之後，除了偶爾修個錯字，幾乎不會再有結構性的變動。
- 結構高度標準化。卷、章、回的層級固定，目錄與上一章／下一章的導覽邏輯寫一次就能用到最後。
- 只在乎閱讀體驗。排版要乾淨、載入要零延遲、頁面上不該有任何雜訊，最好還能轉成 EPUB 離線讀。
這種場景下，Markdown 加純靜態部署幾乎是最佳解。用 Git 配合 CI/CD，AI 可以幫忙生成格式一致的章節頁、調整排版 CSS，甚至校對全書的術語一致性。維護成本極低，伺服器負擔趨近於零。
blog.cqi365.net：為什麼我還是用 CMS
把場景換到部落格，純靜態的問題就開始浮現。部落格不是「寫完歸檔」的靜態書庫，它是一個需要頻繁微調的有機體。
| 操作情境 | CMS（WordPress） | 純靜態 + AI 維護 |
|---|---|---|
| 臨時改兩行錯字 | 手機開後台、編輯、儲存，二十秒。 | 開終端機 → 找檔案 → 請 AI 改字 → 確認沒動到別的標籤 → push 觸發部署。數分鐘起跳。 |
| 調整分類與標籤結構 | 後台拖曳層級，系統自動重新映射所有文章。 | 要讓 AI 遍歷所有檔案重寫關聯，隨時可能漏改或破版。 |
| 下架過期文章、批次轉址 | 移到垃圾桶，外掛接手 301。 | 刪檔 → 重算分頁 → 更新 sitemap → 手動配置轉址規則。 |
| 臨時想到就發 | 手機貼上文字，直接發布。 | 需要本機開發環境，或一套自己維護的 webhook 流程。 |
單看每一格，差距都只是幾分鐘。但這些動作在部落格上是每週、甚至每天都在發生的。
「寫個腳本讓 Agent 自動化」的陷阱
面對這些瑣事，技術人的直覺通常是：寫幾支 Python 腳本、用 n8n 串一下，或者乾脆做一個專屬的 Agent 來管分頁、sitemap 和轉址。
這確實做得到。問題在後面：當你為了分頁邏輯、分類標籤、sitemap、301 轉址、全文搜尋、內部連結，一支一支補上自動化流程之後，你其實是用比較脆弱的方式，親手重新發明了一套 CMS——而且沒有社群、沒有文件、沒有人幫你修 bug。
最後的結果往往是：本來只想寫一篇五百字的觀點分享，一整個下午卻花在 debug 部署腳本上。
三個問題，決定你該站在哪一邊
如果要給一個能帶著走的判準，我會問這三題：
- 這批內容發布之後，平均還會被修改幾次？
- 分類、導覽、資訊架構在未來一年會不會變動？
- 你會不會有「在手機上、在通勤時，臨時想發一段東西」的需求？
三題裡有兩題答「會」，就別為難自己，用 CMS。三題都答「幾乎不會」，靜態加 AI 工具鏈會讓你飛起來。
工具真正的價值，在於吸收日常的微小摩擦
在 cqi365.net 的架構裡，這個實驗給我的結論很單純：
- 靜態加 AI 是把利刃，適合專注、結構化、低變動的內容——小說連載、專題文件、作品集。
- CMS 不是老舊的象徵，它是高頻維護的護城河——部落格、即時筆記、隨時要調整的東西。
CMS 真正的力量，從來不在前台的渲染技術有多新潮，而在它替你默默消化了幾百個你根本不想分心處理的工程細節。這其實跟做流程改善時的原則是同一件事：真正該被消除的，是那些不創造價值、卻穩定消耗你注意力的步驟。
順帶一提，你現在讀到的這篇文章，就是在 WordPress 後台按下發布的。這不是妥協，是分工。
不要為了追求架構上的極簡，把日常創作搞成極繁。找到邊界、各司其職，才是撐得最久的維運方式。