零门槛搭建本地第二大脑:Obsidian入门与AI工作流实操指南
笔记软件我折腾过很多,有道云、Notion 都深度用过,折腾到最后,所有东西都搬回了一个普通的本地文件夹。
笔记本质上就是文件,不应该是别人服务器里的一行记录。
大家常说“第二大脑”,但它不该是个杂物间。如果不管什么都往里丢,攒到几百篇后既搜不出也翻不到,最后大概率弃坑。笔记堆着没有意义,能找得到、能在当下用得上,才算数。

随着本地大模型以及 AI Agent 直接读取本地目录的能力普及,整理这件事终于可以交给程序去跑了。不过,按什么规矩理、边界划在哪里,控制权依然在自己手里。后文第八、九章会详细聊这套逻辑。
目录
一、Obsidian 到底是什么 —— 一个文件夹,加一层 UI
二、下载安装,建第一个库 —— 装完别急着配,先写第一条笔记
三、界面和三个真正有用的功能 —— 双链、标签、全文搜索
四、笔记规范:frontmatter 五个字段 —— 让笔记对人可读、对 AI 可查
五、插件:起步只装两个 —— 装二十个插件是最大的坑
六、目录结构与入口笔记 —— 十个顶层目录,五十八篇入口
七、日记与模板 —— 真正让人坚持下来的那一环
八、让 AI 接管整理 —— 前提、边界、和三层架构
九、几个能直接用的 AI 工作流 —— 日记周报、读书笔记、调研、写作
十、常见坑 —— 九个,每一个都有代价
十一、问题答疑 —— 十二问
一、Obsidian 到底是什么
简单来说,它就是一个把 Markdown 纯文本拿来当笔记用的软件。
每一篇笔记,就是硬盘里的一个 .md 文件,直接用记事本就能改。Obsidian 本身其实就是个看文件的壳子,给这堆纯文本加了一层双链、图谱、搜索和扩展插件的界面。
它和云笔记的区别很直观:

前五项决定了它“省心、不绑架数据”,而第六项——“本地文件能否被 AI 直读”,才是真正的分水岭。
为什么“AI 能不能直接读”很关键
AI 想帮你整理资料,底线要求是它得直接摸到文件:
Apple Notes、印象笔记:格式闭源私有,外部脚本基本探不进去。
Notion:只能调 API,受接口速率限制、权限层级限制,还要做结构转换。
本地 Markdown 文件夹:本地跑任何工具都能读写,不依赖网络请求,也不用跟各种 Token 认证死磕。
这不是体验好坏的问题,而是能不能直接落地的问题。
Markdown 为什么适合喂给 AI
原因主要有三点:
省上下文空间:同等内容,Markdown 比 JSON、XML 能少占 30% 到 50% 的 token。
层次直观:## 是层级标题、> 是引用、反引号是代码,标点本身就是分隔标记,模型读起来很轻松。
输出对齐:大语言模型默认就习惯吐出 Markdown,输入输出无缝衔接。
一个参考数据:20 万 token 的上下文差不多能塞进 50 到 80 万字的 Markdown。个人知识库在这个量级内,基本不需要考虑塞不下的问题。
现实中的旁证
近几年很多 Agent 工具的长期记忆方案,不约而同选了 Markdown:

