关于 Markdown 批注
我一直有给笔记做批注的习惯。
有时候只是把一句话高亮标出来，提醒自己以后再看；有时候则会在后面写一段自己的评论，记录当时为什么觉得这句话重要，或者它和我正在研究的某个问题有什么关系。
这件事听起来很小，但如果长期阅读、写作、做研究，或者经常整理资料，就会发现：高亮和批注其实不是装饰，而是一种非常基础的信息加工动作。对于很多基于 PDF 论文工作流的人来说，这已经是日常操作。只不过我面对的不是 PDF，而是 Markdown 笔记。
毕竟原文可能只是网页摘录，也可能来自别人的观点，批注才真正属于自己。
过去很长一段时间里，我对 Markdown 语法的用法了解得并不深，所以一直用最简单的方式处理这类需求。比如用「加粗」表示重点，用「斜体」表示补充说明，或者直接在原文下面另起一行，写上「我的看法」。（很粗糙的做法，是吗？）
这种方式当然也能用，而且很直接。但它不够清晰。
一篇文章里如果到处都是加粗，很快就分不清哪些是原文重点，哪些是我自己的判断；如果评论直接混在正文里，过一段时间再打开，就会有点像考古：当时这句话到底是引用，还是我自己写的？这段补充是临时想法，还是已经整理过的结论？
后来我才知道，Markdown 生态里其实有一些更适合批注的写法。
比如在很多 Markdown 工具里，可以用：
==高亮部分==
用来表示高亮内容。
在 Obsidian 里，还可以用：
%%批注内容%%
用来生成备注或注释。
这比单纯加粗要明确得多。高亮就是高亮，批注就是批注，正文、重点和个人评论之间开始有了边界。
再后来，我又查到了一种叫 CriticMarkup 的标注语法。它看起来比普通 Markdown 稍复杂，但表达能力也更完整。它不仅可以表示新增内容、删除内容，还可以表示替换、评论和高亮。比如：
{++新增内容++}{--删除内容--}{旧内容~>新内容}{>>评论内容<<}{==高亮内容==}
它的思路很像一种纯文本版本的「修订模式」。
过去我们在 Microsoft Word 里审阅 DOCX 文件时，会看到某个人增加了哪句话，删除了哪一段，旁边还有评论气泡。CriticMarkup 想做的事情，某种程度上就是把这套审阅动作搬回到纯文本里。
这点对我很有吸引力。因为它不依赖某一个特定软件，也不一定要进入复杂的在线协作系统。只要文本本身还在，标注信息就依然还在，不会被锁进某个云端 SaaS 的评论数据库里。
当然，CriticMarkup 原本更偏向多人协作场景。几个人共同修改一份文章、文档或手稿，需要知道谁删了什么、谁加了什么、哪些地方还有争议。这套逻辑和 Word 的审阅功能有点像，只是表达方式更朴素，也更接近 Markdown 用户熟悉的纯文本工作流。
但我后来意识到，它也不一定只能用于多人协作。到了今天，另一个很常见的批注者，可能就是 AI Agent。
比如我写完一段文章，让 AI 帮我 review，它不一定非要直接改掉原文。更好的方式可能是：保留原文，让 AI 用某种批注语法标出哪里表达不清、哪里逻辑跳跃、哪里可以补充例子。
这样我既能看到建议，又不会失去对文章的控制权。这和我一直喜欢的本地优先工作方式很契合。
我不太喜欢把所有资料都塞进一个在线平台，再依赖平台提供的评论、任务、协作和版本功能。它们确实强大，但也会让一份原本简单的文本变得越来越重。
相反，如果批注本身就能留在 Markdown 文件里，那么无论我用 Obsidian、VS Code，还是其它本地编辑器打开，它都仍然是可读、可检索、可迁移的。
这时候，Markdown 也可以变成一种轻量的审阅格式。
我可以给摘录加高亮，可以给段落加评论，可以让 AI 留下修改建议，也可以在以后重新回到这些批注里，判断哪些想法值得展开，哪些只是当时的一闪而过。
不过，高亮和批注只是第一步。
真正的问题是：当我们有了足够多的笔记高亮和评论批注之后，下一步该怎么办？
一开始，几条高亮很好处理。它们就躺在原文里，打开笔记就能看到。
但当一个资料库里有几十篇文章、几百条摘录、上千处高亮之后，情况就变了。高亮不再只是「醒目的黄色标记」，而会变成一堆散落在不同文件里的信息碎片。
你曾经觉得重要的句子，可能已经被埋在很深的目录里；你写过的评论，可能再也不会被重新看见。
这时候，我们需要的就不只是「能高亮」了。
我们需要的是：能把高亮和批注重新收集起来、整理出来，变成可以回顾、筛选、重组的材料。
也就是说，批注的价值不只在于标记当下，而在于它们能否在未来再次浮现出来。
这也是我后来开始关注 SideBar Highlights 这类 Obsidian 插件的原因。
SideBar Highlights 登场
我试过很多 Obsidian 插件，但真正能留下来的并不多。
有些插件野心太大，什么都想做，界面复杂，设置复杂，工作流也复杂。还有一些插件则刚好相反，功能太薄，几乎没有真正解决问题。
所以我后来对 Obsidian 插件有一个很朴素的判断标准：它最好只解决一个清晰的问题，但要把这个问题解决得足够顺手。
对于高亮和批注这件事，我还有一个附加要求：批注信息必须保留在原来的 Markdown 文本文件里，不要另外开一个数据库出来。
因为一旦批注被单独存到某个插件数据库里，它就开始脱离原文了。
今天这个插件还在，当然一切都好；但如果以后插件停止维护、换设备、迁移笔记库，或者我只是想用 VS Code 打开这些 Markdown 文件，那些批注信息还能不能跟着走，就变成了问题。
我不希望自己的阅读痕迹被锁在某个插件里。
我更希望它们就是文本本身的一部分。高亮也好，评论也好，任务也好，都应该和原文待在一起。这样哪怕脱离 Obsidian，哪怕以后换一套工具，这些信息依然可以被看见、被搜索、被处理。
SideBar Highlights 基本上正好符合我的需求。
侧边栏高亮列表
最核心的功能当然是侧边栏列表。
打开一篇笔记后，SideBar Highlights 会把里面的高亮内容集中显示出来。对于长文来说，这个体验非常直接。你不用在正文里滚动查找，只要看侧边栏，就能知道这篇笔记里有哪些地方曾经被你标记过。但需要注意的是，这里所谓的高亮，是指 == ，%%，和脚注（包括 尾注 和 inline）；但并不支持 CriticMarkup 语法， CriticMarkup 太专业了，更适合协作，而不是个人批注使用。
这有点像给长文自动生成了一份「个人重点目录」。
普通目录显示的是标题结构，而 SideBar Highlights 显示的是阅读结构。标题是作者安排的，高亮是我自己留下的。两者合起来，才更接近一篇文章真正被理解和处理过的样子。
也可以把它理解成一份围绕个人阅读痕迹生成的侧边目录。
你不需要重新阅读整篇文章，就能先看到自己当时标出来的重点。看到某一条内容时，也可以直接跳转回原文所在位置。
这就很适合二次阅读。
第一次阅读时，我可能只是顺手高亮；第二次打开时，我不一定想从头读到尾，而是想快速回到那些曾经触动我的地方。
SideBar Highlights 提供的侧边栏列表，就像是把这篇文章压缩成了一组可以跳转的线索。
颜色和 Collection
更进一步，SideBar Highlights 不只是显示高亮。
如果你给不同类型的批注使用不同颜色，它也可以帮助你区分这些内容。
比如我可以把事实信息标成一种颜色，把值得引用的句子标成另一种颜色，把需要追问的问题标成第三种颜色。这样一来，高亮就不只是「我觉得这里重要」，而可以进一步变成一种分类动作。
如果想把散落在各篇笔记里的标记聚合到一起，除了通过颜色区分，也可以通过 Collection 重新组织。
Collection 可以理解成一个分组，或者类似文件夹结构，用来把选定类型的批注汇聚到一个地方。
不过这里也要注意：Collection 会保存到专门的外部文件中，所以它和直接留在 Markdown 原文里的高亮不完全一样。不是说 Collection 不能用，而是它已经不是完全嵌在原 Markdown 文件里的信息了。从数据迁移和长期可控的角度看，这里多少会有点风险。
所以我个人觉得，如果没有强烈需求，未必一定要用 Collection。只靠 Markdown 原文里的高亮、注释和颜色分类，对很多个人使用场景来说，已经足够了。
筛选和过滤
有了高亮列表，并不意味着我一定要一次看完所有高亮，而可以只看某一类标注。
比如只看某种颜色，只看某一组 Collection，或者只看当前阶段真正关心的内容。
当高亮越来越多之后，新的问题很快就会出现：信息太多了。
原来我们是担心重要内容被正文淹没，现在又变成了高亮本身太多，需要继续筛选。
SideBar Highlights 支持多种筛选语法。对多数个人使用场景来说，已经足够。
比如我只想看「问题类批注」，或者只想看某个项目相关的高亮，就不必再从全部标记里手动翻找。它本质上是在高亮之上，又加了一层索引能力。
从正文，到正文的索引，再到索引的索引，某种程度上，这正是我们学习和整理知识的过程：从复杂材料中抽象出一个压缩模型。LLM 理解语言世界的方式，或许也有点类似。
默认隐藏的 Task Tab
还有一个容易被忽略的小功能：SideBar Highlights 里有一个默认隐藏的 Task Tab，我也是无意中发现的。
打开之后，它可以把 Markdown 笔记中的代办任务（- [ ] 语法）汇聚到一起显示。
也就是说，那些散落在不同笔记里的任务，不再需要靠手动翻找了。
这点和高亮列表的逻辑其实是一致的。
高亮负责把重要内容从正文里提取出来，Task Tab 则负责把后续行动从笔记里提取出来。这样一来，一边批注，一边生成后续任务，也就变得很自然。
比如我在阅读时看到一个问题，可以在旁边写下评论；如果这个问题值得继续研究，就顺手写成一个 Markdown 任务。之后再回到 Task Tab，就能看到这些从阅读中自然生长出来的行动项。
更妙的是，这些任务仍然留在 Markdown 里。
不一定需要额外的待办工具，而且任务和上下文天然绑定在一起。它不是孤零零的一条 todo，而是和原文、摘录、评论、高亮待在同一个语境里。
这对我来说很重要。
很多任务管理工具的问题是，任务被抽离得太干净了。你只看到「继续研究某某问题」，但过了几天，可能已经忘了这个任务是从哪篇文章、哪句话、哪个想法里来的。
而如果任务本身就留在 Markdown 笔记里，它的上下文就不会丢。
最后
所以我觉得，SideBar Highlights 的意义更像是把高亮变成了一种可操作的对象。
以前高亮只是留在原文里的颜色痕迹，现在它可以被集中查看，可以跳转，可以筛选，可以分类，也可以放入 Collection。
它开始变成一种真正的索引，就像标签一样；也是一种回到原文的入口，就像标题目录一样。
更重要的是，我一直觉得这是一种把长文，或者大量笔记，重新压缩成个人可理解知识的方法。
Markdown 给了我一个足够简单、足够稳定的文本底座。高亮和批注让我在这个文本底座上留下自己的阅读痕迹。而 SideBar Highlights 做的事情，就是把这些痕迹重新收集起来，让它们不只是躺在原文里，而是重新变成可以被看见、被筛选、被组织、被再次利用的材料。
这也是我喜欢这类小插件的原因。它只是围绕一个很具体的问题，并给出完美的的解决，把那些散落在 Markdown 里的高亮和批注压缩成为个人的「知识线索」。
SideBar Highlights 官方开源地址
https://github.com/trevware/obsidian-sidebar-highlights
直接在Obsidian 插件社区搜索 SideBar Highlights，就能安装。
效率火箭，火箭君的新博客 