.md 不用再转格式了：Google Docs 原生编辑 Markdown，文档与代码仓库终于共用一份真源

很多团队都经历过同一种荒诞：同一份文档，在仓库里是 README.md，在评审时是 Google Doc，到了发布时又变成 PDF。三个版本长得差不多，没有一个敢说自己是真的。改动先落在哪个版本里，全看谁最后记得同步。2026 年 10 月 26 日，Google 在开发者博客上宣布，Google Docs 现在可以直接打开、编辑和协作处理 Drive 里的 Markdown 文件，不再需要先把它转成 Google 文档格式。这不是一个格式转换器升级，而是一次所有权转移：.md 文件从此可以在 Docs 里被当作原生文件对待，改完还是 .md。

这件事值得认真对待，恰恰因为它看起来不大。Markdown 早就不是程序员的私人记号了。它是 README、设计文档、变更记录、提示词说明、AI 生成内容最常见的载体，也是人和大模型之间最省力的共同语言：人能直接读，模型能直接解析，Git 能直接 diff。过去的断裂点在于，写代码的人用 Git 管 .md，写文档、做评审、提意见的人用 Docs，两种工具各有一套真相。Google 这次的动作，是把 Docs 的协作能力——实时共编、行级评论、建议模式、版本历史——直接安放在 .md 文件本身之上，而不是先把它吞进自己的格式里再吐出来。

到底变了什么：四件事，一次说清

第一，文件不再换身份。把 .md 文件上传到 Drive，双击后它会在 Docs 里以 Markdown 模式打开，标题旁有一个醒目的 .md 标记，提醒你正在编辑的是原生 Markdown 文件。编辑、保存之后，它仍然是 .md 文件，不会悄悄变成 Google 文档格式。这一点是整则公告的支点：过去 Docs 也支持 Markdown 的导入、导出、粘贴转换，那些功能解决的是“搬运”，这次解决的是“常驻”。

第二，协作不再需要翻译官。同一份 .md 文件，工程师、产品经理、法务、市场可以在同一个界面里共编、留行级评论、提修改建议。以前的流程是：有人把 .md 贴进 Docs 评审，评审意见落定后再由一个人手工搬回仓库，搬运过程本身就是新的出错源。现在评审意见直接长在源文件上，搬运环节被取消了，意见和定稿之间少了一次转手。

第三，版本历史成了审计线索。Docs 的版本历史会记录人和 AI agent 各自的修改。这对 vibe coding 团队尤其重要：当 agent 半夜改了一份设计文档，或者重写了一段 API 说明，你需要的不只是“最终版长什么样”，而是“谁在什么时候改了哪一行、为什么”。一份带时间线的 .md 文件，比一句“agent 改过了”的口头交代可靠得多。当然，前提是团队真的把 agent 的写入也走同一条通道，而不是让它继续在仓库外另起一份副本。

第四，Drive 里的预览终于像文档了。Drive 可以直接渲染格式化的 Markdown 预览，表格、超链接都能正常显示，也可以一键切换回纯文本。这听起来是小事，但对非技术同事来说是决定性的：他们第一次不需要先学会“井号是什么意思”，就能判断一份文档写得对不对。预览降低了参与门槛，参与的人多了，文档才不再是工程师的独白。

为什么偏偏是现在：Markdown 正在变成协作层

Google 在公告里给出的理由很直白：Drive 里 Markdown 文件的使用量同比大幅增长，而 AI agent 越来越多地承担起草、规划和写代码的工作，Markdown 是人和 AI 工具都能轻松读写的格式。这个判断基本属实，但还可以再往前推一步：Markdown 正在从“程序员的写作格式”变成“团队的协作格式”。

过去一年里，类似的信号一直在累积。AI 生成的内容天然以 Markdown 形式出现：模型输出的报告、计划、代码说明，默认就是标题、列表、表格。团队如果还要把这些内容先转成别的格式才能评审，等于在每一次 AI 产出后面都加了一道人工关卡。Docs 原生支持 .md，等于承认了一个现实：AI 的产出格式已经是团队的工作格式，工具应该去适应格式，而不是反过来要求所有产出先归化。

对 vibe coding 的独立开发者和小团队来说，这个变化的实际意义比大公司更直接。你的项目文档、用户手册、更新说明、API 文档，很可能本来就以 .md 形式躺在仓库里。以前你要么接受“只有会 Git 的人能改文档”，要么接受“文档有两个版本”。现在第三条路出现了：把 .md 文件放进 Drive，让不会 Git 的协作者在 Docs 里改，改完文件原地还是 .md，可以直接提交回仓库。这条路不完美，下面会说它的边界，但它第一次让“文档评审”和“代码评审”共用同一份源文件成为日常操作，而不是项目初期的美好愿望。

