Markdown 工具太多了，我决定做一次「最小保留」

在日常工作和生活中，我使用 Markdown 的频率越来越高，现在几乎已经到了离不开的程度。

但与此同时，我也发现自己使用的软件越来越多：这个软件有一个喜欢的功能，那个软件又有一个舍不得放弃的功能。到最后，功能越来越冗余，工作流越来越复杂，注意力反而被不同的软件不断分散。

软件本来应该帮助我们提高效率。如果为了寻找、配置和切换工具，反而投入了越来越多的时间，那多少有些本末倒置了。

所以最近我决定按照一个原则，重新梳理自己的 Markdown 工具：

最小保留。

能用一个软件解决的，就不用两个；没有明确使用场景的软件，即使功能再强大，也没有必要为了“可能以后会用”而强行塞进自己的工作流。

这篇文章就来梳理一下我目前使用过的几套 Markdown 工具，以及折腾一圈之后，它们最终在我的工作流中分别处在什么位置。

主要涉及：

• Obsidian & Obsidian Addons

• Typora, Zotero & Zotero Plugins

• VS Code & VS Code Extensions

如果先说结论，目前我的选择其实很简单：

长文写作 → Typora

科研阅读笔记 → Zotero + Typora

代码、项目文档以及其他 Markdown 操作 → VS Code

Obsidian → 暂时退出日常工作流

Obsidian & Obsidian Addons¶

前不久，我在使用 Typora 本地管理和同步 Zotero 笔记时遇到了一个问题：因为笔记抬头中的“版本编号冲突”，无法在不同设备上基于同一个 Markdown 文件正常同步 Zotero 笔记。

为了解决这个问题，我专门安装了 Obsidian。

当时的思路是：使用 Obsidian 管理本地 Zotero 笔记，再借助 Zotero 插件 MarkDB-Connect，实现在本地查看、修改和同步 Zotero 条目中的笔记。

这套方案确实解决了之前遇到的版本冲突问题。

但后来，我开始使用 Zotero 插件 Better Notes for Zotero 的笔记同步功能，发现它同样可以很好地解决这个问题，而且更符合我原来的使用习惯。

于是，刚刚配置好的 Obsidian 就被我晾在了一边。

直到现在，我也基本没有再真正使用过它。

不过，当初安装 Obsidian 的时候，我还是花了一番心思，按照自己的需求给它配置了一套有必要、但尽可能精简的插件组合。

虽然 Obsidian 最终没有进入我目前的主力工作流，但我依然觉得这些插件的组合不错，所以还是记录下来，也给正在使用 Obsidian 的小伙伴做个参考。

这次折腾也让我越来越确定一件事：

一个软件很好，不代表我就一定需要它。

Obsidian 很强大，但如果现有工具已经能够很好地解决我的需求，那么再增加一个功能高度重叠的软件，对我来说带来的可能不是效率，而是额外的管理成本。

所以目前，我选择暂时把它移出自己的日常工作流。

Typora, Zotero & Zotero Plugins¶

如果说 Obsidian 是我折腾之后暂时放弃的工具，那么 Typora 则恰恰相反——它是我折腾了一圈之后，依然非常确定会留下来的软件。

对我来说，Typora 是最适合写 Markdown 长文的工具之一。

它的“所见即所得”加上极其简洁的界面，可以让人在写东西的时候几乎感觉不到 Markdown 语法本身的存在。

没有左右分栏，没有大量按钮，也没有太多东西提醒我“你正在使用一个软件”。

打开文件，然后开始写。

我很喜欢这种感觉。

对于经常需要写东西的人来说，能够在 Typora 里安安静静地进入心流，是一件非常幸福的事情。

目前，我使用 Typora 主要有两个目的：

1. 本地查看、修改和管理 Zotero 笔记；

2. 写公众号文章草稿以及其他 Markdown 长文。

为什么要把 Zotero 笔记放到本地？¶

可能因为 Zotero 本身就比较吃内存，当笔记篇幅稍微长一点以后，直接在 Zotero 中打开、浏览和修改笔记，有时会变得不太流畅，甚至出现卡顿。

而相比之下，Typora 在处理长篇 Markdown 文本时要舒服得多。

所以我现在的思路是：

Zotero 负责管理文献和保存最终笔记，Typora 负责真正的阅读和编辑体验。

也就是说，我把 Zotero 笔记导出为本地 Markdown 文件，在 Typora 中查看和修改，再将修改后的内容同步回 Zotero。

整个工作流可以简单概括为：

Zotero → Markdown → Typora 编辑 → 双向同步 → Zotero

为了实现这套工作流，我目前在 Zotero 中安装了两个插件：

• Better Notes for Zotero

• MarkDB-Connect

这两个插件在我的工作流中承担的任务并不完全相同。

MarkDB-Connect 主要负责建立本地 Markdown 文件与 Zotero 条目之间的联系；Typora 负责本地 Markdown 文件的查看和编辑；真正的笔记双向同步，则交给 Better Notes for Zotero。

我会刻意避免让 MarkDB-Connect 同时参与笔记同步，以免两个插件同时操作同一批 Markdown 文件而产生冲突。

下面是我的具体设置。

1. Better Notes for Zotero¶

首先进入：

Zotero → Settings → Better Notes → Sync

我的设置为：

