Obsidian的CEO是怎么做笔记的？

Moy · 2025 年5 月 11 日 06:39

Ob 的现任 CEO Kepano 在自己的 How I use Obsidian 一文中，阐述了自己如何使用 Obsidian 的方法论。

初步研究之后，我做了一些基础的想法和要点记录，抱着“写都写了”的想法，遂分享之。

注：文章本身写得也很好，非常建议阅读原文——配合他的示例库一起查看效果更加！

关于作者

关于 Kepano
Kepano，原名 Steph Ango，现任的 Obsidian CEO；
或许你也用过他写的 Obsidian 主题：Minimal

关于插件

他文章里提到的插件很少，主要是使用了 Dataview 进行数据整合，用了另一个地图插件做地点记录。

结合他“只写纯文本”笔记的习惯，可以推测他库里只会安装非常少量的插件，并且基本只用原生 Markdown 语法。

基本原则

他在个人知识库中遵循的规则：

避免将内容拆分到多个知识库中（单一仓库）
避免使用文件夹进行组织（使用属性进行组织）
避免使用非标准的 Markdown 格式
命名时，始终使用复数形式的单词（例如只用 people 而不是 person），包括分类名称和标签（ #tags ）
大量使用内部链接（最短路径的 Wikilink 形式，如 [[链接]] ）
在所有地方使用 YYYY-MM-DD 格式的日期（这也是 DailyNote 默认的标题名称格式）
使用7分制进行评分

上面这段是原文摘录+补充说明，作为总纲，更多内容可以戳原始文章查看。

关于笔记结构

他基本不用文件夹组织文件，更不用嵌套文件夹——大部分笔记直接放在根目录
但是有一个单独的 Categories 目录，里面放了各种分类（例如 电影 、游戏、 桌游 等等）的索引笔记
基于这样的结构，他主要使用快速切换（Quick Switcher）和链接关系来跳转笔记，而不是文件浏览器（File Explorer）

他的 Categories 目录中的 Books 笔记

关于属性

笔记的元数据中会有一个类似 category: [[电影]] 的属性，与此对应的是 Category 目录下的 电影.md 笔记，这样一来，通过 Dataview 能查询到所有类别为电影的相关笔记
可以说，Kepano 使用这样的属性——而非文件夹——来组织笔记（既不是传统的文件夹结构，也不是标签结构，有趣）
同样的属性应该在不同类型的笔记间通用，例如所有的媒体笔记都可以用 genre 属性，不管它是电影、游戏还是动画
- 这里可以看到他的模板库中所有的属性： kepano-obsidian/.obsidian/types.json
属性名称保持尽量简短，例如用 created 而不是 created_date
对于可能存在多个值的属性，类型选择 list （列表）而不是 text （文本）

可以看到，Kepano 库里很多笔记甚至是纯数据笔记，只写了属性，完全没有正文内容：

——简直就像是从 Notion 导出数据库之后，里面的项目转换成的笔记。

关于笔记内容

关于 Kepano 笔记里记录的内容，可以说是「包罗万象」，并且不拘一格。

什么东西都可以往里记，有一个专门的 References 参考文件夹用于存放这些（非自己笔记的）外部条目。比如电影、电影院、餐厅……

可以说就是“啥都往里记”。

比如他举例的一条日记条目：

I went to see the movie  [[Perfect Days]]  with  [[Aisha]]  at  [[Vidiots]]  and had Filipino food at  [[Little Ongpin]] . I loved this quote from Perfect Days:  [[Next time is next time, now is now]] . It reminds me of the essay ...

就……很普通的一个随笔记录？但也没问题！

具体可以看示例库，这里不多赘述。

关于链接

从上面的那个日记示例也可以看得出来，他大量地使用了双链（甚至看起来在滥用）。

短短一段话里：

[[Perfect Days]] 是电影《完美的日子》
[[Aisha]] 是人名
[[Vidiotss]] 推测是电影院
[[Little Ongpin]] 估计是餐厅
[[Next time is next time, now is now]] 是这部电影里的一句台词摘录——是的，这个也有单独的一个链接！！

说实话第一次看到这么泛滥的内链使用我是很震惊的……
平时一篇笔记里可能也就三四个内链，他这一段话就5个了，甚至还有「把一整句句子作为内链」这种堪称离谱的用法！

但是转念一想，Obsidian 当年出圈主打的两个热门特性就是 知识图谱 和 双向链接，这种用法也算是完全挖掘出「双链」的特性了。

不过具体实践上，见仁见智，感觉可以适当参考，也不用真的给家附近的餐厅和电影院啥的都创建上双链……吧

