基于 Logseq 重构个人知识管理体系

date

Dec 4, 2022

note

slug

knowledge-base-refactoring

type

Post

status

Published

现有体系

参考 DIKW 模型，知识管理主要服务于人类视角下 Data → Information → Knowledge → Wisdom 这一过程，其中从 Information 到 Wisdom 的过程，伴随着相对较漫长的思考和转化。在更核心的视角上，知识管理对应着其中 “信息抓取与存储”、“信息的组织加工”、“信息内化为知识”、“信息与想法的输出” 等过程，支撑我们在脑海中持续完成上述的思考与转化。在我19年实习时写的 Notion 与印象笔记、OneNote 的结合也隐隐约约有些往这个方向靠近，现在再回头看来感觉已清晰不少。

从使用场景具体展开，大致上可以分这三大块：

信息固定、存储：主要是固定日常的碎片想法，还有工作学习中的关键流水信息

信息的组织加工、内化：通过不断调整信息的组织结构，帮助大脑对这些信息建立链接，形成一个网络。这个网络不仅是笔记软件的信息网络，更重要的是脑海里对它们的认知的关联。

对外发表、交流：通过发表、还有与他人的交流碰撞，可以给自己形成一个反馈，察觉到自己想象与现实的落差，可以从更务实的角度去完善自己。

20年开始了解到 Roam Research 之类“双向链接”笔记，可以快速建立信息点之间的引用、被引用的关系。但官方服务略贵，且也是类似 Notion 的中心化云端服务，让人不太放心，一直未开始尝试。毕业上班后，考虑信息安全需要，引入以本地存储为核心的 Obsidian 做工作相关的日常记录。

在这个状态下跑了两年，效果还挺不错，慢慢形成了一个相对稳定的工具体系：

信息固定：日常碎片信息和想法一般用 Flomo 或苹果自带的备忘录，工作学习记录方面，主要是 Notion 和 Obsidian

整理内化：主用 Obsidian，偶尔用 Notion 记录一下，由于 Obsidian 移动端体验相对不如 Notion，生活向的东西会更侧重 Notion 一些

对外发表，主要分日常草稿和互联网上的发表这两部分：

草稿：Markdown 编辑器 / 苹果自带备忘录 / Notion

发表：在 Typecho 的博客，偶尔写写论坛帖子，7月份时精简了方案，把博客也统一集中到了 Notion

回想我这两年在笔记工具的使用，除了日常学习的知识体系梳理外，绝大部分都是工作相关记录。在 Obsidian 的辅助下，网状的知识体系构建基本没啥障碍；但在工作相关场景的使用，方法层面确实还不是太成熟，也许也需要进一步回顾与整理下。

工作日志

在毕业工作的开始，我对于工作的记录等方法并没有太强的意识，且鹅厂内部在这方面各自为战，没有相对成熟统一的工具、理论去支撑，身边同事也少有这方面习惯，只是偶尔在内网看到一些零星的经验分享；外加那时的我也常因为自己的一些完美主义强迫症，容易扎入一些于需求核心目标而言并不是太重要的细节，留给关键事项的时间少了，较快的项目节奏下，常因此导致压力较大的加班。

某天与小组 leader、导师聊起这点困惑，他们给我的建议是，可以试着去做一些日常记录，在一段时间里观察下自己每天想做什么、最后又做了什么。基于笔记软件之上的工作记录习惯，也就这么持续了下来。

经过多次反复尝试，我在 Obsidian 慢慢形成了一种类似 Bullet Journal 的日常笔记流程（在这里有写过），具体操作上主要在于这几点：

以月为粒度，建立一个“流水日志页”（按周、按天的粒度，复制粘贴数据比较麻烦）

把每天的记录归在一个小标题下，再用无序列表、有序列表、任务列表等，整理任务、信息记录、各种沟通讨论的细节、文档链接等。这样每个信息点都算一个 Bullet Point，Bullet Journal 的基本单位，各个 Bullet Point 之间，组合形成一个树状的结构

涉及知识性的东西，专门开一个对应知识点页面，并持续补充完善，在日志页留下链接，在有空有心思的时候花点时间整理整理

