我和 AI 共创了一套会自己生长的 Obsidian 知识库

从 2021 年开始，我一直用 Notion 管理工作、学习和写作笔记。多维表格一度让我以为，笔记的组织问题终于解决了。

但几年下来，我遇到的仍然是同一批问题：会议纪要写完再也没人看，调研材料三个月后和记忆一起蒸发；明明记得讨论过某个问题，却怎么也找不到，即使找到了，也不知道当时为什么会得出那个结论。

今年年初，我转到 Obsidian。起初我以为这只是又一次工具迁移，后来才意识到，真正的变化不是从 Notion 换成 Obsidian，而是开始让 AI 参与知识库的长期维护。

过去的工具降低了「记下来」的成本，却没有降低「用起来」和「维护好」的成本。这篇文章要讲的，就是我如何用 Obsidian + Claude Code 搭建一套持续维护的知识库，并通过 Claudian 插件把日常操作集成在 Obsidian 内完成，尝试解决后两个问题。

我真正想解决的，不是搜索，而是维护

现在最主流的「AI + 知识库」方案是 RAG（检索增强生成）。把文档切成小块，向量化后存进数据库；查询时取 top-k 相关片段，喂给 LLM 拼一个回答。在最常见的只读式 RAG 中，一次查询通常不会反过来更新知识库。

听起来很合理，但用起来有几个绕不开的问题。

• 知识不累积。 每次查询从零开始，前一次的答案不会让下一次更聪明。
• 矛盾从没被发现。 同一个指标在文档 A 和文档 B 里定义不同，RAG 不会提醒你，它只是分别检索出来丢给 LLM，让模型自己消化。
• 源材料永远停留在散乱状态。 片段之间从未连接，散落的还是散落的，矛盾的还是矛盾的。你只是多了一层向量索引，知识本身的问题一个都没解决。

RAG 擅长从材料中找到相关片段，但「发现矛盾、更新旧结论、建立长期关联」通常不在它的默认职责里。

让 AI 来维护笔记这个念头，不是我原创的。卡帕西（Andrej Karpathy）很早就提过类似的想法--既然 LLM 能读写文件，为什么不直接让它帮你维护笔记？他管这叫 LLM wiki。顺着这个思路，我开始想：如果 LLM 能读文件、写文件、理解上下文，那它能不能不只是帮我记笔记，而是帮我维护一个活的、可以自己生长的知识库？而 Obsidian 以本地文件为核心，这一点过去常被视为协作上的限制，但在 AI 直接读写知识库的场景中反而成了优势--AI 拿到的是你硬盘上最完整、最真实的笔记原文，而不是被切碎、被向量化之后的片段。

换个思路，让 AI 来维护笔记

卡帕西的 LLM wiki 给了方向，网上也有很多开源方案，但我看了下都不太适合我，于是我和 AI 一起把这套东西共创了出来。

核心思路是让 LLM 来帮你维护笔记。它读一次原始来源，从中提取关键事实，写入结构化的笔记，然后持续维护。新内容到来时，自动更新受影响的旧笔记，而不是每次从头读原文。查询时直接读已经综合好的笔记，而不是在原始碎片里现翻。

知识库最耗人的不是阅读，而是持续记账；这恰好是 LLM 最适合承担的重复劳动。

为了看得更清楚，这里列一下两种方式的对比：

整个流程串起来，是这样的：

原始资料（只读）
       ↓
AI 提取事实与结论
       ↓
生成结构化笔记
       ↓
更新受影响的旧笔记
       ↓
矛盾校验（一致 / 软矛盾 / 硬矛盾）
       ↓
发现关联并补充 wikilink
       ↓
查询时直接读取维护后的知识
       ↓
按需检查矛盾、孤岛、重复与过期

后面的每一章，基本都在解释这条链路上的某一环。

先看一次完整流程，一篇新资料如何进入知识库

规则和工具先放一放，先把这条链路完整跑一遍。以一篇关于「工地验收」的新文章为例。

一篇工地验收文章进入 00-inbox/ 后，AI 会保留原文，生成结构化摘要，找到「空鼓」「基装」等受影响的旧笔记，判断新旧结论是否冲突，再更新内容并补充双向链接。以后查询相关问题时，直接读取这些维护过的笔记；隔一段时间，我再主动检查孤岛、重复和过期内容。具体每一步的机制，下一节「收录」会展开。

日常只做三件事，收录、查问、体检

