从「收藏即遗忘」到「概念自动浮现」——一套可复用的 Obsidian + 本地大模型工作流

为什么 Obsidian？

我订阅了「人人都是产品经理」很多年，文章读了不少，但真正沉淀下来的很少。收藏夹越堆越满，搜索时却只记得「某篇文章好像讲过类似的事」——标题、作者、具体论点，全都想不起来。

NotebookLM、ChatGPT 文件上传这类工具能帮你检索，但每次提问都要重新拼凑碎片，知识不会累积。我想要的不是「问一次答一次」，而是一本随阅读不断变厚的个人维基——概念之间有链接，观点冲突会被标注，同一主题在不同文章里的论述能自动归拢。

Obsidian 恰好是这个维基最好的「浏览器」：

  • 本地 Markdown，文件即数据，Git 可版本管理
  • 双向链接 + 图谱视图，适合看知识结构
  • 社区插件生态成熟，能接入 AI 工作流
  • Bases、Canvas 等新特性，让运营型仪表盘成为可能

Karpathy 在 LLM Wiki 方法论里把这套模式说得很清楚：Obsidian 是 IDE，LLM 是程序员，Wiki 是代码库。 人负责策展与提问，AI 负责摘要、交叉引用和日常维护。

下面是我把这套想法落地成「人人都是产品经理」专题知识库的实践记录。

三层架构：raw / wiki / schema

整个库刻意分成三层，职责边界清晰：

人人都是产品经理/
├── raw/              ← 原始资料（脚本写入，AI 只读）
│   ├── articles/     ← 抓取的 Markdown 原文
│   └── state/        ← 采集状态、队列
├── wiki/             ← 知识库（AI 维护，人阅读）
│   ├── 来源/         ← 每篇文章的摘要页
│   ├── 概念/         ← ≥2 篇来源时「浮现」
│   ├── 实体/         ← 人名、产品、公司等
│   ├── 对比/         ← 多来源对立观点
│   ├── dashboard/    ← Bases 运营仪表盘
│   └── canvas/       ← 概念地图
└── CLAUDE.md         ← Schema：约定、工作流、创建规则
层级谁写谁读特点
raw/采集脚本LLM不可变，是 source of truth
wiki/LLM人 + LLM结构化、互链、持续更新
Schema人 + LLM 共同演进LLM让 AI 成为「有纪律的维基维护者」

这个分层的价值在于：你永远不会在改摘要时误改原文，也永远不会因为 AI 幻觉污染原始材料。

Obsidian 插件栈

1. Karpathy LLM Wiki —— 自动摄取引擎

这是整个系统的核心插件。配置好后，它会监听 raw/articles 文件夹，新文章一落地就自动：

  1. 创建来源摘要页（摘要、关键要点、相关概念链接）
  2. 提取实体（公司、产品、人物）
  3. 当同一概念出现在 ≥2 篇不同来源时，浮现概念页
  4. 更新 index.md 索引

我的配置要点：

  • 模型：本地 LM Studio 跑 google/gemma-4-26b-a4b-qat，API 地址 http://127.0.0.1:1234/v1
  • 监听模式：Auto Ingest，raw/articles 文件夹有变动即触发
  • 语言：中文摘要与概念命名

Obsidian 开着，daemon 在后台抓文章，知识库就在你眼前一点点长出来——这种「看着图谱节点增加」的反馈，比任何 RAG 问答都更有成就感。

2. Claudian —— 库内 AI 协作者

Claudian 把 Claude Code / Pi CLI 嵌进 Obsidian，vault 就是它的工作目录。我主要用它做：

  • 手动「摄取 XXX」
  • 执行 Wiki Lint 健康检查
  • 按 wiki/prompts/lint.md 里的指令做深度审查（矛盾检测、孤儿页、缺失对比页）
  • 创建对比分析、补 cross-link

它和 Karpathy Wiki 的分工是：Karpathy 管自动化流水线，Claudian 管人工介入和复杂任务。

3. Obsidian Bases —— 知识库运营仪表盘

Wiki 长到几百页后，纯靠图谱和搜索已经不够。我在 wiki/dashboard/ 下建了三个 .base 视图：

仪表盘用途
来源监控最近入库文章、作者分布
概念成熟度候选（1 来源）vs 已浮现（≥2 来源）
孤儿页清理0 入链页面，指导补链

概念页的 frontmatter 里有 source_count 和 maturity 字段，由脚本 enrich_wiki_properties.py 自动维护，Bases 公式直接读取：

---
type: concept
maturity: emerged      # candidate | emerged
source_count: 2
sources:
  - "[[wiki/来源/...]]"
---

在仪表盘里一眼就能看到：哪些概念还缺第二篇来源、哪些页成了孤岛——这比「感觉知识库很乱」具体得多。

4. Canvas —— 概念地图

对于复杂主题，纯文字链接不够直观。我在 wiki/canvas/ 里用 Canvas 画概念关系图，比如「意图驱动 · 交互范式」，并在对比页里嵌入链接。Canvas 和 Markdown 页互相引用，图谱 + 空间布局，两种视角互补。

自下而上的知识浮现

这是 Karpathy 方法论里最打动我的设计：不要预先建分类树，让概念从阅读中自然浮现。

页面类型创建条件
来源摘要页每篇 raw 文章（始终创建）
概念页同一概念在 ≥2 篇不同来源 中被讨论
实体页同一实体在 ≥2 篇不同来源 中被提及
对比页对比主题在 ≥2 篇来源 中有不同立场

