Google Docs 原生支持 Markdown：赢的是「给智能体看的那一层」

结论先说：Google Docs 和 Drive 原生支持 Markdown，表面上是"多支持一种文件格式"，实际是把人和智能体的共享接口层标准化了。值得高兴，但别把它当成知识管理的终点。

据报道，谷歌为 Google Docs 和 Google Drive 加入 Markdown 原生支持：可以直接打开、编辑和使用 .md 文件，渲染后的内容包含可点击链接和结构化表格，并支持实时编辑与评论。功能自 10 月 5 日开始推送，部分用户可能需要等待最多 15 天。

一、为什么这不是一个"格式兼容"的小更新

Markdown 的地位在过去两年发生了质变：它从"程序员的写作格式"变成了智能体交换上下文和指令的默认格式——提示词文件、技能定义、规则清单，绝大多数是 .md。

一旦 Docs 原生支持 .md，一件事就变得可能：同一份文件，人看渲染结果，模型读纯文本，两边不需要转换。

这解决了一个很具体的痛点。以前的流程通常是：在文档里写规范 → 导出或复制成纯文本 → 粘贴进提示词 → 改一处，前三步全部重来。转换环节越少，文档和提示词就越不容易出现版本漂移。

二、三个值得注意的细节

• 保留 .md 格式：文件可以继续以纯文本形态存在于 Drive，不必被转成 Google Doc 的私有结构，可迁移性保留着；
• 支持评论与协作：评论是评审机制。可以让人用评论提修改意见，而正文保持机器可读的干净结构；
• 官方给的用例是"与 AI 智能体协作编辑"：谷歌自己把这件事定位成智能体工作流的一部分，而不只是写作工具。

三、对读者的实际影响（可执行三步）

1. 把规范沉淀成 .md 并进版本控制：团队约定、代码规范、提示词模板，都写成纯文本文件，让"人读的"和"模型读的"是同一份；
2. 用评论做评审，别在正文里改注释：正文只放最终指令，讨论放评论区，避免把说明性文字一起喂给模型；
3. 保留纯文本副本：云端协作方便，但纯文本才是长期可迁移的资产——十年后你还能打开 .md，未必还能打开某个平台的私有格式。

四、需要说清的局限

Markdown 的结构表达力有上限：复杂表格、嵌套结构、精确排版都会退化成"看起来像"。它适合承载规则、清单、说明和流程，不适合当最终交付的排版格式。

另外，评论、权限、审计仍然活在谷歌的生态里。如果你的场景要求气隙部署或数据不出境，这份便利你用不上——回到本地目录加版本控制反而是更稳的选择。

参考来源

• IT之家：《Google Docs 和 Google Drive 引入 Markdown 原生支持，可保留 .md 格式协作编辑》 https://www.ithome.com/1/010/020.htm
• X：Testing Catalog（@testingcatalog）：原生支持 Markdown 与智能体协作 https://x.com/testingcatalog/status/2107379242023739810

延伸阅读：把收件箱清零交给智能体：先给「打标签」，别先给「删除」 · WebMCP 已铺到近 3000 个站点：给智能体开的口子，安全团队还没看见