对某些需要持续跟进的需求，开新页面记录任务、沟通记录等信息，同时在日志页留下链接

小半年下来还挺流畅，但也深刻体会到自己时间精力的有限，不得不说，一个人一天所能付出的行动，确实真的不多。如何把有限的行动力花在合适的地方，是我需要关注的话题。

项目管理

关于有限的行动力如何利用的话题，在鹅厂时我曾选择性上过内部一些时间管理、项目管理相关的培训课程。也才知道，原来并不是只有我一个人有过类似困惑，同时也逐渐意识到抛开“需求”而言、“项目”这一更核心的概念。处理一个需求、上一门课、完成一项作业、读一本书、去一个地方旅行，其实都可以称之为一个“项目”（英文为 Project），台湾同胞们中有个“專案”的说法，“专门处理的案件”，或许表达上会更贴切些。

且看“项目”一词的定义：

为完成某一独特的产品或服务所做临时性努力。

咬文嚼字拆解一下，主要是这三点：

产品或服务：可以理解为这个项目的“目标”，想要产出什么

临时性努力：代表着一段时间的行动，有开始与结束时间，需要“有始有终”的状态

独特性：每一个项目所投入的资源、达成产出的效果都不一样

可以发现，“项目”主要着力于行动层面，在行动的背后更关键的是想要达成的“目标”，在纷繁复杂的世界里，我究竟立足在哪？又希望朝着哪个方向，去做出什么样的行动？人脑本身不太擅长长时间专注与机械化的工作，更多时候是在发散与天马行空。没有明确目标的飘忽不定，带来的往往也是反复横跳下的浅尝辄止。

这也是当前我面临的困境，于我而言幸运的是，我的反复横跳基本都在 Web 和 Unix 的体系之中，基础的技能树点的没啥障碍，但就是说，在尝试去深入某些方向的时候，确实遇到了一点瓶颈 — 我在面对问题时的关注点常过于跳脱和宽泛，缺乏长时间坚持和深入的状态。

面对这样的问题，在 leader 的帮助下，我的解法主要是通过记录去尝试改善，具体而言也是在个人的笔记工具体系中，需要新明确的一个 “项目管理” 层面的目标维度 — 通过记录和整理，让我逐渐对自己的行动力有所把握，辅助我更好地调整、平衡所推进的事项中的各种关系（进度、成本、质量等等），有意识地把有限的时间精力花在实处，排除杂念的干扰，乃至于找到真正属于当下自己的下一步方向。

到这里，我对于笔记工具的需求也更明晰了一些，主要着力于这三个场景：

个人日志：每天的行动记录、阅读、日常交流、碎片想法的固定

知识维度：沉淀整理，发表输出，构建完善自己的知识网络

项目维度：目标梳理、任务拆解规划、任务执行过程中的记录与调整

针对这几个使用场景，冥冥中在 Obsidian 上也有了一点类似的雏形，在上述的每天工作日志记录之间，慢慢地会穿插一些项目记录、会议纪要等等的子页面。对一些相对复杂的需求，则将所有的文档都归到一个个文件夹里（Obsidian 的页面不依赖子文件夹结构，这里只是个人习惯上为方便直观选择的一种组织方式）。

经过两年多的高强度工作洗礼，以 Obsidian 为核心的现有体系，自觉确实让我解放了许多任务切换与信息反复确认的开销，但同时也暴露出一些新的问题：

项目记录与个人日志没有直接关联的同步，实际工作中有的任务点，并非一天可以完整做完，放到第二天行动，任务复制粘贴下，常产生无效的冗余记录，不好同步修改

用文件夹去组织信息，需要去做一些给文档归类、重命名的事情，不太灵活

目前 Obsidian 与 Notion 双线并行，暂无比较明确的分工，进一步带来了一些冗余和纠结用什么工具的内耗

这也让我有了个念头，如何再基于此再进一步由此出发，去寻找 or 创造更合适的工具，并重构整个流程。现实原因时间精力有限，一直将就着未有行动，直到换工作的契机，我才开始关注起这个话题。

核心目标

