article_image

注:本系列文章中的“卡片笔记”为狭义解释,均指观点类的笔记。分类是进一步讨论的前提,有关笔记分类,请参阅 《卡片笔记中的三种笔记类型》 。关于“API”这一隐喻,我最早的用词是“程序”或者“Unix 程序”,而 Andy Matuschak 提出的“API”更明确、更形象,遂拿来主义了一把。

同时存在着词的世界和物理的世界。如果一个物体和合适的名字配在一起,就可以激活两个世界的潜能。——特得姜:《七十二个名字》

相互引用,让笔记联结成网;但是,黑箱这个隐喻,预言了引用卡片时将难以逾越的沟壑:我们总是不能百分之百确信,链接那头到底是什么,除非点进去查看。黑箱的诅咒,是所有卡片笔记——乃至所有笔记——的阿喀琉斯之踵,而破解这个诅咒的方法,在于卡片的名字——标题。

用一个现代的隐喻,我们可以说,每则笔记都是一个 API(Application Programming Interface,应用程序界面),易读易懂的笔记,就是运行良好的程序。调用 API 时,我们不会关心背后源码如何运作,只需几句话就把它嵌入当前代码;引用笔记时也是如此,作者和读者都不想纠缠其背后的论述过程,只想看到观点或结论。如果一开始就把 API 编写得明白易懂、统摄全文,读者(包括未来的自己)读起来就不必劳神苦思。至于编写 API 的艺术,就是设计卡片笔记标题的艺术。

Alt text
引用一篇笔记,如同调用一个 API

陈述句标题如同卡片笔记的 API 接口

在阅读文章时,我们已经习惯了 详见《某某文章》 这样的表述,自然也会萧规曹随,将其带入卡片笔记中;殊不知,这是一种极其耗费读者心力的表述1 。,甚至有点不负责任、把求证过程全部丢给读者。试看下面两种标题(表述也有略微不同):

为什么要用陈述句当标题?请看[[202011160440 感想]]。

为什么要用陈述句当标题?因为[[202011160440 陈述句标题如同卡片笔记的 API 接口]]。

第一个标题没有提供任何信息2,除非打开它,不然不可能知道整句话在说什么(诸君之中应当没有福尔摩斯那样的记忆宫殿高手);而第二个标题则揭示了笔记的核心观点,言之有物。如果放任没有实质内容的标题,在最糟糕的情况下,我们会看到这种触目惊心的东西:

关于[[202109141702 心得]]这个问题,我认为[[202109141703 感想]],并且考虑到[[202109141704 感想]],最好[[202109141705 感悟]]。

如果哪个作者发表出这样的东西,他一定会被读者活活掐死。可是,如果不谨慎拟定标题,我们就相当于在天天做被读者诅咒的勾当——卡片笔记的读者,就是将来的自己。

好的标题,如同借以调用笔记的 API 接口,只要刮一眼标题,就能够知道笔记在说什么;至于其背后的数据、案例、推理如何交错层叠,则不用时时刻刻牵肠挂肚,否则读一句话就要查证两三篇文章,如同栽进了米诺陶诺斯的迷宫。

检验笔记标题的试金石:删掉双括号 [[]]

在卡片笔记中,双括号标记 [[]] 赋予了标题特殊的视觉效果,让笔记标题看上去和文章标题一样,这种呈现方式令人先入为主,不利于我们判断一则标题是否设计恰当。

好的笔记标题应当能够无缝融入正文,某种意义上,被引笔记的内容相当于这句话(本文默认一个标题就是一句话)的注脚。

Alt text
标题和正文,可以视为句子和注释

持这这种态度,就能找到检验笔记标题的良方:删掉双括号,如果句子读起来仍然通顺无阻,那么该标题起码在形式上就过关了。

为了表明清晰,标题应当尽可能使用陈述句,毕竟较长的、完整的句子远比一个名词更能够表达清楚一个想法,而不强求点开该链接,从而降低对于被引用的卡片的依赖。毕竟,无论如何吹捧网状思维,我们的阅读习惯还是线性的。

