背景

用了这么久的 Logseq 和 Hugo 博客，笔记越攒越多。Hugo 博客里有二十多篇文章，Logseq 里更是有几十上百页的技术笔记，但问题是——这些东西虽然都在，用的时候却很难快速找到。

比如我想知道"之前是怎么配 Syncthing 的"，得去 Logseq 里翻半天，再去 Hugo 博客里看一遍旧文章，两边内容还可能有冲突。

说白了，我的笔记系统有个根本性问题：写的时候很爽，用的时候找不到。

后来看到了 Andrej Karpathy（前特斯拉 AI 总监、OpenAI 联合创始人）分享的一个模式，叫做 LLM Wiki。看完觉得这思路很适合我，于是实践了一下，把现有的 Hugo 博客文章和 Logseq 笔记整理成了一个结构化的 Wiki。

这篇就来分享一下整个整理的方法和方案。

为什么不用传统笔记管理方式

我之前其实试过几种方式：

  1. 纯靠 Logseq 搜索——关键词能搜到，但搜出来的结果往往很散，一个知识点分布在好几条笔记里，每次看都要重新拼凑
  2. 建一堆目录分类——技术/运维/开发/AI 这样分，但很多内容跨领域，比如 Docker 既是技术又是运维工具，放哪儿都不对
  3. Obsidian + 标签——标签系统灵活是灵活，但标签多了之后跟没分一样，#docker 下面挂了 50 个完全不相关的笔记

核心问题是：传统笔记系统是"存储导向"的，我需要什么再去翻。而 LLM Wiki 的思路是"知识导向"——先把知识提炼出来，整理成结构化的页面，之后不管谁（人或 AI）来问，都能直接给出答案。

什么是 LLM Wiki

简单说，LLM Wiki 就是一个纯 Markdown 文件组成的知识库，没有数据库，没有特殊软件，就是一个文件夹里的 .md 文件。

但它跟普通笔记有几个关键区别：

  1. 分层结构——原始素材和提炼后的知识分开存放
  2. 实体和概念分离——“Docker 是什么”（实体）和"容器化的设计思想"（概念）是两种不同类型的页面
  3. 强制交叉引用——每个页面必须用 [[wikilink]] 链接到至少 2 个其他页面
  4. 不可变原始素材——导入的笔记原文不动，提炼出的知识写在另外的页面里
  5. 操作日志——每次整理都记录到 log.md，方便追溯

整体架构

最终我的 Wiki 目录长这样：

hermes-wiki/
├── SCHEMA.md           # 结构规范、标签体系、整理规则
├── index.md            # 内容目录，所有页面一页索引
├── log.md              # 操作日志，记录了所有整理动作
├── raw/                # 第一层：原始素材（只读）
│   ├── articles/       # 从 Hugo 博客、Logseq 导入的文章
│   └── ...
├── entities/           # 第二层：实体页面（工具、产品、服务）
├── concepts/           # 第二层：概念页面（技术思想、方法论）
├── comparisons/        # 第二层：对比分析
└── queries/            # 第二层：有价值的问答记录

这里最关键的设计是三层分离：

  • 第一层（raw/）——导入的原始素材，只读不改。从 Hugo 博客导出的文章、从 Logseq 导出的笔记，原封不动放在这里
  • 第二层（entities/、concepts/ 等）——AI 提炼后的知识页面，这才是 Wiki 的核心内容
  • 第三层（SCHEMA.md）——规则文件，定义了整个 Wiki 的结构、标签体系、页面创建门槛

为什么要把原始素材和提炼知识分开？因为原始笔记往往包含大量个人化的、时效性的内容（比如"今天试了这个不行，明天再试试那个"），而 Wiki 页面要的是提炼后的、可复用的知识。分开存放后，原始笔记作为参考源存在，Wiki 页面可以独立更新而不受原始素材干扰。

SCHEMA.md——规则先行

在开始整理之前，先写了一个 SCHEMA.md，相当于给 Wiki 立规矩。这个文件非常重要，决定了后续所有整理的一致性。

我的 SCHEMA.md 里定义了几个关键规则：

标签体系

不能随便打标签，所有标签必须来自预设的分类：

- AI/ML: model, architecture, training, fine-tuning, inference, agent, rag
- Infrastructure: linux, docker, networking, storage, nas, proxy, dns, ssh
- Development: tools, devops, ci-cd, api, database, monitoring, logging
- Security: auth, encryption, vulnerability, hardening
- Platforms: cloud, self-hosted, saas, open-source
- Personal: home-lab, blog, automation, workflow
- Meta: comparison, timeline, tutorial, troubleshooting, review