这里需关注的问题，我到底是想要构建一个怎么样的体系？在场景逐步明晰的基础上，我需要结合现状进一步整理和展开。除了日常的行动、阅读交流等方面的信息固定之外，我想最关键的两个字应该还是「聚焦」。结合上述的三个场景，重新整理下来，大概集中在这三个方面。

首先是时间精力上的聚焦，主要是在“项目”的层面去聚合自己的行动力，做出合适的取舍。一方面是个人视角出发的日常行动记录，大概明确自己一天24小时里究竟主要在哪付出了时间精力；另一方面是从项目视角出发的项目规划、记录等，把项目的大目标拆解成小任务作为基本单位，落地于笔记中。这里的目标与拆分的任务之间，恰好组成了一个树状的结构。

在消化任务的同时，需要的是实时地跟踪进度，并能不断地围绕着目标，根据实际情况变化调整行动计划，降低执行过程中目标无法完成的风险。从中可以发现，关于个人视角与项目视角，这两者间会有较为紧密的关联，背后隐含着一个日常“行动力”投入到项目中的过程，这时对于笔记软件来说，有一个相互链接、引用的机制就比较关键。

然后是知识网络上的聚焦，日常的行动和阅读中，我们常常收获一些有意思的碰撞，脑海里突然冒出的想法和问题等，也是我们所学知识的来源。通常我们会以话题出发，用类似树状的结构去展开它们，最终在脑海里落地的，是各种各样的树状结构交织而成的网络。

信息爆炸的当下，知识网络的构建，需要避免过于发散和反复横跳的状态，慢慢找到属于自己的位置。茫茫大地，能长居的地方其实可能就几个；面对庞大而繁杂的知识网络，每一个方向都很棒，但一个人能够专注研究的领域，同样确实也不多。如庄子所言：“人生而有涯，而知也无涯；以有涯随无涯，殆已！已而为知者，殆而已矣！”。面对无涯的知识之海，对于个人而言，只能说 “弱水三千，只取一瓢饮”。

再者是对外的影响的聚焦，这一点主要是受 yihui 的文章启发，把自己的对外发表、项目等收归在一个域名下，避免时间、精力的发散。恰好前几个月我也在做着类似的事情，尝试去整理我过去曾写过、讲过的东西。从中发现有意思的一点是，当自己写过的文字达到了一定的量级，在 Web 下的一个博客站点，可能是更好的承载方式。在时间的长河里，博客与文章可以作为一个锚点，汇聚个人某一段时间的学习思考与交流；它以一个线性的结构去组织表达，方便人与人之间的信息交流与沟通。

写博客并不代表一个人闭门造车，它更多在于一种集中注意力的手段，移动互联网时代人与人随时都能随时联系，不妨碍交流讨论的发生。博客虽然没有类社交网络的快速直接双向互动的反馈，但这一点可以通过分享 URL，然后再在各自的讨论上下文中去进一步地完善，再进一步反哺、沉淀出新的东西。

最近有一点比较深的体会是，相比于社交网络的碎片化，在工作日益忙碌、自己社交圈子逐步打开、再难有太多精力在琐碎中纠结的背景下，全身心投入的面对面沟通，围绕着某些主题的深入交流，会比网上交流更有意思，大概是参与交流的人在环境的影响下都可以保持在同一个上下文的缘故。一篇博文恰好是聚焦某个主题的载体，可以作为一个讨论话题的中心。对于生活的琐碎，可以更多留在朋友圈和各种不同的社交网络中，日常点点赞，偶尔唠嗑两句，大概就已足够。

进一步往稍微功利的视角去想，还可能会涉及到如何降低他人认识自己的成本，在他人心中的信任感如何建立等等与个人影响力建设相关的话题。话到这里可能飘得有些远了，这方面的收益，我想更多的是知识积累过程的一种副产物，倒不必为此去刻意纠结。

关于目标，这里说了很多，核心需要关注的是，如何运用好手上的工具和媒介，为自己争取多一些静心思考、记录和表达的空间。

以 Block 为单位

