原文：LLM Wiki
作者：Andrej Karpathy
翻译与扩展：AI 辅助翻译 + Hugo 实践补充
这是一个关于如何使用 LLM 代理（如 OpenAI Codex、Claude Code、OpenCode / Pi 等）构建个人知识库的模式文档。它的目标是传达高层次的理念，而具体实现将由你和你的代理协作完成。
大多数人与 LLM 和文档打交道的体验类似于 RAG：你上传一系列文件，LLM 在查询时检索相关片段并生成答案。这确实有效，但问题在于 LLM 每次都要从头开始重新发现知识，没有积累。如果你问一个需要综合五份文档的微妙问题，LLM 必须每次都找到并拼凑相关片段，没有任何东西被沉淀下来。NotebookLM、ChatGPT 文件上传和大多数 RAG 系统都是这样工作的。
这里的理念不同。与其仅在查询时从原始文档中检索，LLM 增量式地构建和维护一个持久的 Wiki —— 一个结构化的、相互链接的 Markdown 文件集合，位于你和原始资料之间。当你添加新资料时，LLM 不只是为了后续检索而索引它。它会阅读资料、提取关键信息，并将其整合到现有 Wiki 中 —— 更新实体页面、修订主题摘要、标记新数据与旧论断的矛盾之处，强化或挑战不断演进的综合结论。知识被编译一次，然后保持最新，而不是每次查询都重新推导。
这是关键区别：Wiki 是一个持久的、复利式的产物。 交叉引用已经存在，矛盾已经被标记，综合已经反映了你读过的所有内容。随着每份资料的添加和每个问题的提出，Wiki 变得越来越丰富。
你永远不会（或很少）亲自编写 Wiki —— LLM 编写和维护所有内容。你负责筛选资料、探索和提出正确的问题。LLM 做所有繁重的工作 —— 总结、交叉引用、归档和记账，这些都是让知识库随时间真正有用的工作。实践中，我通常在一侧打开 LLM 代理，在另一侧打开 Obsidian。LLM 根据我们的对话进行编辑，我实时浏览结果 —— 跟随链接、查看图谱视图、阅读更新的页面。Obsidian 是 IDE；LLM 是程序员；Wiki 是代码库。
用一个比喻来理解：
前者是"即时检索"，后者是"持续积累"。前者回答完问题后对话记录就消失了，后者把每次对话的价值沉淀为可复用的知识资产。
用户提问 → 向量检索相关片段 → LLM 基于片段生成答案 → 答案输出 → 对话结束
RAG 的局限性：
原始资料 → LLM 阅读并提取 → 更新/创建 Wiki 页面 → 交叉引用 → 索引更新
↓
用户提问 → LLM 查询 Wiki 索引 → 阅读相关页面 → 综合答案 → 答案可归档回 Wiki
LLM Wiki 的优势：
| 维度 | RAG | LLM Wiki |
|---|---|---|
| 知识状态 | 无状态，每次重建 | 有状态，持续积累 |
| 信息组织 | 扁平的向量片段 | 结构化的页面网络 |
| 交叉引用 | 依赖检索算法 | 显式的链接关系 |
| 矛盾检测 | 无法自动发现 | 主动标记和解决 |
| 知识复利 | 零积累 | 持续增长 |
| 查询深度 | 受限于上下文窗口 | 可分层深入 |
| 可审计性 | 黑盒检索 | 透明的页面历史 |
RAG 更适合：
LLM Wiki 更适合：
定义：你精心策划的来源文档集合。文章、论文、图片、数据文件。这些是不可变的 —— LLM 从中读取但从不修改。这是你的真理之源。
管理原则：
目录结构建议：
raw/
├── papers/ # 学术论文
│ ├── 2024-attention-is-all-you-need.pdf
│ └── 2023-llm-survey.pdf
├── articles/ # 网络文章、博客
│ ├── karpathy-llm-wiki.md
│ └── some-tech-blog-post.md
├── books/ # 书籍章节或读书笔记
│ ├── clean-code/
│ │ ├── ch1-clean-code.md
│ │ └── ch2-meaningful-names.md
├── images/ # 图片资源
│ └── diagram-2024-01.png
├── data/ # 数据文件
│ └── experiment-results.csv
└── meeting-notes/ # 会议记录
└── 2024-01-15-arch-review.md
Hugo 的实践经验：
我最初把所有资料都丢进一个
raw/目录，结果三个月后根本找不到东西。后来按"来源类型 + 日期"组织，配合log.md记录每次摄取，效率提升很多。关键是一致性 —— 一旦确定命名规范，就要严格执行。
定义：一个由 LLM 生成的 Markdown 文件目录。摘要、实体页面、概念页面、比较、概览、综合。LLM 完全拥有这一层。它创建页面、在新资料到达时更新它们、维护交叉引用、并保持一切一致。你阅读它；LLM 编写它。
页面类型体系：
| 页面类型 | 用途 | 示例 |
|---|---|---|
| 实体页面 | 描述具体的人、组织、工具、项目 | "OpenAI", "Claude Code", "Kubernetes" |
| 概念页面 | 解释抽象概念、模式、原理 | "RAG", "增量学习", "知识复利" |
| 来源摘要 | 单份资料的结构化摘要 | "《Attention Is All You Need》摘要" |
| 比较页面 | 对比多个实体或方案 | "RAG vs LLM Wiki" |
| 综合页面 | 跨多来源的主题综述 | "LLM 应用架构模式综述" |
| 操作指南 | 步骤化的操作流程 | "如何设置新的 Wiki 项目" |
| 日志/时间线 | 按时间记录事件 | "项目演进日志" |
| 索引 | 内容目录和导航 | "主索引", "概念索引" |
页面结构规范：
每个 Wiki 页面建议包含以下部分：
# 页面标题
> 来源：[来源链接或标识]
> 创建日期：YYYY-MM-DD
> 最后更新：YYYY-MM-DD
> 标签：#概念 #LLM #架构
## 定义/概述
（简明扼要的核心定义，2-3 句话）
## 详细说明
（主体内容，可包含多个章节）
## 相关概念
- [相关概念A](/concepts/concept-a)
- [相关概念B](/concepts/concept-b)
## 来源引用
1. [来源1](raw/papers/paper1.pdf) - 关键发现摘要
2. [来源2](raw/articles/article1.md) - 相关观点
## 变更记录
- 2024-01-15: 初始创建
- 2024-02-01: 补充新资料《XXX》的观点
交叉引用机制：
交叉引用是 Wiki 的核心价值所在。它让知识形成网络而非孤岛。
Hugo 的踩坑记录：
早期我让 LLM 自由发挥页面结构，结果有的页面有 YAML frontmatter，有的没有；有的用 H1 标题，有的直接从 H2 开始。后来在
CLAUDE.md中强制规定了页面模板，一致性大幅提升。Obsidian 的图谱视图也因此变得更清晰 —— 结构化的页面更容易形成有意义的连接。
定义：一个文档（例如 Claude Code 的 CLAUDE.md 或 Codex 的 AGENTS.md），告诉 LLM Wiki 如何结构化、惯例是什么，以及在摄取资料、回答问题或维护 Wiki 时要遵循什么工作流程。这是关键的配置文件 —— 它让 LLM 成为一个有纪律的 Wiki 维护者，而不是一个普通的聊天机器人。你和 LLM 会随时间共同演化这个文档，因为你们会摸索出适合你领域的最佳实践。
模式文档的核心内容：
模式文档示例框架：
# Wiki 维护模式
## 目录结构
- `raw/` - 原始资料（只读）
- `wiki/` - Wiki 页面（LLM 维护）
- `index.md` - 内容索引
- `log.md` - 操作日志
## 页面类型
### 实体页面
...
### 概念页面
...
## 操作流程
### 摄取流程
1. 阅读原始资料
2. 识别关键实体和概念
3. 更新或创建对应页面
4. 更新索引
5. 记录日志
### 查询流程
1. 阅读索引找到相关页面
2. 深入阅读相关页面
3. 综合答案
4. （可选）将答案归档为新页面
## 质量标准
- 每个论断必须有来源引用
- 页面之间必须保持交叉引用
- 发现矛盾时必须标记并尝试解决
演化模式文档的技巧：
你将新资料放入原始集合并告诉 LLM 处理它。一个示例流程：
详细步骤：
Step 1: 用户将资料放入 raw/ 目录
↓
Step 2: 用户告知 LLM "请处理 raw/articles/new-article.md"
↓
Step 3: LLM 阅读资料，提取关键信息
- 识别核心论点
- 提取关键实体和概念
- 标记与现有 Wiki 的关联和潜在矛盾
↓
Step 4: LLM 与用户讨论关键要点（可选但推荐）
- 确认理解是否正确
- 询问用户希望强调什么
- 讨论与现有知识的关系
↓
Step 5: LLM 更新 Wiki
- 创建/更新来源摘要页面
- 更新相关实体页面
- 更新相关概念页面
- 创建新的实体/概念页面（如有必要）
- 更新索引
- 追加日志条目
↓
Step 6: 用户审查更新
- 浏览更新的页面
- 检查交叉引用
- 确认质量
单份资料可能涉及 10-15 个 Wiki 页面。
Hugo 的个人偏好：
就我个人而言，我更喜欢一次一份地摄取资料并保持参与 —— 我阅读摘要、检查更新，并指导 LLM 强调什么。但你也可以批量摄取多份资料，减少监督。这取决于你开发适合你风格的工作流程，并在模式中记录下来供将来参考。
我试过批量摄取 5 篇论文，结果 LLM 遗漏了不少交叉引用，后期整理成本反而更高。对于重要资料，逐份摄取 + 即时审查 是更好的策略。
你针对 Wiki 提出问题。LLM 搜索相关页面，阅读它们，并综合一个带引用的答案。
查询流程详解：
Step 1: 用户提出问题
"对比 RAG 和 LLM Wiki 在知识积累方面的差异"
↓
Step 2: LLM 查询索引
- 在 index.md 中查找 "RAG"、"LLM Wiki"、"知识积累" 相关条目
- 识别相关页面列表
↓
Step 3: LLM 深入阅读
- 逐一阅读相关 Wiki 页面
- 提取关键信息
- 注意页面间的矛盾和补充
↓
Step 4: LLM 综合答案
- 结构化组织信息
- 添加引用标注（链接到 Wiki 页面）
- 根据问题类型选择输出格式
↓
Step 5: （关键步骤）答案归档
- 如果答案有价值，归档为新页面
- 更新索引
- 追加日志
答案可以采取的形式：
重要洞察：好的答案可以作为新页面归档回 Wiki。 你要求的比较、分析、发现的联系 —— 这些都是有价值的，不应该消失在聊天记录中。这样，你的探索也会像摄取的资料一样在知识库中产生复利。
Hugo 的实践案例：
有一次我询问 LLM "对比微服务和服务化架构的区别"，它给出了一个很棒的对比分析。我让它把这个答案保存为
wiki/comparisons/microservices-vs-service-oriented.md，后来多次引用这个页面，还基于它扩展出了"架构选型决策树"页面。这就是知识复利 —— 一次探索，持续受益。
定期让 LLM 健康检查 Wiki。这是保持 Wiki 长期可用性的关键步骤，也是最容易被忽视的。
整理检查清单：
| 检查项 | 说明 | 处理策略 |
|---|---|---|
| 页面矛盾 | 不同页面对同一事实的表述冲突 | 标记矛盾，根据最新资料或可信度决定采用哪个版本 |
| 陈旧论断 | 新资料已取代的旧观点 | 更新页面，在变更记录中注明原因 |
| 孤立页面 | 没有入站链接的页面 | 检查是否应删除，或在相关页面中添加引用 |
| 缺失页面 | 提到但缺乏自己页面的重要概念 | 创建新页面，建立双向链接 |
| 断链 | 指向不存在的页面的链接 | 修复链接或创建目标页面 |
| 缺失交叉引用 | 相关页面之间没有链接 | 添加适当的交叉引用 |
| 数据缺口 | 可以通过网络搜索填补的空白 | 建议搜索方向，或创建待办标记 |
| 重复页面 | 内容高度相似的多个页面 | 合并或明确区分各自的侧重点 |
| 索引同步 | 索引与实际页面不一致 | 更新索引，确保完整性 |
整理频率建议：
Hugo 的整理经验：
我设置了一个月度提醒，让 LLM 执行"Wiki 健康检查"。它会生成一份报告，列出所有发现的问题。我只需要审查报告并确认处理方案。通常一次整理能发现 5-10 个小问题，及时处理避免了 Wiki 的"技术债务"积累。
最有价值的发现往往是"矛盾标记" —— 当两份资料对同一问题给出不同答案时，LLM 会标记出来。这促使我深入思考，往往能产生新的洞察。
作用：它是 Wiki 中所有内容的目录 —— 每页都列有链接、一行摘要，以及可选的元数据如日期或来源数量。按类别（实体、概念、来源等）组织。
LLM 在每次摄取时更新它。回答查询时，LLM 先阅读索引找到相关页面，然后深入阅读。
在适度规模（约 100 份来源，数百个页面）下这出奇地有效，避免了基于嵌入的 RAG 基础设施的需求。
索引结构建议：
# Wiki 索引
## 实体
| 页面 | 摘要 | 来源数 | 最后更新 |
|------|------|--------|----------|
| [OpenAI](/entities/openai) | AI 研究与部署公司，GPT 系列模型开发者 | 12 | 2024-03 |
| [Claude Code](/entities/claude-code) | Anthropic 的编程助手工具 | 5 | 2024-02 |
## 概念
| 页面 | 摘要 | 关联页面数 | 最后更新 |
|------|------|-----------|----------|
| [RAG](/concepts/rag) | 检索增强生成，LLM 查询时动态检索相关文档 | 8 | 2024-01 |
| [LLM Wiki](/concepts/llm-wiki) | 使用 LLM 增量维护持久知识库的模式 | 15 | 2024-03 |
## 来源摘要
| 页面 | 来源 | 类型 | 日期 |
|------|------|------|------|
| [Karpathy LLM Wiki](/sources/karpathy-llm-wiki) | Gist | 模式文档 | 2024-01 |
## 比较
| 页面 | 对比对象 | 日期 |
|------|----------|------|
| [RAG vs LLM Wiki](/comparisons/rag-vs-llm-wiki) | RAG, LLM Wiki | 2024-02 |
索引维护原则：
作用：它是一个只追加的记录，记录发生了什么以及何时发生 —— 摄取、查询、整理。
格式规范：
# Wiki 操作日志
## [2024-03-15] 摄取 | 《Attention Is All You Need》
- 来源：raw/papers/attention-is-all-you-need.pdf
- 创建页面：
- [Transformer](/concepts/transformer) - 新页面
- [Self-Attention](/concepts/self-attention) - 新页面
- 更新页面：
- [LLM 架构](/concepts/llm-architecture) - 补充 Transformer 部分
- 发现矛盾：与 [RNN](/concepts/rnn) 页面的"序列建模"描述有冲突，已标记
## [2024-03-14] 查询 | "对比 RAG 和微调"
- 问题：对比 RAG 和微调在领域适配方面的差异
- 使用页面：[RAG](/concepts/rag), [Fine-tuning](/concepts/fine-tuning), [领域适配](/concepts/domain-adaptation)
- 输出：Markdown 对比文档
- 归档：[RAG vs Fine-tuning](/comparisons/rag-vs-fine-tuning)
## [2024-03-10] 整理 | 月度健康检查
- 发现孤立页面：3 个（已处理）
- 发现矛盾：2 处（已标记待解决）
- 更新索引：补充 5 个新页面
有用技巧：如果每个条目都以一致的前缀开头（例如 ## [2026-04-02] 摄取 | 文章标题），日志就可以用简单的 Unix 工具解析：
# 获取最后 5 个条目
grep "^## \\[" log.md | tail -5
# 统计本月摄取次数
grep "^## \\[`date +%Y-%m`" log.md | grep "摄取" | wc -l
# 查找所有整理记录
grep "整理" log.md
日志的价值：
目标：追踪你自己的目标、健康、心理、自我提升 —— 归档日记条目、文章、播客笔记，并随时间建立一个关于你自己的结构化图景。
Wiki 结构示例：
wiki/
├── self/
│ ├── goals/ # 目标追踪
│ │ ├── 2024-goals.md
│ │ └── quarterly-reviews/
│ ├── health/ # 健康记录
│ │ ├── sleep-tracking.md
│ │ └── workout-log.md
│ ├── learning/ # 学习进度
│ │ ├── current-focus.md
│ │ └── completed-courses.md
│ └── reflections/ # 定期反思
│ ├── monthly-reviews/
│ └── annual-reviews/
关键实践：
raw/，LLM 定期整理进结构化页面目标：在数周或数月内深入研究一个主题 —— 阅读论文、文章、报告，并增量式地建立一个包含演进论点的综合 Wiki。
Wiki 结构示例：
wiki/
├── research/
│ ├── llm-reliability/ # 研究主题
│ │ ├── overview.md # 研究综述
│ │ ├── key-papers.md # 关键论文列表
│ │ ├── methodologies/ # 方法论对比
│ │ ├── findings/ # 研究发现
│ │ └── open-questions.md # 待解决问题
│ └── experiments/ # 实验记录
│ ├── exp-2024-01/
│ └── exp-2024-02/
关键实践：
目标：边读边归档每一章，为人物、主题、情节线索建立页面，以及它们如何连接。到最后你会拥有一个丰富的伴读 Wiki。
Wiki 结构示例：
wiki/
├── books/
│ ├── clean-code/
│ │ ├── overview.md
│ │ ├── chapters/ # 每章摘要
│ │ ├── concepts/ # 书中概念
│ │ ├── quotes.md # 精彩引用
│ │ └── action-items.md # 实践清单
Hugo 的读书 Wiki 经验：
想想像 Tolkien Gateway 这样的粉丝 Wiki —— 数千个相互链接的页面，涵盖人物、地点、事件、语言，由志愿者社区多年共建。你也可以在阅读时个人构建类似的东西，由 LLM 完成所有的交叉引用和维护工作。
我读《Clean Code》时，每章都让 LLM 提取关键概念并更新 Wiki。读完时，我不仅有了完整的读书笔记，还有一个"代码质量"概念网络，后来读其他技术书籍时直接复用和扩展。
目标：由 LLM 维护的内部 Wiki，由 Slack 线程、会议纪要、项目文档、客户电话提供内容。可能有人类参与审查更新。Wiki 保持最新，因为 LLM 做了团队中没人愿意做的维护工作。
Wiki 结构示例：
wiki/
├── team/
│ ├── projects/ # 项目文档
│ │ ├── project-alpha/
│ │ └── project-beta/
│ ├── decisions/ # 决策记录 (ADR)
│ ├── meetings/ # 会议纪要
│ ├── processes/ # 流程文档
│ └── people/ # 团队成员、职责
关键实践：
raw/，LLM 提取决策、行动项并更新相关页面目标：持续追踪竞争对手的产品、策略、动态，形成结构化的竞争情报。
Wiki 结构示例：
wiki/
├── competitive/
│ ├── competitors/ # 竞争对手档案
│ │ ├── competitor-a.md
│ │ └── competitor-b.md
│ ├── market-trends/ # 市场趋势
│ ├── product-comparisons/ # 产品对比
│ └── strategy-analysis/ # 策略分析
目标：在投资或合作前，系统性收集和分析目标公司的信息。
关键实践：
目标：收集目的地信息、行程规划、预算管理，形成可复用的旅行知识库。
Wiki 结构示例：
wiki/
├── travel/
│ ├── destinations/ # 目的地档案
│ ├── itineraries/ # 行程模板
│ ├── budgets/ # 预算参考
│ └── tips/ # 实用技巧
目标：系统化整理课程学习内容，便于复习和知识迁移。
关键实践：
目标：对特定爱好（如摄影、烹饪、乐器）建立深度知识库。
Hugo 的案例：
我用 LLM Wiki 管理我的摄影学习。每次看教程、读文章、分析照片，都让 LLM 更新 Wiki。现在我有完整的"曝光三角"、"构图法则"、"后期处理流程"知识体系，还有我拍过的照片的"问题诊断"记录。这比散落在 YouTube 收藏夹和笔记本里的碎片知识有用得多。
Obsidian 是 LLM Wiki 模式的理想载体：
[[页面名]] 语法让交叉引用变得自然Obsidian 配置建议：
设置 → 文件和链接：
- 新笔记的存放位置：指定文件夹（如 wiki/）
- 附件文件夹路径：raw/assets/
- 自动使用 Wikilink：开启（[[页面名]] 格式）
- 新建笔记的模板：选择页面模板
问题：随着 Wiki 增长，索引文件可能不够高效，需要适当的搜索能力。
解决方案：qmd 是一个本地 Markdown 文件搜索引擎，具有混合 BM25/向量搜索和 LLM 重排序，完全在设备上运行。
特点：
Hugo 的搜索方案演进：
我最初用简单的
grep和索引文件，在约 200 个页面时开始感到吃力。切换到 qmd 后，搜索质量明显提升，特别是语义搜索能找到"相关但用词不同"的内容。对于更大的 Wiki（1000+ 页面），可能需要考虑更专业的方案，如 Elasticsearch 或向量数据库。
Obsidian Web Clipper 是一个浏览器扩展，可以将网页文章转换为 Markdown。对于快速将来源放入你的原始集合非常有用。
使用流程：
raw/articles/）配合快捷键下载图片：
在 Obsidian 设置 → 文件和链接中，将"附件文件夹路径"设为固定目录（例如 raw/assets/）。然后在设置 → 快捷键中，搜索"下载"找到"为当前文件下载附件"并绑定一个快捷键（例如 Ctrl+Shift+D）。剪辑文章后，按下快捷键，所有图片都会下载到本地磁盘。
这是可选但有用的 —— 它让 LLM 可以直接查看和引用图片，而不是依赖可能失效的 URL。
注意：LLM 不能原生地在一次传递中阅读带内联图片的 Markdown —— 解决方法是让 LLM 先阅读文本，然后单独查看部分或全部引用的图片以获得额外上下文。有点笨拙但足够好用。
Marp 是一个基于 Markdown 的幻灯片格式。Obsidian 有它的插件。对于直接从 Wiki 内容生成演示文稿很有用。
使用场景：
示例：
---
marp: true
theme: default
---
# RAG vs LLM Wiki
## 知识积累对比
| 维度 | RAG | LLM Wiki |
|------|-----|----------|
| 状态 | 无状态 | 有状态 |
| 组织 | 扁平片段 | 结构化页面 |
| 复利 | 零 | 持续增长 |
---
## 选择建议
- **临时查询** → RAG
- **长期研究** → LLM Wiki
Dataview 是一个 Obsidian 插件，可以在页面前置元数据上运行查询。如果你的 LLM 为 Wiki 页面添加 YAML 前置元数据（标签、日期、来源数量），Dataview 可以生成动态表格和列表。
示例查询：
TABLE source-count as "来源数", last-update as "最后更新"
FROM "concepts"
WHERE tag = "LLM"
SORT source-count DESC
前置元数据建议：
---
type: concept
tag: LLM, architecture
source-count: 12
last-update: 2024-03-15
created: 2024-01-10
---
# 概念标题
...
Wiki 只是一个 Markdown 文件的 Git 仓库。你免费获得了版本历史、分支和协作功能。
Git 在 Wiki 中的价值：
Git 工作流建议：
# 每日工作流
git add .
git commit -m "2024-03-15: 摄取《Attention Is All You Need》"
git push origin main
# 查看某页面的历史
git log --oneline -- wiki/concepts/transformer.md
# 对比版本差异
git diff HEAD~5 -- wiki/concepts/transformer.md
| 工具 | 用途 | 备注 |
|---|---|---|
| Excalidraw | 手绘风格图表 | Obsidian 插件，适合快速画架构图 |
| Mermaid | 文本生成图表 | 直接在 Markdown 中写流程图、时序图 |
| Templater | 自动化模板 | Obsidian 插件，自动插入日期、创建页面结构 |
| Periodic Notes | 周期性笔记 | 自动化创建日/周/月/年笔记 |
| Readwise | 阅读高亮同步 | 自动将电子书高亮同步到 Obsidian |
不要试图一次性建立完美的 Wiki。 从一个主题、一份资料开始，让 Wiki 随时间自然生长。
Hugo 的建议：
我的第一个 Wiki 只有 5 个页面，覆盖我读的一篇论文。三个月后它增长到 200+ 页面，覆盖了我研究领域的核心概念。关键是持续投入，不是完美规划。
LLM 很强大，但你的判断和方向感不可替代。
参与方式：
一致的命名让 Wiki 可预测、可维护。
命名建议：
llm-wiki-pattern.md）X-vs-Y 格式（如 rag-vs-llm-wiki.md）YYYY-MM-DD）即使使用 Git，也要确保远程仓库是可靠的。考虑：
Obsidian 的图谱视图是查看 Wiki 形状的最佳方式 —— 什么连接到什么，哪些是枢纽页面，哪些是孤立页面。
图谱分析技巧：
raw/assets/ 或类似目录YYYYMMDD-description.png 格式对于超长文档（如整本书、长篇报告）：
不要只是"浏览 Wiki"，而是带着具体问题来查询。
好问题 vs 坏问题：
| 坏问题 | 好问题 |
|---|---|
| "告诉我关于 RAG 的一切" | "RAG 在哪些场景下比微调更适合？" |
| "总结这篇论文" | "这篇论文的方法与 [之前读过的论文] 有什么本质区别？" |
| "列出所有概念" | "哪些概念是理解 Transformer 所必需的？" |
好问题能激发 LLM 进行深度综合，产生有价值的答案。
不要让好的答案消失在聊天记录中。
每次产生有价值的分析、对比、洞察时：
这样，一次深入探索可以产生长期价值。
模式文档不是一成不变的。 随着 Wiki 成长，你会发现新的需求和更好的做法。
回顾周期：
维护知识库的繁琐部分不是阅读或思考 —— 而是记账工作。更新交叉引用、保持摘要最新、标记新数据何时与旧论断矛盾、维护数十个页面的一致性。人类放弃 Wiki 是因为维护负担增长得比价值快。LLM 不会感到无聊，不会忘记更新交叉引用，可以在一次传递中处理 15 个文件。Wiki 保持维护是因为维护成本接近零。
人类的工作：筛选资料、指导分析、提出好问题，并思考这一切意味着什么。
LLM 的工作：其他一切。
传统学习方式：
读资料 A → 理解 → （遗忘）
读资料 B → 理解 → （遗忘）
读资料 C → 理解 → （遗忘）
LLM Wiki 方式：
读资料 A → 提取 → 更新 Wiki → 知识沉淀
读资料 B → 提取 → 更新 Wiki → 与 A 的知识关联 → 知识网络扩大
读资料 C → 提取 → 更新 Wiki → 与 A、B 的知识关联 → 综合洞察产生
每一次摄取都在增强整个知识库，而不是仅仅增加一条孤立的信息。
人类维护 Wiki 时：
LLM 维护 Wiki 时：
| 规模 | 人类维护 | LLM 维护 |
|---|---|---|
| 10 个页面 | 轻松 | 轻松 |
| 100 个页面 | 吃力 | 轻松 |
| 1000 个页面 | 几乎不可能 | 可行 |
| 10000 个页面 | 不可能 | 可能需要专业工具 |
Hugo 的观察：
我的 Wiki 在约 300 页面时遇到了第一个"整理瓶颈" —— 人工检查所有页面已经不现实。让 LLM 执行自动化健康检查后，问题迎刃而解。现在约 800 页面，仍然管理得很好。我估计在 2000+ 页面时可能需要引入更专业的搜索和索引工具，但核心模式依然有效。
这个想法在精神上与 Vannevar Bush 的 Memex（1945） 相关 —— 一个个人的、精心策划的知识存储，文档之间有联想路径。
Bush 在 1945 年的文章《As We May Think》中描述了 Memex：
"一种设备，个人可以在其中存储他所有的书籍、记录和通信，且可以以极高的速度和灵活性进行查询。"
Memex 的核心特征：
Bush 的愿景更接近 LLM Wiki，而不是后来网络变成的样子：私人的、积极策划的，文档之间的连接与文档本身一样有价值。
他没能解决的部分是谁来做维护工作。LLM 处理了这个问题。
| 时代 | 代表 | 特点 | 维护成本 |
|---|---|---|---|
| 1945 | Memex（概念） | 联想式个人知识库 | 高（概念阶段） |
| 1960s | 超文本系统 | 链接式文档 | 高 |
| 1990s | World Wide Web | 全球超文本 | 中（个人站点） |
| 2000s | Wikipedia | 协作式 Wiki | 中（社区维护） |
| 2010s | 个人 Wiki / 笔记工具 | 个人知识管理 | 高（纯人工） |
| 2020s | LLM Wiki | AI 辅助维护 | 低 |
短期（1-2 年）：
中期（3-5 年）：
长期（5-10 年）：
Hugo 的预测：
我认为 LLM Wiki 模式会在 3-5 年内成为知识工作者的标准实践。就像现在没人用手写记账一样，未来维护个人知识库也不会是纯人工的。关键是谁先建立高质量的知识资产，谁就能在信息时代获得复利优势。
如果你想立即尝试 LLM Wiki 模式，以下是 15 分钟快速开始指南：
my-wiki/
├── raw/ # 原始资料
│ └── articles/ # 文章
├── wiki/ # Wiki 页面
├── index.md # 索引
├── log.md # 日志
└── CLAUDE.md # 模式文档（或 AGENTS.md）
在 CLAUDE.md 中写入：
# Wiki 维护模式
## 结构
- `raw/`：原始资料，LLM 只读
- `wiki/`：Wiki 页面，LLM 维护
- `index.md`：内容索引
- `log.md`：操作日志
## 页面模板
每个页面包含：
- 标题（H1）
- 来源引用
- 内容主体
- 相关页面链接
- 变更记录
## 操作流程
1. 摄取：阅读资料 → 提取信息 → 更新 Wiki → 更新索引 → 记录日志
2. 查询：阅读索引 → 深入阅读 → 综合答案 → （可选）归档
3. 整理：检查矛盾、孤立页面、缺失链接
raw/articles/恭喜你，你已经启动了你的第一个 LLM Wiki！
问题：LLM 倾向于为每个小概念都创建新页面，导致 Wiki 碎片化。
解决：在模式文档中明确标准：
问题：LLM 需要阅读大量页面才能回答查询。
解决：
问题：LLM 提取的信息与原文不符。
解决：
问题：不同资料对同一问题给出不同答案。
解决：
问题：LLM 移动或重命名页面后，链接断裂。
解决：
问题：Wiki 中可能包含敏感信息（日记、商业机密）。
解决：
问题：Wiki 太大，LLM 无法一次加载所有内容。
解决：
问题：多个人同时维护 Wiki，产生编辑冲突。
解决：
问题：已经有大量笔记，如何转为 LLM Wiki 模式？
解决：
raw/ 中的资料问题：频繁调用 LLM 维护 Wiki 成本较高。
解决：
本文档有意保持抽象。它描述的是理念，而非具体实现。确切的目录结构、模式惯例、页面格式、工具 —— 所有这些都取决于你的领域、你的偏好和你选择的 LLM。上面提到的所有内容都是可选和模块化的 —— 挑选有用的，忽略无用的。
例如：
正确的使用方式是与你的 LLM 代理分享本文档，共同协作实例化一个适合你需求的版本。 本文档的唯一工作就是传达这个模式。你的 LLM 可以想出其余的一切。
最后的话：知识管理的核心不是工具，而是持续投入的习惯。LLM Wiki 模式降低了维护成本，让你能把精力集中在真正重要的事情上 —— 思考、提问、理解。开始你的 Wiki 吧，让它随时间生长为你独一无二的知识资产。