这套做法区别于传统笔记的核心差异：笔记体系不是静态文档的集合，而是一套持续运行的维护流程。它主要跑在我 vault 的长期积累区--10-work/、20-knowledge/、50-creative/ 的学习和写作区，以及会议修正版笔记。日常其实只做三件事。

收录：把新材料变成可复用知识

这条路上最常做的事。每次有一个新内容（文章、会议纪要、调研报告），不是简单存档，而是走一套完整的「让 AI 维护」流程。落在 00-inbox/ 里的新资料，我会先让 inbox-organizer skill 整理一过--标准化 frontmatter、判断该归到哪个目录、补上 description 和 tags，再进入正式收录。

1. 读来源。 阅读原文或 ASR 修正版，不修改原文。这是这条路的基础原则，原文永远是只读的参照物，只要原文还在，整个笔记体系就可以随时重新推导。
2. 产出结构化摘要。 生成或更新一篇 type: source 的笔记，包含核心主张、关键数据、作者观点。
3. 更新相关实体页。 一个新内容常常触及 5 到 10 个已有相关笔记（type: concept），比如一篇工地验收文章要更新「空鼓」「基装」「临境」。
4. 双向补 wikilink。 在新笔记和已有笔记之间建立相互引用。
5. 过矛盾校验门。 新内容和既有笔记之间往往不一致：一致或补充的，合并并记录来源；口径不同但不互斥的软矛盾，并存并标注差异；互相否定的硬矛盾，暂停提交，用 > [!warning] 标注，等人工裁决后再落盘。
6. 自动补链。 笔记新建或大改后，wiki-relate 基于知识图谱在文末自动追加一个「## 参考信息」章节，列出相关笔记。这条路最繁琐的「记账」就此自动化--AI 帮你记账，你只负责最后的人工裁决。

一次收录的收益是持续的。下次再问相关问题，不需要重新消化全部原始材料，只需定位并读取已经维护过的笔记。

查问：从已维护的知识中生成答案

我的查询流程和常见的只读式 RAG 有一个关键差别：它优先读取已经持续维护过的笔记，而不是每次都从原始材料片段开始拼答案。

1. 先定位候选笔记。 用 graphify query 以自然语言查询，利用知识图谱的结构信息，直接告诉你哪些笔记和你的问题最相关；或者直接读 graphify-out/wiki/index.md，它是图谱自动生成的导航索引。传统做法靠手写一个 index.md 做导航，我把它换成了这两条。
2. 读相关笔记，用 wikilink 引用来源，综合给出答案。
3. 好答案可以归档为新笔记。 放回对应的沉淀区，标上 type，这意味着每次查询都可能产生新的知识资产，而不是用完即弃。

和搜索引擎的本质区别在这里。搜索引擎帮你找到网页，查问帮你综合已有的结构化知识。前者是「找」，后者是「用」。

体检：修复知识库的矛盾、孤岛和过期内容

这条路独有的。传统笔记从来没有体检的概念，笔记烂了就烂了，没人知道。体检由我显式触发，不靠定时任务--平时收录时已经过过矛盾校验门，体检是隔一段时间再兜一道。

检查五个维度：

• 矛盾。 新内容与既有笔记冲突吗？
• 孤岛。 有没有完全没有入链的笔记？用 Dataview 查一下没有入链的笔记，或看 graphify 暴露的孤岛。
• 过期。 有没有被新内容取代的旧主张？
• 重复。 有没有可以合并的重复笔记？

关键原则，体检不擅自删除。先出报告，人工确认后再操作。即使确认要删，也会先移到 workspace/trash/ 保留可恢复性。

CLAUDE.md，把规则写成 AI 的员工手册

看完这三件事，你大概也能感觉到：收录、查问、体检每一步，都需要 AI 按一套固定的规矩来。这些规矩，就写在我的 CLAUDE.md 里。

如果这套 AI 维护的笔记库是一家公司，那 CLAUDE.md 就是这家公司的员工手册。告诉 AI 我们公司是做什么的（这是 Obsidian vault）、每个部门负责什么（目录说明）、什么事不能做（禁止事项）、工作流程和规范（写作规范）、公司有什么特色工具（Obsidian 功能）。有了这本手册，AI 就能像老员工一样，不用每次都问，直接按规则做事。

