找笔记方便、写作又给力的知识库,我是这么搭建出来的 好在经过一年多的摸索,我已经愈发感觉到自己的知识库在接近期望的形态了,能让我写出那么多精选文章,已经能从某种程度体现这套知识库的实用性。

Matrix 首页推荐 

Matrix 是少数派的写作社区,我们主张分享真实的产品体验,有实用价值的经验与思考。我们会不定期挑选 Matrix 最优质的文章,展示来自用户的最真实的体验和观点。 
文章代表作者个人观点,少数派仅对标题和排版略作修改。

「早就想偷学你记笔记的方法了」

听闻我要分享如何做知识管理,我的一个朋友如是说。

我大概能理解他想学的原因,多半是我之前发的文章给他留下了印象,在最近的这一年内,我写了 10 篇文章,其中 6 篇发机核的拿到了精选、两篇发少数派的拿到了首页推荐,而最近在机核新发的两篇,也都获得了过百的收藏量。

我近期发在机核的两篇文章,都得到了不错的反响

能做到这些,离不开我的笔记和知识库。

我其实摸索知识管理一年多了,但此前一直没有分享过自己是怎么做的,因为我卡在了实践上。试了不少工具方法、也看了很多教程,但就是很难理解好的知识管理具体要怎么做。

这其中印象最深的就要属「卡片笔记写作法」,即便去看原书,也硬是弄不明白如何做,就好像刻意藏着掖着不想给人知道,让我一度非常沮丧,我只能照着自己对书中内容的理解,一边试验性的搭建知识库,一边搜集其他相关的教程、根据实际使用的情况迭代。

好在经过一年多的摸索,我已经愈发感觉到自己的知识库在接近期望的形态了,能让我写出那么多精选文章,已经能从某种程度体现这套知识库的实用性。而每当我要写文章、想找知识库里现成的笔记时,我都能发现有至少 4 种可选的搜索方法

回想一个或多个标题 / 正文里的关键词,直接找:

回想笔记所在的位置,顺着目录结构逐级往下找:

回想可能链接到这篇笔记的另一篇笔记,顺藤摸瓜的找:

回想笔记可能归入的专题索引,通过索引内的分类寻找并跳转到笔记:

在这篇文章中,我将介绍自己是如何搭建这一套知识库的,如果你也曾像我一样,苦于不知道如何做好个人的知识管理,或是面临笔记堆积成山、找起来头大的问题,我的分享或许能帮到你。

为了避免理解上的困难,在具体说明我的搭建方法前,我想先介绍下这套知识库的构成,但如果你已经开始好奇这套知识库是怎么搭建的了,也可以直接跳转到「我是如何搭建的」。

因为我目前在用的工具是 Obsidian,本文中都会以 Obsidian 举例,但这并不代表搭知识库只能用这一种工具或只能用我的步骤方法,希望你能更关注我在选用特定工具方法时的目的,以便寻找最适合你的工具方法。

这套知识库的构成

笔记

我基于自己从《卡片笔记写作法》的理解,在知识库里存放了 3 种笔记。

闪念笔记:储存突然出现、稍纵即逝的灵感或感悟的简短笔记,比如某一天突然想到两个领域可以碰撞出某种新的火花,就会写一条这种笔记。

文献笔记:储存基本沿用原文表达和结构的笔记,比如译文、摘抄的原文。

永久笔记:储存用自己的话表达、以复用为首要目的的笔记,类似一篇篇独立的文档,知识库最主要的组成部分。

文件夹

对应上面介绍的 3 种笔记,我也建立了 3 个一级目录分别存放它们:

文件夹名称里的数字仅用于排序,而这个顺序则是根据我自己的感觉来定的,我觉闪念笔记算是思考得最浅的,永久笔记则是思考得最深的。

除了这 3 个目录,我还新建了一个名为 images 的目录用来储存图片,因为我的笔记是用 Markdown 写的,而 Markdown 文件的图片必须从外部引用,将所有图片存在同一个地方能让我的笔记目录保持简洁清爽。

而这 3 个目录之下,也都有着不同的二级目录结构:

可能有人会好奇,为什么这 3 个目录下要用不同的结构?由于这套结构是在实践中逐步摸索发展出来、并非最开始就设计好的,这里仅分享下我对这些做法的个人理解:

