给个人网站建立一套可持续写作的 MDX 内容系统
从目录、frontmatter 到渲染链路，讲清楚为什么 MDX 是教程型个人网站的合适底座。
Tutorial Path
从 0 搭建一个可持续写作的 Next.js 个人网站
当前位置：05 / 10
把“内容可持续写作”这件事真正变成工程能力。
一个教程型网站最大的生产成本，不是初次搭建，而是后续每一次更新。如果每发一篇内容都要改数组、改 mock、改路由、改页面判断，写作成本会越来越高。所以内容系统的目标不是“支持写 Markdown”这么简单，而是把写作动作标准化。
为什么这里选择 MDX
我喜欢 MDX 的原因很直接：它既保留了 Markdown 的低门槛，又允许你在必要的时候插入组件化表达。对于教程类内容来说，这非常关键，因为我们经常需要提示块、卡片链接、流程提示、对照区块。全用纯 Markdown 不够灵活，全用 JSX 又会让写作成本变高。
MDX 刚好在中间：默认还是写文章，只有在表达真的受限时，才引入组件。
frontmatter 负责“找得到”，正文负责“读得懂”
我会把内容信息分成两层。frontmatter 负责标题、描述、日期、更新时间、分类、标签这些结构化元数据。正文负责真正要表达的内容、例子和步骤。
这种分层很重要，因为搜索、列表、RSS、SEO、分类页，几乎都依赖 frontmatter；而文章是否值得读，则取决于正文质量。把两者混在一起，会让系统越来越难维护。
一套可持续内容系统至少要有这些约束
- 目录清晰：
content/blog、content/projects、content/notes各司其职。 - 文件命名稳定：博客使用
YYYY-MM-DD-slug.mdx，项目和笔记使用稳定 slug。 - frontmatter 有 schema：缺字段要尽早报错。
- 分类和标签有统一配置，不允许随手乱写。
- 渲染层有白名单组件，而不是任由内容随意扩展。
这些约束不是为了增加门槛，而是为了把系统的复杂度前置控制住。
能用普通 Markdown 表达的地方，就不要急着用 MDX 组件。组件应该留给真正能提高可读性和可复用性的结构，而不是为了“看起来更高级”。
这套内容系统未来能支持什么
当 MDX 内容系统真正落地后，你就能自然地往上叠很多能力：分类聚合、标签规范化、搜索、分页、RSS、动态分享图、后台编辑、发布检查。它们都不是独立存在的功能，而是建立在“内容已经有标准结构”这件事之上的附加收益。
小结
内容系统不是附属能力，而是教程型个人网站最核心的地基之一。没有它，网站只是静态页面集合；有了它，网站才开始具备持续写作的可能。下一篇我们会从“系统能写”继续走到“读者能用”：首页、列表页和详情页应该怎样串成一个完整体验。