我很喜欢 Markdown 的纯粹：作为本地文件，无论换到 Obsidian 还是 Typora 等哪个编辑器都能直接写。但是，一旦把文档丢进团队协作的场景里，事情就没那么简单了。以前那些主打在线协作文档的专门 SaaS（比如飞书文档、语雀等）一度很流行，但这又和我们所追求的「本地优先（Local-first）」产生了矛盾。
假设在一份 MD 格式的项目文档里写着「计划下周上线」。有人批注：「测试做完了吗？」有人回复：「还得等测试小组确认。」这个过程在很多支持审阅功能的 App 或在线文档中都是很平常的事情，但是到了纯文本的 Markdown 里，想要实现并保留下来就不那么简单了。
这时候，如果把这份 .md 文件导出、迁移，却只带走了正文里那句「计划下周上线」，就会产生问题。
对于这种多人协作场景，很多有价值的信息其实都留在侧边栏的评论区里。那里记录了谁提出过质疑、哪些条件还不成熟，以及一个决定是怎么经过反复拉扯才得出来的。（有些组织非常重视这个拉扯的过程。）
最近开源私有云 Nextcloud 的一次更新（随 Hub 26 Summer 推出），让我看到了一种非常朴素、也很极客的解法：它直接把评论作为纯文本，写进了 Markdown 文件里。这样一来，当我们「拥有一份文档」时，也就同时拥有了围绕它所发生过的全部讨论。
我今天并不是要专门介绍 Nextcloud，而是想聊聊它们对 Markdown 协作批注的一些改造思路。
Markdown 的痛点：正文容易搬家，但协作批注很难
Markdown 的正文很容易迁移，因为标题、列表、加粗都有一套通用语法。但一条评论批注包含的信息要复杂得多：它指向哪个位置？谁写的？谁回复了谁？讨论结束了吗？
这些状态并不会因为文件后缀是 .md，就自动被所有软件识别。所以，要想同时支持 Markdown、支持多人协作、支持评论无损迁移，中间其实横着多道门槛。
Nextcloud 社区里有过这样的反馈：某团队的 IT 部门用 Markdown 管理技术文档觉得很顺手，但推广给同事时却卡住了。因为大家已经习惯了 Word 的审阅批注功能，「一起改文档」意味着别人会直接改动你的文字，而「评论」则是先提出问题，把修改权留给原作者。在方案评审和日常写作中，后者往往是更迫切的刚需。
如果一套标榜「开放」的 Markdown 工作流，一到审阅环节就得退回 MS Office 这种封闭软件，或者在文档迁移时丢掉所有批注，那这种「开放性」也就意义不大了。
用「脚注」装下评论：Nextcloud Text 的解法
为了解决这个问题，Nextcloud Text（也用于其笔记和知识库组件）没有发明新格式，而是巧妙地借用了现有的 MD 脚注（Footnote）语法。
在界面上，我们看到的依然是现代化的侧边栏评论气泡，但如果用纯文本编辑器打开底层的 .md 文件，则会看到这样的结构：
计划下周上线。^comment-1^comment-1: - @Hyashimention://user/hayashi (2026-10-07T02:00:00Z) 客户还没有确认，先不要把日期写死。 - @Janemention://user/jane (2026-10-07T02:15:00Z) 同意，改成确认后再排期。
正文中用 [^comment-1] 锚定位置，文末则用列表记录盖楼回复、作者和时间戳。
我很喜欢这种以文件为中心（File-over-App，即文件优先于应用）的思路：
- 在 Nextcloud 里，它可以被渲染成漂亮的侧边栏评论；
- 换到 Obsidian、Logseq 等普通的 Markdown 编辑器里，它可以退化成可读的脚注；
- 哪怕只用系统的记事本打开，这段讨论依然完好无损，以纯文本的形式保留了下来。
哪怕将来彻底换掉工具链，我依然会拥有一份有头有尾的原始记录。这条退路是不是很珍贵？
对比 Notion 与 Google Docs：在线文档的评论迁移困境
如果稍微观察一下就会发现，基于 Markdown 的方案是一个不会锁死生态的方案。
- Notion 等在线文档： 虽然评论和共享协作非常方便，但作为一个封闭的在线系统，它需要账号订阅，会死死锁定生态。一旦把文档导出为 Markdown，侧边栏的讨论就会全部丢失。
- Google Docs： 情况类似，不过它属于体量更大、更成熟的生态。而且 Google 现在也开始原生支持导入和导出 MD 格式了，对迁移相对友好。
- MS Word（.docx）： 需要配置 Office 环境。不过考虑到现在有大量非微软的兼容软件（如 WPS、LibreOffice）都能直接读取
.docx里的审阅批注，在兼容性上相比之下已经算是很好的了。 - Markdown（Nextcloud 提出的方案）： 几乎不依赖任何特定的环境和生态。它既可以放在自己本地并用 Git 做版本控制，也可以放在云盘，或者私有化部署在 Nextcloud 之类的开源平台上，连正文带评论完全由自己掌握。考虑到 Nextcloud 产品，这也符合其基于文件共享平台的立场。
可见 Markdown 几乎不依赖任何特定的环境和生态，既可以放在自己本地并用 Git 做版本控制，也可以放在云盘，或者私有化部署在 Nextcloud 之类的开源平台上，数据完全由自己掌握。
纯文本批注的局限性：Nextcloud 方案的三个缺陷
Nextcloud 的方案虽然足够聪明，但也不是万能的。
- 它是点状标记，而非划词批注： 它只能锚定在某个光标所在的位置，没法像 Word 或 Notion 那样精准高亮框选一整段话。
- 账户体系无法跨平台： 文本里的
mention://user/hayashi到了别的软件里，就只是一串普通字符，失去了@联动通知的能力，存在一定的规格依赖。 - 不具备审计效力： 既然评论本身就是纯文本，意味着任何人都能用编辑器手动修改里面的作者名字和时间戳。它适合用来留存讨论的上下文，但不能作为严肃的审批证据。这是纯文本天生的硬伤。
不过，像 Nextcloud 这样的轻量级方案，已经解决了很多痛点，在一个公开透明的组织或小团队里，这已经完全够用了。而如果为了解决更大层面上人与人之间的信任关系，软件最终往往还是会演变成一个复杂的封闭系统。
总结：文档协作的「上下文」价值与 AI 时代的思考
沿着这个方向想下去，评论其实只是文档「上下文（Context）」的一部分。
一段结论为什么可信，取决于它的引用来源；一个决定为什么被搁置，往往藏在某条回复里。如果在迁移时只留下一版光溜溜的正文，后来接手的人，甚至包括通过 RAG（检索增强生成）读取本地知识库来帮你总结资料的 AI，就只能看到看似确定的结论，却看不见背后的争议与保留意见。
换言之，一份经过多人打磨的文档，其中评论和协作过程的上下文价值，可能早就溢出了正文。这也是 Markdown 这类朴素的纯文本格式，在未来发展中需要考虑的问题。
