我为什么放弃传统博客，转向 Runtime Knowledge System

我越来越不想把自己的站点叫作“博客”。

不是因为博客这个词过时，而是因为传统博客默认的系统边界已经不够用了。传统博客关心的是：

Markdown
↓
HTML
↓
页面

但我真正需要的是：

知识对象
↓
投影
↓
阅读空间
↓
关系网络
↓
运行时状态

这两者不是同一种东西。

一篇文章不只是一个文件。一本书不只是一个 PDF。一个视觉素材不只是一个图片路径。它们都应该是可以被阅读、搜索、关联、标注、继续生长的对象。

所以这篇不是“好用工具推荐合集”。那种文章已经太多了。真正有价值的是：我为什么从传统博客一路踩坑，最后走向 Runtime Knowledge System。

为什么传统博客越来越不够用

传统博客的核心假设很简单：

内容是文章
文章是 Markdown
站点是构建结果
搜索是静态索引

这个模型在早期很好。写几篇文章，生成几个页面，RSS 和搜索能跑，部署到服务器，就够了。

但当内容系统开始变复杂，它会暴露出几个根本问题。

第一，Markdown 只是文件，不是对象。

传统博客把 Markdown 当成文章源码，但我的知识库里不只有文章。还有书籍、PDF、视觉素材、项目记录、维护笔记、史料、代码片段、阅读高亮、未完成草稿。这些东西都有元数据、状态、关系和使用场景。把它们全塞进 posts，只会让系统越来越脏。

第二，写作空间和发布空间会互相污染。

Obsidian 里的 Vault 是认知空间，里面应该有草稿、碎片、私有笔记、附件、双链和临时结构。公开站点是发布空间，它必须有明确边界。如果直接把 Vault 当博客源，最后一定会混进不该公开的内容。

第三，静态索引不是知识系统。

Pagefind 这类静态搜索非常适合构建期页面，但它并不知道你的对象关系、阅读状态、Graph、书籍进度、视觉素材聚类。它可以是一个搜索投影，但不能成为整个知识系统的 authority。

第四，构建期系统很难表达运行时状态。

我需要的是：

• 阅读位置
• 高亮和批注
• Drawer Reader
• 书籍目录
• Runtime Feed
• Graph
• OpenList 文件层
• 视觉素材索引
• 后台元数据
• 多端同步

这些东西不是 npm run build 能全部解决的。它们需要 runtime。

所以传统博客的问题不是“不够炫”，而是系统模型太窄。

Obsidian 为什么会成为事实写作真源

我最后还是把 Obsidian 放在写作真源的位置。

不是因为它适合直接发布，而是因为它适合长期写作。

Obsidian 的真正价值在这里：

