Matrix 首页推荐
Matrix 是少数派的写作社区，我们主张分享真实的产品体验，有实用价值的经验与思考。我们会不定期挑选 Matrix 最优质的文章，展示来自用户的最真实的体验和观点。
文章代表作者个人观点，少数派仅对标题和排版略作修改。
用 obsidian 已经两年多了，距离我上次更新《如何用 obsidian 和 flomo 搭建知识体系》已经过去一年半了，重新看了一遍以前写的内容，当时选择 obsidian 的优点，现在依然成立。
特别是第一点，通用 md 形式这个优点对我来说更重要了，但是里面的使用案例基本上都失效了，不再和 flomo 联用。
以前旧版 flomo 还没下架的时候，我还写过 flomo 下载成 md 的脚本，现在这些 flomo 文件也被我从 obsidian 里面移除了。大概率我不会换最终笔记软件了，哪怕 obsidian 是很方便跑路的。
首先，我对移动端的需求还挺高，obsidian 官方移动端不好用，很难快速丝滑地进行全局搜索，这也是我犹豫了几次要不要咬咬牙上官方同步最后还是放弃了的原因。
其次，电脑端的原生搜索，只有侧边栏小小一块，用起来很不爽，结果展示不够全面。
现在这两个问题都得到了解决，我的大部分知识管理内容主要在 obsidian 进行， workflowy 里主要是放一些个人时间轴，标记每个阶段的大事件。
方案一，不使用 obsidian 官方移动端，ios 用 1writer webdav 方式打开 obsidian 的库（文件夹），两端是实时双向同步的，不需要导入导出的操作。
我的同步平台是 win、mac、ios，同步主要用的坚果云，但是坚果云 webdav 接口有单条 750 条的限制，如果单个文件夹里没有超过这个数量不影响，因为我的超过了所以用的 alist。另外写文章的这几天 iCloud 同步卡顿的问题有所缓解，持续观察一下，如果真的变稳定了，可以直接采用 iCloud 同步。
1writer 只有 ios，30 元买断制，优点是全局搜索非常快，几乎是秒开，比 obsidian 的电脑搜索还要快。
方案二，原生搜索的两个优化插件：float search 和 better search view。
float search 的作用是把官方搜索挪到页面中间或者居中弹窗，比起原生侧边栏窄窄一条，视觉上更宽敞舒服。
better search view 的作用则是优化展示结果。比如 > 这种 md 引用语法在原生里面是不会渲染成预览效果的，用了这个插件后在搜索结果里会展示出来，此外还有图片、[]() 等语法都会渲染。如果一段话是属于某个 heading 的标题下的，在搜索结果也会展示出来，这样可以看到文本所属的标题，比如图片里是微信读书同步过来的笔记，可以看到所属章节，非常清晰。
如果库里笔记特别多，better search view 会有一点影响搜索速度，我目前 3k 条左右，在一个性能一般的 win 笔记本上用起来还好，不算卡，可以在自己的设备上感受一下能否接受。
总的来说，工具的使用比例完全倾斜到了 obsidian ，主要是它的搜索体验上去了，就像我前几篇文章里强调的：重搜索，轻整理。越来越认同这一点，是 workflowy 的搜索设计给我的启发。
把这个放在第一条写，是因为折腾效率工具以来，和很多人一对一交流过工具的使用问题，时间长了发现每个人的需求千差万别，对软件在意的方面完全不一样，比如我喜欢 obsidian 的离线可用，通用 md，很多人压根不在意什么离不离线，只想有一个打开就能用的软件。
所以现在哪怕我使用 obsidian 非常快乐，也知道它适合的人群有限，虽然还是有一种自家孩子想炫耀的心理，尽量在 obsidian 群大本营里得瑟。
最初玩 obsidian 的时候，每天就是兴致勃勃的体验各种各样的插件，笔记倒没写多少。插件系统也是很多人对 obsidian 望而生畏的原因，觉得复杂。实际上插件不是必需品，如果现在让我做选择，我觉得只有前面提到的两款搜索插件是一定要有的，其余功能官方自带都可以满足，安心和其它笔记软件一样打字就好。我的新建笔记基本上都是从空白文件开始，很少用 yaml，模板等。
其余的插件虽然也用，比如会用 dataview 写日记模板，这样每天会看一下每年今日的笔记，用 better word count 计算页面字符，库里的笔记数量等， 都是一些锦上添花可有可无的东西。我甚至都不用三方主题，就是自带的主题，稍微改一改颜色。
我的 obsidian 一级目录虽然看起来很多，但是其实只是对收藏型的内容做了来源（微信读书、wucai 等）和文件类型（pdf、html）分类，自己写的笔记都放在「我的笔记」这个文件夹里。
因为大部分内容都不需要刻意整理，只需要在想找到的时候，能快速找到就行。所以我现在很多笔记的标题就是一些关键词组合或者问句，比如 hugo 部署遇到的问题，hugo 的博客系统有哪些。
以前觉得 obsidian 的全文搜索不行，所以尝试过一段时间的单主题放在单一文件里，比如前端笔记、减肥笔记等全都放在一个 md，后来发现这样的文件，随着内容的越来越多，虽然在侧边栏可以生成一个大纲树，但是翻阅的时候会觉得非常干扰，难以专心，时间长了还会不记得哪些是自己写过的小主题。
现在一个页面一个问题的好处就是，我平常会用快速切换，可以很清晰的看到自己写过什么问题。
现在我 obsidian 里标题命名法应该算常青笔记里的原子化原则吧，对于常青笔记的概念可以参考少楠这篇 《何谓常青笔记（EvergreenNotes）》。
Ryooo 的 kg 笔记法也一定程度有点相似，但是我的命名没有那么严格的按概念笔记、实体笔记和关系笔记去分类，而且我认为很多概念和实体笔记是没有必要刻意手动用自己的话写出来的，一定程度上不认同 flomo 提倡的用自己的话做笔记。
因为概念和实体实在是太多了，如果你真的理解了这个概念，不用记下来，没有理解的话，用自己的话记录也是欺骗自己。当然我这里特指的是概念笔记，比如什么是常青笔记这些，我最近大量删除了很多这类笔记。
笔记圈里特别爱讨论的一个问题就是为什么要做笔记？其实现在回顾确实很多笔记是在骗自己，如果当时没有理解记下来的东西，事后也不会想起来自己记过这个东西。而真正理解了，好像也没有记下来的必要了，这算不算是一个笔记的悖论。
但是我还是觉得记笔记是有好处的，只是形式和以前不一样了，比起大段大段的复制粘贴，更重要的是关键词，自己遇到的问题，下次再遇到的时候需要用什么关键词快速找到答案，建立起一个个锚点。
那么在自己完全理解某个概念前和问题前，应该怎么办呢？完全放任不管也不行，时间长了也想不起来看过的资料。
我使用剪藏类的工具也有很长时间的历史了，从最初的印象笔记全文剪藏，到 cubox 的全文剪藏基础上再划线，再到现在的五彩划线，发现收藏量级上去以后，想要找到自己看过的某个文章的内容是很难的，而且大部分的划线，更多的是在那一刻的认同，不一定对自己是真的有实际意义的。
渐进式总结里也提到了这个困境：知识的挑战在于跨时距，现在的你要为未来的你埋点，让未来更快的找到想要的内容，而不是淹没在一堆不经筛选的内容里。
所以你才需要在每次搜索了某个问题后，进行一个阶段性的小结，我现在的做法就是用五彩和 obsidian 结合，比如我搜正手划船和反手划船的区别，看到认可的内容会划线，看了好几个网页后，我会在最认可的某些答案里，会加上双链 [[正手划船和反手划船的区别]]，相当于双链是我搜索的最高权重，只有我认为最有参考价值的才会加，如果某个问题我没找到最满意的答案，这次在原网页上高亮划线的内容，可以在我下次查找的过程中起到作用。
可以很清晰看到，这个页面的并没有刻意用自己的话去复述自己的笔记，因为这篇文章的答案我已经很满意了，一句话概述就是正手主要锻炼的是背的上半部分，反手是下半部分。下次我想再复习一下原因，可以很快的重新打开这篇文章查看，也不用做很多复制粘贴的工作。
当然不必在每一次搜索的时候都要做笔记，我现在的强迫症越来越少了，想找某个资料找不到的情况一定会发生。既然不可能 100% 杜绝找不到，那好像 1-99% 的概率会找不到区别也不是特别大。
找不到的时候都是会不爽的，所以为了减少一点点找不到的概率，而去事无巨细的存、整理花费的时间。相比之下还是调整一下心态性价比高一点。
以前觉得 obsidian 作为文档型笔记软件，块引用没有 logseq 优雅，所以双链用的比较少。现在用单页面单个具体问题的方式后，在我的 obsidian 库里页面引用其实等于块引用。
前面提到我的笔记不分类，可能你会困惑怎么结构化，答案和以前一样还是 moc，但是只有一个主题相关的卡片非常多了，有必要建一个索引我才会建 moc，下面是我的一个 moc 示范。
这种 moc 的搭建不会建很多，目前我只有这些：
这个 moc 文件名搜索是一个文件，里面用的是 obsidian 自带的嵌入 query 语法，这个语法好像已经上线两年了，我最近才知道。
```query
file:"moc" -搜索
```用这个语法的场景是，有一些经常需要调用的搜索，搜索条件又不止一个关键词，懒得每次输搜索条件，可以建一个这样的页面来存搜索条件，我就有一个文件夹叫搜索存档。
我的 obsidian 2023 年版使用心得就分享到这里啦，前面埋了一个彩蛋，引用了我的博客的一段内容，是我前段时间用 hugo+github pages 折腾的，有修改的内容会在博客版继续更新，有兴趣可以关注一下。
> 下载 少数派 2.0 客户端、关注 少数派公众号，解锁全新阅读体验 📰
> 实用、好用的 正版软件，少数派为你呈现 🚀
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。