Claude Code 启动时会自动读取工作目录下的 CLAUDE.md。这意味着你不需要每次打开终端都重新解释一遍「这是我的 Obsidian vault，图片要放到 30-assets/img/，不要删除文件」。更重要的是，当你有多个 Skill、多个工作流之后，CLAUDE.md 是唯一的全局约束层。Skill 只管自己的任务，CLAUDE.md 管所有任务的共同底线。

一份好的 CLAUDE.md 写什么？

我的 CLAUDE.md 迭代了很多版，最后沉淀出五个关键模块。

第一，Vault 身份与格式。 告诉 AI 这是 Obsidian Vault，不是普通文件夹--使用 [[双向链接]] 连接相关笔记、用 YAML frontmatter 管理属性、图片用 ![[图片路径]] 嵌入、总结和报告中引用来源笔记时优先使用 wikilink。这点很关键，因为很多 AI 对 Markdown 的默认行为是「当成纯文本文档处理」，你不说，它就不会主动建立双向链接，不会在前置元数据里填 tags，也不会把图片放到正确的目录。这些看起来不重要的细节，恰恰是知识库长期可维护性的基础。

第二，目录职责。 写清楚每个目录是干什么的。我的目录结构，摘自实际 CLAUDE.md：

docs/
├── 00-inbox/          # 收件箱,新内容暂放,待分类
├── 10-work/           # 工作区,进行中的工作
├── 20-knowledge/      # 长期知识库
├── 30-assets/         # 资产区(图片、模板、会议纪要)
├── 40-archive/        # 长期归档
└── 50-creative/       # 个人创作区

当你说「帮我把这篇调研整理到合适的位置」，AI 看到这个目录说明，就知道技术选型调研放 20-knowledge/references/，会议纪要走 30-assets/meeting/。不用每次都解释。

第三，安全边界。 写清楚不能做什么，这比能做什么更重要：不直接删除文件（即使确认删除也必须先移动到 workspace/trash/ 保留可恢复性）、所有正式图片资产统一存放于 30-assets/img/ 并用描述性文件名、不要破坏 YAML frontmatter、不要覆盖原始会议纪要（生成修正版时新建 _修正版.md）。AI 有读写文件的能力，不划红线，它有时候会好心办坏事--比如为了让目录「更好看」批量重命名你的文件，或者把截图随手放在根目录。

第四，笔记类型。 统一写作规范，用 frontmatter 建立类型系统：

---
created: 2026-05-09
updated: 2026-05-09
type: meeting-note       # meeting-note | report | source | concept | reading-note | pattern
tags:
  - 验收
status: Draft
---

我把每篇笔记的 type 显式标注出来。meeting-note（会议纪要）、source（外部来源的摘要）、concept（主题笔记）、reading-note（精读笔记）、pattern（可复用模式）。这本质上是用 YAML 给笔记体系建立一个类型系统，让 Obsidian 的搜索、Bases、Graph view 都能正常工作。

第五，工作流程。 收录、查问、体检这三件事，每件都写成显式的步骤序列，让 AI 严格遵循，不自由发挥。也就是上一节讲的那三件。

不要从零手写 CLAUDE.md

一个实用技巧。CLAUDE.md 不需要从零手写。更有效的做法是先用 Claude Code 的 /init 指令自动生成一版初始说明，然后每次发现 AI 做了你不满意的事，就把对应的规则加进去。这个过程是逐步迭代的，你不可能第一天把所有规矩都定好，但每次纠正都会让后续合作更顺畅。完整的 CLAUDE.md 比较长，我在文末放了一份教程链接，感兴趣的可以照着搭。

工具链，每个工具只负责一件事

如果 CLAUDE.md 是宪法，三工作流是法律程序，那工具链就是执法力量。我的经验是少即是多--每个工具只负责一件事，组合起来才不会乱。

CLAUDE.md 上一章讲过了，下面分别看其余几个。

Obsidian，不只编辑器，是知识库的「操作系统」

为什么是 Obsidian 而不是 Notion 或纯文件夹？三个根本原因。

• 本地 Markdown 文件。 你的笔记就是 .md 文件，不依赖任何专有格式。任何一个文本编辑器都能打开，任何一个 AI 工具都能读写。这是这条路的技术前提，LLM 可以直接操作文件系统。
• 双向链接 + Graph View。 wikilink 不只链接文件，而是在建立知识网络。一个常用比喻：每篇笔记是一个神经元，wikilink 是神经元之间的突触连接，Graph view 是你的大脑皮层活动图，AI 助手是你的思维扩展器。
• 插件生态。 配合 Claude Code，插件的配置和使用都可以让 AI 帮你完成。

