内容系统最容易被讨论成工具信仰：Notion 快，MDX 可控，CMS 完整。可独立开发者真正要解决的，通常不是“哪种系统更先进”，而是当前站点到底卡在什么阶段。如果你还没有稳定写出第一批文章，企业级后台只会拖慢开始；如果内容已经开始影响导航、产品目录和搜索，纯笔记又会显得太松；如果多人协作和权限真的出现，文件系统也可能开始吃力。
先问当前摩擦，不要先问工具立场
我在 MakePlans 的公共博客里越来越明显地感受到这点。现在内容源在 content/posts/*.mdx，配一个轻量解析器，frontmatter 参与站点数据，正文由 ArticleBody 按文章协议渲染。它不是最完整的内容平台，但正好解决当前阶段最重要的问题：文章、分类、产品导航和工程上下文需要在同一个仓库里被稳定维护。
如果只从工具偏好出发，很容易把系统做错阶段。太早上 CMS，会先背上字段、预览、权限、同步和后台维护成本；一直停在 Notion，又会在公开站点需要稳定 slug、分类、版本记录时开始补各种约束。
阶段错了，工具再好也会变成负担。
Notion 适合让内容先长出来
在验证期，Notion 的价值很现实。它足够快，编辑阻力小，适合搭选题池、写初稿、收集片段，也适合放那些还没成形的判断。对个人项目来说，这很重要，因为很多内容计划会死在“系统还没想好，所以一直没开始写”。
但 Notion 的强项也是它公开发布时的弱项。它允许结构自由，可公开站点往往需要稳定 frontmatter、明确 slug、固定 category、可追踪变更历史，以及和产品页面一起进入版本管理。到了这个阶段，Notion 不是不能用，而是你会不断给它补约束。
对 MakePlans 来说，Notion 更适合前台之前
MakePlans 当前要解决的不是单篇文章能不能写出来，而是整批内容能否被读取、校验、归档、搜索和展示。Notion 仍然适合放草稿、资料和发散判断，但不适合作为公开博客唯一 source of truth。
它解决的是“先写出来”，不是“长期可维护地发布出去”。
当内容和站点结构绑定时，MDX 价值会上升
MDX 对我最重要的不是“开发者友好”这个标签，而是它让内容和站点结构处在同一个工程语境里。文章文件就在仓库中，标题、摘要、分类、deck 和正文都能和页面、测试、构建一起被审视。
这对 serious personal product blog 很关键。内容不再只是装饰，它会参与首页排序、主题页、RSS、搜索和产品叙事。文章如果和工程完全分离，就很容易出现“写作里说一套，项目里做一套”。
轻量 MDX 的好处，是逼内容先清楚
当前这套 MDX 并不重。它没有急着引入复杂组件，也没有把正文变成半个可视化编辑器。相反，它要求文章遵守清楚的结构：intro paragraph、## section、### 小节、callout、代码块。
这种限制不是弱点。它让内容判断先于后台建设，也让渲染系统更容易保持干净。对当前阶段来说，比“内容系统很高级”更重要的是“每篇文章都能稳定进入公共阅读结构”。
CMS 适合真实组织复杂度，而不是提前消费规模感
CMS 有明确价值。只要内容类型开始分化，角色开始变多，草稿、审核、排期、权限、资产管理、多语言这些问题都真实出现，CMS 就能显著降低混乱。
问题是很多个人项目会在还没有这些问题时，先把 CMS 当成未来感的象征。结果不是工作流更成熟，而是先给自己背上一套字段模型、预览链路、同步逻辑和后台维护成本。复杂度没有解决生产问题，只是在提前消费规模幻想。
到 CMS 阶段通常有两个信号
第一，内容数量和类型已经多到手工维护 frontmatter、slug 和目录结构会持续出错。
第二，参与内容的人不止作者自己，而且不同角色对发布流程有明确分工。
这两个信号没出现时，CMS 很可能不是解法，而是新的注意力黑洞。
最终不是三选一，而是分层使用
Notion、MDX、CMS 并不是互相否定的三条路。更合理的关系是：Notion 负责前置思考和资料收集，MDX 负责当前公开发布层，CMS 等组织复杂度真的出现后再接管协作。
对 MakePlans 当前状态来说，MDX 是最合适的公开层，因为它足够轻，也足够稳定，还能直接和分类体系、产品目录、搜索、RSS、发布检查和工程上下文咬合。
工具选择本质上是在选择维护边界
选 Notion，是承认现在最需要速度和发散；选 MDX，是承认内容已经成为站点结构的一部分；选 CMS，是承认协作和内容模型复杂度已经超过个人文件维护。
所以我现在不再问“哪个工具最好”，而是先问站点处在哪个阶段。阶段判断对了，工具会变轻；阶段判断错了，工具越完整，系统越重。