本地 Markdown 文件可能是目前最便于个人本地保存的文件格式之一。 大量原本需要专有格式的 文档，都变成了 纯文本的形式。用户可以自己本地保存和同步，完全不用看云平台的脸色。 但是云平台并不是没有价值。
实际工作过程中，我们需要和同事，供应商或客户协作有时仍不可避免需要文件交换。 发送邮件传输是很古老的方式了，一般都是传送在线平台协作链接，然后共同编辑。
Markdown 文件 虽然简洁明了可以保持内容信息，但是没有复杂到可以保留协作过程的能力。 一般这些都是云平台才有的。 无论是 Notion，还是 Google Docs，还是其它各类在线文档。
所以既要保持文档的本地自主性，又要能够协作，还能够查看协作过程。 对于 Markdown 来说就力不从心了。 而选择 Google Docs 或 Notion，我们会发现文档数据是在平台上的，只有手工导出才能获得本地文档，而且有些还是格式和结构缩水的版本。
现在，Google Docs 可与原生支持 Markdown 编辑了，不仅是一个在线的 MD 文本编辑器， 或者 Docs 增加了一种格式，而是结合了 本地数据保存 和 云端协作 两者的优点
这次不是简单地支持 Markdown 格式
其实 Google Docs 支持 Markdown 已经有一段时间了。
2022 年，它开始支持使用 Markdown 语法进行部分文本格式化，当时这种做法很流行。
2024 年，Google Docs 又进一步提供 Markdown 导入、导出，以及复制和粘贴转换功能。但是这只是导入支持，不是原生支持。本质上还是在做两种文档格式之间的转换而已。
例如，我们把一个 Markdown 文件导入 Google Docs，编辑完以后再导出 .md 文件。虽然可以完成工作，但整个过程相当于把原始文件交给 Google Docs 改造成另一种格式，再转换回来。
至于其他人修改了什么、留下了哪些评论，都记录在在线文档里。我们必须决定什么时候导出，什么时候覆盖本地文件。如果本地文件也发生了修改，两边还可能产生分歧。
导入和导出解决的是格式转换，并没有真正解决同一份文件如何跨工具协作的问题。
2026 年 10 月 ，Google 正式宣布 Google Drive 和 Google Docs 原生支持 .md 和 .markdown 文件。现在，将 Markdown 文件上传到 Google Drive 后，就可以直接在 Google Docs 中打开和编辑。
文件不会被转换成 Google Docs 的专有文档格式，而是继续保持 .md 类型。打开后，文档标题旁边会显示一个 .md 标识。
Google Drive 还可以直接渲染 Markdown 内容，包括标题、链接、列表和表格，同时允许切换查看原始文本。 在首次打开 MD 文件类型，我看见 Google 给了一个贴心的提示， Markdown 和 Docs 格式会有些许差异，这很公平，Markdown 是一个简化的文档工具，没有奢望它面面俱到。
但值得关注的则是，这些 Markdown 文件现在可以使用 Google Docs 熟悉的协作能力：
- 多人实时编辑同一份文件
- 针对文档内容发表评论和讨论
- 提出修改建议，并由其他人审阅
- 查看版本历史，追踪修改过程
而参与协作的人，不需要理解 Markdown 语法，也不必安装专门的 Markdown 编辑器。就和以往一样，一个 Docs 共享链接，搞定一切。
文件归文件，协作归协作
我一直比较喜欢把文档内容与文档工具分开看待。
一份文档的生命周期可能很长，但我们使用的编辑工具未必会一直不变。今天可能用 Obsidian，明天使用 Typora，几年后甚至可能换成一款现在还不存在的编辑器。只要文件仍然是标准 Markdown，就可以继续使用。
但协作是另外一回事。一份共同编写的说明文档，可能需要知道是谁修改了哪一段内容。
这些能力并不是 Markdown 文本格式本身应该负责的事情。
我觉得 Google Docs 这次提供了一种「协作层」和「数据层」分开的方式：
Markdown 负责保存内容，Google Docs 负责处理协作。
因此，这是一种内容格式与协作服务的分离，而不是所有数据都已经完全脱离 Google 平台。
即便如此，我认为已经迈出了一大步。
如果只是把 Markdown 文件上传到 Google Drive，也就是说，我们可以把需要协作的 Markdown 文件放进 Google Drive 的同步目录里，像个本地文件一样。
在自己电脑上，继续使用 Obsidian、VS Code、Typora，或者任何喜欢的 Markdown 编辑器。
需要客户或者同事参与时，就分享这个文件的 Google Docs 协作链接，让他们直接在线编辑。
完成修改后，Google Drive 再将更新同步到本地。
这样，日常写作和文件管理依然可以使用自己熟悉的本地工具，而 Google Docs 只在需要协作时出现。 整个过程中，不再需要不断进行 Markdown 与平台专有文档之间的格式转换。
不过，如果希望这种工作方式稳定运行，我会建议只把需要协作的部分文档放入同步目录，而不是一开始就把整套本地知识库搬进去。
AI 的加入，让这种分工更有意义
这件事和 AI 有什么关系？ 考虑 Markdown 已经逐渐成为 AI 工具处理文档时最常见的格式之一。无论是 ChatGPT、Claude Code，还是各种能够读写本地文件的 AI 工具，都很容易处理 Markdown。它不需要复杂的文档解析，也不需要依赖某家软件的专有接口。
我们的工作 协作已经不局限于 人与人之间的协作了， 还有人与AI的协作。
我们已经可以让 AI 帮忙撰写内容、整理资料、修改文档，甚至定期生成报告。
比如，让 AI 生成一份周报草稿，保存为 Markdown。我们再通过 Google Docs 分享给团队成员，进行审阅和评论。
确认之后，AI 仍然可以继续读取这份 Markdown，用于下一轮分析或者生成其他材料。
这意味着人类和 AI 不一定需要使用同一套编辑工具，却可以使用相同的内容格式。至少在文档内容这一层，格式转换的障碍减少了。虽然没有自动获得评论接口，但是多少在「数据层」将AI 加入了进来。
最后
目前还不能说 Google Docs 已经变成本地优先工具，显然不是。
首先，Google Docs 最大价值依然是一个云端协作服务。
Markdown 文件可以保留在本地，但在线评论、协作权限和修改历史，仍然依赖 Google 的服务体系。Google Docs 并没有因此变成一个可以完全自部署的协作编辑器。
其次，Markdown 本身能够保存的格式有限。如前面我说的，Goggle 会提示你 MD 格式 会有排版等功能损。如果需要复杂排版、精细的页面布局或者大量 Google Docs 专有组件，Markdown 就未必适合。
不管怎么说，Google Drive 虽然可以让云端文件回到电脑，但我依然会把本地备份作为独立的一环，而不是完全交给同步工具。
现在，文档可以继续保持开放格式，协作服务不一定需要占有文档格式。 两者不会锁死在一起，用户有了更多选择，生产力工具链也可以从本地延长到云端，这应该是一个对用户友好的方向，希望未来有更多这样的惊喜。
发表回复