为什么我不用「收藏夹」或「Notion」
认知前提：Obsidian、Obsidian Web Clipper、LLM Wiki 到底是什么
Obsidian Web Clipper
Obsidian Web Clipper 是 Obsidian 官方提供的浏览器扩展，它可以把网页内容或高亮内容直接保存到你的仓库里，所以它最适合承担“入口层”的工作。
它不只是一个简单的“保存网页”按钮，官方文档还明确支持自定义模板、变量、过滤器和逻辑，这意味着你可以针对不同网站设计不同的剪藏规则。
Obsidian
Obsidian 本身更像一个本地化的 Markdown 工作台。
它的强项不是替你写内容，而是让你的笔记、页面、链接和图谱可以长期存在，并且保持可控。
LLM Wiki
LLM Wiki 这个思想来自 Andrej Karpathy（对，就是那个前 Tesla AI 负责人、OpenAI 创始成员）。他发现一个尴尬的事实：大多数人写笔记，要么写得像狗啃的一样（几行潦草的关键词），要么长篇大论直接贴原文。前者没法复用，后者没法检索。
如果只用 Obsidian，你会得到很多笔记。
但把 LLM Wiki 这层也加上之后，你才有机会把零散资料慢慢长成一张真正互相连接的知识网络。
这套知识库的核心思路
很多人第一次接触 LLM Wiki，会把它理解成“AI 帮我搜一下资料”。
但它和传统的临时检索思路不太一样，因为它强调的是：资料进入系统时，就尽量被整理、抽象、链接，而不是等到提问时再临时拼答案。
换句话说，RAG 更像“你问了，我再去翻”。
LLM Wiki 更像“我先把资料编译成结构化页面，后面你问的时候，读的是已经沉淀好的知识层”。
这个差异很重要。
因为博客写作、知识积累、专题研究，本来就不是一次性动作。
你今天剪一篇文章，明天记一条笔记，后天又问一个问题，如果这些内容最后都只停留在聊天记录里，那它们迟早还是会散掉。
所以这套流程里，我更推荐把结构先想清楚，再开始用工具。
工具只是入口，结构才决定后面会不会越来越顺手。
环境准备
安装 Obsidian Web Clipper
Obsidian Web Clipper 的基础能力并不复杂：安装扩展、选内容、保存到仓库。
真正决定它好不好用的，其实是模板。官方文档明确提到，它支持为特定网站建立自定义模板，并在模板里使用变量、过滤设置和逻辑判断。
这意味着你完全可以把“新闻站点”“技术博客”“影评网站”“文档页面”分开处理，而不是所有内容都塞进一个默认模板里。一些用户实践里，也会把剪藏内容落到专门的 ReadLater 或 Clippings 文件夹，并在保存时自动附加标签，这样后面筛选和回看会轻松很多。
示例：博客写作
假设你需要整理自己的博客，那么可以设置一个博客的模版，我的设置（在Obsidian Web Clipper扩展里面进行设置）如下：
模板名称：博客
行为：创建新笔记
笔记名称：{{meta:property:og:title}}
笔记位置：raw
保管库：最近使用
属性（可以自行添加）：
title： {{meta:property:og:title}}
type：技术教程
subtype:ai
author: {{author}}
site: {{site}}
domain: {{domain}}
url: {{url}}
published: {{published|date:”YYYY-MM-DD”}}
clpped: {{date|date:”YYYY-MM-DD HH:mm”}}
description: {{meta:property:og:description}}
image: {{meta:property:og:image}}
tags: [clippings,影评，电影, 技术教程，软件推荐]
status: 未读
笔记内容：{{content}}
安装 Obsidian
让 LLM Wiki 真正开始工作
搭完 Obsidian 和 Web Clipper 之后，很多人会停在这里。
然后几个月后发现，仓库里只是多了几百篇没消化的 Markdown。
这就是为什么我后面越来越看重 LLM Wiki。
因为它不是让你再存一份资料，而是让 LLM 帮你把原始资料加工成更稳定的知识页面。
公开资料里，比较典型的做法是：
先把文章、文档、网页这些原始内容放进 Raw Sources。
再让 LLM 读取这些资料，识别关键概念、主题和关系，生成结构化的 Wiki 页面。
接着继续提问，把有价值的问答结果沉淀回 Wiki，而不是只停留在聊天窗口里。
这件事说白了，其实就是把 LLM 从“回答问题的人”，变成“维护知识库的人”。
而且一旦页面之间开始建立双向链接，Obsidian 的图谱视图就能把这些原本分散的内容串起来，形成一个更接近网络而不是文件夹的结构。
wiki实战
按照Andrej Karpathy的思路，一步步搭建个人知识库。
我搭的这个知识库，适用于个人博客写作，如果想应用在其他场景，过程是一样的。
在开始前，先把你收集的原始文档（如你自己的博客、你喜欢的作品等）通过Obsidian Web Clipper放到raw文件夹下，比如我的是F:\llm-wiki-agent\blogs\raw
然后进入这个知识库的根目录（比如，我的是F:\llm-wiki-agent\blogs），claude启动Claude Code（或你的智能体框架）
先下载llm-wiki.md，放到知识库的根目录下，然后跟智能体如claude交流，我的输入为：
请先阅读：
F:\llm-wiki-agent\blogs\llm-wiki.md
后续我希望你基于这个文档的思路，为：
F:\llm-wiki-agent\blogs\raw
里的资料设计一套适合博客知识积累的 wiki 方案，并最终整理成：
F:\llm-wiki-agent\blogs\llm-wiki-blogs.md
但现在先不要直接生成最终文档，也不要立刻批量处理 raw 目录。
请先做两件事：
1. 提炼 llm-wiki.md 里对这个项目最有价值的核心思路；
2. 结合“博客知识积累”这个目标，先向我提问，和我讨论清楚需要的页面类型、目录结构、命名方式、元数据规范和后续用途。
要求：
– 先讨论，再设计；
– 先给问题和初步判断，不要直接输出最终方案；
– 如果有多种设计方向，先做简要对比，再给出推荐；
– 整体以长期维护、便于写博客、便于复用知识为目标。
现在请先输出：
1. 你从 llm-wiki.md 里读到的关键思路；
2. 你需要向我确认的问题。
期间不断跟agent讨论，最后就会形成一个wiki。
我建议补一份 METADATA.md
LLM Wiki 真正难的，不是第一页生成出来。而是生成到第 50 页、第 100 页以后，还能不能保持结构稳定。
所以我很建议你一开始就补一份 METADATA.md（位于wiki目录下，wiki目录跟raw同一级目录）。
它的作用不是给人看，而是给后面协助你的 LLM 看。
你至少应该写清楚这些规则：
页面命名规则：中文名还是英文名，空格怎么处理，是否统一加前缀。
frontmatter 规范：标题、来源、创建时间、标签、状态是否必填。
页面类型：摘要页、概念页、专题页、问答页分别长什么样。
链接规范：什么时候加双向链接，什么时候回链来源。
更新策略：新资料进入时，是新建页面，还是合并到旧页面。
引用规范：任何结论尽量能追溯回原始资料。
社区经验总结里也反复强调，Schema 和规范层是这套系统能否长期稳定的关键，因为它本质上是在把一个通用聊天模型约束成“知识库维护员”。
如果没有这层约束，页面会很快越长越乱，后面就又回到“看起来很多，实际不好用”的老路上。
当agent把raw的原材料整理好并形成wiki之后，可以在Obsidian里面进行可视化与检索。