• 文件是本地 Markdown，寿命足够长
• Vault 可以完整迁移，不被某个服务绑死
• [wikilink](#wikilink) 能自然表达知识之间的关系
• Graph 不是装饰，而是知识对象之间的导航方式
• 插件生态足够强
• local-first，写作时不依赖远端服务

官方入口：https://obsidian.md

但这里必须说清楚：Obsidian 是认知空间，不是发布系统。

它里面可以有混乱、草稿、私人内容、附件和半成品。网站不应该直接读取整个 Vault。成熟架构应该是：

Obsidian Vault
↓
Normalize
↓
Runtime MarkdownObject
↓
Public Projection

这一步是我从“博客”走向“知识系统”的关键。

Quartz 为什么会火

Quartz 不能只理解成静态博客生成器。

它真正厉害的地方是：它把 Obsidian Vault 投影成一个可浏览的网站。

我更愿意把 Quartz 理解成：

Vault Projection Engine

它解决的不是“怎么写博客主题”，而是：

• wikilink 怎么变成网页链接
• backlink 怎么生成
• folder 和 tag 怎么投影成页面
• Graph 怎么渲染
• Markdown 怎么经过统一 transform pipeline
• 私有内容和公开内容怎么区分

项目地址：https://github.com/jackyzha0/quartz

这也是为什么 Quartz 在 Obsidian 发布领域会火。它抓住了一个本质问题：写作真源和展示站点之间必须有一层 projection。

为什么我没有直接用 Quartz

我没有直接把站点换成 Quartz。

原因不是 Quartz 不好，而是我的系统目标已经超过了“发布一个数字花园”。

Quartz 更偏 publish：

Vault
↓
Static Site

而我需要的是：

Vault
↓
Runtime Projection
↓
Feed / Reader / Drawer / Search / Graph / Books / Visuals

我需要的不只是页面，而是运行时对象。

例如一篇文章进入站点之后，它不应该只生成一个 HTML。它还要进入首页 Feed、Reader Drawer、Knowledge Graph、RSS、搜索索引、分类和标签页面。一本书也不应该只是文件链接，它要有目录、正文、阅读位置、高亮和关联节点。

Quartz 的思想我会吸收，尤其是 Markdown pipeline、wikilink、backlink 和 graph projection。但我不想把整个前台交给 Quartz，因为我的前台已经变成了一个更复杂的 Runtime Shell。

这也是我最终选择：

Obsidian
↓
Runtime MarkdownObject
↓
Astro Presentation Shell

而不是：

Obsidian
↓
Quartz Site

Headless CMS 为什么崛起

Headless CMS 的本质不是“一个更好看的后台”。

它真正代表的是一个架构分层：

Content Authority
≠
Presentation Layer

传统 CMS 把内容、后台、模板、数据库和页面绑在一起。Headless CMS 则把内容变成 API 或对象模型，让前台只负责展示。

这正好契合知识系统的需求。因为我的站点不应该让 Astro 组件直接变成内容真源。前台应该是只读投影，真正的写作和元数据管理应该在更清晰的 authority 层。

几个项目值得重点看，但不要把它们写成工具清单。

Directus 的重点是数据库对象系统。它可以把 SQL 数据库直接变成 API、后台和权限控制面。对我来说，它适合管理书籍、视觉素材、文件索引和人工 metadata overlay。

Directus：https://github.com/directus/directus

Strapi 更像典型 Headless CMS 路线。它强调内容类型、媒体库、REST / GraphQL、插件生态和企业内容管理。它适合标准化内容运营，但如果个人知识系统已经高度对象化，就需要小心别把它重新做成后台表单。

Strapi：https://github.com/strapi/strapi

Payload 的价值在于 TypeScript native 和 Next.js native。它更像把 CMS 和应用后端合并成一个现代全栈框架，适合需要强类型、React 管理界面和自定义业务逻辑的项目。

Payload：https://github.com/payloadcms/payload

这些项目共同说明了一件事：内容系统已经不再只是 Markdown 文件夹。真正重要的是 authority、权限、对象模型、API 和运行时投影。

Astro 在我的系统里扮演什么角色

Astro 仍然非常适合做展示层。

它的优势很明确：内容型网站性能好，默认 HTML 输出干净，React islands 可以只在需要交互的地方激活，构建产物也容易部署。

Astro：https://astro.build

但 Astro 不应该被误用成全部真源。

我现在给 Astro 的定位是：

Presentation Shell

它负责页面、布局、视觉系统、静态构建和少量 islands。它不负责成为所有对象的最终 authority。

文章来自 Runtime MarkdownObject。书籍来自 OpenList live/index。视觉素材未来可以来自 Immich 或对象存储索引。运行时状态进入数据库。Astro 只负责把这些对象投影成可阅读、可浏览、可交互的界面。

Runtime Blog 会成为下一代个人网站吗

我越来越相信，个人网站会从“博客”变成“个人操作系统”。

不是每个人都需要这么复杂。但如果一个人的内容系统已经包含：

• 写作
• 读书
• 项目记录
• 图片和视频素材
• 史料库
• Graph
• 高亮
• 文件库
• 搜索
• 自动同步

那它就不再是一个博客主题能解决的问题。

这时需要的是 Runtime Blog，或者更准确地说：

Runtime Knowledge System

它的核心不是“动态网站”，而是“对象运行时”。

每篇文章都是 MarkdownObject。

每本书都是 BookObject。

每张图都是 VisualObject。

每条高亮都是 AnnotationObject。

每个文件都应该知道自己的来源、状态、投影位置和关系。

我现在的技术栈

我目前更认可这样的分层：

Authoring
└── Obsidian
 
Sync
└── Remotely Save / WebDAV / OpenList
 
Storage
└── Vault + OpenList + Object Storage
 
Projection
└── Runtime MarkdownObject
 
Frontend
└── Astro + React Islands
 
Search
└── Pagefind now / Meilisearch later
 
Media
└── Immich / visual runtime later
 
Metadata
└── Directus or similar Headless CMS later

这个结构最重要的不是用了哪些项目，而是每一层都知道自己是不是 authority。

Obsidian 是写作真源。

Runtime MarkdownObject 是公开文章投影真源。

Astro 是展示层。

数据库只保存运行时状态。

OpenList 是文件层，不是 CMS。

这几句话比任何工具列表都重要。

我踩过的坑

真正让我转向 Runtime Knowledge System 的，不是看了某个开源项目，而是踩坑。

我踩过的坑包括：

第一，双 authority。

一套内容在 Astro posts，一套内容在 runtime index。两个地方都能决定文章是否存在，最后系统会变得不可理解。

第二，fake runtime。

页面看起来是动态的，但真正决定内容存在性的仍然是构建期 artifact。这种“看起来 runtime，实际 build-time”的系统最容易误导维护者。

第三，兼容层复活。

有些东西名义上 deprecated，但只要还有组件引用，它就会重新变成事实真源。

第四，watcher upload 幻觉。

监听文件变化不等于发布系统。没有 normalize、过滤、权限边界和 projection contract，watcher 只是一个更危险的复制器。

第五，overlay explosion。

Drawer、Command、Reader、Graph、Search 都各写一套 runtime，最后会出现状态分裂。真正成熟的系统要收束 runtime authority，而不是不断加新层。

第六，工具名词替代架构判断。

Quartz、Directus、Strapi、Payload、Astro 都很好，但它们不能替你决定系统边界。真正的问题永远是：谁是写作真源？谁是公开投影？谁是运行时状态？谁只是缓存？

最后

我放弃的不是博客写作。

我放弃的是传统博客那个过窄的系统模型。

我仍然需要文章、RSS、搜索和页面。但我更需要一个能容纳文章、书籍、视觉素材、项目、史料、Graph 和阅读状态的知识运行时。

所以我现在真正想做的，不是一个更漂亮的博客。

而是一套：

Runtime Knowledge System

它从 Obsidian 开始，但不止于 Obsidian。

它借鉴 Quartz，但不止于发布。

它会接入 Headless CMS，但不退回后台表单。

它使用 Astro，但不让 Astro 冒充全部真源。

这才是我这次重构真正想要的方向。