流程设计的核心原则是：写的时候不要碰到发布相关的任何东西。一旦写作过程中需要想“文件放哪、格式对不对、要不要提交”，思路就断了。

三个阶段

1. 草稿：只求快

在笔记软件里建一个 blog/ 目录，想到什么写什么。允许长句、允许 TODO、允许只有三行。

这个阶段的产物没有任何格式要求，双链、标签、随手贴的截图都可以。

2. 成稿：迁移到博客仓库

准备发布时，把内容复制到 src/content/blog/<slug>.md，补齐 frontmatter：

---
title: '标题'
description: '摘要'
pubDate: '2026-10-07'
tags: ['workflow']
---

这一步主要做三件事：换掉双链语法、把图片挪进仓库、把口语化的段落改掉。

3. 发布：本地验证后推送

npm run build    # 构建通过 = 没有语法/链接错误
git add -A && git commit -m "post: 文章标题"
git push

推送后 CI 自动构建发布，大约一分钟。失败的话在 Cloudflare 的构建日志里能直接看到报错行。

为什么不在线写

在线的所见即所得编辑器，写作体验其实很好。问题在两处：

• 版本控制：改错了想回退到三天前的版本，编辑器通常只能给一个模糊的“历史记录”；
• 格式归属：排版和内容耦合在同一个编辑器里，换工具等于重排。

Markdown + Git 的组合谈不上优雅，但十年后它一定还读得出来。

一点经验

让发布的阻力尽可能小，让修改的阻力尽可能大。

具体来说：npm run dev 开着热更新，改完立刻看到效果；但真正发布必须手动 git push 一次。这样既不会因为流程繁琐而放弃写字，也不会因为太容易而反复折腾样式。