底层都没去堆复杂的向量库或关系型数据库,用的就是纯文本文件。
名词对照
Vault / 库 就是电脑里的一个文件夹,笔记全在里面 Markdown 纯文本语法,用 # 标标题,** 标加粗 双链 [[ ]] 用 [[笔记名]] 关联另一篇,支持双向查看 Backlinks 反向链接:列出哪些笔记提到了当前这篇 Frontmatter 每篇笔记开头用 --- 圈起来的属性栏(存标签、日期等) 附件 图片、PDF 等,单独放在附件文件夹 Callout 样式化的引用卡片,支持图标和折叠 插件 官方核心插件 + 社区插件,按需开启功能
缩略对应:
📁 Vault → 一个文件夹 📝 Markdown → 纯文本码字 🔗 双链 → 页面互相打洞关联 🏷️ Frontmatter → 文件的结构化元数据 🧩 插件 → 按需加功能 🤖 AI 可读 → 纯文本天生开放
官网地址:obsidian.md
二、下载安装,建第一个库
去官网下对应操作系统的安装包。
软件个人使用免费,不需要登录注册,装完直接用。初次打开它只让你做一件事:选一个本地文件夹当库(Vault)。
哪怕是已有的 Markdown 目录也可以直接选,它不会动里面的内容,只会在根目录自动新建一个 .obsidian/ 隐藏配置文件夹。
存放位置建议
不建议把库放在 iCloud、坚果云、OneDrive 这类默认实时双向同步的目录里。
同步网盘的冲突机制和本地软件对文件的读写经常打架,轻则冒出一堆带“冲突副本”的文件,重则文件内容直接被覆盖损坏。
推荐路径:
Mac: ~/Documents/MyVault Windows: D:MyVault
需要多端同步的话,通常这几种方式比较稳妥:
官方 Obsidian Sync:省心,需付费。
Git:免费,版本回滚明确,适合熟悉 Git 的人。
手动或定时单向备份:用脚本或工具,只从本地单向同步到移动硬盘或网盘做备份,不做实时双向合并。
手机端也可以装一个,平时随手记个灵感,回电脑前不用花精力在手机上做分类。
装好后先做两件事
设成中文界面:Settings → General → Language → 简体中文。
关掉设置,马上新建写下第一篇笔记。
先别一上来花半天时间去画标签树或者搭文件夹架构。
笔记结构应该是随着记录逐渐长出来的。还没写几篇就设计出一套大而全规范的人,大多在两周内就会因为维护成本太高而弃用。先写上几十篇,再回过头来顺手立规矩。
三、界面和三个真正有用的功能
默认界面划分很清爽:
┌──────────┬────────────────────┬──────────┐ │ 左侧栏 │ 编辑区 │ 右侧栏 │ │ 文件列表 │ 正文写作区 │ 出链/反链 │ │ 全文搜索 │ │ 标签/大纲 │ └──────────┴────────────────────┴──────────┘

