用了2年Obsidian,Logseq以前也知道并试用过,当时只有web版,稳定性差就没关注了。不久前看了Randy Lu关于Logseq的视频分享,被吸引到了,于是试用了2周。这期间只用Logseq,没用Obsidian。

现在,想基于经验分析下二者的功能差异及未来的可能的迭代方向。需要说明的是,这不是一个教程,但如果你正在试用这两个软件,并在犹豫选择哪一个,本文或许能提供一些视角。

这两个软件共同主打的特点是:本地存储+文本文件。这对在意数据安全、数据可迁移性的用户(比如我)来讲,非常有吸引力。

它们的核心差异点有两个:

  1. Logseq强制使用大纲视图,Obsidian是自由格式的markdown文档
  2. Logseq没有文件夹结构,Obsidian有文件夹结构。

一、首先讲讲自由格式与强制大纲带来的影响

Logseq强制使用大纲视图,其实就是block优先,先有block,然后block组成page,并且block还有层级的关系。

Obsidian自由格式,就是page优先,当它想去支持block的时候,只能从段落出发,每一段是个block,段落间当然也没有层级关系。(官方文档介绍:前后有空行包围的东西就是block)。

从通用性来讲,Obsidian的自由格式,其实兼容Logseq大纲视图。网上有很多人分享二者共用一个库的方案,无一例外的都是以Logseq库为准,然后让Obsidian去兼容Logseq,充分佐证了这一点。

以block为例,前方讲Obsidian的block是基于段落的,但大纲带也是支持的,如下图所示。

Obsidian大纲中的反向链接
Obsidian大纲中的反向链接

相比Logseq的block,Obsidian的block有两个问题:

  • Logseq能直接在反向引用中编辑和操作(比如点击链接)内容,Obsidian则必须跳转到原文档才能编辑和操作。
  • Logseq的#标签和``引用,都是作用于块的属性,通过query能直接查询到块,Obsidian通用dataview的query只能查询到page。

尤其是第2条,对task的管理非常重要。事实上,Obsidian的dataview社区已经在计划实现相关功能了。

再看看Logseq,因为是强制大纲,所以不适合写长文,有趣的是,Logseq社区呼声第二高的Feature Request就是支持长文写作

这个帖子对Logseq应该如何处理长文block给出的建议,就是Obsidian基于段落的方案。

按照这个畅想,Logseq支持定义page的类型,一类是大纲视图page,一类是长文视图page。

长远来看,Obsidian在自由格式上支持更友好的block是顺理成章的事,但Logseq在现有强约束的情况下去支持自由格式的长文,需要打破框架。不清楚Logseq团队是否会考虑支持长文(目前roadmap中还看不到),但这确实是我无法放弃Obsidian唯一的原因。

我个人比较期待二者最后殊途同归,Obsidian更好的支持block,Logseq打破框架支持长文写作。

二、再谈谈文件夹支持

这一点,同样体现了Obsidian对Logseq的兼容。

至于哪个更好,这个见仁见智,我倾向于Logseq简化文件夹的方式,减轻分类的压力。Logseq的页面支持namespace层级,可以实现类似文件夹的功能。但需要注意,这是非常定制化的能力,离开了Logseq这样的关系就丢失了,所以,如果考虑数据的可迁移性,这个功能应该慎重使用。

三、我最终的选择

我希望在笔记软件中写长文,Logseq无法完全替代Obsidian,虽然Obsidian的大纲能力比Logseq弱但也完全够用,所以本着少折腾的原则,继续使用Obsidian。但在使用习惯上,会把Obsidian中的daily note大纲化。

哪天Logseq支持长文了,会考虑迁移。也许那一天,Obsidian的block能力也能与Logseq并驾齐驱了。

最后,本文使用Obsidian写成。

相关阅读

🔔 Email 或 RSS 订阅本博客