我当前在用的核心插件/功能：

一个实用建议。不要一上来全装。先装 obsidian-git（保底）和 Templates（提效），其他边用边装。

Claude Code，不只编程助手，是你笔记的「整理助手」

很多人以为 Claude Code 只是写代码的工具。但其实，Claude Code 是一个可以读写任何文本文件的 CLI。把它指向 Obsidian vault 的根目录，它就变成了一个可以理解你全部笔记上下文的 AI 助手--收件箱整理、会议纪要修正、精读笔记、周报生成，这些日常操作它都能做，背后是各个 Skill 在跑（下一节展开）。

Claude Code 的威力不在任何一个单独的功能，而在于所有这些能力共享同一份 CLAUDE.md 规则。AI 不需要每次重新理解你的知识库结构，它读完 CLAUDE.md 就知道目录怎么走、格式怎么来、什么不能做。

Skill，可复用的专业工作流

如果说 CLAUDE.md 是公司基本法，那 Skill 就是具体岗位的标准操作手册。我把它叫作「专业工具箱」，每个工具都是为特定场景定制好的，拿起来就能用，不用自己从零打造。

什么时候你需要一个 Skill？当你发现自己反复对 AI 说同样的话的时候。

「以后帮我整理会议纪要时，都要：只修明显的 ASR 错误、不改动原意、保留决策和待办、输出修正版和修正总结。」

这段话说三遍就该沉淀成 Skill 了。我日常把常用的流程都沉淀成了 Skill，需要时一句话调用，不用每次重新交代。几个我自己沉淀、最常用的：

• inbox-organizer。 00-inbox/ 有新资料时调用，自动标准化 frontmatter、按 CLAUDE.md 的目录规则判断路由、补上 description 和 tags，是「收录」流程的入口。
• digest。 把一篇外部长文编译成结构化精读笔记（type: reading-note），拆成核心主张、关键论据、概念解释和关联笔记，是处理外部文章的主力。
• meeting-minutes-gen。 会议纪要专用：基于我维护在 30-assets/meeting/CLAUDE.md 的热词对照表修正 ASR 错别字（「临境」不被误写成「临近」、「空鼓」不被误写成「空腹」），保留决策和待办，输出 _修正版.md 和修正总结，原始版可追溯。
• report-generator。 给定一批项目材料，按模板整理成结构化报告，会议结论、调研输出都能用。

加上前面讲过的 wiki-relate，这几个 Skill 覆盖了我知识库日常的收录、整理、关联和产出。

graphify + wiki-relate，发现关联并写回笔记

graphify 是一个开源工具，项目地址在 GitHub。它扫描指定目录，提取笔记中的实体和关系，生成一张可查询的知识图谱。相比关键词搜索，它更适合发现没有被显式标注的关联--比如多篇笔记都提到「空鼓」，它能把这几篇连起来，还能做社区发现，把紧密关联的笔记聚成知识板块；它也能暴露知识缺口和孤岛笔记，让体检有据可依。

但关联如果只停留在图谱里，笔记本身仍然没有变化。因此我又基于 graphify 自建了 wiki-relate skill：新建或大改笔记后，自动在文末加入「## 参考信息」章节，把相关页面以 wikilink 写回笔记。简单说，graphify 负责发现，wiki-relate 负责记账。它还支持精细控制：frontmatter 里写 wiki-relate: skip 显式跳过（比如草稿不想被关联）、wiki-relate: force 强制关联；命令支持 --dry-run 预览不落盘、--skip-update 连续多篇时跳过图谱更新。

这些维护动作都不靠定时任务，而是由具体动作触发：整理 inbox 时会触发 graphify 更新，新建或大改笔记会触发 wiki-relate 补链。人脑记不住所有关联，笔记越多，这一对工具就越不可或缺--这正是前面那句话的落地：记账是 LLM 最适合承担的重复劳动。

[!note]- graphify 的产物与命令 对指定目录运行 graphify <path>，自动提取实体和关系构建图谱。运行后在 graphify-out/ 产出三类资产：交互式 HTML 图谱（graph.html）、结构化数据（graph.json）和文字报告（GRAPH_REPORT.md）。查询用 graphify query "<问题>"，打开 graph.html 看可视化图谱。

五个坑，如何避免知识库再次退化

不要什么都进知识库

