blogV2 为什么更该重视可持续发布：草稿预览、历史迁移和质量闸门要一起做

我现在看 blogV2 这类站点，已经不太会先问“这一版什么时候正式上线”，而是更在意它能不能稳定地持续发布。因为对内容系统来说，最容易拖垮人的从来不是第一次把站点搭起来，而是后面一篇篇补写、迁移、修订和回归时，发现所有流程都还靠记忆撑着。

所谓“可持续发布”，在我这里从来不是一句口号，而是每次准备发内容时都得重新回答几件很具体的事：

• 草稿能不能先预览但不污染公开列表
• 老文章迁移进来以后，slug 和归档会不会乱
• 只写了半篇的内容，能不能在 build 前被挡住
• 站点是不是每次都要人工翻全站，才知道哪篇不该发

只要这些问题还没被流程接住，发布次数越多，系统就越像一间不断往里塞东西、却没人持续整理的仓库。

可持续发布先解决的，不是速度，而是中间状态怎么活着

很多内容系统最容易忽略的，就是“半成品”到底放哪。真实写作几乎不可能每篇都一次成稿，但如果半成品直接进入公开入口，读者看到的就会是被污染的站点；如果系统又完全不允许半成品存在，作者的工作流会非常别扭。

所以我一直很在意草稿流，因为它解决的是中间状态能不能被系统好好收住。

草稿流不是可选体验，而是长期写作的缓冲层

我很喜欢 plugins/recent-blog-posts.js 里那条默认逻辑：draft: true 的内容不会进入公开全局数据，但本地预览可以通过 includeDrafts 开关看到。

这其实就已经是一套很像样的草稿流了：

• 内容可以先进入仓库
• 作者可以先在本地预览
• 公开站点不会把半成品提前暴露出去

这比“等完全写完再创建文件”更符合真实写作习惯。因为长期写作一定会有中间状态，可持续发布的核心不是消灭中间状态，而是让中间状态不要污染正式入口。

历史迁移不是一次性工程，而是发布链路的一部分

很多人一说发布，就只想到新文章。但 blogV2 这种站点真正麻烦的地方在于：老内容不会自己消失，它们会一直回来。

scripts/migrate-blog-posts.js 就是在处理这种现实。它不是一把“导入工具”，而是一层持续运行的整理逻辑。它不仅要把历史内容转成当前站点能读的格式，还要尽量保住：

• 标题
• 日期
• slug
• 归档来源

这件事特别关键，因为你每补一批旧文，其实都在做一次“延迟发布”。如果迁移策略不稳，站点信用不是在某次事故里一下掉光，而是在每次小补丁里一点点被磨损。

薄内容拦截，本质上是在保护发布节奏

我越来越认同一个看起来有点“严格”的做法：不要让只有几句话的内容轻易进入正式发布。

现在 tests/thin-content-remediation.test.js 已经把净正文下限设成了 500 字，这种门槛的价值不是追求整齐，而是防止站点越来越被半成品占满。

因为对作者来说，最容易欺骗自己的状态就是：

• 文件已经建了
• 标题已经想好了
• 看起来像有一篇文章

但对读者来说，它其实什么都还没交付。

我现在更愿意把发布链路看成四个连续动作

在 blogV2 里，我更希望一次正常发布至少包含这四步：

1. 创建或补写内容，允许草稿状态存在。
2. 通过迁移脚本和站内索引把内容纳入统一系统。
3. 用质量测试挡住 description、模板短语和薄内容问题。
4. 最后再 build，确认整站产物是健康的。

这四步连起来，发布才不是一次性动作，而是一个可以重复执行的日常流程。

可持续发布的关键，是让整理动作本身变成日常能力

长期内容系统最容易让人焦虑的，就是总觉得要先把所有问题一次解决掉，才能继续写。可实际操作里，真正能持续推进的往往不是“大整理”，而是让整理动作本身变成系统的一部分：

• 今天补一篇旧文
• 明天修一组 description
• 后天迁移一批历史稿
• 每次都让测试和 build 替你兜底

这样系统虽然不是瞬间变完美，但它会持续变得更稳。

我对可持续发布的理解

内容系统能不能长期写下去，关键不在于某一次上线是不是很完整，而在于反复出现的问题有没有被自动化挡住。草稿流、历史迁移、薄内容拦截和构建预检，看起来分散，其实都在做同一件事：把“靠作者记住”的部分，尽量改成“靠系统提醒”。

只有这样，发布这件事才不会越来越沉重，站点也才能真正撑得住长期写作。对我来说，可持续发布不是“发得更快”，而是“每次继续发的时候，都不用重新担心上一轮已经踩过的问题”。