告别手动整理：小白如何用 Obsidian 搭一个 AI 驱动的个人知识库（附提示词）

很多人都遇到过同一个问题：明明收藏过一篇很有用的文章，真正需要时却想不起标题和关键词，翻遍笔记库也找不到，最后只能重新打开 Google。

公众号、知乎文章、网页剪藏、PDF、视频转写和 AI 对话截图不断进入收藏夹，但几个月后，这些内容往往只剩下一堆散落的文件。Obsidian 的知识图谱看起来很强大，自己的库里却只有零星几条连线。

问题并不是没有记录，而是记录以后再也没有得到持续整理。

01｜传统笔记为什么会卡住

传统笔记系统的核心问题是“只进不出”。

文件夹要求你在保存资料前判断分类，标签要求你长期手动维护。资料少时尚可应付，数量增加后，分类、打标、更新和查找的成本会迅速上升。

最终得到的更像一座仓库：东西都在，却没有人负责整理、建立索引、发现资料之间的联系，也没有人提醒哪些判断已经过时。

AI 时代的信息来源更多、变化更快，传统系统仅仅解决“存下来”已经不够。个人知识库还需要具备持续整理、长期调用和跨资料提问的能力。

02｜AI 知识库解决的不是存储，而是维护

Notion、Obsidian、Bear 和飞书文档都能保存内容，但真正困难的是：资料来源分散、数量太多、更新太快，等到再次使用时已经找不到，或者找到后还要重新理解。

AI 知识库和传统笔记的关键区别不在“存”，而在“维护”。AI 的任务不是增加一个聊天输入框，而是把已保存的资料组织成可提问、可追溯、可持续更新的结构。

当你提出问题时，AI 应该优先从已经积累的笔记中寻找素材、依据和相关概念，而不是每次都从互联网重新搜索。目标是把“我存过什么”转化为“我现在能从已有笔记中找到什么，以及能组合出什么”。

个人使用不必一开始就建设企业级系统。先把自己的资料做成一个能被 AI 阅读和维护的 Wiki，就完成了最关键的第一步。

下面的方案默认使用 Codex 或 Claude Code 操作文件，使用 Obsidian 阅读、浏览和检索知识库。

03｜AI 维护知识库的五项核心工作

1. 持续编译

新资料进入知识库后，AI 阅读内容，并把关键信息整合进已有的概念页、索引和日志。它持续更新现有结构，而不是每次从头翻阅所有文件。

2. 跨资料建立连接

三个月前保存的提示词文章和上周记录的 AI 协作复盘，可能位于完全不同的目录。AI 可以识别它们讨论的是同一主题，并建立联系。

一些笔记单独看只是片段，放在一起才会显现共同主题、相互印证的结论或彼此冲突的判断。AI 的价值之一，就是把这些散点连接成线索。

3. 让问答结果回流

AI 查阅整个资料库后生成的复杂答案，如果只留在聊天窗口中，下次仍要重新提问。应该把有价值的答案保存为文件，成为以后可以直接调用的知识资产。

4. 巩固知识网络

每份新资料都要挂接到已有概念、项目和问题上。这样知识库不会随着使用变得更加分散，而会逐渐形成清晰的网络。

5. 定期进行健康检查

AI 可以扫描整个知识库，找出缺少来源的页面、互相矛盾的概念、没有其他页面链接的孤岛，以及可能已经过时的判断。

这五项工作共同完成一件事：让静态的笔记仓库变成持续生长的知识库。

04｜什么是 LLM Wiki

这套方法通常称为 LLM Wiki。它不是特定产品或插件，而是一种让 AI 像维护代码仓库一样维护知识库的模式，可参看 Karpathy 对 LLM Wiki 的介绍。

一个基础目录可以这样设计：

AI 知识库/
├── raw/                 # 原始资料，只新增，不乱改
│   ├── articles/        # 外部文章、博客、教程
│   ├── papers/          # 论文、研究报告
│   └── clips/           # 网页剪藏、摘录
├── wiki/                # AI 编译后的知识条目
│   ├── index.md         # 知识库总目录，快速知道库里有什么
│   ├── log.md           # 维护日志，记录每次新增和编译
│   ├── concepts/        # 概念页，每个重要概念一个文件
│   ├── entities/        # 实体页：人、组织、产品、项目
│   ├── syntheses/       # 综合页，跨资料整合后的主题梳理
│   └── sources/         # 来源摘要页，每条原始资料一份
├── outputs/             # 问答、报告、健康检查
│   ├── qa/              # 复杂问题的答案存档
│   └── health/          # 健康检查报告
└── AGENTS.md            # 写给 AI 的维护规则

