如果你希望 blog 能穩定更新，發文流程一定要夠輕量、夠可重複。
這個站不是用大型 CMS，而是用 Markdown、frontmatter、Python 和 Jinja2 組成一個靜態產生流程。好處是內容寫起來快，版型集中管理，部署也很單純。
這篇把目前的內容工作流整理成一份可重複使用的站務筆記。
🎯 這篇適合誰
| 你的情況 | 建議先看哪段 |
|---|---|
| 想了解這個 blog 的發文結構 | 整體流程 |
| 想複製 frontmatter 格式來用 | frontmatter 規格 |
| 想降低寫文到上線的摩擦 | 寫作到發布的檢查表 |
| 想讓內容站更好維護 | 這套流程適合什麼規模 |
🧱 整體流程
這個站點以 content/posts/*.md 作為文章來源。
每篇文章只要填好 frontmatter，就能自動進入：
- 首頁最新文章
- 文章庫
- 分類頁
- 標籤頁
- RSS
- sitemap
- 搜尋索引
發文流程可以拆成五步：
- 在
content/posts/新增 Markdown。 - 填好標題、摘要、分類、標籤和日期。
- 用 Markdown 寫正文。
- 執行
python build.py產生靜態檔。 - 部署到 Cloudflare Workers Static Assets。
這種流程最大的優點，是文章和版型分離。
寫文章時不用管首頁怎麼排，也不用手動更新 archive。只要資料結構正確，建置流程會把內容送到所有該出現的位置。
🧾 frontmatter 規格
目前一篇文章的基本格式如下：
---
title: "Markdown 部落格發文流程設計：frontmatter 規格與資料夾結構讓上線更快"
description: "設計清楚的 frontmatter 規格與資料夾結構，可以大幅降低 blog 每次更新的摩擦力。"
pubDate: 2026-04-17
categories: ["部落格工作流"]
tags:
- Markdown
- 部落格
- frontmatter
featured: false
draft: false
image: "✍️"
heroTitle: "只要丟進一份 Markdown，就能更快把內容上線。"
---
幾個欄位特別重要：
| 欄位 | 用途 |
|---|---|
title |
頁面標題、OG 標題、文章列表標題 |
description |
SEO 描述、文章摘要、社群分享描述 |
pubDate |
排序、RSS、Article schema |
categories |
分類頁與站內主題聚合 |
tags |
長尾標籤與搜尋索引 |
image |
文章列表的小圖示 |
heroTitle |
文章頁首的情境化標題 |
標題和 heroTitle 可以不同。
title 比較適合搜尋結果，要清楚包含主題和任務。
heroTitle 則可以更像讀者進文章後看到的第一句話，讓語氣比較自然。
🗂️ 分類和標籤怎麼用
分類不要太多，因為分類是網站的主入口。
標籤可以比較細，因為標籤更像交叉索引。
例如一篇 Tailscale 文章可以這樣拆：
- categories:
["遠端存取", "Synology"] - tags:
["Synology", "NAS", "Tailscale", "VPN", "資安"]
分類回答的是「這篇屬於哪個大主題」。
標籤回答的是「這篇還跟哪些細節有關」。
如果分類太細，首頁和文章庫會變得很碎。
如果標籤太少，搜尋和長尾探索會比較弱。
🧪 寫作到發布的檢查表
每篇文章發布前，我會建議至少檢查這些項目：
- 標題是否明確包含主要任務
- description 是否能單獨說明文章價值
- 第一段是否直接指出讀者痛點
- 是否有「這篇適合誰」表格
- 是否有至少一張圖解或流程圖
- 是否有兩個以上段落分隔線
- 是否有「延伸閱讀」
- 是否連到同主題的樞紐文或下一步教學
- 程式碼區塊是否能被複製
- build 是否成功
這些規則看起來有點瑣碎，但會讓整站文章格式變得一致。
一致不是為了僵硬，而是讓讀者每次打開文章都知道該怎麼讀。
🧭 檔名和 slug 規則
檔名最好穩定，不要發布後一直改。
因為這個站會用檔名產生文章路徑，例如：
content/posts/synology_tailscale_full_guide.md
會產生：
/posts/synology_tailscale_full_guide/
命名時可以遵守幾個原則：
- 用英文或明確的技術詞做 slug
- 不要把年份放進 slug，除非文章本身就是年度比較
- 不要用太抽象的名稱，例如
tips.md - 同一系列使用相同前綴，例如
synology_、claude_ - 發布後盡量不要改檔名，避免舊網址失效
標題可以調整，slug 應該穩定。
這樣 Google、RSS、社群分享和站內連結都比較不會斷。
🧹 內容維護節奏
Markdown 工作流還有一個好處：很適合批次檢查。
可以定期跑：
python audit_posts.py
python build.py
前者檢查內容品質訊號，後者確認網站可以產出。
每次整理文章時，可以先處理這幾類：
- 缺延伸閱讀的文章
- 沒有圖解的文章
- 太短但又有搜尋價值的文章
- 分類和標籤不一致的文章
- 已經過時但仍有流量的文章
這會讓內容站越來越像資料庫，而不是一堆散落的文字檔。
🔁 這套流程適合什麼規模
Markdown 靜態站很適合：
- 個人技術 blog
- 小型知識庫
- 教學文章網站
- 工具頁搭配內容頁
- 不需要多人即時協作的內容站
當文章數量來到 50 到 200 篇時，這種架構仍然很好維護。
真正需要注意的是內容治理，而不是技術本身。
例如：
- 分類是否失控
- 舊文是否有更新
- 文章是否互相連結
- 短文是否該合併或擴寫
- 重複主題是否該整理成樞紐文
這也是為什麼這篇被歸在「部落格工作流」而不是 NAS 主題裡。它不是一般讀者一定會看的教學，而是用來整理本站內容系統的站務筆記。
📌 小結
一套好的發文流程，真正節省的不是幾分鐘操作，而是讓靈感到上線之間的阻力變小。
Markdown 負責內容。
frontmatter 負責結構。
build script 負責產出頁面。
模板負責視覺一致性。
當這些分工清楚，blog 就能穩定累積，而不是每次發文都重新發明一次流程。