我没有把文章内容一开始就完全交给后台编辑器。原因很简单：个人博客的核心资产是文字，Markdown 文件更容易备份、迁移和审阅。

现在的流程是混合式的：

  1. 重要基础文章放在 src/content/articles；
  2. 每篇文章用 frontmatter 声明标题、日期、分类、标签、摘要和封面；
  3. npm run db:seed 会读取这些 Markdown 文件；
  4. 种子脚本按 slug 写入 SQLite；
  5. 站点运行时从数据库读取文章，用同一套互动系统计算点赞、收藏和评论数。

这样做有两个好处。

第一，内容有源文件。即使数据库出问题，Markdown 仍然在仓库里。文章不是被锁进某个后台表单里的黑盒。

第二，网站功能可以围绕数据库展开。搜索、分类、标签、RSS、Sitemap、评论、收藏和写作台都不需要分别读取文件系统，而是使用统一的数据层。

我比较喜欢这种“文件负责创作，数据库负责运行”的方式。写作时不被后台打扰，发布后又能享受动态站的能力。

当然，这种方案也有边界：如果以后要支持多人协作、复杂审批、富文本媒体库，那就应该引入更正式的 CMS。但对当前这个小站来说，Markdown + SQLite 已经足够清楚。

一个内容系统是否健康，不在于后台有多少按钮，而在于三件事：

  • 新文章能不能低成本写进去；
  • 旧文章能不能稳定地被找到；
  • 迁移时能不能不被工具绑架。

薄荷手记现在优先满足这三点。