举个例子：「认知负荷」先在 2012 年一篇按钮设计文章里被提到，又在 2026 年一篇用户调研反思里出现——第二篇入库后，概念页自动浮现，maturity 从 candidate 变为 emerged。

这种延迟命名避免了过早分类的陷阱。你只负责持续阅读（或者说，让采集脚本持续喂料），知识结构会自己长出来。

自动化流水线

Obsidian 负责「看」，采集和调度在 vault 外用脚本完成：

./run.sh discover   # 从 sitemap 索引历史 URL（约 13 万篇）
./run.sh fetch      # RSS + 队列 → raw/articles/
./run.sh daemon     # 后台循环抓取（默认每小时一轮）
./run.sh enrich     # 补充 source_count / maturity
./run.sh lint       # 健康检查，结果写入 wiki/log.md

完整数据流：

RSS / Sitemap → fetch.py → raw/articles/ → Karpathy Wiki Auto Ingest → wiki/来源/ →（≥2 篇来源？）→ wiki/概念/；并行产出 wiki/实体/；Claudian / Lint 维护 wiki/对比/ 与补链；Bases 仪表盘驱动运营决策。

.env 里有一个关键开关：

INGEST_ENGINE=karpathywiki   # Obsidian 插件自动摄取
# INGEST_ENGINE=python       # 备用：脚本 ingest.py

我选 karpathywiki，是因为摄取过程能在 Obsidian 里实时看到页面生成，体验最好。Obsidian 不必 24 小时开着——下次打开时，插件会处理积压的新文章。

页面长什么样？

来源摘要页

每篇入库文章对应一页，链回 raw 原文，提取摘要和关键要点：

---
type: source
source_url: https://www.woshipm.com/share/6414344.html
source_author: 木兰姐
created: 2026-06-16
---

[[raw/articles/6414344_爆品思维...md]]

## 摘要
...

## 相关概念
- [[wiki/概念/爆品思维]]

对比分析页

当多篇文章对同一主题持不同立场，手动或让 Claudian 创建对比页。例如「意图驱动 vs 命令驱动」：

维度命令驱动意图驱动
学习成本高低
可预测性高低
适用场景专业工具复杂目标拆解

每个单元格都链回具体来源，立场可追溯，不是 AI 的空口综合。

Wiki Lint：让知识库保持健康

Wiki 最大的敌人是维护债——链接断了、概念重复、新旧观点矛盾没人管。LLM 的优势正是「不厌烦、不漏改、一次改 15 个文件」。

我每周跑一次 lint，流程是：

  1. python3 scripts/wiki_lint.py --log 拿基线数据
  2. 在 Claudian 里执行 wiki/prompts/lint.md 里的标准指令
  3. 结果追加到 wiki/log.md

最近一次检查结果（2026-06-17）：

  • 总页面：459
  • 已浮现概念：46
  • 候选概念：140
  • 孤儿页：68

lint 不追求零孤儿——而是把「该补链的」列成可执行清单。这比凭感觉整理靠谱太多。

几个实用 Obsidian 技巧

浏览器插件抓文章进 raw/，设置附件目录为 raw/assets/，快捷键下载图片到本地，避免链接失效。

  1. Web Clipper + 本地图片

哪些概念是 hub、哪些是 orphan，图谱比任何目录都直观。

  1. Graph View 看结构

type、source_count、maturity、tags 给 Bases 和 Dataview 提供查询基础。Schema 里约定字段，AI 写入时保持一致。

  1. Frontmatter 即数据库

Wiki 就是一个 Markdown 仓库。改摘要、补链接、解决矛盾，全有历史记录。

  1. Git 版本管理

摄取是高频、长上下文任务，本地 Gemma 4 26B 够用了，没有 API 费用焦虑，隐私也在本地。

  1. 本地模型优先

这套实践改变了什么？

之前：读 100 篇文章 ≈ 100 条浏览器书签，一个月后全忘。

现在：

  • 459 个 wiki 页，46 个已浮现概念，跨文章的主题自动归拢
  • 问「意图驱动和命令驱动各有什么适用场景？」——直接打开对比页，带来源引用
  • 仪表盘告诉我下一步该读什么（给候选概念补第二篇来源），而不是盲目刷 RSS

Obsidian 在这里不是「笔记软件」，而是个人知识库的 IDE。你负责选读什么、问什么、判断什么；LLM 负责摘要、链接、更新、lint。知识终于开始复利了。

如何起步

如果你想复刻这套流程，最小路径是：

  1. 建 Obsidian vault，放入 CLAUDE.md 作为 Schema
  2. 安装 Karpathy LLM Wiki + Claudian 插件
  3. 配好本地 LLM（LM Studio 或任意 OpenAI 兼容 API）
  4. 建 raw/ 和 wiki/ 目录，丢几篇文章进 raw/articles/
  5. 打开 Auto Ingest，看来源页和概念页生成
  6. 概念够多后，加 Bases 仪表盘和每周 lint

Karpathy 的原话值得再引用一次：

*The tedious part of maintaining a knowledge base is not the reading or the thinking — it's the bookkeeping.*

Obsidian + LLM Wiki 要做的，就是把 bookkeeping 交给 AI，把你还给阅读本身。

*方法论参考 [Karpathy LLM Wiki](https://github.com/karpathy/llm-wiki)；插件：[Karpathy LLM Wiki](https://github.com/green-dalii/obsidian-karpathywiki)、[Claudian](https://github.com/YishenTu/obsidian-claudian)。*