接下来我想讨论的是如何从现实视角去落地这样的想法。从上面的整理来看，我所依赖的笔记体系其实离不开 Bullet Journal 这一内核，它的基本记录单位是 Bullet Point，无论知识体系还是项目的执行记录，都可以基于这样的 Bullet Point 组合而成。

这里的 Bullet Point 恰好也与 Notion 所推崇的 Block 概念类似，我在迁移博客的记录中有提到 Block 这一点，以文档为中心的 Page 粒度相对较粗，若能深入到 Block 粒度会是更好的状态。无论是文本、图片、代码、任务，还是文件等等，都可以抽象为一个 Block，相较于传统基于纸笔的 Bullet Journal 的 “任务列表 + 信息点” 而言，Block-based 系统的表达力更加丰富，并且不会像纸笔因物理的局限，需要比较精心的设计才能兼顾系统的迁移和扩展等问题。

到这里我们已明确了信息的 Block 粒度去组织这一点，关注点从 Bullet Point 转向表达力更丰富的 Block。在这个视角下，一个文档是由多个 Block 组成的 Page，通常我们会以 Page 为单位去对外做一个信息的交换和传递。

更关键的事情在于 Block 之间的“链接”。为了实现这样的“链接”，我们需要的是，明确一个命名体系，通过名字去记录和寻找另一个赋予链接的 Block。就像关系数据库中某一行数据的“主键”与“外键”的关系，通过“主键”确定某个实体在体系中的独一无二，通过“外键”去记录某个实体与另一个实体的链接关系。

然而起名并不是一件容易的事，Page 页面的命名，我们是通过“文件名”去实现的，文件名的命名难度尚能接受，但细化到具体的 block 而言，要给它们都起名就很灾难了，毕竟随着编辑的进行，它们通常变化非常频繁，带来额外心智负担。由此，相比让用户起名而言，有个自动生成名字的编号体系会更靠谱些，严谨地说，这样的编号称之为 ID（Identifier，标识符）。在这个视角下，我们给某个文件命名，实质上也是在通过人肉的方式去做一些 ID 生成的活儿。

通常我们也可以用数字做 ID，但数字并不能很好保证在不同体系间不冲突，且被枚举攻击的概率相对较高（可能是 B站从 av 号切换到 BV号的一点原因），我们需要更好的 ID 生成方式。

Notion 所使用的 32 字符 uuid 也是软件开发中通行的编号姿势（参考 RFC 4122），按此标准方法生成，理论上有的空间可用，一辈子都用不完，在数学上可以保证发生重复命名的概率接近于 0，作为 Block 的 ID 恰好合适，借此这一起名难题也能得以妥善解决。

上述的使用 Obsidian 遇到的冗余、不同步等问题，通过基于 ID 的引用，可以保证数据来源是唯一的，修改一处即能影响全局；文件系统中“目录”与“文件”背后的树状关系，实际上也可以通过 Block 的 ID 引用来构造，相比依赖数据而言，会更加灵活（这也是 Git 管理版本用到的思路）。

到这里我们可以明确这里新的笔记软件中的基本元素：Block，构建 Block 之间链接关系的 block ID、由多个 Block 组合而成的 Page，作为构建起整个体系的原料。

Why not only Notion

写到这里，我的关注点不知不觉已在向着 Notion 的形态靠拢了，毕竟 Block 与 Block ID 之间构成的链接体系，正是 Notion 的一大核心设计哲学。也很佩服 Notion 的创造者们从中取舍的智慧，那么在这里为什么我不直接 All in Notion？

首先 Notion 是一个云端应用，它的工作强依赖于网络，体验上会因为网络环境而受到波动，尤其是在大陆的环境更加明显。具体而言主要在离线状态的编辑体验，笔记的实时查找和搜索等方面，依赖云端的处理效率其实不及本地的体验。

相比之下我更喜欢开源和纯本地存储的方案（类似 Local-first software 的概念），数据本地可控，在隐私方面也有所保障；除了方便备份外、也赋予用户足够的透明。在透明性方面，使用笔记软件的不安全感比较强，底层依赖的数据结构可直接编辑的情况下，即使笔记软件出了问题，笔记数据依然还是可用的。Notion 所有的笔记都托管在云端，Notion 作为开创者，大家对这个品牌有足够的信赖，愿意把自己笔记托付给它，但不排除有不可抗力因素出问题的可能性。