怎么用才划算：三条具体的工作流

第一条，README 和设计文档的联合评审。把仓库里的核心文档——README、架构说明、接口约定——同步到 Drive 的一个专用文件夹，评审期间只改 Drive 里的版本，评审结束由负责人把定稿合并回仓库。规则要写死：评审期仓库里的对应文件冻结，只接受 Drive 版本的合并；否则两边同时改，冲突会比以前更难收拾。这个流程的收益是，产品和运营第一次能直接在设计文档上留行级意见，而不是在聊天软件里发一句“第三段好像不对”。

第二条，AI 产出的人工定稿通道。让 agent 把初稿写成 .md，存进 Drive，人在 Docs 里做三件事：删掉 agent 编造的细节、补上只有人才知道的背景、把模糊的表述改成可执行的承诺。定稿后再由人或脚本同步回仓库。这个流程的关键是分工：agent 负责“写出结构”，人负责“对事实负责”。如果反过来，让 agent 直接改仓库里的定稿，又没有人审，那 Docs 的版本历史再完整也救不了你——因为错误已经以“正式文件”的身份进了仓库。

第三条，面向非技术读者的发布前校对。用户手册、帮助文档、更新说明，先在 Docs 里过一遍语言和结构，再发布。Drive 的渲染预览在这里很有用：写文档的人可以直接看到用户最终看到的表格和链接长什么样，而不是凭想象猜测渲染结果。校对完再发布，发布物和评审物是同一份文件，发布后发现错别字要改，改的也是同一份文件。

边界在哪里：四件 Docs 做不到、也别指望它做的事

第一，格式保真是有代价的。Google 之外的报道已经指出，Docs 里特有的格式——字体颜色、高亮、对齐方式、智能芯片——在 Markdown 模式下会被降级：智能芯片会变成纯文本或链接，HTML 格式会变成纯文本。这不是 bug，而是两种格式的基因差异：Markdown 本来就没有这些概念。一个团队如果在 Docs 里把文档排得花里胡哨，再指望它原样回到仓库，一定会失望。务实的做法是：把 .md 文件当作“内容文件”而不是“排版文件”，样式交给发布端去管。

第二，它不是 Git。Docs 的版本历史能告诉你谁改了什么，但它不能替代分支、合并、代码评审和冲突解决。多人同时改同一段、agent 和人在同一分钟改同一行，这类冲突在 Docs 里会被实时协作掩盖一部分，但在合并回仓库时仍可能冒出来。团队需要一条明确规则：Docs 是评审场，仓库是定稿场；评审场的热闹不能直接等于定稿，合并那一步必须有人负责。

第三，适用范围是个人账号和 Workspace 账号，公告说“任何拥有 Google 或 Workspace 账号的人都可以立即开始”。这句话要读出两层意思：一是门槛确实低，二是企业级管控、合规审计、数据驻留这类问题，公告没有展开。涉及敏感设计文档、未公开产品信息的团队，在把文件放进 Drive 之前，应该先过一遍自己公司的合规清单，而不是默认“Google 能打开就等于公司允许”。

第四，渐进式推出的老问题。第三方报道提到，这项支持覆盖个人账号和 Workspace 账号，但推出是逐步进行的，可能需要一段时间才能在所有账号上出现。如果你今天打开 Drive 还没看到 Markdown 模式，先别急着下结论说“功能是假的”，也别急着让全团队切换流程；等账号实际出现该功能、亲自开一份文件改一行、确认它回到仓库后格式无损，再把流程写进团队规范。

给 vibe coder 的判断：用，还是不用

判断标准其实只有一条：你的文档有没有“非 Git 用户必须参与评审”这个需求。如果你的文档读者全是会用 Git 的工程师，这次更新对你几乎没有增量——你本来就在仓库里直接改 .md，Docs 只是多了一个入口。但如果你的文档需要产品、运营、客服、外部顾问参与评审，或者你的 AI 产出需要经过非技术同事的事实核查，那么这次更新值得立即试用：它把原来“评审一次、搬运一次、核对一次”的三步，压缩成“评审即定稿”的一步。

更长远的判断是，文档工具正在分化成两条路线：一条是“以代码仓库为中心”，文档是代码的附属品；另一条是“以协作为中心”，文档是团队共同工作的场所。Google 这次的选择，是让第二条路线去兼容第一条路线的格式，而不是要求第一条路线放弃自己的格式。对 vibe coding 团队来说，这是一个好信号：你不需要在“写得快”和“审得严”之间二选一，但你需要在流程上补一课——谁有权定稿、什么时候冻结、合并由谁负责。工具把格式墙拆了，流程墙还得你自己拆。

