轻量 MDX 的价值，不在于省事，而在于不提前许错承诺
很多人讨论内容系统时，第一反应都是工具栈：要不要上 CMS，要不要可视化后台，要不要块级编辑器，要不要专门的内容数据库。可对一个仍在快速调整站点结构的个人项目来说，真正稀缺的通常不是这些能力，而是持续更新的节奏、稳定的栏目边界，以及一套不会把人拖进基础设施黑洞的工作方式。也就是说，内容系统最容易犯的错，不是太简单，而是太早把未来所有可能的问题都当成现在的问题。
我现在更愿意从轻量 MDX 开始，就是因为它不会假装这些问题已经到了必须解决的阶段。文章、frontmatter、版本历史、改动记录和发布链路都在同一套仓库里，意味着我可以先把“内容怎么长出来”这件事跑顺，再决定哪些地方真的值得升级。相比之下，重型内容栈的危险在于，它会让人产生一种很强的工程满足感：字段很完整、后台很漂亮、流程很像团队协作，但内容本身还没有形成稳定节奏。
当前这个站点，为什么更适合 `content/posts/*.mdx`
在 MakePlans 当前的公共博客层里，内容并不是孤立存在的。它要同时服务文章列表、详情页、topic 页面、RSS、搜索，以及首页和 about 页里的阅读路径。如果我一开始就把内容拆进一套更重的后台系统，我反而会更难看清这些页面到底共享什么。现在这套方式更直接：content/posts/*.mdx 负责内容源，src/content/public-site.ts 负责聚合、校验、映射与派生，页面层只消费已经整理好的结构。
这种设计的好处，不只是“文件好管理”，而是责任边界很清楚。内容文件回答的是“写了什么”；内容聚合层回答的是“哪些信息要给列表、详情、搜索和 topic 路由”；页面层回答的是“怎么呈现”。一旦你把这些层分开，很多原本会被误以为需要 CMS 才能解决的问题，其实都可以在当前阶段用更轻的方式处理。
轻量方案同样需要护栏，否则它只是另一种随便
我并不把“轻量 MDX”理解成随便写几篇文件就完事。真正让这套方案成立的，是后来补上的那些护栏：模板文件、frontmatter 必填校验、分类白名单、日期校验、正文存在性检查、下划线前缀支持文件忽略规则，以及围绕这些规则写下来的测试。换句话说，轻量并不等于松散；它只是把复杂度放到了更符合当前阶段的位置。
比如这个项目后来明确了五类主题分类，public-site.ts 会直接拒绝未知分类；_template.mdx 让新增文章时不用重复猜 frontmatter 结构；public-site-mdx-content.test.ts 会守住内容加载器的边界；RSS 和搜索也都继续吃同一份内容源。这样做的意义在于，系统不会因为没有后台就变得不可控。它只是用代码、测试和文件组织来承担本来很多人会交给 CMS 的那部分秩序。
我为什么会警惕“内容栈成就感”
对工程背景的人来说，搭系统往往比持续写内容更容易带来即时反馈。你能看到 schema 变完整、功能变多、界面变高级，于是很容易误把“基础设施越来越厉害”当成“内容系统越来越成熟”。可这两件事并不是一回事。内容系统真正成熟的标志，不是后台菜单越来越多，而是你能不能稳定地产出、分类、重写、下线、归档，并且在几个月后仍然知道哪些内容是主线、哪些内容只是阶段性材料。
我这次越往后做越确定，轻量 MDX 反而有一种健康的约束：它逼你直面内容本身。没有一个看起来很专业的后台帮你掩盖空洞，文章写得薄就是薄，分类不清就是不清，首页说不明白就是说不明白。很多问题因此会更早暴露出来，这反而是好事。因为你会被迫先修正文案、结构和阅读路径，而不是继续把问题推迟到另一个更复杂的系统里。
什么时候才真的值得升级成更重的内容平台
我并不反对未来上更重的方案，只是我认为它应该由真实压力推动，而不是由想象中的“以后可能会用到”推动。至少要同时满足几件事，升级才值得开始。第一，内容发布已经稳定到手工维护 frontmatter、目录和衍生信息真的变成负担。第二，内容类型已经复杂到当前轻量正文解析无法再清楚表达，比如确实需要大量复杂组件、富媒体模块或多人编辑流。第三，现有测试和内容聚合层已经把站点的核心模型说明白，这样迁移才不是盲迁。
在那之前，轻量 MDX 不是过渡方案，而是当前阶段更诚实的方案。它允许内容结构先站住，再决定要不要继续加系统；它让文章、测试、搜索、RSS 和页面结构围绕同一份源数据工作；它也让人不至于在“把内容系统做得像内容系统”这件事上花掉太多精力。对一个仍在重建公共博客、继续优化信息架构、还要兼顾真实产品和发布链路的项目来说，这种克制比华丽更有价值。