使用指南
将此站点作为 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？
- 这个插件或模板做什么？
- 我该如何迁移？
- 我该如何部署？
- 为什么现在值得采用？
如果页面无法把其中一个问题讲透，通常说明它的范围需要进一步收敛。