当然,大胆引用之所以可行,离不开我们的第一个隐喻——黑箱。详言之,我们默认大多数卡片都达到了“令人信服”的标准,可以放心引用。

重视标题,并非延续着考试作文和学术论文的窠臼,而是一个正当的需求。在独立研究员 Andy Matuschak 那里,标题也有着极高的地位,甚至被他称作“句柄”(handle),即看到一个词、一句话就知道整篇笔记在讲什么。

When Evergreen notes are factored and titled well, those titles become an abstraction for the note itself. The entire note’s ideas can then be referenced using that handle (see Concept handles, after Alexander). In fact, this property itself functions as a kind of litmus: as you develops ideas in notes over time and improve the “APIs,” you’ll be able to write individual notes which abstract over increasingly large subtrees.——Evergreen note titles are like APIs

能够胜任句柄的名词或词组都少之又少,而且容易产生歧义,最后唯有写出完整句子。例如同样针对“浅层模式匹配”这一话题3,最初我可能只有一则笔记,只写一个词语无可厚非,但随着笔记数量增加,我发现了 202102271234 从多个角度描述记忆卡可以缓解浅层模式匹配202103040525 随机排版可以缓解模式匹配 等解决之道,还发现这一现象的积极作用——202102270339 模式匹配可以充当助记符,此时就得老老实实概括笔记内容,充当标题。如果不介意,你可以读读这段话的另一个版本:

例如同样针对“202009141747”这一话题,最初我可能只有一则笔记,只写一个词语无可厚非,但随着笔记数量增加,我发现了 `202102271234`、`202103040525` 等解决之道,还发现这一现象的积极作用——`202102270339`,此时就得老老实实概括笔记内容,充当标题,否则我的心情就会和你读到这段话时一样糟糕。

正面标题比负面标题更利于引用

同样是陈述句,正面的表达比负面的更好。我曾经倾向于使用负面标题(如“不要””避免“),借此提醒自己避免再犯某些错误。但在相当多的笔记中,我实际上已经给出了解决方案,此时更适合将解答写入标题、让它来到台前,以便直接引用这些标题,在其上 搭建笔记或文章的大厦

固然,仅仅使用正面描述可能不全面,因此 Andy Matuschak 还提出过一个“要,而不要”的折中表达,比如将“不要记笔记”写成“思考,而不要记笔记”。它比单纯的负面标题更能够表现整篇笔记的核心内容,也更利于被引用。毕竟,解答是搭建在问题之上的,如果已经有了某种相对可靠的解答,就应当在解答之上叠床架屋而非屡屡回归问题。

公共辩论陷入僵局的一大原因是,参与者不知道该如何继续推进。过分关注负面因素是部分原因,也就是只看对方错在哪里……马丁·路德·金的著名演讲《我有一个梦想》之所以有力量,部分原因就在于,它毕竟还是在谈梦想……试想一下,如果他只谈噩梦,那会如何……——安东尼·韦斯顿:《论证是一门学问》

正面标题同样适用于侧重描述而非建议的笔记,不妨将这些笔记视为函数式编程(是什么),而给出方案的笔记就像是命令式编程(做什么),相同的一点在于,它们基本都是正面的。如果一篇笔记很难给出什么正面建议,不妨试着将它改成对问题的描述,如”人们习惯于”“这样不利于”等等,并将其搁置一旁,以后的思路可以接着这些问题继续展开。

最后,还有这样一个简单的理由:我们不想总是看到负面的东西。卡片笔记的正文已经承载了艰辛的思索过程,我们没有必要一直忆苦思甜、深陷在艰难的回忆里。

带上语境比单纯提出建议更容易理解

从理查德·道金斯到股神巴菲特,都指出这样一个现象:提出一个要求时,只要带上理由,即便不是那么充分,我们也更容易接受。这就是语境的力量。语境也可以用在卡片标题上,使它们更易懂。试看下面两种表述:

  1. 不给任何理由,就甩出一句 202102271234 从多个角度描述记忆卡
  2. 带上一点语境,说 202102271234 从多个角度描述记忆卡可以缓解浅层模式匹配