不否认的是，Notion 的 Database 功能确实强大，适合做一些项目规划和整理的事情，还有对外发表的聚焦、人与人协作等方面，这是许多同类软件难以企及的。并且因为它有专门团队去更新和迭代，软件质量和新功能开发方面会比较活跃些。

Why not Obsidian

为什么我不想再继续依赖 Obsidian？仔细想来，可能可以从 Obsidian 的核心形态去展开，如前文说到的，一方面是信息组织粒度的问题，另一方面是它的笔记结构上，与文件系统存在较强的耦合。

Obsidian 的信息组织粒度，是 Markdown 文档，然后再基于这个文档去相互建立链接。Markdown 格式做的是从复杂的排版模式中抽出一些必要的子集（段落、加粗、斜体字、下划线、列表、图片、链接、代码等等），用一些接近于最终 UI 展示的符号去表达这样的排版模式，在人类感性直觉与计算机数据结构的严谨之间，寻找一点平衡。

这里有一点问题是：Markdown 文档是笔记的基本单位吗？我想不是。Markdown 更多侧重于如何组织和表达一个完整的文档，文档是由若干个“元素”组合组成（一个典型例子是，在 Web 的 HTML 体系下，每一个“元素”都通过“标签”去表达，每个“标签”都有自己的 id）。一篇文档的形成，需要花很多的时间和精力去尝试去记录和编排其中的各种“元素”，对应了上面说到的 Page 和 Block 的概念，但 Obsidian 更多强调的是 Page 和 Page 之间的链接网络。

以 Page 粒度的引用链接面临一点问题是，当我们需要跨文档去引用其他 Page 的某个元素的时候，我们不仅要拿到 Page 的 ID，也需要指定对应的元素 ID，如 Web 网页 URL 中的 /[page-id].html#[element-id] 模式。最原始的 Markdown 格式无形中把 element ID 的表达精简掉了，且未预设一个比较好的解决方案，导致维持引用的成本变高，Obsidian 在初始状态下也只是实现了针对“小标题”的引用~~（关于 block 的支持目前暂时不明，听闻有第三方插件在做这个？）~~。

2023.02.27 更新
新版的 Obsidian 可以基于部分文本引用了，但思路是通过截取文本中部分的字符串去做的处理，存在与我在前文提到的依赖“数据”的问题

感觉上，在写文章表达的场景，侧重于阅读的体验，而不很强调细致的引用，以 Page 为粒度是可以接受的；但在笔记场景，信息高频率的修改、频繁地相互引用的状态下，处理引用关系会带来比较大的心智负担，导致其并不总是好用。比如，在项目任务的管理中，需要组织高频率变化的 Task List，又需考虑这些点的相互之间链接的时候；在知识点的管理上，也会有类似问题，当一处信息发生更新，与之相关联的另一处，也需要得到一个及时的更新，这样的手动同步就比较繁琐和痛苦。

关于信息组织粒度的问题就写到此，另一个痛点在于文件夹形态带来的问题。集中在命名与分类方面，命名问题在前文已有讨论，这里主要是分类受制于“文件系统”中“目录”和“文件”的概念所带来的局限。

因为存储的需要，我们的笔记会以文件为单位以树形结构保存在本地磁盘某个文件夹中，Obsidian 会通过一个主文件夹，作为一个 Vault （知识库）的入口，不知不觉我们也在以文件夹的树形结构去对自己的积累做一个分类，如何纠结和更新分类体系也是一个负担；而且这里目录组织的变化，也会直接在存储层面引起比较大的文件变动，类似一些文档的元数据（修改时间、创建时间等）也会一起变化，受操作系统影响也比较强（比如说可能因为网盘同步等原因文件的创建、修改时间发生了变化，这时候这部分信息就丢失了）。

另外还有一点问题是，当你想要基于某个目录去与其他页面做链接，Obsidian 还不能直接办到。目前 Obsidian 默认设置下，链接只存在于 Page 与 Page 和 Block（小标题或者 ^ 的引用）之间。

