Appearance
很多人做知识库，最后都会卡在一个现实问题：资料越存越多，真正要用的时候，还是得重新翻、重新找、重新问。问题不是存得不够多，而是你的知识库只是一个仓库，不是一个系统。
这套方法解决什么问题
普通人的做法： 收藏文章→写摘要→扔文件夹→下次翻出来用
LLM Wiki的做法： 资料进来→Agent帮你整理→更新概念页/主题页/索引页→下次提问时，Agent优先站在已经整理过的wiki层回答
区别在哪？前者是存资料，后者是编译知识。
准备工作
只需要3样东西：
- Obsidian — 本地知识库工作区
- Codex — 让Agent直接读写知识库文件
- 一个空文件夹 — 这次LLM Wiki的仓库
建议先单独建一个实验仓，比如llm-wiki-lab，不要直接拿已有的复杂仓库开刀。
8步跑通最小闭环
第一步：Obsidian打开实验仓
打开Obsidian，选择"Open folder as vault"，把llm-wiki-lab文件夹作为新vault打开。
先保持干净，只建2个顶层文件夹：
raw/ — 放原始资料（文章、网页摘录、PDF、会议纪要）
wiki/ — 放整理后的知识页（概念页、人物页、工具页、主题页）常见翻车： 很多人一上来把所有内容丢一个目录里，raw和wiki混着放，短期省事，长期必乱。
第二步：建一个最小规则文件
在仓库根目录下新建AGENTS.md，这是给Agent的工作规则，不是给人看的说明书。
最小版本：
markdown
# LLM Wiki Rules
## 目标
这个仓库用于维护一个可持续进化的知识系统。
## 目录约定
- raw/: 原始资料
- wiki/: 整理后的知识页
- AGENTS.md: 仓库根目录下的工作规则
## ingest 原则
当有新资料进入 raw/ 时：
1. 生成对应的来源页
2. 提炼关键观点
3. 更新相关的 wiki 页面
4. 增加必要的交叉链接
5. 如无对应页面，则创建新页面
## 查询原则
回答问题时，优先参考 wiki/ 中已经整理过的页面；必要时再回看 raw/。重点是让Agent知道：这个仓库不是随便记笔记的地方，而是一个有结构、有分层、有规则的系统。
第三步：往raw层放第一份资料
不要急着问Agent问题，先给它一份真正的输入。
在raw/里新建一个Markdown文件，比如：
2026-04-27-karpathy-llm-wiki.md
最小示例结构：
markdown
# 5分钟复刻Andrej Karpathy的LLM Wiki
- URL: https://example.com
- Author: xxx
- Date: 2026-04-27
## Raw Notes
- 文章核心在于把知识库从检索系统变成持续更新的wiki
- 强调raw/wiki双层+AGENTS.md规则文件的结构
- 强调先跑通ingest，再谈大规模扩展💡 经验： 第一次实验别一口气塞十篇文章，先塞一篇验证链路。
第四步：Codex执行第一次ingest
bash
cd ~/path/to/llm-wiki-lab
codex给一个具体的任务：
请读取 raw/2026-04-27-karpathy-llm-wiki.md。
基于其中内容：
1. 在 wiki/ 下创建一页来源总结页
2. 提炼关键概念
3. 如果需要，新建相关概念页
4. 为新旧页面增加交叉链接
5. 最后告诉我这次新增了哪些文件、更新了哪些文件任务越具体，第一次成功率越高。
第五步：检查Agent做了什么
重点看3件事：
| 检查项 | 说明 |
|---|---|
| 有没有生成来源页 | wiki/source-xxx.md，应包括核心观点、价值、关联 |
| 有没有生成概念页 | 提出来的高价值概念，不是孤立的摘要 |
| 有没有加交叉链接 | [[LLM Wiki]] [[Ingest Workflow]] |
如果只生成了几个页面但彼此没链接，那本质上还是在堆笔记。
第六步：第一次"基于wiki的提问"
真正的价值不在自动建页，而在于：以后提问时能不能优先站在wiki层回答。
请基于 wiki/ 中已经整理好的内容回答：
LLM Wiki 和传统 RAG 的差别到底是什么？
如果还需要补充，再回看 raw/ 里的原始资料。如果Agent的回答明显先引用了wiki页面，再去补充raw层——说明这套结构开始工作了。
第七步：把问答沉淀回wiki
继续让Agent回写：
请把刚才关于"LLM Wiki vs RAG"的回答，整理成 wiki/ 下的一页对比页，
补上必要链接，并关联到已有页面。一旦开始这样做，知识库就会出现一个明显变化：它不再只吸收新资料，也开始吸收新问题。
这才是一个系统会持续长起来的信号。
第八步：最小目录结构
llm-wiki-lab/
├── AGENTS.md
├── raw/
│ └── 2026-04-27-karpathy-llm-wiki.md
├── wiki/
│ ├── source-karpathy-llm-wiki.md
│ ├── llm-wiki.md
│ ├── ingest-workflow.md
│ └── llm-wiki-vs-rag.md先别急着加：tags体系、复杂frontmatter、自动化脚本、批量ingest、多层索引页——这些以后都能加。
第一次最重要的是：你能不能在30分钟内，把第一条链路跑通。
三个最容易翻车的地方
| 翻车点 | 正确做法 |
|---|---|
| 一上来设计超级复杂的结构 | 先跑通，再优化 |
| 把raw和wiki混在一起 | 必须分层，raw是原料，wiki是成品 |
| 只让Agent做摘要，不更新知识网络 | 要让Agent更新已有页面、加交叉链接、回写索引页 |
它和普通RAG到底差在哪
| 方案 | 流程 | 结果 |
|---|---|---|
| 普通RAG | 文件存进去→切片检索→现场拼答案 | 知识不会累积 |
| LLM Wiki | 资料进raw→Agent整理编译→wiki层沉淀→提问优先查wiki | 知识越用越好用 |
核心差别不是能不能回答问题，而是你的知识会不会越用越好用。
总结
这8步跑通，你就有了第一版可用的LLM Wiki：
- 新建独立实验仓
llm-wiki-lab - Obsidian打开，建好
raw/和wiki/两个文件夹 - 仓库根目录下新建
AGENTS.md - 往
raw/塞第一篇文章 - Codex执行第一次ingest
- 回Obsidian检查wiki页面、双链、来源页
- 基于wiki提第一个问题
- 把好的问答继续沉淀回wiki
先跑通，再优化。 这套方法不是让你再建一个笔记库，而是让平时收集的文章、想法，慢慢变成一个能持续维护、持续调用、还能自己长出来的知识系统。