这套结构分为三个内容层和一个规则文件：

• raw/ 是原始资料仓库，只负责保留证据。文章、论文、网页剪藏和 AI 对话记录放进去后，不随意修改。
• wiki/ 是整理后的书架。AI 在这里维护总目录、日志、概念页、实体页、综合页和来源摘要页。
• outputs/ 是工作台，用来保存问答、研究报告和健康检查结果。
• AGENTS.md 或 CLAUDE.md 是 AI 的维护说明书，规定原始资料不可覆盖、重要判断需要来源、整理后必须更新目录和日志、不确定内容要标记“待核验”等规则。

Obsidian 在这套系统中不是 AI 本体，而是知识库的阅读和浏览界面。AI 负责维护 Markdown 文件，人负责阅读、判断方向和添加资料。

AI 持续把原始资料整理成可读、可链接、可追溯的 Wiki，这个过程就是“编译”。

实际使用时不必机械照搬目录名称。例如，原始材料也可以分散在笔记、日记和项目目录中。关键原则是：原始资料和 AI 编译后的内容必须分开，概念页、来源页、综合页和问题页各自承担清晰的职责。

05｜LLM Wiki 与传统笔记、RAG 的区别

传统笔记主要由人手动维护，AI 偶尔读取其中的内容。

RAG 的基本工作方式是：收到问题后，系统先从资料中检索相关片段，再把片段和问题一起交给 AI 生成答案。它类似于给 AI 接入一个面向私有资料的搜索引擎。

RAG 很有用，但通常会涉及文本切块、检索算法、向量数据库和权限控制等技术环节。

LLM Wiki 更适合个人起步，因为文件就是 Markdown：人可以阅读，AI 可以修改，也便于备份和追溯。个人知识库不必一开始就上 RAG。先跑通资料进入、编译、提问、回流和检查的完整流程；等资料规模扩大、普通搜索确实不够用时，再考虑更强的检索方案。

06｜让 AI 初始化知识库

第一步，新建一个独立的笔记仓库，不要直接在主笔记库中试验。先在单独文件夹中跑通流程，确认适合自己的使用习惯后再迁移。

第二步，把下面的提示词交给 Codex 或 Claude Code：

请帮我初始化一个个人 AI 知识库。

目标：
我想用 LLM Wiki 的思路搭一个普通人能用的 Markdown 知识库。这个库不做企业级 RAG，不上复杂数据库，先用文件夹和 Markdown 跑通最小闭环。

请你完成这些事：

1. 创建下面的目录结构：
   - raw/articles/
   - raw/papers/
   - raw/clips/
   - wiki/concepts/
   - wiki/entities/
   - wiki/syntheses/
   - wiki/sources/
   - outputs/qa/
   - outputs/health/

2. 创建 wiki/index.md，用来说明这个知识库当前有哪些主题、资料和入口。

3. 创建 wiki/log.md，用来记录每次新增资料、编译资料、更新页面和健康检查的结果。

4. 创建项目工程规则文件，写清楚以后维护这个知识库时必须遵守的规则：
   - 如果我用的是 Codex，请创建 AGENTS.md。
   - 如果我用的是 Claude Code，请创建 CLAUDE.md。
   - 如果你不确定我用哪个工具，请同时创建 AGENTS.md 和 CLAUDE.md，两个文件内容保持一致。
   - raw/ 只保存原始资料，不要删除，不要覆盖。
   - wiki/ 里放你整理后的知识条目。
   - 每个重要判断都尽量指向来源。
   - 新资料进来后，先生成来源摘要页，再更新概念页、实体页、index.md 和 log.md。
   - 不确定的信息要标注待核验，不要编。
   - 每次整理完成后，告诉我你改了哪些文件。

5. 在 wiki/sources/README.md 里写一个来源摘要页模板，字段包括：
   - title
   - source
   - source_url
   - created
   - summary
   - key_points
   - related_concepts

6. 在 outputs/health/README.md 里写一份健康检查说明，提醒以后定期检查：
   - 哪些页面缺来源。
   - 哪些概念重复或冲突。
   - 哪些页面没有链接。
   - 哪些判断可能过期。

请直接创建这些目录和文件。完成后，用一段话告诉我这个知识库现在怎么用。

执行完成后，用 Obsidian 将这个文件夹作为新仓库打开。此时应该能看到完整的目录结构、index.md、log.md 和 AI 维护规则。

