使用指南

將此網站作為 EmDash 文件、遷移內容、外掛、模板與產品更新的發佈系統。

這個網站應該扮演的角色

emdashcmseverything.com 不該只是一般的落地頁,而應作為 EmDash 生態系的公開知識層與分發層。

這代表要在同一套一致的系統中整合多種內容任務:

  • 說明 EmDash 是什麼
  • 教會使用者它如何運作
  • 呈現它適合的場景
  • 發佈外掛與模板
  • 引導 WordPress 遷移
  • 公佈產品進度與版本更新

建議的資訊架構

目前的結構就是為了支援這個模型而設計:

  • docs/docs:常青型文件內容
  • docs/use-cases:以情境驅動的採用內容
  • docs/plugins:外掛目錄條目
  • docs/templates:模板目錄條目
  • docs/faq:更新、教學與編輯型內容

這比把所有內容硬塞進單一行銷首頁,或把產品資訊藏在框架元件中,更符合生態網站需求。

各分區如何使用

Docs

這個分區適合放置長期有效且意圖明確的內容:

  • 入門指南
  • 功能說明
  • 部署說明
  • 架構總覽
  • FAQ

這些頁面應回答使用者在評估前與評估過程中的核心問題。

Use Cases

此分區用來把產品能力轉換為決策者語境。當 EmDash 被放在以下場景時,會更容易理解:

  • 編輯型發佈
  • 文件與知識庫
  • 外掛生態
  • 模板商業

這個分區應把產品形態連結到實際成果。

Plugins

外掛頁面應該像小型產品頁,而不只是發行說明。每個頁面都應清楚說明:

  • 外掛做什麼
  • 適合哪些使用者
  • 目前狀態
  • 價格或可用性
  • 下載路徑
  • 安裝與相容性

Templates

模板頁面應讓人容易比較不同網站起始包。優質條目通常包含:

  • 目標受眾
  • 截圖
  • 技術堆疊細節
  • 版本與發佈日期
  • 示範連結
  • 下載連結或儲存庫連結

Blog and Updates

這個分區應持續呈現網站與產品的動態:

  • 發佈說明
  • 遷移指南
  • 產品觀點
  • 教學文章
  • 案例研究

這是讓網站保持活躍並持續累積價值的關鍵。

發佈工作流程

對此專案而言,最精簡且穩定的流程是:

  1. docs/ 新增或修改內容
  2. 檢查 Git diff
  3. 本地預覽
  4. 將建置後的靜態網站部署到 Cloudflare Pages

當 AI 參與草稿撰寫、編修、重構與一致性校對時,這套流程特別有效。

為什麼這種結構適合與 AI 協作

當網站以以下原則為核心時,AI 編修會更可靠:

  • 小而清晰的 MDX 檔案
  • 明確的 frontmatter
  • 可重用頁面元件
  • 穩定的路由模式
  • 內容與 UI 程式碼分離

這也是目前網站刻意採用內容優先結構的原因。

這與 EmDash 本身的關係

EmDash 官方資料強調執行階段集合、後台編輯、外掛能力、媒體儲存與雲端可移植性。這些都是產品優勢,但面向公眾的生態網站不需要一開始就全部導入。

靜態網站是對外呈現層。

當你出現以下需求時,再導入完整 EmDash 執行階段作為下一層:

  • 非技術編輯者在瀏覽器中工作
  • 需要驗證身分的投稿流程
  • 執行階段媒體管理
  • 更完整的自動化或外掛提交流程

編輯實務準則

每一頁都應清楚回答以下至少一個問題:

  • EmDash 是什麼?
  • 為什麼不是 WordPress?
  • 這個外掛或模板在做什麼?
  • 我要如何遷移?
  • 我要如何部署?
  • 為什麼現在值得採用?

若一個頁面無法把其中一個問題講清楚,通常表示它的範圍需要再收斂。