从 Hexo 到 LLM Wiki：我为什么重构自己的数字花园

最近我重新审视了自己的知识管理方式。

过去几年里，我把课程笔记、项目资料、网页剪藏、技术调试记录、博客文章、实验报告和一些半成品想法都堆进了同一套目录体系。刚开始这种做法很自然：一切都在一个地方，搜索起来也方便。

但时间一长，这种“都在一起”的舒服感会慢慢反过来变成摩擦。

我遇到的真实问题主要有三个：

1. 写作入口不稳定：同样是 Markdown，有的内容写在 Obsidian，有的写在 Hexo，有的又写在专题站点里。每次想重新开始写，都要先回忆“这次该写到哪里”。
2. 公开与私有边界不清：很多笔记原本只是私人记录，但后来又觉得其中一部分值得公开。只要内容本体和发布本体不是一份文件，后面维护就容易双写。
3. AI 自动化没有稳定落点：如果原始笔记、派生整理、发布站点和项目代码全混在一起，Agent 很难稳定工作。它不知道什么是事实原文，什么是整理结果，什么是站点渲染层。

我后来看到 Karpathy 提出的 LLM Knowledge Bases 思路，最大的触动不是“让 LLM 帮我写总结”，而是他把知识系统分成了几层：

• 原始来源（raw sources）
• 结构化 wiki（LLM 维护）
• schema / 约束
• 版本化演进

这让我意识到，真正应该重构的不是博客主题，而是知识流的分层。

我最终采用的结构

我把新的系统拆成四层：

• private_*：人类维护的原始私有笔记和素材
• llm_wiki：LLM 维护的派生 wiki
• public_content：公开导出内容仓
• publish_site：站点渲染与部署层

同时，对项目型内容再加一层“项目胶囊”：

• 项目代码仓独立存在
• 项目私有笔记单独沉淀
• 通过 project_manifest 把代码上下文、私有笔记和派生 wiki 绑在一起

这样做之后，我希望达到的效果是：

• 我平时只管记原始笔记
• Agent 负责整理成可检索、可引用、可发布的 wiki
• 当我决定公开时，只是把内容导出到公开层，而不是重新复制维护一份正文
• 发布站点只负责渲染，不再承担知识本体

为什么先从旧博客迁移开始

很多系统重构都容易掉进一个陷阱：先设计出完美模型，但迟迟没有第一批真实内容。

所以我决定先做两件最实际的事：

1. 把旧 Hexo 博客迁到新的公开内容仓
2. 用新的发布框架重新把它跑起来

这样一来，这次迁移本身就不只是“写了一堆架构文档”，而是立刻留下一个可以继续生长的公开知识系统。

接下来会做什么

下一步我会继续把项目笔记、专题内容和强化学习笔记逐步迁入这套结构，并把 Agent 工作流真正接进来：

• 从私有笔记到 LLM wiki 的整理
• 从 LLM wiki 到公开内容的导出
• 从公开内容到站点的自动构建与发布

如果这套系统最终跑顺了，它就不只是一个博客迁移，而是我真正开始积累自己数字资产的起点。

参考：Karpathy, LLM Knowledge Bases。