这条路最大的陷阱是「什么都要收录」，这会导致噪音淹没信号。

我的输入规则很简单。 只收集能回答某类问题的内容。比如验收知识库只收四类信息：验收标准（「这个地方合格吗？」）、历史验收记录（「之前类似情况怎么处理的？」）、常见问题（「这个问题怎么解决？」）、优秀案例（「好的做法是什么样的？」）。如果一篇内容不属于任何明确的「可查询问题域」，它就不应该占用收录的精力。

不要一开始就建完美结构

我见过很多人花三周设计一个「完美的目录体系」，然后用了三天就发现不合适。

正确做法。 先有 00-inbox/ 和 10-work/，边用边长。当某个目录下文件超过 30 个、开始感到混乱时，再拆分子目录。让结构从实际需求中长出来，而不是从想象中设计出来。一句话：先让它存在，再让它变好。

不要让 AI 无边界操作

AI 有读写文件的能力，不划红线，它有时候会好心办坏事--比如为了让目录「更好看」批量重命名你的文件，或者把截图随手放在根目录。

其中图片的混乱是知识库退化的头号杀手。「截图放根目录」「同一张图出现在三个地方」「命名全是 image.png」，这些问题不会立刻致命，但三个月后当你要找一张架构图时，你会发现时间全浪费在翻文件上。

我的规则很简单。 所有正式图片资产统一放 30-assets/img/，用描述性文件名（不要 image.png），在笔记中用 ![[img/文件名]] 引用。这条规则写在 CLAUDE.md 的「禁止事项」里，AI 会严格遵守。

CLAUDE.md 不是一次性工程

我的 CLAUDE.md 现在的版本比第一版长了 5 倍。不是因为一开始没想清楚，而是每次发现 AI 做了不符合预期的事，我就追一条规则进去。

一个好习惯。 每次 AI 让你皱眉头，问自己一句「我能在 CLAUDE.md 里加一条什么规则来防止这种事再次发生？」两个月后，你的定制化规则就是你的知识库最大的护城河。

知识库的维护靠「养」，不靠突击

知识库的建设靠的是长期养，而不是三分钟热度。

每天花 10 分钟做一点（把 inbox 清空、给新笔记补两条 wikilink），比一个月突击一天效果好十倍。知识的复利效应需要时间才能显现，你的第二大脑不会一夜之间变聪明，但它每天都在变聪明一点点。

两周最小实践方案

如果你看到这里想动手试试，我之前在培训的过程中，给大家留过一些课后练习，仅供参考。

第 1 天，30 分钟。

• 装好 Obsidian，创建一个新 vault。
• 用 Claude Code 的 /init 生成一版初始 CLAUDE.md。
• 至少写清楚三个目录（收件箱、工作区、知识库）和三条禁止事项。

第 3 天，15 分钟。

• 在 00-inbox/ 里扔一篇你最近读的文章。
• 让 Claude Code 帮你整理，补 frontmatter、拆结构、建议存放位置。

第 7 天，20 分钟。

• 给已有笔记补充 3 到 5 个 wikilink，打开 Graph view 看看连接变化。
• 装 obsidian-git 插件，把知识库纳入版本控制。

第 14 天，30 分钟。

• 运行一次 graphify，让它帮你发现隐藏的关联。
• 跑一次体检，看有没有孤岛笔记或缺失的相关笔记。

两周后，你会开始感受到知识复利的苗头。以前翻半天找不到的东西，现在几个 wikilink 跳转就到了。

总结，知识库不是终点，是基础设施

回顾这段实践，我最深的体会：

知识库不是用来「看」的，是用来「用」的。

一个只能看的知识库，无论结构多精美、笔记多丰富，最终都会变成电子坟墓。真正有价值的知识库，是当你做决策、写报告或准备会议时，能以很低的成本调出相关上下文、历史判断和关联材料，而不必重新翻找全部原文。

这需要三个前提。

• AI 帮你维护（让笔记自己整理、自己更新），显著降低重复维护成本，把人的精力留给判断和取舍。
• 规则写进 CLAUDE.md，让 AI 的行为可预测、可复现、可持续迭代。
• 养成「先让它存在，再让它变好」的心态，不追求完美，只追求持续的微小改进。

从「找资料」到「用知识」，中间差的不是更好的工具，而是一套让知识自己生长、自己记账、自己质检的机制。这套机制，Obsidian + Claude Code 给得了你。