寫部落格文章不需要另外做一個新畫面。只要在 src/content/blog/ 底下新增一個 Markdown 檔，建置時就會產生文章頁面，同時也反映到各語言的列表、RSS 與網站地圖。作者只管理內文與 frontmatter，重複出現的畫面與串接則由網站程式碼負責。
為什麼不做管理後台？
這個部落格的主要工作是寫文章與發佈。如果先做管理後台，就得一併維運登入、權限、儲存 API 與編輯器。相對地，Markdown 可以在 git 裡查看修改紀錄，而且文章和程式碼在同一個儲存庫，一次建置就能確認公開結果。
所以我把文章的輸入單位定得很小。
檔案開頭先寫 frontmatter，下面是內文，需要時再放 d3-flow 之類的圖表區塊。每篇文章都重複這個結構，不需要另外的編輯器，就能使用相同的渲染規則。
一個檔案就是一篇文章。檔名會成為網址的 slug，所以一旦決定就一直沿用。即使修改文章，網址也不會改變。
frontmatter 負責什麼
內文上方的 frontmatter 寫標題、說明、發佈日與標籤。省略 lang 就是韓文文章；其他語言的文章只要寫 lang 與指向韓文原文的 pair，就能建立語言選單與 hreflang 的連結。
---
title: 文章標題
description: 顯示在搜尋結果的一句話摘要
pubDate: 2026-10-24
tags: [Astro, Markdown]
---標題與說明的長度，由 content schema 在建置時檢查。必填值漏掉或使用了不允許的語言，在部署前就能看到錯誤。這不是每篇文章都靠記憶規則來檢查，而是在讀取內容的邊界上確認。
一個檔案如何變成多種結果
建置時，Astro content collection 會讀取 src/content/blog/*.md。draft: true 的文章不放進列表，各語言的文章依發佈日由新到舊排序。相同標籤的文章累積到一定數量後，相關文章也會自動附上。
這個流程的優點，是減少了可能漏掉串接的地方。不需要另外把文章登錄到列表，也不用手動修改 RSS 檔。新文章一進入 collection，各項結果就都從同一份原始檔產生。
圖表也放在內文裡
較長的說明，我會用程式碼區塊放入自己做的 D3 圖表。例如上面的流程圖，就是在 d3-flow 區塊裡寫的 JSON。建置外掛會把它轉成 SVG，所以不需要外部圖片或截圖檔。
圖表裡的文字也和內文採用相同標準。不放未經確認的數字或營運資訊，只放說明文章流程所需要的名稱。如果 JSON 寫錯，可以依建置紀錄中的警告來修正。
新增文章時要確認的事
寫新文章時，我只確認四件事。
- 檔名是不是由小寫英文字母、數字與連字號組成的唯一 slug？
- frontmatter 裡有沒有標題、說明與發佈日？
- 內文有沒有寫
# H1？ - D3 圖表與 Markdown 語法在建置時是否正常處理？
最後一項用下面的指令確認。
pnpm --filter site30cut build新增一個文章檔的方式很單純，但要維持這份單純，重點在於信任自動串接，不要增加手動登錄。內容放在 Markdown，共通的行為放在網站程式碼，兩邊的責任就不會混在一起。
常見問題
之後需要加上管理後台嗎？
當撰寫與審閱文章的人變多，或需要非開發人員編輯時，可以再評估。如果目前在 git 裡管理文章的流程已經足夠，管理後台就得額外維運儲存庫、權限與編輯器，這是它的代價。
可以暫時隱藏文章嗎？
在 frontmatter 寫上 draft: true，就會從建置結果中排除。要公開時，把這個值刪掉或改成 false，再重新建置即可。
每篇文章都要另外寫頁面程式碼嗎？
不需要。共用的部落格頁面元件會讀取 collection 裡的文章資料。每篇文章不同的，只有 Markdown 檔與 frontmatter。