使用指南
將此網站作為 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
這個分區應持續呈現網站與產品的動態:
- 發佈說明
- 遷移指南
- 產品觀點
- 教學文章
- 案例研究
這是讓網站保持活躍並持續累積價值的關鍵。
發佈工作流程
對此專案而言,最精簡且穩定的流程是:
- 在
docs/新增或修改內容 - 檢查 Git diff
- 本地預覽
- 將建置後的靜態網站部署到 Cloudflare Pages
當 AI 參與草稿撰寫、編修、重構與一致性校對時,這套流程特別有效。
為什麼這種結構適合與 AI 協作
當網站以以下原則為核心時,AI 編修會更可靠:
- 小而清晰的 MDX 檔案
- 明確的 frontmatter
- 可重用頁面元件
- 穩定的路由模式
- 內容與 UI 程式碼分離
這也是目前網站刻意採用內容優先結構的原因。
這與 EmDash 本身的關係
EmDash 官方資料強調執行階段集合、後台編輯、外掛能力、媒體儲存與雲端可移植性。這些都是產品優勢,但面向公眾的生態網站不需要一開始就全部導入。
靜態網站是對外呈現層。
當你出現以下需求時,再導入完整 EmDash 執行階段作為下一層:
- 非技術編輯者在瀏覽器中工作
- 需要驗證身分的投稿流程
- 執行階段媒體管理
- 更完整的自動化或外掛提交流程
編輯實務準則
每一頁都應清楚回答以下至少一個問題:
- EmDash 是什麼?
- 為什麼不是 WordPress?
- 這個外掛或模板在做什麼?
- 我要如何遷移?
- 我要如何部署?
- 為什麼現在值得採用?
若一個頁面無法把其中一個問題講清楚,通常表示它的範圍需要再收斂。