创建链接的技巧

说到这里也补充两点：

善用「空链接」，也就是你可以写 [[这样一个完全没有同名笔记的链接]] ，Obsidian 也是会识别的，而且在下次输入 [[这样一个 的时候也能弹出对应的补全
- 你可以先这样写着，直到它数量确实够多的时候，再创建链接实际指向的笔记
- 而当实际笔记创建的时候，它的反链就能显示出过往所有提及到自己的笔记
最常见的链接方式是输入两个 [[ 符号然后选择，在此基础上，有一些插件可以优化体验，例如：
1. Easy Typing 插件可以把 「「 或者 【【 映射成链接符号，这样在中文输入法下也不用频繁切换中英文符号
2. Various Completions 插件可以在你打字的时候，自动弹出同名笔记选项，这样甚至能直接省略输入符号的步骤，直接写笔记名然后选择即可

通过 VariousCompletions 直接显示同名笔记

关于链接格式

另外，你应该也看出来了，对于链接格式他选择的是：「尽可能简短的形式」+「Wiki 链接」选项

我曾经为了像是和 Typora 之类软件的兼容性，类型会选择「相对链接」，但最终用下来发现「最短 wiki」确实是最适合 Obsidian 的链接形式，这样笔记的移动完全不会影响链接，是最省事儿的！

所以，我也推荐按这个配置来！很香的！

（甚至更进一步，你可以把所有的图片也都塞进同一个附件文件夹里，讲究一个「大道至简，无为而治」）

笔记属性内的链接

这其实也是我看完他的示例库才开始大胆用的一个特性：
在笔记属性里写双链。

源代码模式下查看是这样的：

---
people:
  - "[[Kepano]]"
---

Obsidian 原生就支持将它解析成链接，通过这个属性你可以直接点击跳转到对应的笔记，会很方便。

关于一致性

这点其实也是我学习到最多的一点。

保持一致的风格可以将数百个未来的决定合并为一个，并让我集中精力。例如，我总是将标签复数化，这样我就不必想如何命名新标签。
选择让您感觉舒适的规则并将它们写下来。制作您自己的风格指南。您以后可以随时更改规则。

举几个关于“一致性”的例子：

总是选择单词的复数，这样就不用考虑 Category 还是 Categories ——直接选后者！用这个策略，应该创建像是 Clippings、Projects、Works 这样的文件夹！
总是使用7分评分制
所有用到日期的地方，统一使用 2025-05-11 这样的固定日期形式
- 首先，这样带来的好处是，每日笔记（DailyNotes，默认日期格式就是 yyyy-MM-DD）中可以通过反向链接查看到所有和当天有关的笔记
- 其次，这也能让你搜索的时候不用考虑搜 5月11日 或者 5.11 之类的变种格式，保持统一的情况下，你只需要搜索 05-11 一个关键字。

看完之后，我自己做的一些调整：

重命名了大量笔记——以前我会有一些 2025.05.11 格式的日期前缀，现在统一都改成了 250511_ （嗯，这点算是我的坚持，因为笔记名不希望太长）
把输入法中快速输入的日期也从 2025.05.11 换成了 2025-05-11，兼容每日笔记基础格式
重命名了部分标签和文件夹名称，都按复数形式来命名

我获得的一个感受是：
需要想的规矩越少，记录的阻碍就越小。

所以，一定形成了你自己的「固定一致性原则」，你在执行的时候就可以完全不去“重复思考”，直接按照既定规矩自动化执行即可。

（而且，毕竟是自己的规矩，所以也不用拘泥于“祖宗之罚不可变”，哪天想要做出调整的话，调就是了）

一些学到的经验

大胆创新！
——这里的新指“新笔记”、“新链接”以及“新模板”，反正都是纯文本文件，你怕什么！需要就创建新的！创！多创！
人家模板文件夹里有 57 个模板！！

你的笔记是非常私人且自由的：不要怕记多，更不要怕记错。

而且对于“文件名”（链接）也不要墨守成规，纠结什么格式啊标点符号之类的。
只要文件系统允许的命名，都可以写！

保持灵活，保持开放。

总结

以上，这就是我对于 Kepano 使用 Obsidian 的方式的拆解和思考，希望能给你带来一些新的构想。

不过也需要说一句，虽然他是“Obsidian 的 CEO”，但这不代表他使用 Obsidian 的方式就是「权威」和「标准」。
别人的做法是基于他们自己的人生经验得出来的，不一定适合自己。
可以借鉴的，学习之，同时也要保留自己的风格和坚持。

还是那句话：适合自己的，才是最好的。

L1B3 · 2025 年6 月 6 日 08:31

CEO的日常购买建议
大家可以看看他的个人blog，里面写着他一些日常学习工作生活的小巧思

aoout · 2025 年6 月 11 日 01:23

我一直都感觉挺奇怪的，这应该就是最传统的双向链接笔记的做法，但是观察 Obsidian 社区，这种方法似乎已经被 Obsidian 用户遗弃了，转而去研究各种复杂的目录结构，甚至可以说越来越复杂，觉得越复杂越好。

我在三年前就发帖写过，文件夹，标签，双向链接本质完全是相同的，用任何一者都能构建出几乎完全一样的笔记系统。

记得有一段时间是各个笔记服务推出嵌套标签功能的热潮，我想这种结构化的系统在某种程度上还是最符合人类的直觉，即想要“找到“一个东西，就把它贴上对应的”标签“，或者放在对应的”地方“。这都是暗合物理世界的法则的，而双向链接在物理世界中并不存在直接对应。但是我一直觉得，这种非直觉性，才是双向链接给我带来的思维上的最根本的改变。

Moy · 2025 年6 月 11 日 04:49

我一直都感觉挺奇怪的，这应该就是最传统的双向链接笔记的做法，但是观察 Obsidian 社区，这种方法似乎已经被 Obsidian 用户遗弃了，转而去研究各种复杂的目录结构，甚至可以说越来越复杂，觉得越复杂越好。

「这应该就是最传统的双向链接笔记的做法」
——或许是的！可能称之为“正统”也不为过，哈哈。

不过与其说是「被用户遗弃」，我感觉更像是「还没广泛地被学习」。毕竟……以我自己为例吧，在接触到 OB 之后，我也会最先用自己熟悉的“文件组织结构”（文件夹）去进行构架——更何况 OB 的 Vault 本身遵循系统的文件层级，也使得这个操作变得“自然而然”。

反而是这种“原初的”双链的用法，是需要额外付出学习成本才能理解和掌握的。

我在三年前就发帖写过，文件夹，标签，双向链接本质完全是相同的，用任何一者都能构建出几乎完全一样的笔记系统。

很巧，我前阵子也就在梳理这三种的差异和使用场景（我的对比中，用的是 categories 这个更特化的“双链”）

虽说理论上——用足够多的技术和技巧——可以让这三者都实现“类似平替”的特性，不过还是有它们各自原生最擅长且适合发挥的领域。
（换句话说，最“不折腾”的使用方式）

而标签和 [[Categories]] （存在属性区域的双链）就是最让我感到困惑的。

到目前为止，我梳理出来双链和标签对比，最大的一个特性和优势是“解耦”。
使用双链建立的关系，发生变动时修改的影响是最小的；可能是出于程序员思维，会更青睐这种干净的感觉。

举个例子，如果将 #A/B/C 中的 A 修改为 α，所有涉及到的子级标签，以及带有这些标签的文件都会发生变动；文件夹的改名/移动亦然。
这种大范围的变动是会让我觉得很不爽的 : /

其次，是“关系的描述”。
它创建的联系完全是逻辑层面的一种“关联”，不同于 A/B/C 的文件夹结构或者 #A/B/C 的标签，它完全可以让 C 的上级同时是 A 和 B。
此外，它的联系是更精准的——比起标签的“关系”，它还能描述“什么样的关系”。

比如 上级: [[A]] 和 归属: [[B]]，不光能表达存在关系，还可以呈现出更具体的“关系类型”。

对标签来说或许也能实现，但可能就需要专门维护更特定的标签规则体系了
（我标签用的实在是少……这部分的理解如有错漏还请斧正）

aoout · 2025 年6 月 11 日 06:37

曾经我只使用一个属性 up 来链接到上一级笔记。后来看了 How I use Obsidian — Steph Ango ，想到我这样其实是浪费了键名本身的含义。于是我重新整理了库，把原本的 up 分解为 categories 和 topics 两种属性。以往，我自己写的小说本体，和一些我关于小说创作的心得体会，剪藏全都混在了一起，现在就分开了，表意更加明确。

其实对于文件夹来说，文件夹代表着什么，这件事是模糊不清的。比如，如果我分为健康，学习，游戏，那这是按照话题来分。如果同时我又有一个剪藏文件夹，那这就是按照来源来分了。这导致我自身的游戏内容和剪藏的游戏内容被分开了。但是本不应该这样。

而对于标签，我当然也可以创建“小说/本体”，“小说/心得”这样的嵌套标签，甚至可以是“分类/小说”，“相关/小说”这样的嵌套标签，实际效果都是完全一样的（虽然我的审美并不接受这种标签设置…），标签其实就是一个没有本体笔记的链接。同样链接就是本体也是一个笔记的标签。具体的差异只在于软件设计层面，而不是理论层面（譬如，有的插件可以给每个标签也创建一个标签笔记，还有给文件夹创建文件夹笔记的插件，但是原生层面上只有链接有对应的笔记）。在 Obsidian 中，点击标签，会在左侧展示对应的查询结果。而点击属性链接，会进入对应链接笔记。

至于笔记中写了什么，之前是 dataview，现在是 bases，是一个自定义程度显然要比一个查询结果更强的仪表盘。bases 之后肯定要加入更多 layout 的，到时候还可以根据不同属性选择不同 layout。

同时，也不仅仅是 bases，也可以加入对于该属性的描述。

所以从这个角度看，我现在个人的看法是，标签是一个轻量级的链接，链接是一个重量级的标签。有需要的时候用链接，没有需要的时候用标签。

Moy · 2025 年6 月 11 日 07:11

于是我重新整理了库，把原本的 up 分解为 categories 和 topics 两种属性。以往，我自己写的小说本体，和一些我关于小说创作的心得体会，剪藏全都混在了一起，现在就分开了，表意更加明确。

对的对的，这个就是「双链」在结构上比起另外两种形式最大的优势之一我觉得~

更何况这个链接到的“本体笔记”本身就是一个自指的「说明文档」，而不需要像文件夹那样用额外的插件来构建“文件夹的笔记”（虽然我也同时在用 FolderNotes 插件，很好用哈哈）

以及正如你所说，Category（之类的页面）本身还具备根据自己的特性进行不同的类目笔记呈现的功能，这也是其他二者很难实现的。

甚至可以是“分类/小说”，“相关/小说”这样的嵌套标签

这个其实就是标签的一个局限所在了，即：一个元素在不同的分类层级下可能出现在多个嵌套结构中。

“文学/小说”、“分类/小说”、“相关/小说”……它们都是“小说”，但为了不同的结构而被分进多种不同的嵌套标签内，这在我看来是相当混乱的。
除非做到嵌套结构中的元素具备足够的「唯一性」，但这样也对“如何分类”做出了相当高的要求。

不过最后还想到一点，再补充一下：
标签在我看来倒是也还有一个非常大的不可替代性——就是它可以足够零散。

我完全可以在文章的任意位置打上一个 #回头看一下 的标签，方便需要的时候回顾。这种灵活性和“低负担”也是它的独特优势。
（只是也需要控制好数量避免标签过于杂乱）

Benton · 2025 年6 月 14 日 10:14

請問只使用 UP 屬性鏈結上級筆記為何浪費鍵名本身的含意？對此感到困惑，希望能有更多的說明。此外，可以說明下 categories 和 topics 兩種屬性的差異嗎？我的理解是 categories 類似於關鍵字，但困惑於與 topics 的差別在哪？

我認為卡片筆記關鍵在於卡片內容與卡片鏈結，只有確保兩者的高品質，才能合適地與卡片對話。因此我會關注相關話題，還請不令指教。

Moy · 2025 年6 月 14 日 10:34

可以看一下 Kepano 原文，以及他附带的示例库。

其实是单一的 up 属性太过笼统了——
举个例子，Josef Fares 既是游戏制作人，又是电影导演。

对于他的3部作品，我们可以这样：

祖祖
up: [[Josef Fares]]

双人成行
up: [[Josef Fares]]

双影奇境
up: [[Josef Fares]]

这个时候，在 Josef Fares 里可以用 up == this 来筛选出这些笔记。
但是，并不够准确，知道大概知道“都是他的作品”。

反之，如果是：

祖祖
director: [[Josef Fares]]

双人成行
producer: [[Josef Fares]]

双影奇境
producer: [[Josef Fares]]

这个时候，就可以根据属性本身，分列出他“作为导演”的作品以及“作为制作人”的作品。

（不过在一些特定笔记，父子关系明确的时候，只用 parent 或者 up 亦是没问题的）

aoout · 2025 年6 月 14 日 12:18

其实我觉得问题在于需要多少的精度。在我的库的定义中，categories 表示某一类笔记的“类别”，而 topics 表示某一个笔记与其他笔记的“相关。topics 其实很粗略，还可以细分。

大概就是这样。

所以说是浪费确实不算特别准确，可以说是精确度不符合我的要求。