其实我确定分类方法的思路,可以总结为两点:

下面我来说说,我是如何从零开始搭建这套知识库的。

我是如何搭建的

创建顶层目录

我最先做的一步,就是为前面提到的 3 种笔记创建对应的文件夹,我在 Obsidian 库中最顶层分别创建了 3 个文件夹:

这之后,为了集中存放图片、保持笔记目录的清爽,我创建了一个名为 images 的文件夹,在目录中右键,将其设为了附件文件夹

至此,这套知识库有了一个基础的框架,就像为了种植不同的作物、在一大块田里划分了多块区域,接下来该准备播种了。

写闪念笔记

就像我在前面所说,我理解的闪念笔记是一种简短的笔记,用于记录突发的灵感或感悟,以便后续合并到其他笔记。

我在 Obsidian 里写这种笔记时,会用到软件自带的核心插件「时间戳生成器」,第一次使用需要先手动启用插件,再 Obsidian 中依次打开:设置 > 核心插件 > 搜索插件 > 时间戳生成器,点击开关启用。

在核心插件设置中,启用时间戳生成器

启用后,就可以通过各种方式创建时间戳笔记了:

每当我有突然的灵感时,只要条件允许,我都会立即打开 Obsidian 新建一个时间戳笔记。通常我更倾向于用快捷键创建笔记,因为这样速度更快、能让我尽快抓住稍纵即逝的灵感。

新建笔记后,我会在标题的时间戳后加上一段话、作为正式的标题描述,这段话要尽可能概括我准备在笔记中写的内容,比如《202211252119 免费内容如何参与黑五促销》。

闪念笔记先写标题、再写内容

对我来说,这样做的好处有两点:

写闪念笔记的正文时,我不会给自己特定的结构限制,只要记录的信息有助于日后再次使用,是否插图、用不用有序 / 无序列表都无所谓。

如果写的过程中涉及到了自己知识库中的其他笔记,我也会加上链接,以便后续顺着关联性整理笔记。在 Obsidian 中,默认输入两个左方括号即可唤出笔记的搜索框,再输入文本就可以按标题搜索笔记,最后选择要关联的笔记,就会创建一条新的链接。

Obsidian 唤出笔记搜索框

如果一时半会想不起要找的笔记标题是什么、或是找不到笔记,我会按 ctrl/cmd+shift+F 切换到全局搜索,用标题 / 正文的关键词找笔记,再回到闪念笔记中创建链接。

全局搜索,用标题 / 正文关键词找笔记

在此基础上,继续完善写完标题概括的内容,一篇闪念笔记就完成了。

对我来说,闪念笔记就像是某天吃到了惊艳的料理,激动的写了一段评价,讲这道料理有多好吃、让自己想起了某段愉快的记忆,简短、但没法让我做出同一道菜。

写文献笔记

文献笔记是保持原文表达的笔记,我通常会在这几种条件下写:

记这类笔记时,我通常要关注两个区域,一是原文,二是新建的笔记,因而我的查看方式也会取决于原文:

图书和论文方面,因为我平时输入比较少,这里就暂不分享了。

新建一条文献笔记后,如果原文自带标题,我会直接沿用原标题或将其译为中文,如果原文没有标题,我再根据内容概括一个标题,就像写闪念笔记时所做的那样。

如果原文自带标题,我会直接沿用原标题或将其译为中文

接着,我会参考原文的类型将笔记移动到合适的位置。比如要翻译一篇宣传片教程文章、作者是资深宣传片制作人 Derek Lieu,我会将笔记移动到 2-文献笔记/文章/Derek Lieu 目录下,这样一来,之后就可以通过回忆原文信息快速找到这篇笔记。

出于习惯,完成这一步后我也会在笔记的结尾记下原文链接 / 出处,以便下次需要确认原文或继续查看时,能快速回到原位。

我习惯于在文献笔记结尾放链接

到这里,一篇文献笔记就有了标题、放到了合适的位置、也存好了原文链接,剩下的正文我通常有两种记录方式

一串推文的原文 vs 笔记

这一步完成后,一篇文献笔记也就写完了。