总的来看，从记录和表达的视角来看，Obsidian 做得相当不错，但在信息的组织与整理的体验的，确实相对较弱许多，它会比较重度地受 Markdown 语法、文件系统预设的树形结构这两重局限所制约。若想从中实现 Page 之间的链接进阶过渡到 Block 之间的链接，会带来较大的操作成本和出问题的可能性，这也是遇见 Logseq 后我选择放弃它的一大原因。

Why Logseq - 核心逻辑

尝试了一段时间 Logseq，发现它无论在功能上，还是数据结构上的设计，都挺贴近我上述的对于笔记软件的需要，接下来也展开写写它比较吸引我的地方。

Logseq 的核心在于“大纲”，类似上述的 Bullet Point 模式，每一个信息点都隶属于一个 Bullet Point，和 Notion 所用的 Block 是一样的思路。关于 Bullet 和 Bullet 的关系，是通过它们的大纲层级的缩进实现的，由一个“主题”展开多个“子主题”，形成一个树形结构。一系列的 Bullet Point 可以组成一个 Page，在一个 Page 中可以通过 [[某个 Page 的名字]] 的语法去引用其他的页面。

可贵的是，Logseq 在存储的视角，也遵循了同样的思路。它以纯文本（支持 Markdown / Org-mode 格式）的代码在本地存储笔记，方便我们的备份、同步和管理。我们也可以在代码的视角去感受到作者在的设计上的考虑，下面是一个 Page 的 Markdown 原始代码。


- 笔记软件
  - [[Notion]]
    - Block
    - Database
      - TODO 了解 Notion 的 Database 使用
  - Logseq
  - Obsidian
  - Roam Research
  - ...

上述的结构其实与 Obsidian 别无二致，反而可能还因为强制要求用 - 来标记一个 Bullet Point 使得文档看起来多了很多密密麻麻的小点点。但我想这也是其精妙的地方。它可以辅助程序区分不同的 Bullet Point，并可以很方便地为一个 Bullet Point 赋予一些具体的属性，比如说可供其他地方链接使用的 ID、某个 ToDo 任务的执行记录、某个文件的修改时间相关的元数据等等。

一个 Bullet Point，带上其各种各样的不同属性，在概念上构成了前文所述的 Block。比如以下的代码，在一个 - 的内容后边，带上了 ID 和这个 ToDo 任务的执行记录，我们可以通过 ((014a0a8c-73e9-4bf1-9c4e-b5880649146b)) 这样的语法去引用这个 Block，实现 Block 之间的链接。


- 笔记软件
	- [[Notion]]
		- Block
		- Database
			- TODO 了解 Notion 的 Database 使用
        ::id 014a0a8c-73e9-4bf1-9c4e-b5880649146b
        :logbook:
			    CLOCK: [2022-12-04 Sun 19:05:31]--[2022-12-04 Sun 19:05:33] =>  00:00:02
        :END:
  - Logseq
  - Obsidian
  - Roam Research
  - ...
- 任务
  - ((014a0a8c-73e9-4bf1-9c4e-b5880649146b))

在代码的视角，这样的功能扩展可能有些眼花缭乱，属性与元数据相关的细节暴露在外，处理起来会带来比较大的心智负担。让我们把视角转换到 UI 层面，以上代码在 UI 层面的展示如下图（除去日期部分），可以发现在 UI 的视角，Logseq 还是挺简洁的，我们可以看到各个 Block、TODO 状态，以及它们间的互相引用同步的内容。

在 Markdown 文件的使用上，Logseq 更多是把它作为一个笔记落地存储的格式，绝大部分时间都通过它自己的 UI 来编辑笔记；用户直接编辑源文件的场景相对比较少，源文件的操作，更多时候是作为一个出问题时的逃生舱存在。Obsidian 的界面设计上，相对较为依赖 Markdown 代码本身，UI 展示的视角较受限于 Markdown 本身能支持的场景，基于 Markdown 的语法层面能做的扩展上，要想兼顾简洁和表达力，就不是很灵活，且实现中容易因大段纯文本操作没处理好而触发一些奇怪的 bug。