最后说一句可能被忽略的话：这次更新最大的受益者，也许不是 Docs 的重度用户，而是那些一直被排除在文档评审之外的人。以前他们只能在会议上口头提意见，意见落不落到文档里全看记录的人靠不靠谱。现在他们可以直接在文件上留下一行评论，这行评论有名字、有时间、有上下文。文档质量的提升，往往不是从更好的写作工具开始的，而是从“提意见的人终于能直接改到文件上”开始的。

切换之前，先亲手测这五件事

不要一上来就让全团队迁移文档流程。先拿一份真实的、但不关键的文档做一次全程演练：把它放进 Drive，在 Docs 里改，改完放回仓库，然后逐项核对。第一，表格有没有变形：Markdown 表格的列数、对齐方式、单元格里的链接，回到仓库后是不是原样。第二，代码块有没有被“美化”：缩进、特殊字符、行内代码标记，是不是被 Docs 的自动格式化动过。第三，图片和链接的相对路径有没有断：Docs 里能正常显示的图片，回到仓库后路径是否仍然有效——这是最容易在搬运中丢掉的一环。第四，中文标点和特殊符号有没有被替换：全角引号、破折号、省略号，这些细节在跨工具流转时最容易悄悄变样。第五，版本历史是否可追溯：改动的人、时间、内容，能不能在 Docs 里完整回放，回到仓库后提交记录里能不能对应上。这五项全过，再谈流程切换；有一项不过，就先把那一项的规避办法写进规范。

演练时还要故意制造一次冲突：让两个人同时改同一段，看 Docs 如何处理，再看合并回仓库时冲突长什么样。很多团队的流程是在“一切顺利”时写出来的，第一次冲突才暴露规则漏洞。与其等上线前夜才发现，不如在演练里先把冲突吵出来。冲突处理规则至少要定三条：谁有最终裁决权、冲突段落是否冻结其他修改、裁决结果是否需要在文档里留一行说明。没有这三条，实时协作的便利会变成责任不清的温床。

它和 Obsidian、Notion、纯仓库流比，位置在哪里

把 Docs 的原生 Markdown 支持放进工具版图里看，位置会更清楚。Obsidian 的强项是本地优先、双向链接、个人知识库，它解决的是“一个人如何把知识管起来”；Notion 的强项是数据库视图、页面组合、团队知识库，它解决的是“一个团队如何把信息组织起来”；纯仓库流的强项是版本控制、评审流程、与代码同生命周期，它解决的是“文档如何跟代码一起演进”。Docs 原生 .md 的强项不在这三者任何一处，而在“让不会用前三种工具的人，也能直接改同一份源文件”。

这一定位决定了它的适用边界：它是评审入口，不是知识库，也不是发布系统。长期沉淀的知识，仍然适合放在 Obsidian 或 Notion 里；需要严格版本控制的接口文档，仍然适合以仓库为唯一真源；Docs 的 .md 模式最适合的，是那些“需要跨职能评审、但最终要落回仓库”的文档：产品需求说明、发布说明、用户手册初稿、合作方评审稿。把每种工具放在它最擅长的位置上，比争论哪个工具“全能”更有价值。工具越是宣称全能，团队越容易把所有文档都塞进一个地方，最后哪个环节都做不好。

还有一个容易被忽略的视角：这次更新降低的是“参与评审”的门槛，而不是“写出好文档”的门槛。文档写得好不好，仍然取决于写的人是否清楚读者是谁、是否敢删掉不必要的段落、是否愿意为每一个数字负责。Docs 能让更多人参与修改，但它不能替团队决定“这份文档到底要讲什么”。如果一份文档本身逻辑混乱，十个人同时在线改，只会得到一份修改痕迹更丰富的混乱文档。工具升级之后，真正需要升级的，是团队对文档质量的共识：谁是读者、什么是定稿、什么情况下可以拒绝一次修改。更实际的建议是，给每一份核心文档指定一名“文档负责人”，他的职责不是写所有内容，而是守住定稿标准：结构是否完整、术语是否一致、示例是否可运行、过期内容是否及时清理。没有负责人，再好的协作工具也只会加速混乱的扩散。

图注：同一份 .md 文件从仓库到 Drive、再到 Docs 评审、最后合并回仓库，全程不换格式；规则是 Docs 为评审场、仓库为定稿场。

来源：Google Developers Blog 2026 年 10 月 26 日公告《Preview, edit, and collaborate on markdown (.md) files natively in Google Docs and Drive》。文中关于格式降级、逐步推出的说明，来自公告发布后的第三方报道，已在正文中标注为报道口径，未冒充为 Google 原文。