其实今天回想起来,双向链接笔记的跟风热潮并没有成功地给广大用户带来一种新的思考方式。因为如果以我今天的理解来评价的话,绝大多数 roam research 的模仿品只学了一点皮毛,学得好一点的模仿品只有寥寥几个,而且即便是学得好的也都有一些关键点没学到位。换句话说,如果做产品的人自己对 roam research 的双向链接都只理解了一点皮毛,传达给用户的当然也就是皮毛。 不用说,这种环境当然会在很多人心中催生「双向链接无用论」,但即使是觉得双向链接有用的人,大多也都还抱持着「互相链接」「网状」这种在今天的我看来根本没入门的理解。 当然这件事肯定不能怪广大用户,毕竟 roam research 有很长很长一段时期连登录进去都困难。我自己对于这种新产品当然是有很大的兴趣去深度尝试,但是天天盯着这个加载界面船锚发呆也不是个事,所以就转向一些早期模仿品去体验双向链接。
但是在当时,对 roam research 模仿得比较好的几个产品一个比一个不稳定,天天出现各种难以忍受的魔幻 bug,于是做得稳定的产品就能吸引到更多用户,包括我。可偏偏做得稳定的产品没一个把双向链接学明白了的,再加上「比起 roam research 主要是差一个细粒度引用」这种言论占据了主流,所以我自己在早期也对双向链接有很大误解,经历了很多曲折才扭转过来。 这篇文章有两大贯穿全文的重点: 其一是通过双向链接笔记工具来实践真正高效的 daily notes 快速无压记录流程。仅通过这一个场景就能向大家证明,哪怕完全不提诸如「网状」「联系」之类的噱头,双向链接依然有很大的价值。不过这篇文章里对于双向链接的诸多使用技巧只会提一小部分,其余的在下一篇文章里单独写,双向链接无用论已经到了可以终结的时候了。 其二是「快速无压记录」这件事背后的深刻原理。快速和无压绝不仅仅是前期的事,它们必须要有后期功能的支撑,更需要使用者对时间管理有足够的理解,这些理念我之前从没看见有别人提到过,所以这篇文章里要一次性写满。
「合并」这个设计不仅体现在 roam research 的页面合并上,writeathon、flomo 和滴答清单也都具备合并标签的功能,这样用户在一开始记录某条内容的时候就可以随便写一个标签名,无需考虑已有的标签树长什么样。
为检索压力兜底的「随机」 roam research 里是没有明面上的文档树的,这让很多人无法接受甚至直接弃用。如果所有文档不能以树状形式组织起来,就会让很多人担心某条笔记在将来找不到,当然这里的「找不到」不是指主动的全局搜索功能不好用,而是指忘记了自己曾经写过这么个文档。 虽然我很想说能忘记的东西多半不重要忘了就忘了呗,但我也清楚,这种观念不可能这么轻易放下,这个心态不解决就不能做到无压使用。 所以还是来说一点更现实的东西吧。很多小型的专题 wiki 站点都会做一个侧栏文档树或者一个 moc 页面,让访客直接鸟瞰本站有哪些条目,这也是在个人笔记系统上维护文档树的主要预期。但是只要文档数量很多,全局文档树和全局 moc 很难维护下去,如果文档数量多到了 Wikipedia(维基百科)那种程度,想在左边做个涵盖整站文档的全局文档树是不可能完成的任务,所以 Wikipedia 也只能在不同粒度上做一些包括 Contents 在内的局部 moc;可是同样是做局部 moc,用 roam research 比 MediaWiki 方便了无数倍,而且 roam research 和 logseq 还有嵌套链接或 namespace page 来表示局部的树状关系,能直接选择 parent rem 的 remnote 就更不用说了,它们并不是没有分类或不能分类,只是没有摆在明面上,导致很多轻度用户没有探索到。如果一个人连那些老式 wiki 都能接受,完全没有理由不接受 roam research 的设计。 而且从我的长期经验来说,只要文档数量多到一定程度,维护分类的人真的会麻木,不维护分类的访客也懒得一层层点开目录树、都是直接全局搜索,最后全局分类体系形同虚设,就连局部 moc 也一定会疏于维护。所以我对文档树的理解就是一个树状的「收藏面板」,把常用的东西拿出来摆放一下就够了,没必要花精力维护全局的分类,logseq 的右侧栏和 remnote 的左侧栏也是这么做的。 但这还是没有解决那个问题:就算我说一大堆理由,但如果一个人无论如何就是想看看这里都有哪些东西,而且这个人也忘了用来全局搜索的关键词,该怎么办?特别是在个人笔记上,为了做到无压使用,这个问题一定不能逃避。 对于这个问题,Wikipedia 和 Reddit 给出了完美的答案:随机。 Wikipedia 左侧栏的随机按钮可以随机打开一个页面,Reddit 也可以进入随机版块,想看看这里有哪些东西吗,点随机按钮吧。
为粒度压力兜底的「统一」 之前在跟人讨论的时候,别人提出了这样一个问题: 在有一条新的想法要快速记录的时候,究竟是为它单独新建一个文档,还是把它追加到某个已有文档的末尾呢? daily notes 流程告诉你,不用想这些,把内容搭配上主题锚文本写在 daily notes 页面就好了。 那假如将来有一天,我使用上一节提到的随机技巧,随机出了多个页面,然后我发现这些页面里的 B 从内容上说是 A 的子话题,有没有办法做调整呢?即使是传统笔记软件,也不是不能靠剪贴板把整个 B 页面的内容转移到 A 页面,但是双链笔记上不能直接这么做,因为 B 的反链会因此消失。 roam research 可以直接把 B 改成 [[[[A]]: B]]、logseq 可以把 B 改成 A/B 来让 B 的链接出现在 A 页面的底部,这样就可以体现这两个主题的父子关系,可是如果我是想对外输出或是想大规模重写内容,当然更想把 B 的正文直接合并到 A 中,同时还要保证 B 的反链不消失,这个场景它俩就应付不了了,因为原来对 B 的引用是页面引用,而合并之后需要的是对名叫 B 的节点的块引用。并且,一旦 B 带上所有子节点成为了 A 中的一个块,daily notes 中也无法再靠 [[ 搜到它,得用 (( 才行,而使用者可能根本想不起 B 已经降级这回事。 同样的需求,在 remnote 里可以很轻松地做到,直接把 A 设为 B 的父节点就好了,而且 A 和 B 都可以标记为文档放在左侧文档树里,在 remnote 中,「文档」只是节点的一个可有可无的状态,没必要单独做出一个名叫「文档」的对象。在 remnote 中,所有节点都处于同一个空间里,它们可以自由地进行组合,发明一个叫「页面」的东西会让这个空间出现两种不同的粒度,名叫 A 的节点不能变成名叫 A 的页面,名叫 B 的页面不能变成名叫 B 的节点,这是对自由度的破坏。所以我一直都说「页面」这个概念在大纲型笔记上没必要存在,roam research 的页面重命名合并功能也不是非得要有一个页面命名空间,remnote 会主动探测重名节点、同样能解决这个问题。 文档型双链笔记没法做到像 remnote 这样完全统一,但它们依然有办法来弥补这个问题,比如思源笔记可以让正文里的某个 H 标题及其下属内容转换成文档树上的一个文档、也可以进行逆操作让一个文档变成正文里的一个 H 标题和下属正文,无序列表也即将支持这种双向转换;在这个打破粒度限制的转换过程中,所有链接都不会失效,并且思源笔记把文档块也当成一种块,[[ 和 (( 也是完全统一的,转换之后依然可以在 daily notes 中搜到。思源笔记在这方面跟 remnote 的差距主要就是文件名只能有纯文字、不支持各种行级元素,但是这种调整上的自由度在所有文档型笔记里已经一骑绝尘了,大纲型双链笔记里除了完全统一的 remnote,也只有 roam edit 做了单向转换。 总之,统一的粒度能带来最大的整理自由,只要认识到这一点,前期记录就能更加无压、更加肆无忌惮。 PS:还有一些软件看起来做了跟上面几个软件有点类似的功能,实际上背后的思想和达成的效果差异很大。比如 notion 可以把一个文档锚文本在原地展开变成一篇正文,hypernotes 和 obsidian 的 note refactor 可以用正文内容生成新文件,但它们都无法保持住被操作对象原本的反链,这个问题在双链时代之前也许无所谓,但放到现在就很成问题了,更别说有的转换操作还不是双向对称的。究其原因,它们做这些功能的思考出发点可能就是一种很传统的思考,notion 现在连双链都只做了一点皮毛,距离意识到粒度统一的问题起码还隔着两步。
在反链层级选取上也没有什么好多说的,就是跟 roam research 一模一样,前面已经分析过了 roam research 的反链规则好在哪。另外,作为文档型软件,思源笔记在列表块之外还有标题块和普通段落块,它们的反链规则基本也是保持跟上面一样的思路,这就属于更灵活的进阶用法了,在这一篇里先不多提。除了合适的层级规则,现在思源笔记反链面板中的内容也可以直接拖动到正文中了。 现在的思源笔记证明了文档型双链笔记并不是解决不了反链上的两个主要问题,主要还是取决于意愿。v1.3.6 反链更新之后,虽然单说双链体验比起 roam research 还差得不少,但实践完整的 daily notes 流程问题不大,论坛上也有不少用户发了使用感受,反响还是很不错的。 主要矛盾已经解决了,至于次要矛盾,至少从开发计划上看,短期内应该不会解决。次要矛盾是什么呢?具体来说,roam research 等大纲双链笔记的反链都具备完整的编辑能力,而思源的反链面板只展示纯文本,还是稍微差点意思。 举两个小例子。 在上面的图中,一级子节点的下方究竟是不是还有二级子节点,从反链面板上是无法直接看到的,需要把鼠标放上去在浮窗里看。
这个操作虽然看起来相当简单,只需要把鼠标放上去就可以了,但是在做这个动作之前我并不知道该节点下方是不是还有子级内容,悬浮预览的结果可能是「有」也可能是「没有」,而每一次「没有」都是一次负反馈,多来几次负反馈我基本上就没有动力再把鼠标移上去看了。也许有人能在这件小事上战胜人性,反正我不能,宝贵的意志力不应该消耗在这种地方,而且设计者本来就应该在心里把全体用户都假设成极品懒狗。 所以浮窗这种形式有时候是有局限性的,任何操作上只要存在不可预知的负反馈,它就很有可能直接沦为摆设,正反馈奖励特别强的除外。(题外话:用这套逻辑来分析,绝大多数双链笔记里查看 PDF 某条批注被引用情况的小功能也都是鸡肋) 第二个小例子是这样的,我有时候看到有意思的图片会顺手收集一下,在 daily notes 中我是这样记录的(在 roam research 和思源里,这种记录完全没必要用软换行,我是为了数据通用性才会用这种写法):
引用原文:roam research 可以直接把 B 改成 [[[[A]]: B]]、logseq 可以把 B 改成 A/B 来让 B 的链接出现在 A 页面的底部,这样就可以体现这两个主题的父子关系,可是如果我是想对外输出或是想大规模重写内容,当然更想把 B 的正文直接合并到 A 中,同时还要保证 B 的反链不消失,这个场景它俩就应付不了了,因为原来对 B 的引用是页面引用,而合并之后需要的是对名叫 B 的节点的块引用。并且,一旦 B 带上所有子节点成为了 A 中的一个块,daily notes 中也无法再靠 [[ 搜到它,得用 (( 才行,而使用者可能根本想不起 B 已经降级这回事。