把一个Markdown文件上传到Google Drive，再用Google Docs打开，文档标题区域会出现一个“.md”标记。它提醒编辑者，手里这份文件仍是Markdown。谷歌10月26日宣布，Docs和Drive已经支持原生查看、编辑和协作这类文件，用户可以在熟悉的文档界面里改稿，同时保留文件类型。

这项更新瞄准的场景很具体。开发者和智能体习惯输出Markdown，产品、运营和其他参与者则常在在线文档里评论。文件来回转换时，同一份说明容易分成适合代码工具的一版，以及适合人阅读的一版。谷歌此次把协作界面接到原生文件上，试图让两种工作方式围绕同一个对象展开。

保留文件，比增加一个导入按钮更关键

Markdown用文本表示标题、表格和列表，谷歌将其描述为人和AI工具都容易读取的共同语言。官方提到，Drive中的Markdown文件使用量同比大幅增长，但没有在这篇公告中给出具体增速。此次产品动作的重点，是允许用户直接编辑文件，不必先转换为另一种文档格式。

文件保真是这条路径的基础。一个需要继续交给开发工具或Git仓库的说明文件，在Docs里协作后仍保留原来的文件类型。对工程团队来说，这使在线审阅有机会接入既有文档流程；对非工程同事来说，他们可以使用熟悉的评论入口，而不用先理解代码仓库的操作方式。

这里最容易被忽略的变化，是审阅位置的移动。过去团队可能把Markdown渲染结果发给其他人看，再把反馈人工搬回原文件。现在，谷歌提供逐行评论和建议，反馈可以直接落到共同编辑的文档上。产品经理指出的一处描述问题，能够与开发者或智能体正在修改的内容放在同一条协作链里。

这也让文档的用途变得更连续。起草、阅读、评论和修订不必分别依赖一个格式转换动作。文件格式相同，并不会自动消除团队意见分歧，但可以减少“讨论的是哪一版”这类额外确认。对需要多人反复调整的技术说明，版本分叉本身就会消耗注意力。

历史记录开始同时承接人的修改和机器的修改

公告列出的另一项能力，是完整的版本历史。谷歌明确把人类贡献者和AI智能体的修订都纳入这条记录。讨论AI协作时，大家容易先看一次能写多少内容；版本历史关心的是内容经过怎样的变化，以及参与者怎样回看这些变化。

同一份文档允许多人和智能体共同编辑，组织就需要一个共同的核对位置。历史记录为修订提供可追溯的轨迹，逐行评论为意见提供具体落点。两者合在一起，使“让AI先起草、人再审阅”能够从文件传递，转向围绕同一对象协作。这个收益来自工作流衔接，不能直接换算成公告没有披露的效率数字。

阅读端也随之变化。Drive可以直接预览带格式的Markdown，支持表格和超链接，也可以切换到原始文本。审阅者可以先看排版后的内容，遇到格式问题再看文本表达。对于包含结构化信息的说明，这两个视角服务不同任务：一个检查意思是否清楚，一个检查文件里实际保存了什么。

它与只展示渲染页面的预览工具有不同的交付责任。预览解决打开和阅读，Docs协作还要承接修改、建议与历史。谷歌把这些能力放在同一产品入口内，事实上也在争取技术文档的日常工作时间。原来停留在开发工具里的文本，增加了一个可以邀请业务同事参与的窗口。

开放范围相对直接。按公告，拥有Google或Workspace账号的用户，上传.md文件即可开始使用。团队接入这一能力的起点，是已有文件和已有账号。至于企业如何安排访问权限、怎样把协作结果纳入正式交付，仍需沿用各自的组织流程；官方这篇公告没有宣布新的仓库自动同步能力。

因此，最值得区分的是文件延续性与流程自动化。保留.md类型，可以让文件继续服务开发工具，却不等于在线修改已经自动成为某个仓库的提交。把这个边界放回具体动作，团队就更容易判断该在何处审阅、何时确认，以及由谁把最终内容交回工程流程。

标题栏上的小标记改变了谷歌文档入口的含义。它接住的不再只有传统在线文稿，也包括智能体和代码工具习惯处理的文本。工程团队保留原生文件，业务同事获得熟悉的评论界面，谷歌则把协作关系延伸到了原先更偏向开发者的内容对象上。