从一间小书房开始：设计这套博客系统的初衷

很多个人项目开始于一个技术问题：我能不能把它做出来？这套博客的起点却更简单——我能不能拥有一个愿意长期回来写字的地方？

页面是否足够漂亮、框架是否足够新，当然重要。但如果每次发布都要重新熟悉流程，如果修改旧文章令人紧张，如果系统隔一段时间就需要大修，那么注意力迟早会从写作转移到维护。设计这套博客时，我最先考虑的不是功能清单，而是如何让这种消耗尽量少一些。

为什么没有停在现成平台

现成的内容平台已经能完成绝大多数事情：编辑、上传、发布、统计，甚至自动分发。自己做一套系统，并不是因为它们不够好，而是我想保留几项很具体的自主权。

文章应该拥有稳定的地址，内容应该能以 Markdown 导出，页面结构不必追随平台改版，公开阅读也不应该被后台产品的复杂度牵着走。更重要的是，我希望系统可以按照自己的写作习惯缓慢调整，而不是反过来训练我适应某个产品。

我真正想拥有的，不只是一组页面，而是一种可以持续很多年的写作关系。

让后台顺着写作发生

后台首先是一张可以放心落笔的桌子，然后才是管理系统。围绕这个判断，许多看似普通的细节获得了优先级：

• 草稿自动保存，减少对意外丢失的担心；
• 真实预览尽量接近公开页面，让排版问题在发布前出现；
• 每次重要修改留下版本快照，旧文章因此可以被大胆重写；
• 图片作为独立资产管理，不让正文被上传流程打断；
• 发布、撤回和归档拥有清楚的状态，不依赖模糊的操作习惯。

这些功能没有哪一项令人惊讶。它们的价值在于共同降低心理负担：打开后台时，不需要先处理系统，只需要继续上次没有写完的句子。

把阅读和管理分成两条路

系统结构上最重要的决定，是把公开博客与内容后台分开。Blog Worker 只负责展示已经发布的内容；CMS Worker 负责写入、版本、媒体和状态变化；Cloudflare Access 则守在管理入口之前。

这样做不是为了画出更复杂的架构图，而是为了让边界更容易理解。公开流量无法顺手触碰管理能力，后台的变化也不必把展示层一起拖动。每个部分只承担少量明确的责任，出问题时更容易知道应该看哪里。

选择 Cloudflare，是为了少照看一些

Workers、D1 和 R2 并不是这套博客的主题，它们只是恰好组成了一组维护负担较低的基础设施：请求在 Workers 中处理，文章和版本保存在 D1，图片进入 R2，内部读取通过 Service Binding 完成。

我不想为个人博客长期维护一台服务器，也不想把数据库升级、证书续期和进程守护变成固定日程。托管服务当然仍有边界，但它把更多时间还给了写作。对个人系统而言，少一个必须时刻记住的部件，往往比多一项能力更有价值。

给未来留下出口

长期使用并不意味着永远不更换技术。相反，真正面向长期的设计应该允许离开。

正文保存为 Markdown，媒体保持普通文件形态，核心数据关系足够简单，公开页面也不依赖只有当前框架才能理解的内容格式。哪一天需要迁移，理想状态不是重新开始，而是把已经积累的文章带走，再选择下一种实现。

这也是为什么我刻意克制功能范围。协同审核、复杂权限、插件市场都可以让系统看起来更完整，却不是一个人写作所必需的。没有真实需求的能力，会提前收取未来的维护费用。

博客最终会长成使用者的样子

上线只是这套系统第一次可以被使用，而不是设计结束。真正重要的变化会发生在日常里：哪一个按钮总是多余，哪一种预览不够准确，哪些旧文章开始通过标签彼此连接。

我希望它以后仍然保持小而清楚。需要新能力时认真增加，不再需要时坦然删除。系统不必证明自己多么先进，只要在想写东西的时候可靠地出现，在文字完成之后安静地退开。

如果它最终能让我少犹豫一次、少丢失一个念头、多完成几篇真正想写的文章，那么设计它的初衷就已经实现了。