已有 41 条评论

  1. 文章对于二者的对比,对我很有启发,我在 obsidian 上同时实践类似于 daily note 的周期笔记,以及 PARA,感觉挺舒服的:
    https://zhuanlan.zhihu.com/p/640042778

    1. 你这个写的好详细👍
      我也基本在用PARA,但非常轻量,不太重整理,啥都依赖搜索和双链。

      1. PARA 很大一部分在日记中记录了,所以也不太需要整理!

  2. 好巧我也看过Randy Lu的这期视频,目前我主要是以Logseq写日记和灵感,Obsidian的多端丝滑流畅一直让我有点摇摆,其次觉得自己的写作水平较难以一次性生成长篇的内容,所以目前还是在使用以block为主的logseq,毕竟Obsidian主要是以Page为主,以无序列表代替Block的大纲感觉还是差了不少意思。不知道博主平日里的日记以及灵感主要是怎么记录下来的(memos和Flomo也使用过,但都觉得差点意思),如果博主有分享记录方式的话,希望能够学习学习,谢谢啦~
    另:无意间进入博客,感觉氛围和字体非常棒,赞一个👍👍

    1. 是的,Obsidian的Block体验差不少。

      所以,我用memos收集灵感,然后用脚本下载到Obsidian库,每条memos保存为一篇笔记。定期在Obsidian中整理这些memos,该删的删,该扩展的扩展,以及打上tag,做双链关系。

      总的来讲,基于Page,实现原子笔记。

      我在Obsidian也用Daily Note,但Daily Note只记录当天todo、每日总结(偏流水账类型)、往年今日(用dataview查询)。灵感/知识类的笔记不放Daily Note。

      1. 谢谢博主的回复!你的写作排版好赞,果然是习惯 Obsidian 的人,我的 Logseq 习惯一写出来就是一大段…😂

        有几个疑问还请指教:

        1.记流水账 Daily Note 的话,不怕污染知识库吗?

        2.如果 memos 太短的话,我总觉得是不是太占用文件数了(总觉得一个 md 文件就应该尽量多一些内容,可能是纸质笔记的后遗症)

        3.Logseq 的模式是偏园丁型的,Page 无需刻意的分类,但 Obsidian 是以文件夹式管理的,当文件数量比较大的话,文件分类反而成了一个比较大的工作量,比如博主脚本导出的 memos 库,在归类上有什么高见吗?这一直是比较困扰我的地方。

        上一条不知道为什么有序列表丢了…

        1. 直接一条条回复:

          1、我使用目录做大的领域区分,加上Obsidian的搜索、图谱都支持目录筛选功能,能解决污染问题。我的目录按如下方式组织:

          (1)日记:即Daily Note,下面按年月组织子目录。
          (2)博客:发在博客的文章,下面分文章、周刊、页面三个子目录,文章和周刊对应本博客的两个大分类。
          (3)笔记:即所有知识类笔记,不分子目录
          (4)摘录:按来源工具分子目录,具体有:
          微信读书:有Obsidian插件支持导出,一本书一条笔记。
          hypothesis:一款网页标注工具,有Obsidian插件支持导出,一个网页一条笔记
          Omnivore:是一款稍后阅读+标注的工具,有Obsidian插件支持导出,一个网页一条笔记
          memos:自己写脚本导出

          总体而言,我按功能组织目录,不用纠错一条笔记应该放在哪。工作流大概是:

          (1)摘录目录是最需要整理的部分,它本身只是一个缓冲,我通常将好的摘录内容复制一份到笔记目录作为永久的知识笔记,并且往往会用自己的语言进行重写,再用一条引用链接关联到原始的摘录笔记。(很长的,涉及多主题的接录,比如读书摘录,也会创建多条知识笔记,关联到原始的摘录笔记)
          (2)笔记目录作为主要知识库,我不分子目录,全部使用标签进行分类,可以一对多,使用起来方便,不用纠错分类问题。同时,我有尝试MOC组织笔记,但目前做的也不太好。
          (3)输出都放在博客目录下。
          (4)日记很纯粹了。

          2、对,我以前也这样,觉得短内容建一条笔记不好。这是一个纯粹的观念/心理感受问题,现在已经克服了,不必让这个观念成为工作使用的阻碍。我有些一句话笔记,甚至没有正文,直接写在标题中就行了。

          实际上,我现在觉得建一条新笔记有些好处:

          (1)强迫判断一下,一条短内容有没有价值,没有价值就删除掉。
          (2)如果有价值,应该适当的扩展一下,或与其它的笔记形成关联。短内容最典型的就是名言,但名言都是一些大道理,如果要使用它,最好是与一些案例进行关联,可以与一些案例笔记进行关联。

          3、目录问题在1中阐述了。

          1. 认真读了很多遍,受教了,非常非常感谢!
            我觉得有从Logseq转到Obsidian的动力了(差生文具多系列)

            1. 我也分享下我的实践:
              我采用两套系统,一个是知识管理系统,另一个是周期笔记,前者以项目/领域/资源为维度,进行知识管理,后者以时间为维度,进行任务/目标/时间管理。这样自然而然分开了两个系统,但是二者之间通过标签相互索引!

              知识管理:采用 PARA 系统

              Projects -> 项目是与目标相关的一系列任务,有截止日期Areas -> 领域是一种活动领域,需要在一定时间内保持一定的标准Resources -> 资源是持续感兴趣的话题或主题Archives -> 存档是来自上述三个类别的非活动条目

              周期笔记

              长期:自顶向下,专注于长期的目标短期:自底向上,专注于短期的任务
              -日常:捕捉想法洞见,实现自我觉察;耗时统计,确保聚焦于项目
              -日记

              其中 PARA 越靠近 Projects,它的可操作性就越高;周期笔记越长期,它的可预测性就越低;
              这两套系统相当于制造了两个上下文,让我保持聚焦

              一个是基于时间的(周期笔记),即我到达某个时间节点,我就基于对应周期笔记作业,且笔记中有足够的上下文;
              另一个是基于主题的(PARA),即我想对某个主题进行调查研究的时候,我就基于对应主题的索引(README.md)作业,且笔记中已经收集了不少上下文;

              完整的实践请前往:https://zhuanlan.zhihu.com/p/640042778

      2. 谢谢博主的回复!你的写作排版好赞,果然是习惯Obsidian的人,我的Logseq习惯一写出来就是一大段…😂

        有几个疑问还请指教:

        记流水账Daily Note的话,不怕污染知识库吗?如果memos太短的话,我总觉得是不是太占用文件数了(总觉得一个md文件就应该尽量多一些内容,可能是纸质笔记的后遗症)Logseq的模式是偏园丁型的,Page无需刻意的分类,但Obsidian是以文件夹式管理的,当文件数量比较大的话,文件分类反而成了一个比较大的工作量,比如博主脚本导出的memos库,在归类上有什么高见吗?这一直是比较困扰我的地方。
        1. silascript silascript

          obsidian什么时候以文件夹管理了?ob你可以完全一个文件夹都不建,用标签等方式管理--某些ob使用者是完全不建文件夹,文档都“散掉”的,就靠标签、链接等将知识点“凑”起来。所谓文件夹结构,就是树型结构,这种方式有优点也有缺点,优点是层次分明,分类清晰--这种结构非常适合“强迫症患者”,缺点就是有些东西是似是而非,不太好归类,而且过多或过深的目录结构,在使用和管理上也麻烦。所以我个人使用经常是使用“矮树型”,即使用不超过两层文件夹归类方式管理文档。而像logseq这种扯蛋的创新,完全就是削弱了markdown的文档能力(相较的,ob才是将md这种文档的可能性发挥到极致的软件),还多此一举地弄出个block概念。logseq就只适合记下日记、周期什么的,就如它的名称logseq中的log日志一般,它的适用范围就只在日志这块,其他超出这范围的使用,只能在使用上非常难受!

  3. LiuDun LiuDun

    最近几天就在纠结使用那个呢,obsidian使用过一段时间,很酷,但是也很折腾。想试试logseq。感谢分析。👍

    1. 界面和交互的简洁性,Logseq更胜一筹。
      从折腾来讲,都挺折腾,但形式不一样。

  4. Hex Hex

    1.我怎么记得Obsidian可以链接到块啊。
    2.Logseq没有文件夹这也太激进了吧,为什么要把传统的文件管理方式全盘否定掉。(管理文件本身是一个非常耗费精力的事情,Logseq干脆不管理)对于新手来说很容易一脸懵逼。
    3.Logseq的审美比Obsidian差一大截。😂

    1. Obsidian是UI大改版之后好看了,感觉刚开始的UI也不好看。
      Logseq的UI,甚在简洁,当然,也是因为没有文件管理面板带来的简洁。

      文件管理这部分,其实我个人是更喜欢纯标签管理的,像Gmail那样,没有分类的压力和纠结(我现在实际也只分了很少几文件夹),但这个方式确实非常依赖app,不通用,如果离开了app,在电脑文件系统看就很麻烦。

  5. a-nobody a-nobody

    觉得logseq激进一点应该没有什么所谓,毕竟开源,不会太影响可迁移性。

    下一个软件可以借鉴logseq的源码

    1. 也很期待,笔记还能做成什么样。
      从传统的印象笔记到Notion的数据库,再到RR的双链+block。很难想像还能做成什么样,哈哈。

  6. Obsidian 不强制双向链接主导的文件索引模式,增加了文本的「通用性」,日后有合适的软件,迁移成本较低。
    我现在是把永久笔记存放在目录文件夹中,子弹笔记和文献笔记都沿用双向链接架构的文件管理模式。
    保证永久笔记迁移的低成本。
    另外,更看好 Obsidian 的商业模式和社区活力。

    1. 感觉双链已经成为笔记软件的标配,未来的兼容性应该不是问题,没有Obsidian,其它软件也会支持。
      但实际使用中,我还是倾向于文件夹+标签管理笔记,双链不作为管理/索引手段,仅仅真的是一个笔记要引用另一条笔记时使用。

  7. Peng Peng

    写的挺深入的,正在用logseq的我准备去试试obsidian看看。
    有个问题是,logseq的#和[[]]只能找到页面啊,不能作用于块吧?

    1. fit666 fit666

      能使用对块的引用啊,官方文档上有,在官方文档上搜索“块引用”就行

    2. 是的,logseq的块只有(())

  8. hun ojo hun ojo

    当长文章作为出入链显示在某页面的下方,想想就摇头。
    logseq显示模式还是略显简陋。

  9. hun ojo hun ojo

    logseq页面下方显示出入链,通常不会折叠。
    当一或几篇不怎么分块(block)的长文章作为出链显示在某页面的下方,那酸爽。。。
    当下logseq的显示模板,太简陋,使得zhangw

    1. 这个可以在edn配置文件中设置,反链显示几层关系。默认显示了匹配块的子节点,如果有大量并列的子节点,就会造成你讲的现象。解决上:
      1、可以考虑设置不显示子节点,或者
      2、有意识的避开写大量并列子节点,我用这个方法,如果有大量子节点,一般会再分组,弄成孙结点,不会在反链中呈现。
      这个部分Obsidian确实处理的巧妙一些,有三个选项:只显示标题、只显示匹配块、显示匹配块的上下文。并且这三个选项随时切换,不用在设置中写死。

  10. 重度使用一年多ob了,最近被朋友安利logseq还在入坑,摸索到了这篇文章
    作者把特点和问题都梳理得好清楚!而且最后选择的解决方法也一致哈哈,还是ob为主,思考怎么兼容logseq一起使用
    希望作者对ob未来会改进块体验的畅想会成真!我也是觉得,如果ob现在着手改进块引用,其实也没有无法解决的障碍。把代码隐藏显示(像callout、表格那样做成及时渲染);把块和页解除绑定、每个块有独一无二的标识码,就差不多可以了

    1. ob的客户端迭代明显慢下来了,块的支持还看不到希望。Notion的数据库功能,倒是看到一些插件朝这个方向努力。

      1. 宋图样 宋图样

        现在的obsidian里,^和[[^^ 命令的块引用很差吗?

        1. 肯定是不如Logseq来的灵活,Logseq的块有层级关系,且能在引用的地方直接编辑。Obsidian目前不行(貌似有插件尝试实现,没具体用过。

          我个人对块引用诉求不强,我一般会尽量把笔记原子化。即使是长篇笔记,到标题引用一般也够用。

添加新评论