文献笔记对我来说,就像是吃到了惊艳的料理,拍下照片,记下了食用体验、能看出来用到的食材,甚至冲进厨房从头到尾拍下厨师的制作过程,相比吃后评价(闪念笔记)多出了一些具体的信息,但也还不足以让我做出同一道菜。

写永久笔记

永久笔记是用我自己的话表达、以复用为目的的笔记,我一般会在这些情况下写:

近期学到的新知识,可以写成永久笔记
文献笔记里发现有价值的知识,也可以重构成永久笔记

上面这些情况,能说明某个时间点、我在某个主题下知识储备够多了,但要怎样才能写出易于复用的笔记?

我的答案是为笔记选用合适的框架

每当我准备写一篇永久笔记,我都会先想象写完后自己要如何用这篇笔记,再从 3 种文档类型里选择最合适的一种(文章类除外):

这套文档分类并非我的原创,而是从别的领域迁移过来的,我曾有段时间在研究如何写出好的开发文档,偶然找到了 Youtube 视频《What nobody tells you about documentation》,其中介绍了 4 种文档类型(比上面介绍的 3 种多了一个教程)。

4 种文档目的各异、却又被学习和工作串联,大部分教程 / 笔记之所以难用,往往是混杂了多种类型

因为这些文档和知识库中笔记的定位很贴近,我便尝试用在了自己的知识库里,意外发现完美匹配我的使用需求,便一直用下来了。

在 Obsidian 中,可以通过 # 和文本来加标签,选定一种文档类型后,我便会在笔记的开头加上对应的标签:

这样不仅指定了笔记的预期用途,而且可以用标题时刻提醒自己,避免写的过程中偏离了预期的方向。

但这还只是开了个头,选择的文档类型不同,笔记的写作思路也会有所不同,接下来我分别介绍下自己写这 3 种笔记时的关注点。

操作指南

操作指南是帮助解决一个具体问题的笔记,侧重于描述指导实践的做法。

写操作指南时,我会先起个好标题,需要满足这两个条件:

比如我想写一篇笔记,讲用 Python 从网页爬取数据、需要用到一个名为 Scrapy 的库,好的标题可以是《如何用 Python 爬取网页》,不太好的标题可能是《如何使用 Python 的 Scrapy 库》,因为前者更好的体现了「做什么」。

明确标题后,为了确保自己能写出清晰的操作指南,我在写笔记正文时还会考虑一些点。

操作指南可以分步骤,也可以是实践向、没有特别明显步骤的

总结一下,操作指南我是这么写的:

  1. 起个面向实践的标题,比如《如何 xxx》
  2. 提供可实践的步骤 / 做法
  3. 选择合适的起点
  4. 注重结果,而非解释
  5. 允许多种途径

解释

解释类笔记正如其名,旨在帮助读者理解一个或多个相关的术语、概念或某些因果关系。

我在写这类笔记时同样很关注标题,好的标题应该一眼就能看出来是解释某些东西的,具体来说,我会考虑这两种表达:

定好标题后,写这类笔记的正文时,为了做到通俗易懂、实用的解释,我也会关注一些点。

wiki 的内容很详细,但写给自己看的东西,还是得用自己看得懂的话
用图像、视觉化的内容解释
举个例子
打比方、用比喻
在分享自己创作经验的文章中,为了更好的让读者理解工具的适用场景,我会特别解释选工具的原因

最后,我还会为解释类笔记加上别名,这是一个 Obsidian 中支持的功能,为笔记指定一个或多个文本作为别名后,就可以额外通过这些文本搜到这篇笔记,这其实是方便了我后续的找笔记。

比如《游戏的钩子》这篇笔记,这个概念对应的英文是 hook,我就会在笔记的开头写上这样一段内容,加上「hook」和「钩子」这两个别名:

它们在 Markdown 里其实是这样写在开头的:

---
alias: hook, 钩子
---

加上别名后,我就可以通过别名的文本搜到这篇笔记,不管是全局搜索还是创建链接时都支持:

总结一下,解释类笔记我是这么写的:

  1. 选一个能体现出概念 / 因果解释的标题
  2. 讲自己能听懂的话
  3. 选择合适的解释方法
  4. 讲清前因后果
  5. 避免讲做法、或写成结构化的参考

参考