且不说后者是否符合逻辑(这是那则笔记正文的任务),至少它有了语境,让人觉得听上去还比较合理。实际上,所有的建议都最好有所属语境,毕竟我们做笔记,并不是请大腕站台一样让各种观点露个脸,我们还得结合上下文进行解释——最理想的情况下,标题本身就可以带有语境,给出前因或者后果。

此外,语境有时是一个客观现象,它比在此之上的建议更加可靠。例如,在思考“既得利益者”这一话题时,我可以使用建议式的标题 不与胜者辩,也可以直接描述刚刚发现的现象 既得利益者会维护其传播体系,前者是后者的逻辑结论。客观现象比建议更加可靠,因为建议随时可能变更,而一个现象则可能持续很久。确实,在后续的思考中,我意识到自己会反复提及 既得利益者会维护其传播体系 这一现象,并将其作为前提去阐述 既得利益者需要被承认 等问题。换个角度想,凭空抽出一条建议作为标题,可能背离了 API 的隐喻:在软件设计中,你不可能引入一段 API,然后又买椟还珠、只使用它开头的环境变量;如果我使用了 不与胜者辩,就不得不解释一下其前提、并且指出我想要的只是前提而非结论,这样就显得很荒唐。

当然,并不完全排斥将建议作为标题,只是这种情况下,写作者就要承担更多的论证责任。许多建议在特定语境下不证自明,例如讨论卡片笔记时可以说“将所有摘抄存入卡片盒”“优先使用正面标题”以及这篇笔记“描述现象优先于提出建议”,但是对外发表时就必须解释这些建议的理由,因为外部读者并不知道我所处的语境——稍微拉长一下时间维度的话,还会发现未来的自己也可能忘记语境,所以,不如从一开始就尽可能把语境融入标题。

小结

从 API 的隐喻出发,构建卡片笔记系统如同搭建一套软件,重点不是赏心悦目、满满当当,而是能够顺畅运行——即便于阅读、易于理解、益于沟通。在这个过程中,笔记标题充当了 API 接口的角色,其设计规则大致可以归纳为:

  1. 使用陈述句,完整概括笔记内容;
  2. 使用正面描述,便于直接引用,避免一直纠缠于原始问题;
  3. 尽量带上语境,让标题拥有前因或者后果,避免沦为命令。

归根结底,标题是为了沟通而存在。比阿特丽斯·沃德(Beatrice Warde)曾经作出了字体设计界最著名的宣言,个中原理,也适用于双向链接,尤其是双向链接中的标题:

好字体为沟通思想而存在,而不是为了被察觉,更不是为了被钦佩。

我们也可以说,好标题是为沟通思想而编写,而不是为了喧宾夺主,更不是为了不明觉厉。

Banner Credit: Bob Rose & Studio Ghibli

🛍 我撰写的付费栏目《信息管理,文件为本位的方案》正在 UNTAG 售卖,对本文话题有进一步讨论,欢迎选购。

🔗 付费栏目链接


  1. 乔治·米勒(George Miller)提出了组块理论,认为大脑可以把想法打包成越来越大的单元,借以减少对记忆的占用。恰当的笔记标题起到了打包功能,将几百上千字的内容压缩到一句话,降低了日后阅读时的压力。参见史蒂芬·平克:《风格感觉》,北京奥维博世图书发行有限公司2018年版。
  2. 我知道,Roam Research 等工具可以“嵌入”被引用者的内容,但如果一句话就能表情达意,为什么要把原文全部糊到脸上?。
  3. 一种心理学现象,指根据表面模式来记忆知识,而非深入思考,典型如看到题目的前几个字就想起之前做过的习题,并马上写下答案——往往是错误的。

author_avatar

Lawyer, macOS/iOS Automation Amateur