从单个 Block 的视角，Logseq 遵循了大家写 Markdown 的基本习惯，比如说加粗、斜体、链接、图片、代码、数学公式等，这里就不再赘述，无论 Logseq、Obsidian 还是 Notion 其实都遵循了相似的逻辑。

在数据结构的视角，Logseq 相比于 Obsidian 而言，会更侧重于以 Block 为中心的设计，在构造信息的相互链接方面，可以带来更丰富和可靠的发挥空间，恰好也是我想要的部分。

Why Logseq - 功能

上面讨论了很多关于 Block 和 Block 之间的组合和链接的核心逻辑，总归有些抽象。但也正是，当抽象的结构足够稳定时候，才好去承载更加具体又丰富的功能。关于 Logseq 我目前比较重度依赖的功能点，从基本的记录角度来看，Logseq 和其他工具差异不大，这里更多侧重于信息的组织方面，主要是设计者基于 Block 与链接延伸出的一些有用实践。

首先一个让我眼前一亮的是它的 Journals，Logseq 会每天生成一个独立的 Journal Page，并自动把最近几天的日常记录连在一块，可以随时翻看。就如我最初在“工作日志”的场景下，每个月新建页面，按天拆分的小标题一般，实际体验下来，这里的有的更多的是无缝衔接的丝滑。

另一个比较核心的功能点是 Logseq 页面的 Reference 功能，在 Logseq 的设计中，某个页面的 Reference 和页面内容本身可以获得同等的关注度。当我为某个具体的项目开一个新的 Page 时候，可以直接以链接某个 Journal 的方式，实现把某项任务直接添加至对应日期的 Journal 的效果；相对应的，我们在 Journal 页面可以链接某个 Page，在对应的 Page 的 Reference 部分也可以发现每一天的执行记录。

这也大大避免了不必要的复制和粘贴，也可以帮助我们快速发现一些有意思的关联。在知识点的视角也如此，日常的阅读和发现，可以直接把想法关联至某个知识点上，然后可以再找时间去进一步整理与完善该知识点在自己脑海中的理解。

这个视角下，每一天的阅读和学习、工作等，就像是以“行动力”为中心的原料，构建起我们需要的项目，还有记录下来的各个领域的知识点等。这样的项目和知识点的关联形成的错综复杂网络，也在一步步地构筑着我们的人生。

在复杂的网络中，需要有一个切入网络的口子，除了 Journals 这个每日记录的入口外，Logseq 预设了一个 Contents 页面，作为一个全局的入口存在固定在右上角。我们用它可以以一个树形大纲形式去组织笔记中的一些关键主题，就如 Obsidian 的文件夹一般，与之不同的是，它不局限于文件夹，调整的过程不会影响到具体的笔记如何存储。另外，它还在边栏预设了一个 Favorites 栏目，类似 Notion 的逻辑，把一些页面固定在侧边栏，方便快速进入一些最近关注的页面和项目。

以上为我重度依赖的一些 Logseq 的核心功能。此外，在探索 Logseq 的旅程中，它也给了我很多意外之喜。

一个惊喜是 TODO 项的 DOING 状态和计时功能，在实际使用中，通过切换 DOING 和 TODO、DONE 这样的动作，可以很好地提醒我自己此刻应该聚焦在什么任务上，类似一个专注的提醒，减少任务切换的脑力开销；自觉我经常会因为容易进入一个专注忘我的状态而忘记时间，计时的功能也给了我一个客观的视角去衡量自己一天的时间究竟投在了哪里，适当地有意识从中抽离出来。

另一个深得我心的是它的 PDF 阅读标注功能，对于 PDF 文档它可以标注特定的文字（纯文本选择或者框选截图），并生成对应的 Block，可以以 block id 链接的形式直接插入笔记中，帮助我们做进一步整理和加工。试着用它读了下 CSAPP，感觉比 MarginNote 等更加灵活和方便。这也意味着，在 Logseq 中建立的这一个基于 block 构建的 knowledge base 可以直接无缝对接上书籍、论文这个载体。这是 Notion、Obsidian 等其他软件所不具备的。

