一篇文章是怎么发出去的

博客搭好了、部署通了、服务器配好了，剩下的就是往里面填内容了。这一章讲的是现在写文章的完整流程——从打开编辑器到读者看到更新。

写

编辑器用的 Typora。文章格式是 MDX——Markdown 的超集，可以在文章里嵌入 React 组件（比如下载卡片、代码高亮这些），但日常写作跟写普通 Markdown 没有区别。

文件直接放在项目的 content/ 目录里，每个合集一个文件夹，每篇文章一个 .mdx 文件。想开一个新合集，建个目录、写一个 _meta.json 配置文件就行。

写作体验比之前好太多了。之前要打开浏览器、登后台、在网页编辑器里写，还不如 Typora 的所见即所得体验好。现在就是打开一个本地文件，写完保存，跟写笔记一样。

贴图

写文章免不了贴图。之前用完整前后端架构的时候，有个自建图床 API：粘贴截图 → 前端调 API → 后端存文件 → 返回 URL。后端砍掉之后这条路不通了。

现在的方案是 SFTP 直传：Typora 里粘贴截图的时候，触发一个自定义脚本。脚本做的事情很简单——把图片文件通过 SSH 传到服务器的 /data/blog-uploads/ 目录，文件名用 UUID 避免冲突，然后把公网可访问的 URL（https://yustia.com/uploads/2026/08/xxx.png）返回给 Typora，自动插入到文章里。

整个过程不到两秒，体验上就是粘贴 → 图片出现在文章里，跟有后端 API 的时候一样顺畅。区别是中间没有后端了，直接走 SSH。

封面

每个合集有一张封面图。这些封面是用 AI 画的——GPT Image 2，效果挺好。

画法大致是：先想好封面要表达什么（合集的主题、情绪），然后写一段 prompt 描述画面内容和风格，让 AI 生成。通常要调几轮——构图不满意就重新描述，细节不对就补充说明。

生成的原图（PNG，通常好几 MB）存在 assets/raw-images/ 目录里作为归档。发布之前跑一个优化脚本（npm run optimize-images），把 PNG 转成 WebP 格式，限宽 1600px，质量 82——肉眼看不出跟原图的差异，但文件大小能从几 MB 压到几十 KB。优化后的 WebP 文件输出到 public/images/，这才是最终部署到服务器上的版本。

原图留在仓库里，但不会被部署上去——Dockerfile 只复制 out/ 目录（构建产物），assets/ 不在里面。本地和 git 有归档，线上只有压缩后的小文件。

SVG 格式的图（比如架构图）不需要转换，直接放在 public/images/ 里就行。

发

写完、图片贴好、封面做完，剩下的就是发布了。

git add .
git commit -m "feat: 新文章标题"
git push

push 到 master 之后 CI/CD 自动接管：构建静态站点 → 打包镜像 → 传到服务器 → 重启容器。几分钟后读者就能看到更新。

整个链路是：Typora 写内容 → 图片 SFTP 传服务器 → git push → GitHub Actions 自动构建部署。中间没有后台、没有数据库、没有手动操作服务器。

以前改一篇文章的流程是：开浏览器 → 登后台 → 找到那篇文章 → 在网页编辑器里改 → 点保存 → 等接口返回。现在是：打开文件 → 改 → 保存 → git push。步骤少了一半，体验好了不止一倍。