為什麼公開內容先用 Astro Content Collections 加本地 Markdown

內容網站一開始就接 CMS，通常會讓人覺得比較完整。但對目前這個網站來說，真正需要先解決的是文章身份、語言版本、草稿邊界和正式輸出，不是先做一個遠端後台。

現在選擇 Astro Content Collections 加本地 Markdown，不是因為 CMS 不好，也不是把這個選擇當成長期承諾。主要判斷是：目前公開筆記的內容量和協作方式，還不需要為了編輯後台引入資料庫、登入、權限和另一套發布系統；先把內容契約做穩，成本比較小，也比較容易查證。

先看內容真正需要什麼

目前的筆記是網站的一部分，不是需要即時交易的資料服務。文章需要的事情包括：

• 有穩定身份，讓同一篇文章的不同語言可以彼此對應。
• 有 slug 和 locale，讓每種語言使用自己的網址。
• 有 draft、publishedAt 和 updatedAt，分開描述內容狀態和日期。
• 有 category、tags、標題、摘要和作者等 metadata。
• 正式頁面可以在建置時產生 HTML，草稿可以在本機預覽。

這些需求都可以在 Markdown frontmatter 和 Content Collection schema 裡表達。此時先接一個 CMS，解決的會是「遠端編輯與管理」；它不會自動替我們決定文章身份、多語對應或哪些內容可以公開。

Content Collections 提供的是內容契約

本地 Markdown 不代表資料可以隨便寫。Astro 的 collection loader 會讀取 src/content/notes/ 底下的文章，schema 再驗證每份 frontmatter。

目前的資料流可以簡化成：

本地 Markdown
  → Content Collection loader
  → noteSchema
  → getAllNotes()
  → getPublishedNotes()
  → 首頁、列表、文章頁與 sitemap

schema 會限制 locale、slug、日期格式和目前支援的 category，也會拒絕正式文章缺少 publishedAt 的狀態。文章查詢另外檢查同語言的 slug 和 stableId 是否重複，並確認檔案所在語言目錄和 locale 相符。

這些檢查讓 Markdown 保留可讀性，同時不必把每篇文章的結構交給作者自行猜測。檔案是內容來源，schema 是內容邊界，發布查詢則是公開資格的邊界。

為什麼目前先放在 repository 裡

內容和版本可以一起讀回

文章與網站版型、路由和驗證腳本放在同一個專案裡。要追一篇文章為什麼有這個欄位、哪個頁面會使用它，可以直接從內容模型和使用點往回查，不必先登入另一個系統，再對照一份遠端資料。

這也讓文章的變更可以和程式變更分開檢查。新增一篇文章時，可以只檢查 Markdown 與內容驗證；修改發布規則時，則要一起檢查頁面和 sitemap。兩種變更的責任仍然不同，但資料來源不會被藏在另一個不可見的後台裡。

公開輸出不需要執行時查詢

目前網站是靜態輸出。正式建置時讀取文章，產生首頁、列表、文章詳頁和 sitemap；瀏覽器拿到的是已經生成的 HTML，不需要在讀者開頁面時再向內容 API 查詢一次。

這個做法不代表靜態輸出一定比較快，也不代表搜尋結果一定比較好。能確認的是，文章公開資格和頁面輸出在同一個建置流程裡決定，少了一層執行時內容服務要維護。

草稿邊界比較直接

所有合法 Markdown 都可以被本機預覽讀取，但正式頁面只讀取可發布文章。草稿保留在檔案裡，不代表它會自動成為正式路由；只有通過 draft、publishedAt 和發布日期條件的文章，才會進入公開集合。

因此，內容校稿可以先進行，正式網站也可以維持只有已確認文章的狀態。這個邊界不是 CMS 才能做到，但在目前的資料量下，用檔案、schema 和查詢函式就足以表達。

這個選擇刻意不做什麼

本地 Markdown 有明確的成本。它目前不提供：

• 瀏覽器裡的文章編輯器。
• 非技術編輯可以直接登入修改的後台。
• 不重新建置就能立即更新的遠端發布流程。
• 內建帳號、權限、留言或訂閱管理。
• 由內容系統自動提供的全文搜尋、審稿工作流或版本比較介面。

這些不是被藏起來的功能，而是目前沒有納入範圍的能力。只要內容的作者、校稿和發布流程仍然可以在 repository 與本機預覽中完成，先不支付這些系統的複雜度是有意識的取捨。

同樣要分清楚公開筆記和產品資料。文章適合用 build-time 內容；帳號、財務資料或需要使用者操作後即時保存的資料，不能因為網站使用 Markdown，就一起塞進 Markdown。

什麼情況下值得重新評估 CMS

未來如果出現以下需求，就可以重新評估 CMS 或其他內容服務：

• 有多位不直接修改 repository 的作者或編輯。
• 文章需要頻繁由非開發者即時發布。
• 內容審稿、權限、排程或版本比較變成固定工作。
• 文章量和查詢需求增加到本地檔案不再容易維護。
• 需要讓網站以外的產品、App 或 API 共用同一份內容。

這些條件成立時，CMS 可能減少實際工作；但導入後仍然要重新設計 stable ID、語言版本、發布資格、快取、預覽和輸出驗證。換成後台不等於內容契約消失，只是內容來源從檔案移到另一個系統。

反過來說，只有因為 mockup 裡畫了文章列表、或未來可能會有更多文章，還不足以證明現在需要 CMS。介面位置描述的是閱讀方向，不是管理系統的需求證據。

這套架構目前能證明什麼

從目前的 loader、schema、查詢函式、頁面路由和輸出驗證，可以確認：

• Markdown 文章能以受控 metadata 進入 Content Collection。
• 正式頁面使用發布集合，不把所有檔案直接當成公開內容。
• 語言文章可以用 stableId 對應，網址仍由各語言的 slug 決定。
• 草稿可以在 Astro dev 預覽，正式 build 不會註冊預覽路由。
• 首頁、列表、文章頁和 sitemap 可以使用同一套公開資格判斷。

這些證據不能推出以下結論：

• 本地 Markdown 對所有團隊都比 CMS 好。
• 目前的內容量永遠不會增加到需要後台。
• 讀者一定偏好檔案式內容流程。
• 靜態輸出已經證明了效能、SEO、流量或商業結果。

目前的選擇只回答一個比較窄的問題：在這個內容量、這種協作方式和靜態發布邊界下，哪一種內容來源最容易先做對、先查證。

先把內容來源做小，不代表把未來鎖死

只要文章身份、語言版本和發布資格沒有被寫死在某個頁面裡，未來換內容來源仍然可以保留同一組公開契約。真正值得先固定的是：什麼叫同一篇文章、哪個版本可以公開、頁面要從哪裡讀取，以及輸出如何被驗證。

目前先用 Astro Content Collections 加本地 Markdown，是在這些契約已經足夠、CMS 的額外能力還沒有被需求證明時，選擇較小的系統邊界。等內容工作真的需要另一種工具，再用新的需求重新評估，而不是先為想像中的規模付維護成本。

紀錄範圍

本文根據目前的 Content Collection loader、note schema、文章查詢、預覽 integration、頁面路由、sitemap 與工作室開發規格整理。它說明目前為什麼不先引入 CMS，以及這個決定保留的限制；沒有宣稱 CMS 不適合其他內容團隊，也沒有把未來的後台、搜尋或遠端發布寫成已存在的功能。