为什么我先把这个博客放到 Cloudflare 上

很多人看见一个博客项目，第一反应是先找个最顺手的平台上线，能发文就行。这个思路不算错，但不适合我现在这条线。

我需要的不是一个“能写文章”的地方，而是一块以后可以继续叠工具、叠工作流、叠自动化的地基。这个站后面要接 AI、接内容分发、接素材管理、接 Obsidian、甚至接我自己正在跑的品牌和工具业务。要是底层一开始就分裂，后面每往上堆一层，都会多一层摩擦。

我看重的不是便宜，是同一套运行环境

Cloudflare 这套东西吸引我的地方，不是单点能力，而是它能把站点、数据库、对象存储和边缘运行放到一条线上。博客正文在 D1，图片在 R2，前台和接口跑在 Workers，后面如果要接 AI 能力，也不用再换一套完全不同的部署语境。

这个统一性很重要。因为我做的事情不是单一内容站。一边是聆花文化这种偏品牌、偏产品、偏交付的业务；另一边是英语市场上的 AI 工具站，偏效率、偏系统、偏增长。它们表面上差很远，但对我来说，本质上都在争同一件事：能不能把一个想法迅速变成可验证的线上系统。

博客不是内容孤岛，它要能长出工具

如果博客只是发文，那 Vercel、静态站、传统 CMS 都能做。但我现在更在意的是，文章会不会继续变成别的东西。

一篇文章后面可能衍生出：

• 一套 AI 摘要和标签生成逻辑
• 一套封面图和配图工作流
• 一个 Obsidian 发布入口
• 一条同步到不同渠道的分发链路
• 一组和我业务主题强相关的内部知识库

这些东西如果全靠外部插件和碎片服务拼，短期能跑，长期会越来越脏。Cloudflare 不是万能药，但它足够像一块可以继续往上焊接的钢板。

对我来说，部署速度本身就是生产力

还有一个很现实的原因：我做站，不喜欢把大量时间耗在平台特有的限制和运维噪音上。我需要的是一个改完就能发、发完就能验证、验证完还能继续往业务里回灌的循环。

Cloudflare 这套路线，至少在这个阶段，足够符合这个要求。站点、数据、资源、AI 能力都在同一条链上，后面我要做文章智能处理、内容检索、工作流触发，顺手就能往里塞。

所以把博客先放到 Cloudflare，不是“为了部署而部署”。说白了，是为了给后面的内容系统和工具系统留出空间。博客只是第一层壳，真正重要的是它后面能长出什么。