如果需要新标签，必须先在 SCHEMA.md 里注册，才能使用。这样防止标签泛滥。

页面创建门槛

不是看到什么都要建一个新页面，有明确门槛：

  • 出现在 2+ 个素材中 或者 是某个素材的核心主题，才创建页面
  • 一笔带过的内容不创建页面
  • 页面超过 200 行就考虑拆分
  • 被完全替代的内容移到 _archive/ 目录

页面格式规范

每个 Wiki 页面必须有 YAML frontmatter：

---
title: Docker
created: 2026-04-20
updated: 2026-04-20
type: entity
tags: [docker, infrastructure, self-hosted]
sources: [raw/articles/hugo-docker-docker.md]
---

这个 frontmatter 不是为了好看，而是为了后续可以做过期检测——如果某个页面的 updated 时间远早于最新相关素材的时间，就说明这个页面可能过时了，需要更新。

整理步骤——从素材到知识库

第一步：扫描现有素材

先看看手里有什么。我的来源主要有两个：

  1. Hugo 博客——content/posts/ 目录下有 25 篇技术文章，涵盖 Docker、Syncthing、ZeroTier、Minio、Unraid 等
  2. Logseq 笔记——pages 目录下有 83 页，包括技术笔记、读书笔记、100 天学习计划等

扫描后发现，Logseq 里有大量个人生活内容（体重记录、家庭计划等），这些不在 Wiki 的技术知识领域内，直接跳过。

第二步：筛选和复制

把相关的素材复制到 raw/articles/ 目录，加上来源前缀方便区分：

  • Hugo 博客的文章复制为 hugo-原文件名.md
  • Logseq 的笔记复制为 logseq-原文件名.md

这里有个细节：Hugo 博客的目录结构是 content/posts/docker/index.md 这种嵌套的，复制的时候我把路径扁平化了，用 - 连接各层目录名，变成 hugo-docker-docker.md。这样后续找文件更方便。

最终复制了 44 个原始素材文件。

第三步：识别实体和概念

逐个阅读素材，标记出需要建页面的内容。以我的素材为例：

实体页面（具体的工具、产品、服务）：

  • Docker —— 容器化平台
  • Syncthing —— P2P 文件同步工具
  • ZeroTier —— SDN 虚拟局域网
  • Minio —— S3 兼容对象存储
  • Unraid —— NAS 操作系统
  • Hugo —— 静态网站生成器
  • Drone —— CI/CD 平台
  • Let’s Encrypt —— 免费 SSL 证书
  • FileBrowser —— Web 文件管理器
  • CompreFace —— 面部识别服务
  • dst-admin —— 饥荒服务器管理

概念页面（技术思想、方法论）：

  • 软件架构设计
  • Linux 基础运维
  • Windows 开发环境搭建
  • WSL2 架构
  • 服务器维护
  • 间隔重复学习

第四步：合并重复内容

这是整理过程中最花时间的部分。

比如 Syncthing 这个工具，在 Hugo 博客里有一整篇专门的文章（《Syncthing 使用以及服务器搭建》），在 Logseq 里也有好几条相关笔记。如果直接按素材建页面，就会有好几个 Syncthing 页面。

正确的做法是：合并成一个实体页面，把 Hugo 博客里的服务器搭建教程和 Logseq 里的使用心得融合在一起，形成一份完整的 Syncthing 知识页面。

Docker 同理——博客里有 Docker 日常使用方案，Logseq 里有 Docker 概念笔记和 Dockerfile 使用笔记，合并成一个页面。

第五步：写 Wiki 页面

每个 Wiki 页面的结构大概是这样的：

---
title: Syncthing
created: 2026-04-20
updated: 2026-04-20
type: entity
tags: [tools, self-hosted, storage]
sources: [raw/articles/hugo-syncthing-syncthing.md, raw/articles/logseq-Syncthing.md]
---

# Syncthing

一句话介绍是什么。

## 核心特性
- P2P 模式，无中心服务器
- 局域网直连，跨网通过中继
- 开源，数据安全自己掌控

## 使用场景
- Logseq 笔记跨设备同步
- 服务器间文件同步

## 服务端搭建
简要步骤...