参考类笔记像 wiki、字典一样结构化,查阅时往往只需要关注特定部分的信息,比如发布文章前的检查项目、数据库常用的查询代码、用不同器具制作咖啡时手磨的研磨度。

和前面两种笔记一样,参考类笔记也要一个好的标题,根据我的经验,我倾向于在标题中纳入找笔记会用的关键词

比如一篇参考类笔记,描述了用不同器具制作咖啡时,推荐手磨设置的刻度,我用的标题是《C40 制作各类咖啡的研磨刻度参考》,其中的关键词是「C40」和「刻度」。

在写这类笔记的正文时,为了让自己日后能更便捷的查阅参考,我也有一些考虑的点。

使用对查阅友好的结构:就像我找笔记时借标题理解其中的内容,在查阅参考类笔记时,我也会通过大纲中的子级标题理解对应部分的内容。为了帮助自己更高效的查阅,我也习惯于将查阅的关键词作为标题。

比如上面咖啡手磨刻度的笔记,我在查阅这个笔记时相当于在问「要制作 xx 类型的咖啡,我应该将手磨的刻度调到什么范围内?」,查阅的关键词都是「咖啡类型」,因而笔记内的子级标题最好都是咖啡的类型。

C40 手磨研磨刻度的笔记,不过这个例子算比较极端了,其实这里数据这么少、我完全可以用一个表格解决

只提供查阅所需信息:提供的信息应该刚好能满足查阅的需求,避免添加过多无关信息、导致查阅的效率变低。

还是手磨刻度笔记的例子,我在查阅时只需要知道「刻度范围」,因而每块内容中讲清推荐的刻度范围即可,而不应出现「如何调节刻度」这样的内容,后者适合单独写一篇笔记,必要时通过链接引用。

保持准确一致:参考类笔记中的内容需要经常查看,为了避免误导,需要持续更新、保持内容的准确性,而为了提高查阅的效率,也最好使用一致的结构、语气和格式。

总结一下,参考类笔记我是这么写的:

  1. 用找笔记的关键词起标题
  2. 使用对查阅友好的结构
  3. 只提供查阅所需信息
  4. 保持准确一致

至此,便是我用 3 类文档框架写永久笔记的做法。

永久笔记对我来说,就像是我为了能还原某道好吃的料理,反复摸索尝试后写出的食谱,能指导我的实践行动,告诉我要准备哪些食材、如何烹饪、最终还原出那一道料理。

这样的笔记不管内容上还是形式上,都离不开「让自己高效复用知识」的目的。

链接笔记

每次写笔记时,我也会关注其中是否有关联到其他笔记的内容,如果有的话,便会新建一个链接、在对应的位置链接关联笔记。

在知识库的长期使用中,我发现链接笔记主要有这两个好处:

但什么时候才要链接笔记?在写这篇文章的期间,我也随机回顾了不少知识库中的笔记,发现我创建链接的场景主要有这 3 种