07｜第一次添加和编译资料

先准备 5～10 篇同一主题的内容，可以是网页剪藏、公众号文章、PDF、视频转写或 AI 对话记录。按照资料类型放进 raw/ 的对应目录，然后执行第一次编译：

请读取 raw/ 里的新增资料，把它们编译进 wiki/。

你要做这些事：
1. 为每篇资料生成一份来源摘要页，保留 source_url。
2. 提取重要概念，如果 wiki/concepts/ 里已有相关页面，就更新旧页面；没有就新建。
3. 更新 wiki/index.md，让我能快速知道现在库里有什么。
4. 更新 wiki/log.md，记录这次处理了哪些资料。
5. 不要删除 raw/ 里的原始资料。

第一次编译不必追求完美。摘要可能遗漏重点，概念归类可能不准确，内部链接也可能不完整。先确认整个流程能够运转，再逐步修正。

编译完成后，在 Obsidian 中花约 10 分钟检查三个问题：

1. 来源摘要页是否保留原始链接。
2. 概念页的逻辑是否通顺。
3. index.md 是否列出了所有新增资料。

发现问题后不必逐页手工修改，可以把问题集中记录下来，下一轮交给 AI 修正。

08｜建立日常维护循环

第一次编译完成后，知识库已经有了骨架。之后主要执行投喂、提问、回流和检查四项操作。

投喂新资料

看到有价值的文章、完成项目复盘或与 AI 讨论出可复用结论后，把内容放进 raw/，再让 AI 编译：

请读取 raw/ 里新增的资料，把它们编译进 wiki/。

你要做这些事：
1. 为每篇新资料生成来源摘要页，保留 source_url。
2. 提取重要概念，更新或新建 wiki/concepts/ 里的概念页。
3. 更新 wiki/index.md 和 wiki/log.md。
4. 不要删除 raw/ 里的原始资料。

优先向自己的知识库提问

遇到问题时，先让 AI 查阅现有知识库：

请先读取 wiki/index.md 了解当前知识库的全貌，然后根据 wiki/ 里的内容回答我的问题：[你的问题]

回答时请引用 wiki/ 里的具体来源页面。如果知识库里没有相关信息，也请告诉我。

复杂问题的答案不要只留在对话窗口，应保存到 outputs/qa/。

让有价值的结果回流

阶段总结、对比表和研究结论都应落成文件。有价值的 AI 对话本身也可以作为新的 raw/ 输入。

整理问答时可以使用：

请把刚才的问答/讨论整理成一篇笔记，保存到 outputs/qa/。

内容包括：问题背景、关键结论、涉及的 wiki 页面链接。

每周做一次健康检查

请先读取 wiki/index.md 了解当前知识库的全貌，然后做一次健康检查。

重点检查：
1. 哪些页面缺少来源。
2. 哪些概念定义互相冲突。
3. 哪些页面几乎没有链接，像孤岛。
4. 哪些重要概念被多次提到，但还没有独立页面。
5. 哪些页面可能已经过期，需要重新核验。

请把报告保存到 outputs/health/，并给出最优先修复的 5 个问题。

09｜六个常见误区

1. 不要一开始就搭 RAG。 先跑通 LLM Wiki 的最小闭环，资料规模增长后再评估是否需要更复杂的检索系统。
2. 不要只保存正文而不保存来源。 缺少来源链接会导致信息无法追溯，AI 编译后的判断也难以核验。
3. 不要把 `raw/` 和 `wiki/` 混在一起。 前者保存原始证据，后者存放整理结果。混用可能使 AI 生成的内容污染原始资料。
4. 不要让 AI 覆盖原始资料。 raw/ 中的文件只能新增，不能随意删除或覆盖。
5. 不要把重要问答留在聊天记录中。 有价值的答案、对比和结论要保存到 outputs/。
6. 不要认为编译一次就结束了。 AI 可能遗漏信息，知识也会变化，因此需要持续更新并定期进行健康检查。

结语

这套系统的核心不是做出一张漂亮的知识图谱，而是建立一个能够持续运转的维护循环：原始资料进入 raw/，AI 将其编译进 wiki/，问题和研究结果沉淀到 outputs/，再通过健康检查不断修复结构。

每次加入资料，知识网络就增加一个节点；每次提问，答案都尽量从已经积累的内容中生成；每次回流和检查，又会让已有知识变得更容易查找、组合和核验。

进一步了解这一模式，可阅读 Karpathy 的 LLM Wiki 说明。

参考：X 长文/动态