常用快捷键
日常用熟这几个就够:
Ctrl/Cmd + N 新建笔记 Ctrl/Cmd + O 快速模糊搜索打开笔记(比在左侧文件夹里扒拉快得多) Ctrl/Cmd + P 打开命令面板(记不住快捷键时直接搜命令) Ctrl/Cmd + Shift + F 全局搜索(支持正则) Ctrl/Cmd + E 切换编辑 / 预览模式 Ctrl/Cmd + D 打开今天的日记(需要开启 Daily Notes) Ctrl/Cmd + B 加粗 [[ 输入两个左中括号,自动联想库内笔记
快速打开是 Cmd+O,命令面板是 Cmd+P,从 VS Code 转过来的习惯稍微留心一下就行。
基础 Markdown 语法
熟记这几行,日常记录就够用了:
# 一级标题 ## 二级标题 ### 三级标题 **加粗** *斜体* ~~删除线~~ - 无序列表 1. 有序列表 > 引用 `行内代码`
| 表头 | 表头 | ← 表格 - [ ] 待办项 - [x] 已完成 [[笔记名]] ← 双链 ![[图片.png]] ← 嵌入图片 --- ← 分隔线
需要注意的是,[[笔记名]] 和 ![[图片.png]] 是 Obsidian 常见的 WikiLink 语法,并非标准 Markdown 的文本。
在调用普通 AI 写文件时,如果没做提示词约定,AI 容易默认写成普通 Markdown 链接,Obsidian 识别起来会别扭。这部分在第八章配 Skills 时能彻底解决。
功能一:双向链接
输入 [[,直接输入关键词回车就能连过去。
值得一提的是:链接目标即使还没创建也可以先打上去。此时 Obsidian 会生成一个占位空链接,点进去就成了新笔记。这很符合边写边记录思路的节奏——写到某个名词时先把钩子埋好,后面想写了再去展开。
写完后,在右侧的 Backlinks(反链)面板里,能看到所有引用过当前文章的笔记。
对 AI 来说,这也是确定性的遍历路径。比如让模型整理一篇关于 RAG 的总结,它顺着正文里的 [[向量数据库]] 和 [[Embedding]] 就能精准抓取关联文件,比全文盲搜关键词要准很多。
功能二:标签
一篇笔记通常只在一个文件夹里,但标签可以打多个。标签无需预先定义,在正文敲 #标签名,软件就会自动收录。
标签适合用于交叉属性。比如一篇“用大模型做跨境电商选品”的文章,不管是放电商还是放技术目录都容易顾此失彼,打上 #AI #跨境电商 就两边都能检索到了。
功能三:全文搜索
快捷键 Cmd+Shift+F,支持正则,也支持按路径、标签和时间快速过滤。
三者各司其职:
双链负责点对点的明确关联,标签负责多维归类,全文搜索兜底做模糊查找。
关系图谱:当成阶段性体检就好
快捷键 Cmd+P 搜 graph 就能调出图谱。看图谱主要注意三点:
连线密集的中心节点:说明是核心主题,可以提炼出更清晰的结构。
零散的孤岛节点:说明缺少关联,可以顺手补一补前置知识链接。
意外粘连在一起的子群:往往预示着不同主题之间的交集。
平时写东西不用总开着它,偶尔看一眼当成复盘工具就行。
四、笔记规范:frontmatter 五个字段
要想让本地文件跟 AI 跑顺畅,开头最好留一套干净的元数据,方便工具在不读全文的情况下秒懂这篇笔记的核心信息。
基础结构
推荐在每篇笔记顶部加上这段:
--- title: 笔记标题 tags: [tech, reference] created: 2026-09-28 type: permanent summary: 一两句话说明本篇的核心内容
字段说明

四条约定
tags 尽量用英文单词:英文标签在系统工具做 grep 全局搜或者写脚本抓取时,排查异常字符的概率更小。
created 统一用 YYYY-MM-DD:比如 2026-09-28,不写中文“9月28日”。ISO 格式能省去解析歧义,且按名字排序列天然规范。
type 限制在三个值以内:
fleeting:随手记的临时想法或毛坯。
literature:看书、看文章摘录的内容。
permanent:自己梳理消化后的观点与成型知识。
状态拆得越细,后期维护越容易烂尾。
summary 保持在 30 到 80 字:用最平实的话概括。如果一篇内容浓缩不出一段话,通常说明这篇该拆成两篇写了。
旧笔记补全方法
不用人工一篇篇改,让脚本或者 AI 本地批量扫一遍:
读取 vault 里未包含 frontmatter 的所有 Markdown 文件: 根据内容提取并补齐 title、tags、created、type、summary 五个字段。 无法准确判断类型的一律标记为 type: fleeting,完成后在根目录输出一份处理清单。
维护一份专用词汇表
同一个东西,有的笔记写“RAG”,有的写“检索增强生成”,模型直接搜缩写可能会漏。
可以在库根目录建一个 glossary.md,把常用的缩写和对应的全称罗列进去,写明项目内的统一指代规则。同样的信息也可以写进给 AI 读的配置说明里。
五、插件:起步只装两个
优先开启的两个官方核心插件
路径:设置 → 核心插件:
日记(Daily Notes):每天点一下就生成以当天日期命名的文件。
模板(Templates):把常用格式一键套入新笔记。
日记解决的是“下笔的心理负担”,不用琢磨起什么标题、扔哪个目录,点开就写。
模板则能保证笔记在排版上风格统一,AI 后续去解析特定版块时也更稳定。
其他自带的核心插件
文件列表 · 全局搜索 · 快速切换 · 关系图谱 · 反向链接 标签面板 · 属性视图 · 页面预览 · 命令面板 · 文件大纲 字数统计 · 文件恢复 · 同步功能 · 笔记书签
按需开着就行,默认的已经很全。
社区插件推荐
路径:设置 → 第三方插件(先关掉安全模式)。
刚开始用的时候,第三方插件一个都不装也没问题。先老老实实写上两三个月,切实碰到底层功能不顺手的地方再去装。
如果确实有需要,这几个比较常用:

辅助 AI 类的插件:

千万别刚进门就一口气装一二十个社区插件。界面堆满按钮,启动越来越慢,快捷键打架,最后光顾着修插件,反倒一篇正经笔记都没写。
外部资料收集方式
写笔记的前提是素材能够顺手收进来。
网页抓取:推荐官方出的浏览器扩展 Obsidian Web Clipper。点一下直接提取正文并输出 Markdown 本地保存。
微信文章:微信基本没有开放接口,通常用第三方转存工具,或者全选复制到笔记后,顺手把头尾的引导关注、广告文案删掉,避免这类噪音后续干扰搜索。
平时收集资料,守住这几条规则:
进库一律先进 Inbox 收集箱:抓内容时注意力在阅读上,别在收集的当下强行琢磨该归到哪里。
存下来不等于消化掉:剪藏了一千篇文章不代表学到手了。定期清空 Inbox,梳理过的再移到资料归档区。
让 AI 帮忙做初筛:如果 Inbox 堆了太多待处理的长文,直接给本地模型下命令批量出摘要、归类标签,然后转移目录。
六、目录结构与入口笔记
组织架构尽量从轻,复杂了很难长期跑下去。
示例目录结构
可以根据自己的生活和工作做微调,这里提供一个实用的参考:
00 Inbox 收集箱:临时抓的灵感、待整理的外部网页 01 资料仓库 外部素材:剪藏的文章、摘录资料、引用出处 02 个人知识 自己的积累:技术笔记、方法论、复盘思考 03 工作项目 工作记录:项目进程、会议记录、协作资料 04 附件 图片、PDF、图表文件 08 译文 翻译和技术搬运的材料 09 原创输出 自己公开发表的文章或交付物 98 模板 日常用的各类文件模板 99 归档 历史结项、不再更新的文件 100 日记 按月归档的每日日志
为什么用数字作为前缀
很朴素的目录管理逻辑:
大多数操作系统的文件管理器按名称排序时,数字天然排在文字前面,层级顺序不会乱窜。
把 98、99、100 这类基础功能目录编号拉大,是让系统类文件夹始终沉在最底端,不干扰上面的业务分类。
设立“入口笔记”
在笔记数量突破上百篇后,光靠翻左侧的树状列表找东西会很累。
一个很管用的做法是:在每个重要的大目录下面,放一篇叫 目录名_入口.md 的索引文件。
这篇入口文件只做一件事:把当前目录下的关键主题、高频笔记链接整理出来。
比如根目录放一篇 首页.md,只挂核心入口;点进 02 个人知识_入口.md,里面只列主要技术模块的下一级链接。
无论库里积累了五百篇还是一千篇,从首页开始点,基本上三跳以内就能定位到具体页面。
首页内容怎么排
一个简洁的首页通常长这样:
## 一、高频入口(最常看的三个项目或方向) - [[工作项目_入口]] - [[个人知识_入口]] - [[100 日记/2026-10]]
二、当前焦点
本月主攻:搞定业务新系统上线,梳理相关技术栈笔记
三、其他归档
[[01 资料仓库_入口]]
[[99 归档_入口]]
四、归档守则
外部文章统统进 00 Inbox
完成的项目打包丢进 99 归档
为什么这套结构对 AI 很友好
如果一个目录里散落着几十个文件,大模型为了理清脉络得通篇扫描。
如果在文件夹里备好了一篇 index.md 或入口笔记,只交代“这个目录干什么的、重点看哪几篇”,AI 扫一眼就知道前因后果,省 token 也省推理时间。对人来说是地图,对工具来说就是现成的索引。
七、日记与模板
目录和入口搭好后,最容易让人长久记下去的其实是日记。
设置项
路径:设置 → 日记:
日期格式:YYYY-MM/YYYY-MM-DD (自动按月分文件夹存放) 存放位置:100 日记 模板文件:98 模板/日记模板
日记模板参考
## 今日待办 - [ ] - [ ] ## 作息与状态 - 起床: 入睡: ## 日常简记 - ## 业务量化数据 - 进度/交付: - 触达/沟通: ## 灵感与思考 - ## 明日预备 -
记录的关键是低负担。几句话、几个要点写下来就行,不要把它当成作文来写,形式越繁重越容易中途弃用。
八、让 AI 接管整理
前面七节讨论的是怎么把底子搭好。有了干净的纯文本库,就可以让本地的大模型工具参与进来做归纳和维护了。
在这之前,必须明确两者的分工边界。
传统整理的三种硬伤
纯靠人力去维持系统,时间一长大多会遇到瓶颈:

这三者的本质问题是一样的:人每天的注意力和意志力是有限的,靠严格的自律去做琐碎的分类打标,很难长期坚持。
合理的分工模式
人负责记录感受、提出观点和拍板决定;AI 负责跑脚本、批量打标、提取摘要和穿针引线。
永远保留自己的判断权,不要让 AI 去替你决定某个观点“到底重不重要”。
如何与本地工具打通
因为你的笔记就是纯粹的本地文件,直接在终端里敲两行命令就能把本地 Agent 工具接进来(以 Claude Code 为例):
cd ~/Documents/MyVault claude
工具启动后自动读取当前工作目录,不需要中间搭服务器转发。连上后可以先跑一条简单的测试指令:
概览一下当前库里有哪些核心目录,简单总结一下。
配合规则提升对语法识别的准确度
通用 AI 默认只会标准 Markdown。它不知道 [[双链]] 是什么,会把 callout 拆散,可能把 frontmatter 的 YAML 格式改坏。 也可以不装跳过到下一节,现在的AI 能力基本都能识别了!
Obsidian 的 CEO(网名 kepano)在 2026 年 1 月发布了一组官方 Skills 解决这个问题,包含四个:

装完 AI 就知道:遇到 [[ ]] 不要当普通链接处理,遇到 callout 不要拆散结构,遇到 frontmatter 要保留 YAML 格式。
全篇唯一一个敢说「必装」的东西,因为它修的是「AI 会把格式搞坏」这个硬伤,而不是锦上添花。
装法按官方仓库的说明来(这类工具迭代快,命令以仓库 README 为准)。
文件夹、标签与双链的职责划分
不要把所有的功能混在一起,各管一摊才是最清晰的:
文件夹管周期:只用它区分状态(比如进行中、已结项、归档、临时箱),尽量别拿它细分几十个学科主题。
标签管领域:给文件打维度标签,控制在一到两个常用标签,别无限嵌套。
双链管逻辑关联:标出点对点的引用与概念推演关系。
编写提示词守则:CLAUDE.md
在你的库根目录下建一个 CLAUDE.md(或者系统规则说明文件),本地工具启动时会自动加载。里面写好四件事:
1. 项目背景:使用者关注的技术方向、偏好 2. 目录规则:各编号文件夹的职责,哪些是原始记录,哪些是归档 3. 修改红线:明确禁止改动和删除的内容范围 4. 笔记规范:新生成文件必须遵循的 frontmatter 格式和双链写法
其中红线部分务必写死:
允许:补充标签、建立 [[双向链接]]、生成概括性摘要、在指定目录新建整合笔记 禁止:删除用户原笔记正文、改写用户的原笔录数据、清空现有文件
这个规则文件随着日常报错不断追加即可,遇到模型改坏了什么,就顺手往里添一条约束。
推荐的架构划分:raw / wiki / output
如果希望引入 AI 自动维护大量内容,建议建立清晰的层级目录,把人的手写内容和工具的生成内容隔离开:
vault/ ├── raw/ 原始输入:剪藏的网页、未加工的速记,只读不改 ├── wiki/ 加工后的结构化知识:概念页、词条、由 AI 辅助汇总沉淀 │ ├── concepts/ │ ├── topics/ │ └── INDEX.md ├── output/ 基于 wiki 生成的总结长文、分析方案 └── CLAUDE.md 规则手册 这套结构的核心逻辑是: * raw/ 是不可撼动的底层事实输入。 * wiki/ 是二次梳理后的成果,允许程序参与维护,人做微调。 * output/ 是对外发布的产物。 **严禁把手写碎记和 AI 大段生成的内容混在同一篇文件里。** 混得越久,越难分辨哪些是自己真正的想法,哪些是模型附和的套话。 ## **批量整理旧笔记的指令模板** 如果有大量零散的旧文件想做初筛,可以这样提示: ```text 扫描 unsorted/ 目录下所有的 Markdown 文件,针对每个文件执行: 1. 检查并补充标准 frontmatter(包含 title、tags、created、summary) 2. 根据核心内容归类,移动至对应编号的文件夹 3. 检查库中已有的概念词条,为相关实体补充 [[双向链接]] 4. 处理完毕后,在根目录生成一份整理记录,列出改动明细
原则:
严禁删减正文内容,只补充结构化元数据
无法明确分类的文件,移动至 00 Inbox 并做标注
单次执行最多处理 50 篇,分批执行
单次批处理规模控制在几十篇以内,人工扫一眼差异没问题,再放行下一批。
用 Git 作为安全垫
在放手让自动化工具大批量修改本地目录之前,务必把版本控制做好。
Git 能提供两样东西:改乱了随时一键还原的后悔药,以及通过 git diff 清晰审查改动的能力。
本地初始化操作:
cd ~/Documents/MyVault # 忽略界面布局类配置文件,防止提交干扰 cat > .gitignore <<'EOF' .obsidian/workspace.json .obsidian/workspace-mobile.json EOF git init git add -A git commit -m "初始化库"
平时只要准备让工具大动文件,提前随手打个提交:
git add -A && git commit -m "运行批量整理前备份"
万一改砸了,直接还原:
git checkout -- .
如果不熟悉命令行,可以在 Obsidian 里装一个 Obsidian Git 插件,设好自动定时备份。
规模与向量库的选择
个人笔记库究竟需不需要上复杂的向量检索方案?

对绝大多数日常记录而言,库内文本在二三十万字上下是很普遍的状态。当前主流大模型拥有数十万字上下文的处理能力,只要给它正确的索引指引,模型直接调取几篇关联文档读取就完全够用了,没必要过早把技术栈搞得太复杂。
九、几个能直接用的 AI 工作流
以下几个流程以不增加平时记录负担为前提:

1. 日记转每周回顾
平时写日记不要求任何格式,一句话一个待办都可以。
周末跑一次:
读取 100 日记/ 下属于本周的所有日期文件,总结一份周报: 1. 本周推进完结的项目(提取任务标记) 2. 记录过的思考闪念与洞察 3. 待下周跟进的事项 生成结果写入 weekly/2026-W39.md
平时散落记下的细小进展,周末就能直接汇总成一份脉络清晰的工作备忘。
2. 读书划线整理
看书时摘出重点,把零碎的划线直接堆进文件,不要停下来花力气排版:
读取 某某书籍-摘录.md: 1. 提炼全书的 3 到 5 个核心论点及支撑案例 2. 保留原标注里的读者个人感想,不要篡改 3. 搜索当前库内笔记,看看和哪些已有的概念产生了关联,加上 [[双向链接]] 整理后保存至 02 个人知识/某某书籍精读.md
这样既保留了原文摘要,又把新买的书直接挂接到了自己原有的知识脉络里。
3. 调研材料建档
做技术选型或竞品分析时,把几篇长篇评测、文档直接放进 00 Inbox:
阅读 00 Inbox 下与某某主题相关的所有调研材料,合并为一篇综合笔记: 1. 梳理基本定义、主流方案区别、当前社区落地难点 2. 每项结论保留信息出处 3. 建立相关知识的双向链接 结果保存至 02 个人知识/某某技术调研.md
下次遇到同类问题,直接翻这篇汇总,就能接着上次的结论继续推。
4. 基于现有笔记写初稿
不再面对空白文档发呆,让模型先当素材检索器:
我想写一篇关于「本地小模型在个人知识管理中的落地点」的文章。 请检索库内所有日记、调研记录和笔记,挑出所有相关的段落和历史观点列一个清单, 然后基于这些素材拟定一个包含论点的大纲。
大纲出来后,再让它顺着大纲填成草稿。此时你修改的是一个已经充斥着自己真实经历和手头资料的草稿,比起纯靠模型凭空编出来的东西要扎实得多。
5. 实体补全链接
写日常流水账的时候不用分心敲 [[:
读取 100 日记/2026-10-11.md: 抓取文中提到的技术名、人名、项目名, 检索库内是否已有对应文档,如果有,将纯文本改为 [[名称]]。 如果有重要概念但尚无文档,在结尾输出一份建议新建的词条清单。
把容易打断思路的琐碎关联工作,挪到写完之后集中处理。
十、常见坑
整理中踩过的弯路,列出来避坑:
把库直接丢进实时同步网盘:iCloud 或 OneDrive 的并发同步机制和频繁保存的 Markdown 容易互锁,导致生成大量类似 xxx(冲突副本).md 的文件,严重的还会吞掉最新修改。
还没写几篇就开始搞体系规划:写了不到十篇笔记,花了几天去雕琢层级架构。系统脱离了使用场景,最后往往因维护太繁琐而放弃。
一口气装太多插件:几十个社区插件同时跑,快捷键冲突,打开软件卡顿,最后大半精力用在排查插件 bug 上。
把文件夹当成唯一分类依据:一旦出现跨领域交叉主题,就不知道扔哪个文件夹合适。牢记:状态用目录,领域用标签,关联用双链。
不管什么格式全塞进库里:录音原文件、大几百兆的 PDF 扔进库,直接把本地目录撑爆,拖慢搜索响应。库里以文本为主,大文件尽量放外部路径。
缩写和指代不统一:同一件事换了三种叫法,导致全文检索容易漏掉。根目录常备一份术语表统一关键词。
个人原话与 AI 生成混在同一个文件:时间久了根本记不清哪些话是自己的推演,哪些是 AI 的补全。严格区分目录或文件名。
完全不做版本控制与冷备:纯文本不怕单个文件坏掉,就怕手误删了整个顶层文件夹。常备 Git 加上定期外部磁盘单向拷贝。
Git 仓库不排除窗口状态文件:.obsidian/workspace.json 每次移动窗口都会变,如果不写进 .gitignore,版本记录会被这类界面状态垃圾信息淹没。
十一、问题答疑
1. Obsidian 要花钱买吗?
个人免费,功能不阉割。官方的跨端同步服务(Sync)和网页托管(Publish)是付费的。日常放本地单机跑或者自己做备份,不需要掏钱。
2. 和 Notion 相比怎么选?
需要团队线上协作、复杂无代码数据库看板、现成花哨样式的,用 Notion;在乎数据隐私所有权、注重长期不掉线、希望离线可用且便于本地 AI 直读的,用 Obsidian。两者也不冲突,可以用 Obsidian 存核心知识,Notion 仅作为对外展示面板。
3. 笔记到底要不要分类?
少花时间纠结静态分类,多用双链打通。分类是单向的树形图,而日常思考是网状发散的。找内容的核心靠的是检索与关联上下文。
4. 图片等附件怎么存最规整?
建一个 04 附件/ 文件夹。在 设置 → 文件与链接 → 附件默认位置 里把它指定死,免得图片跟 .md 散落在同一个目录下。
5. 笔记写多了会不会越用越卡?
纯文本几十万字占用的磁盘空间微乎其微。变卡通常是两个原因:引入了太多未压缩的超大附件图片,或是后台装了一堆占用主线程的社区插件。
6. 手机端适合拿来做什么?
手机端最适合随时抓取闪念和查阅,不适合在小屏幕上大动干戈做归档重构。收集的事随手做,整理的事回电脑做。
7. 怎么做多设备备份比较踏实?
三处设防:工作电脑本地盘 + 移动介质冷备 + Git 托管仓。动重要目录之前养成确认状态的好习惯。
8. 必须要玩转关系图谱吗?
不需要。图谱最大的作用是隔一段时间看看知识关联情况,没必要把它当成刚需生产力工具,更不要为了让图谱好看而刻意刷链接。
9. 本地 AI 整理会不会把原笔记改坏?
只要没设边界就一定会。防范只需做好三道防线:第一,全局设定里写死“不得删除正文”;第二,提示词加上“只增补结构”;第三,用 Git 版本控制垫底,改乱了一秒回退。
10. 不用 AI 行不行?
完全行。Obsidian 本身的基础功能已经足够成为一个合格的离线知识库。AI 是在你积累了足够多的素材、不想花精力去做琐碎分类打标时,提供一个帮工,而不是记笔记的前提。
11. 一定要搞向量数据库(RAG)吗?
几十万字以内的规模完全用不上。大模型的长上下文配合合理的目录索引,直接读文件的效率和准确率已经很够用,不必徒增架构复杂度。
12. 能不能全托给 AI 自动帮我建知识库?
做不到。模型可以代劳跑腿、做归类、写摘要,但它无法替你决定“这件事究竟值不值得被记录”,更无法代替你的真实理解与业务决策。
总结
说到底,Obsidian 就是一个由你完全掌控的本地 Markdown 文件夹,顺便给各种本地运行的工具留出了最直接的读写窗口。
上手这个工具不需要太宏大的规划,真正需要想清楚的是:你记这些东西是为了在什么场景下用起来。
所谓知识库,不是为了证明自己读了多少东西,而是让过去的经历和思考能在具体写方案、做决策时,能被随时调用出来。
落地三步:
建好几个带编号的顶层文件夹;
在主要目录里写一篇简单的索引入口;
打开每日日记,从记录当天的几行碎片开始。
后面的结构让它自己长出来。至于 AI 辅助,先从“帮忙提取周报”或者“为摘抄提炼摘要”这种小事开始跑通,磨合顺手了,再慢慢放开更多归纳的工作。
无论是本地的 Claude Code、各类通用推理模型,还是其他兼容的命令行 Agent 工具,核心逻辑都一样:把控制权和原始文本留给自己,把跑腿的活留给机器。
作者提示含AI生成内容。作者声明本文无利益相关,欢迎值友理性交流,和谐讨论~