另外它提供的 Flashcards 功能也有意思，类似于 Anki 根据遗忘曲线自动安排复习的机制。不过目前我在背诵的需求相对较少，所以暂时用的不多，但感觉是个实用的功能。还有其他类似 Query 脚本等高级 feature，这个就慢慢再探索了。

Logseq 还有一个优势在于，它背后活跃的开源社区，听了作者秦天生的一期播客，我对它背后的支持多了许多了解，也有不少的共鸣。作者是一个重度的 Org-mode 用户，主要因为个人在笔记工具领域的跨平台需要难以只在 Emacs 上满足，希望可以开发一个更易用的跨多平台的 GUI 笔记软件，然后选择在 Web 技术栈之上去构建。慢慢地用的人越来越多，也有了很多用户自发在视频网站上分享使用经验。乃至于投资人也在重度使用和依赖，并进一步获得资金支持他全职投入其中，再逐步发展出了一个团队去持续迭代。

就长期的方向而言，它也在沿袭着前面提到我所向往的 Local-first 的理念，用作者的话来说，即使 Logseq 未来内部可能会引入相对复杂的同步协作逻辑，但在用户的视角而言，还是会优先考虑让信息在本地保持一个纯文本文件存储的透明状态，给用户保留一个选择与切换的空间。加之软件选择了开源协作的维护方式，可以说给了用户非常充分的自由，是一个非常吸引人的卖点。毕竟于云服务而言，我们无法保证它能保持常年稳定，保不准啥时候会因某些因素（公司倒闭、不可抗力等）而无法使用；但对于笔记而言，很多时候这些记录是陪伴一生的，我们更需要的是，持续几年乃至几十年的稳定性。

新的体系 - 分工与迁移

结合 Logseq 的功能和我对笔记工具的预期，笔记工具的选择上，主要就集中在 Logseq 和 Notion 两者、再辅以一些碎片信息记录、脑图和文档等方面的软件。以此再重新去整理各个软件于我的分工，大概是这样：

日常信息固定：

Flomo、iOS 备忘录：比较日常随意的碎片信息、想法等
Logseq 的 Journal 页：在电脑前沉浸专注工作、学习、读网上文章的记录，通过 iCloud 同步至手机，手机端只读，以避免修改带来文件冲突
Logseq 的 PDF 阅读器：主要处理书籍、论文向的内容

整理与内化：以 Logseq 为中心，侧重于个人知识网络的构建、项目记录的复盘

规划和协作：以 Notion 为中心，主要做一些生活向的自我规划、与他人的合作交流（比如社区的活动）等等，以及一些相对不太硬核的内容

对外发表：沿用我在7月份重新构建的以 Notion 为中心的博客方案

在迁移方面，主要是 Obsidian 的存量数据，直接以导入数据的方式搬运显得有些粗暴，感觉不太必要。因此我的策略是，保留现有数据，当未来发现有了某些对旧数据的关联，再一步步做搬运迁移。也如乔布斯所说的 “Connect the dots”，无须着急让某条记录立马发挥作用，某一天突然发现“原来这个想法我过去也有在关注”时候，再将它们串起来也不迟。

后记

这篇博文自10月国庆假期开工，写到这里时已年近尾声，不知不觉想了很多，或许也是我这几年在笔记工具间折腾切换的轮回之间的告一段落。

说起来做笔记这件事，并不需要纠结于具体的形式 or 工具，并非一定就要 Logseq，只是它的设计上，恰好满足了我当前的需要。在明确一些核心目标（如我前文所述）的基础下，即便是基于纸和笔，考虑其物理上的局限以及扩展的方案，经过一番设计，我们也一样可以构建出类似的体系，比如说康奈尔笔记法、结合活页本和线圈本去做 Bullet Journal 等等…（可惜我当年高考还没有这个意识 QAQ）。

选择某个工具，在于它能解决我当前的所需，并且相信它正在往更有益的方向去迭代。也深深地感觉到，在走上工作道路后，时间越来越有限，切换新工具的阻力确实挺大。在投入较大的时间精力成本去切换工具之前，试着多想、多尝试，慢慢明确自己的目标和需要，还是蛮重要的。