microfeed：把 CMS 塞进 Cloudflare，让 AI 代理替你发内容
项目速览：在 cloudflare 上自托管的轻量级 cms，用于播客、博客、照片、视频、文档和精选 URL。
秒懂
- 它是什么？
- microfeed 是一个托管在 Cloudflare Workers、R2 与 D1 上的轻量级 CMS，支持播客、博客、图片、视频和文档。它的核心卖点是可以用本地 AI 代理通过官方 CLI 自动管理内容，但你需要先接受 AGPL 许可和 Cloudflare 平台绑定。
- 适合谁用？
- 适合愿意把内容托管在 Cloudflare 生态里的个人站长、播客作者和小型团队，尤其是那些已经熟悉 Workers、R2 和 D1 的人。如果你需要传统服务器上的完整控制，或者不想被 AGPL 约束，microfeed 并不合适。
- 能商用吗？
- 可以，但条件严格。AGPL-3.0 是网络 copyleft 许可证：如果别人通过网络使用你修改过的版本（例如作为托管服务），你必须以同一许可证向他们提供源代码。
- 还在维护吗？
- 在维护。仓库最近一次提交在 7 天前。
- 用什么语言写的？
- 主要是 TypeScript（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月18日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决的是“不想养服务器”的发布问题
自 1990 年代以来，Web 上很大一部分内容通过 feed 分发。microfeed 把这个概念搬到 Cloudflare 上，让你不需要维护虚拟机或容器，就能发布播客、博客、图片、视频、文档和外部链接。目标用户是技术上有能力自己部署，但不想碰服务器运维的人。它不是一个通用 CMS，而是围绕 feed 模型设计的，输出形式是网页、RSS 和 JSON Feed。
架构：Workers 跑代码，R2 存文件，D1 存元数据
microfeed 的运行时完全依赖 Cloudflare 的三大件：Workers 负责执行代码，R2 托管和提供媒体文件，D1 存储元数据。管理后台用邮箱加密码登录，没有额外的身份认证服务。这种设计意味着你的内容数据分散在对象存储和关系型数据库里，但用户看到的只是一个统一的网站。文档特别提到 Cloudflare 的免费额度很慷慨，个人使用几乎不花钱，但你仍然需要自己买域名。
部署：一条 npx 命令，但首次要 1.3 GB
官方推荐的快速开始方式是用本地 AI 编码代理，比如 OpenAI Codex、Claude Code 或 Cursor，给代理一句提示词：Deploy microfeed to Cloudflare. Start by running `npx @microfeed/cli manage`。这个启动器要求 Node.js 22.12 或更高版本，并且不需要 Git 或 Corepack。它会下载精确的 microfeed 版本，验证并复制到私有缓存，然后安装锁定依赖。首次设置大约占用 1.3 GB，耗时几分钟，后续运行会复用缓存。注意，它不会在当前文件夹创建源码文件，这是有意为之，避免污染你的工作目录。
内容管理：管理面板之外，还有 AI 代理入口
内置管理后台类似 WordPress，你可以创建和编辑帖子、上传媒体、调整站点外观。但更有意思的是官方 CLI `@microfeed/cli`，它允许本地 AI 代理创建、更新、删除条目，上传图片、音频、视频和文档。运行方式很简单，在任意目录执行 `npx @microfeed/cli`。如果你克隆了 microfeed 源码仓库并安装了依赖，`yarn microfeed` 是运行仓库内本地 CLI 的快捷方式。这个设计把 CMS 的管理权交给了自动化工具，适合需要批量发布或定期更新的场景。
主题与版本：不可变快照，但定制有门槛
microfeed 支持主题化发布，D1 后端保存不可变的版本快照，管理后台的草稿和预览是隔离的。你可以通过 `npx @microfeed/cli manage theme` 安装 GitHub 上的主题，或者用独立的 `@microfeed/theme-kit` 作者 CLI 来开发自己的主题。文档还提到可编辑的 `robots.txt`、`llms.txt` 和 `sitemap.xml`，这些文件是自动生成的，但你可以覆盖。对于想深度定制的人来说，主题开发需要理解 Cloudflare Workers 的部署模型，不是简单的 HTML 模板替换。
限制：平台锁定与 AGPL 许可
microfeed 只能跑在 Cloudflare 上，你不能把它迁移到 AWS 或自有服务器。虽然 Cloudflare 免费额度慷慨，但如果你超出配额，R2 的出站流量和 D1 的读写都会产生费用。另一个硬约束是 AGPL-3.0 许可，这意味着如果你修改了代码并对外提供网络服务，你有义务开源你的修改版本。对于企业内部使用可能无所谓，但如果你计划基于它构建商业产品，需要谨慎评估。文档没有提供离线部署或替代运行时，所以平台绑定是明确的。
替代方案：传统 CMS 与静态站点生成器
如果你不想绑定 Cloudflare，WordPress 依然是功能最全的替代品，它运行在你自己的服务器上，插件生态庞大，但你需要处理 PHP、数据库和安全更新。另一个方向是静态站点生成器，比如 Hugo 或 Jekyll，它们输出纯 HTML，可以托管在任何地方，但没有内置管理后台，内容更新需要重新构建。microfeed 的独特之处在于它把动态管理能力和静态分发的简单性结合在一起，代价是你必须接受 Cloudflare 作为唯一运行时。
维护成本：版本更新与依赖管理
microfeed 的发布节奏看起来比较活跃，最近几个版本集中在远程主题工作流、免克隆部署和 Webhook 自动化上。这意味着你需要定期拉取新版本，否则会错过功能修复和安全更新。CLI 启动器会缓存精确的发布版本，但升级路径没有在 README 中详细说明。如果你使用本地 AI 代理部署，每次升级可能都要重新运行 `npx @microfeed/cli manage`，并验证部署结果。考虑到 AGPL 许可，如果你修改了源码，维护分支的成本会更高。
编辑结论
适合愿意把内容托管在 Cloudflare 生态里的个人站长、播客作者和小型团队，尤其是那些已经熟悉 Workers、R2 和 D1 的人。如果你需要传统服务器上的完整控制，或者不想被 AGPL 约束，microfeed 并不合适。在采用前，先确认你的 Cloudflare 账户能承受 1.3 GB 的首次部署缓存，并仔细阅读 AGPL 条款，特别是如果你计划修改源码并对外提供服务。另外，CLI 依赖 Node.js 22.12 以上版本，本地环境需要提前准备。
社区笔记