从 Markdown 到网页，一条足够短的发布链路

一个个人博客可以从很简单的结构开始：一组 Markdown 文件、一层内容读取逻辑，以及负责排版的页面。

本文是发布流程的设计示例，不代表已经部署到生产环境。

让内容独立存在

将文章放在独立目录，文件名作为稳定的地址。主题组件不进入文章正文，这样修改视觉设计时就不需要逐篇调整内容。

content/
  posts/
    markdown-publishing-workflow.md
  notes/
    keep-the-question.md
src/
  app/
  components/
  lib/content.ts

内容读取层只负责读文件、校验字段和筛选草稿；页面负责把结果展示出来。这条边界比提前拆成多个仓库更重要。

在发布前发现问题

标题、日期、摘要和标签应该在构建时校验。出现格式错误时，构建明确失败，比上线之后才发现文章列表缺了一项更容易处理。

草稿也需要统一过滤。除了首页，它还可能出现在归档、标签页、RSS 和站点地图中。让所有页面使用同一份已发布内容集合，可以减少遗漏。

把预览当作一次校对

一篇文章写完后，至少看一下手机宽度下的标题、长代码块和表格。编辑器里的排版与真正的阅读页面并不完全相同。

可以按照这个顺序检查：

1. 标题和摘要是否准确表达主题。
2. 图片有没有说明文字，链接是否指向正确的位置。
3. 代码块在窄屏下是否可以横向滚动。
4. 示例、推测与实际验证的结果是否区分清楚。

保持发布过程可重复

将 Git 仓库接入 Vercel 后，可以使用分支预览检查改动，再通过生产分支发布。正式域名需要写入站点配置，以便生成正确的订阅和分享地址。

有关部署的具体行为，以 Vercel 的 Git 部署文档 为准。后续扩展交互内容时，可以参考 Next.js 的 Markdown 与 MDX 文档。

发布流程越短，记录一件小事的心理成本就越低。