• Auto-sync period (seconds): 1

• Attachment folder: attachments

• √ Auto-sync notes linked to / from an already-synced note

设置完成之后，进入：

Zotero → Tools → Sync Manager → Detect

选择本地用于管理 Zotero 笔记的路径，例如：

~/ReadingNotes

然后依次：

Refresh → Sync

其中，Refresh 用于更新本地文件夹中当前已有的笔记文件，Sync 则负责双向同步本地 Markdown 笔记和 Zotero 数据库中的对应笔记。

实际使用下来，这个同步过程几乎是毫秒级的，基本没有体感。

也是因为这一点，我后来彻底把笔记同步交给了 Better Notes for Zotero。至少在我的使用场景下，它比 MarkDB-Connect 自带的笔记同步功能好用太多。

2. MarkDB-Connect¶

接下来设置 MarkDB-Connect。

Location of Markdown Reading Notes¶

Folder Containing Markdown Reading Notes

这里我会故意设置为一个根目录和所有子目录中都不包含 Markdown（.md）文件的路径，例如：

~/Desktop

这么设置看起来似乎有点奇怪，但其实是故意的。

目的就是让 MarkDB-Connect 的同步功能找不到任何 Markdown 笔记，从而避免它和 Better Notes for Zotero 同时同步同一批文件而产生冲突。

Custom File Filter → RegExp (case insensitive)

设置为：

/^NOTES-(\w+)\.md$/i

也就是说，我的笔记文件名统一以 NOTES- 为前缀。

Match Markdown Files to Zotero Items Using¶

选择：

Zotero-Item-Key - captured with custom RegExp

RegExp 设置为：

/^\$itemKey:\s*(\w+)/m

Open Markdown Files using¶

选择：

System’s Default Editor

Advanced Settings¶

我的设置为：

• Specify a Custom Tag Name? → tag: Typora

• Include Group Libraries? → Also match items in Group Libraries.

• Remove tags from unmatched Zotero items? → Keep Zotero tags synced with Markdown Database (recommended).

3. 导出 Zotero 笔记¶

最后是笔记导出。

在 Zotero 中选中条目内的笔记，右键选择：

Export Note…

然后设置：

• Format: Markdown (.md)

• √ Convert linked notes to standalone exports

• √ Set auto-sync for each note

• √ With YAML header

• √ Auto generate file name

最后点击 OK。

至此，我现在使用的 Zotero + Typora 本地笔记工作流就基本搭建完成了。

这套方案最让我满意的一点，是三个工具的职责非常明确：

Zotero 管文献，Typora 管阅读和编辑体验，Better Notes 管同步。

各做各最擅长的事情。

VS Code & VS Code Extensions¶

Typora 适合让我专心“写东西”，但一旦进入代码、项目文件和更复杂的 Markdown 使用场景，我还是会回到 VS Code。

以下是我目前日常使用 VS Code 时，所有涉及 Markdown 的相关插件：

这些插件各自承担不同的功能，基本涵盖了我在 VS Code 中与 Markdown 文件互动的大部分场景。

具体每个插件的特色功能这里就不一一展开了。

不过，有一个插件我特别想单独说一下。

因为它是一个——

我安装之后觉得惊艳，然后又迅速卸载掉的插件：Office Viewer。

刚安装的时候，我甚至一度觉得它可以替代 Typora。

因为它直接在 VS Code 中实现了类似 Typora 的“所见即所得”体验。如果能够在 VS Code 里同时获得代码编辑能力和 Typora 式的 Markdown 编辑体验，理论上我甚至可以再减少一个软件。

听起来非常符合我的“最小保留”原则。

可惜实际使用没多久，我就放弃了。

原因是它占用了太多我日常使用的快捷键，包括复制、粘贴，甚至回车，严重影响了我正常使用 VS Code。

当然，这些快捷键冲突完全可以自己重新配置。

但我懒得配。

所以最后还是把它卸载了。

于是，我又回到了现在的方案：继续使用 VS Code + 上述 Markdown 插件完成各种复杂操作，而把真正需要专心写长文的场景交给 Typora。

这反而让我觉得更舒服。

最后：我到底留下了什么？¶

折腾了一圈 Obsidian、Typora、Zotero 和 VS Code 之后，我目前真正留下来的 Markdown 工作流其实比以前简单了很多：

• Typora：专心写长文，以及查看和编辑本地 Zotero 笔记；

• Zotero + Better Notes + MarkDB-Connect：管理文献，并连接本地 Markdown 阅读笔记；

• VS Code：处理代码项目中的 Markdown，以及需要更多扩展功能的 Markdown 使用场景；

• Obsidian：配置保留，但暂时退出日常工作流。

以前我很容易因为一个软件有某个独特的功能，就觉得“这个也应该留着”。

但现在越来越觉得：

软件的价值不在于“它能做什么”，而在于“我是否真的会用它做什么”。

一个功能再强大的软件，如果没有进入自己的真实工作流，它最终也只是多一个需要安装、更新、配置和管理的东西。

工具越多，并不意味着效率越高。

真正理想的工具组合，也未必是功能最全的那一套。

对我来说，现在更喜欢的是：

在能够满足需求的前提下，让工具尽可能少，让每一个留下来的工具都有一个明确的位置。

这就是我现在理解的——

“最小保留”。

总结¶