## 关联
- [[ZeroTier]] —— 跨网络场景下配合使用
- [[Docker]] —— 可用 Docker 方式部署
- [[unraid]] —— 可在 NAS 上运行

## 来源
- [Syncthing 使用以及服务器搭建](../raw/articles/hugo-syncthing-syncthing.md)

关键点：

  1. sources 字段指向原始素材，方便追溯
  2. 关联部分 用 [[wikilink]] 链接到其他页面，至少 2 个
  3. 内容不是素材的简单复制，而是提炼后的知识点

第六步：更新索引和日志

整理完成后，更新两个导航文件：

index.md——所有页面的一页式目录，每个页面对应一行摘要：

## Entities
- [[compre-face]] — 开源面部识别服务，由 Exadel 开发。
- [[drone]] — 基于 Docker 的 CI/CD 平台（已弃用，博客已迁移至 GitHub Actions）。
- [[docker]] — 容器化平台，用于打包应用到可移植的容器中。
...

log.md——追加本次整理的操作记录：

## [2026-04-20] ingest | Initial bulk import - Hugo blog + Logseq tech notes
- Sources: 25 Hugo blog posts + 83 Logseq pages → 44 raw sources saved
- Wiki pages created: 15
  - Entities (9): drone, dst-admin, filebrowser, hugo, letsencrypt, minio, syncthing, unraid, zerotier
  - Concepts (6): architecture-design, docker, linux-basics, server-maintenance, windows-dev-env, wsl2-arch
- Cross-references established between related pages
- Skipped: Obsidian daily_life (personal), Logseq journals (expired), Logseq personal plans

实际成果

第一次批量整理后，结果如下：

  • 原始素材：44 个文件（25 篇 Hugo 博客 + 19 篇 Logseq 技术笔记）
  • Wiki 页面：17 个（10 个实体 + 7 个概念）
  • 跳过的内容：个人生活笔记、过期的日记、放弃的个人计划
  • 交叉引用：每个页面都链接了 2+ 个相关页面

比如 Docker 页面链接了 Minio、Drone、Unraid（都用到了 Docker）；Syncthing 页面链接了 ZeroTier（跨网络同步场景）。

后续再有新素材（比如学了一个新技术、看了篇好文章），只需要：

  1. 放到 raw/articles/
  2. 看是否命中已有页面，命中了就更新，没命中且达到门槛就新建
  3. 更新 index.md 和 log.md

这样 Wiki 就会持续成长，而不是一次性整理完就放着不动了。

为什么这套方法有效

用了一段时间后，我总结出几个原因：

  1. 原始素材不动，心理压力小——不用担心改坏笔记，提炼的知识写在另一个页面里，原文随时可以参考
  2. 交叉引用自动形成知识网络——随着页面越来越多，[[wikilink]] 自然形成了一个知识图谱，相关的知识都连在一起
  3. AI 可以持续维护——这套结构纯 Markdown + 约定，AI 能很好地理解和操作。我可以把新文章丢给它，它自动分析、提炼、更新 Wiki 页面
  4. 和传统笔记不冲突——Logseq 继续日常记录，Hugo 继续写博客，Wiki 作为提炼层存在，三套系统各司其职

适用场景

这套方法最适合：

  • 已经有大量笔记（几十上百篇），但查找困难的人
  • 技术博客作者，想把历史文章结构化
  • 使用 AI 辅助研究的开发者，需要一个结构化的知识底座
  • 想把个人知识沉淀为可查询、可更新的长期资产

如果你只有几篇笔记，可能不需要这么重的方案，直接一个 Obsidian 库就够了。但当笔记量上来之后，“存"和"用"的矛盾会越来越突出，这时候就需要一套系统化的整理方法了。

总结

LLM Wiki 的核心思想其实很简单：把"存笔记"变成"写知识”。

不再是往笔记本里扔东西，而是主动提炼、组织、关联知识。原始素材作为参考源保留，提炼后的知识页面才是核心资产。配合 AI 的自动化能力，这套系统可以持续运转，越用越有价值。

目前我的 Wiki 还在早期阶段，只有 17 个页面。随着后续持续摄入新素材，它会变得越来越完善。后续可能会写一篇关于"AI 如何自动化维护 Wiki"的文章，感兴趣的朋友可以关注一下。

最后，如果你对 WSL2、Docker、本地大模型部署、以及 AI 辅助知识管理这些感兴趣，可以关注我的 B 站（UID: 483468180 - 晓若寒轻），后面还会出更多实用教程。