如何建立純靜態 CMS，以及發佈內容的流程

純靜態 CMS 不需要在瀏覽器中管理資料庫。內容就是版本控制中的檔案：作者用 Markdown 撰寫，建置工具把它們轉成 HTML、RSS 與 sitemap，最後只部署產生的靜態檔案。

這種做法很適合以文章為主、發布頻率穩定的網站。它沒有後端登入、資料庫或客戶端管理介面，換來的是更少的維護面、更快的載入速度，以及可追溯的內容歷史。

內容如何成為 CMS

先為文章約定一個內容目錄與 frontmatter 格式。每篇文章以 metadata 說明標題、日期、標籤與編修者。

---
title: "文章標題"
description: "供摘要、搜尋與 RSS 使用的說明。"
publishedAt: 2026-07-20
tags: ["CMS", "Static Site"]
editors: ["編修者名稱"]
---

從這裡開始撰寫文章內容。

Astro Content Collections 會在建置時驗證這些欄位，再由頁面範本列出文章、產生標籤頁，並渲染 Markdown。CMS 的核心不是一個遠端控制台，而是清楚的內容規則與可重複執行的建置流程。

發佈流程

階段	做法	產出
撰寫	新增或修改 Markdown 與 frontmatter	可審閱的內容差異
編修	檢查正確性、原創性、連結與編修者資訊	準備發布的文章
建置	執行 `npm run build`	`dist/` 中的 HTML、RSS 與 sitemap
審查	檢視建置結果與 Git diff	可合併的變更
發佈	合併 Pull Request 並部署 `dist/`	對外可讀的靜態網站

為什麼以 Pull Request 發布文章

Pull Request（PR）把「撰寫完成」與「正式發布」分開。它讓編修者能直接檢視 Markdown 差異、確認 frontmatter、連結、原創性與正確性，也留下每次修改與審查的可追溯紀錄。這比直接推送預設分支更容易發現誤刪、錯誤網址或不完整的 metadata。PR 也能讓 AI agent 先對文章品質進行初步審查，例如檢查結構、連結與內容一致性；是否採納建議與是否發布，仍由人類編修者決定。

AI review loop

AI 審查應是可重複執行的迴圈，而不是一次性的批准：

作者完成草稿與 frontmatter，先在分支上建置。
AI 依文章審查規則提出阻擋問題、結構改善與可選潤飾，檢查範圍包括來源是否支持主張、公開資訊與編修者資訊。
人類編修者逐項核對 AI 的意見與原始來源，決定採納、修改或駁回；AI 的結論不能取代查證。
修正後再次建置並重跑 AI 審查；若仍有阻擋問題，就回到修正步驟。
沒有阻擋問題後，由人類在 PR 中確認最終差異並決定是否合併。

這個迴圈讓 AI 擔任初步檢查者，而人類保有對原創性、正確性與發布的最終責任。

不過，PR 是流程約定，不會自動形成強制保護。應依使用的協作平台與團隊需求，建立可驗證的審查與發布機制，並讓審查紀錄可以追溯。

實際操作可以保持很短：

# 建立內容後，先在本機建置驗證
npm run build

# 以功能分支提交，再透過 Pull Request 發佈
git switch -c article/topic
git add <article-file>
git commit -m "docs: add article"
git push -u origin article/topic

正式發佈以靜態檔案為主

依 Cloudflare Pages 的 Framework presets，以 Astro preset 建置時，部署輸出目錄為 dist。¹ 正式網站不公開開發期工具或管理介面；發布完成後，網站仍是一組可被 CDN 快取、可離線保存的文件。

Cloudflare Pages 免費方案注意事項

使用 Cloudflare Pages 前，應先依官方文件確認當期限制。免費方案有部署與檔案數量限制：目前每月最多 500 次部署，單一網站最多 20,000 個檔案；發布頻率與網站規模應先納入規劃。²

靜態網站可以降低資安風險

靜態選型的安全意義來自「不建立不需要的功能」。OWASP 將攻擊面視為資料或指令進出系統的路徑，以及保護這些路徑與資料的程式；登入、管理後台、資料庫與寫入 API 都是必須被分析與保護的部分。³

因此，若網站的需求只是公開閱讀文章，選擇不提供登入、內容寫入或資料庫查詢，便可讓這些功能與相應的公開入口不存在。這不是把動態功能做得更安全，而是避免在沒有需求時建立它們；安全工作便能聚焦在仍然存在的內容、建置供應鏈與部署權限。

這不代表網站自動安全。內容與連結仍應審查，建置相依套件與部署帳號仍須維護權限，且公開資料本身不應包含敏感資訊。OWASP Top 10 與 NIST 的 Secure Software Development Framework（SSDF）不會指定應採用靜態或動態架構，但可用來檢查這些剩餘風險與安全開發流程。⁴⁵

在靜態安全前提下比較 Astro、Hugo 與 WordPress

前述安全優勢的判準是：網站是否只發布靜態檔案，並避免建立不需要的公開功能。Hugo 也可以符合這個判準；它以 Go 的 template 語法將內容、資料與資源轉為頁面。⁶ 因此，Astro 與 Hugo 的差異主要在客製化方式；兩者都仍須依其實際功能與流程管理安全風險。

工具	對靜態安全前提的影響	本網站的取捨
Hugo	可建立靜態網站，和 Astro 一樣可避免不需要的登入、資料庫與寫入端點。	適合熟悉 Go template 與 Hugo 模板工作流的團隊。
WordPress	theme 控制呈現、plugin 擴充功能，適合需要後台與外掛工作流的情境。⁷⁸	本網站以縮小攻擊面為優先；公開閱讀不需要後台或動態功能，因此不引入相應的執行期元件。
Astro	Content Collections 可在建置時驗證本地 Markdown 的資料結構，並以元件與版面客製輸出。⁹	在保留純靜態部署的前提下，較符合本網站對內容規則與版面的客製需求。

因此，本網站選擇 Astro 的理由是客製化更直接，而選擇靜態的理由才是縮小不必要的攻擊面。若團隊較熟悉 Hugo，Hugo 仍是符合相同安全目標的選擇；若需求改為後台協作或動態功能，才應重新評估 WordPress 或其他架構所需的安全控制。

讓流程可以長久運作

內容規則應寫進專案文件，並由建置檢查維持一致。每次發布前，確認文章 metadata 完整、編修者可追溯、npm run build 成功，然後再透過 Pull Request 讓變更被審閱。

如此一來，CMS 不必變複雜：它是一個由檔案、版本控制、人工判斷與靜態建置共同組成的發布流程。