Obsidian 管这种内部笔记间的链接叫「内部链接」,要新建一个内部链接,可以在编辑笔记时连输两个 [ 、唤出内部链接菜单:

Obsidian 唤出内部链接菜单

此时输入文本,即可用关键词搜索标题,查找匹配的笔记:

Obsidian 内部链接,输入文本搜索笔记

最后,选中要链接的笔记,链接就创建成功了:

创建好的内部链接

点击内部链接,便会打开对应的笔记、跳转到开头,但我通常还会有一些额外的需求:

大部分情况下,我更需要下面一种简洁的表达

我在 Obsidian 里都找到了对应的解决方案,比如希望打开笔记后跳转到特定位置,可以在链接中输入 # 搜索并选择标题。在内部链接中用 # 唤出标题选单

在内部链接中用 # 唤出标题选单

如果想要跳转到更精确的位置,比如另一篇笔记里的某一段文字,则可以在链接中输入 ^ 搜索并选择对应的内容,注意这种格式和链接到标题只能二选一

在内部链接中用 ^ 唤出文本块选单

要自定义链接显示的文本,可以在链接的末端输入 | ,然后输入要显示的文本,比如 [[一大串超长的笔记名称|这篇笔记]] 会显示为「这篇笔记」。

自定义链接文本编辑模式 vs 阅读模式

在链接笔记时,笔记的别名也能提高我找笔记的效率和成功率,就是我在解释类笔记里提到过的那个 alias,因为有时候脑子一抽、就是想不起来要找到的那个概念的中文 / 英文叫什么,如果设置了自己印象深刻的别名,就可以用还记得的关键词都试试。

链接笔记时也能搜索 alias 别名

维护子级目录

前面已经讲了我是怎么写各种笔记的,但搭建易用的知识库显然不只是写笔记这么简单,因为时间一长,知识库里的笔记也会堆积,导致很难在文件列表里找笔记,这也是我不得不面对的问题。

想象一下这个列表的长度翻上几倍,大概就是我曾经面临的情况

试过不少方法后,我最终选择了不预先创建目录、而是等某个文件夹的笔记堆积到一定量再建,也就是自下而上的搭建目录,因为我发现这么做对我有两个好处

具体来说,我并没有为触发目录更新设定一个精确的笔记堆积量,更多是凭感觉

每当我存入一篇新笔记、或是随意浏览文件列表时,我都会扫一眼可见范围内同级的笔记数量,如果笔记数量已经堆到我一眼看了就无法忍受,我就会开始在这一级更新目录

我会快速扫视这些笔记的标题、先对它们的内容有一个大致的印象,然后选一个能纳入最多笔记的分类、新建文件夹、将对应的笔记移动进去。

文献笔记大多可以依靠原文类型、来源平台 / 作者建立子级目录,但永久笔记都是自己的话写出来的,最好有一套定制的目录,而且目录的结构不能太过复杂,否则找笔记也头疼。

文献笔记的子级目录

为此,我为永久笔记下的子级目录指定了命名规范,统一用 000-分类名 这样的格式,3 位数字分别代表一级、二级、三级目录的序号,也由此限制了子级目录的宽度和深度。

以我最近在学的游戏宣传片领域为例,对应的目录逐层深入就是:

在为子级目录写分类名称时,我也会尽可能保留一定的拓展空间、避免范围限得太小,但即便一时没选好也不会有太大负担,因为后续的目录维护也能换更合适的分类名,必要时还可以重新移动笔记位置。

维护索引

要找一篇笔记,除了搜索标题 / 正文关键词、顺着目录结构找、顺着内部链接找,我在开头还提到过一种途径,不知你是否还能回想起来?

答案是通过索引跳转。

索引相当于笔记的中转站、传送大厅,其中专门整理了同一专题笔记的链接,并且会用多级标题将关联的笔记分门别类,便于我高效查阅、找到所需的笔记,这个角度来说,索引也算是一种参考类笔记。

每当我发现知识库里的笔记可以凑够一个专题,我就会尝试新建一个索引笔记,将关联的笔记链接都收录进来。

至于多级标题如何取,一级标题我会用文档框架分,比如如何做、参考、解释,二级再视情况「自下而上」创建,选择对我自己有意义的分类。

索引内的标题,也是自下而上生成的

对我来说,索引算是锦上添花的存在,相当于额外搭建了一个找笔记的途径,而整理索引的过程中,也会帮助我深入理解原有的笔记。

总结

以上,便是我目前这套知识库的搭建方法,基本可以概括为 3 步

  1. 创建顶层目录
  2. 写笔记存入
  3. 维护发现笔记的渠道

在摸索这套知识库的过程中,我也发现了这 4 个对我帮助较大、让我学得更深的技巧

但我必须承认,这套搭建方法并不完美,比如现在就还存在这两个问题:

要搭好个人的知识库,方法也不一定只有这一种,这么做只是暂时满足了我当前对找笔记和写作的需求。可以预见的是,在未来的时间里,我也会继续把这套知识库折腾下去,在学习、记笔记和创作的过程中持续优化它。

希望我的做法和经验能对你有所启发,帮你更好的学习新知识、创作自己的内容。

至于开头提到的那位朋友,看完这篇文章的草稿后,他留下了这句话:

「一年,你知道我这一年怎么过的吗」

> 少数派请你做地图:城市声音收藏夹火热征集中,期待你创作的城市之声 🎧

> 下载少数派 2.0 客户端 、关注少数派公众号,解锁全新阅读体验 📰

> 实用、好用的正版软件,少数派为你呈现 🚀

全文完
本文由 简悦 SimpRead 转码,用以提升阅读体验,原文地址