Markdown 应成为各类操作系统的原生文档格式

在我看来，2026 年我们竟然仍无法在几乎任何电脑或手机上打开 Markdown 文档，并期待它在不安装额外软件的情况下正常显示实在很奇怪。Markdown 已经存在了 20 多年，并已成为文档编写、写作、发布和分享信息的重要格式。它简单、便于携带、易于阅读，并得到了大量应用程序和网站的支持。然而，像接收一个 .md 文件这样再普通不过的事情，仍可能让人们只能盯着原始的格式语法，或者四处寻找能够将其作为文档显示的应用。我们现有的操作系统可以打开照片、播放视频、读取 PDF，并识别无数复杂的文件格式，却无需我们费心思考这些功能是如何实现的。我认为，Markdown 也理应得到同样的对待。

多年来，我一直在使用 Markdown，它已成为我最喜欢的组织和撰写信息的方式之一。我个人网站上的许多内容最初都是用 Markdown 撰写的，因为它让我可以专注于写作，而不是排版。我可以将这些文件保存在 Git 中，用几乎任何文本编辑器进行编辑，将它们转换成网页，同时保留原始文档，而不依赖任何专有应用。知道自己今天写下的文字几十年后仍可访问是一件极其令人安心的事，即使我现在使用的所有应用都消失也无妨。Markdown 文档不需要账户、订阅、特定公司或复杂的文件格式，就能继续发挥用途。正是这种简洁性让我认为，它应该在整个计算机世界都被视为一等文档。

我们把简单的事情弄得不必要地复杂

Markdown 最初的基本理念之一，是即使在计算机解析文档格式之前，文档也应保持可读。John Gruber 在 Aaron Swartz 的协助下于 2004 年引入了这种格式，利用普通的文本约定来表示标题、链接、强调和其他常见的文档结构。它的结果是一种撰写结构化材料的方式，无需在每句话周围添加 HTML 标签，也无需在专用的文档编辑器中工作。任何人只要在软件仓库中打开过 README 文件，就很可能接触过 Markdown，即使不知道这种格式叫什么。它的用途后来远远超出了编程领域，扩展到书籍、技术文档、学术笔记、发布系统和个人知识库。这种格式取得成功，很大程度上是因为它对创建文档的软件几乎没有任何额外要求。

这正是如今的处境令人沮丧的原因。Markdown 本身就是纯文本，因此从技术上说，几乎所有操作系统都能用某种文本编辑器打开它。缺失的一环，是将该文件作为文档处理，而不是仅仅显示用于描述其格式的字符。标题应该看起来像标题，表格应该看起来像表格，链接也应该像链接一样可用。如果我想查看原始的 Markdown 语法，就应当能够同样轻松地切换到该视图。上述任何操作都不应该要求我寻找冷门工具、安装预览扩展，或者把文档移入另一个能够将其转换为其他格式的应用中。

我可以给别人发送一个 PDF，并合理地预期他们的电脑或手机知道该怎么处理它。他们通常可以打开文件、阅读内容、搜索文字并浏览文档，而不必担心设备是由哪家公司生产的。Markdown 至少也应该同样易于阅读，尤其考虑到它的底层格式要简单得多。与 PDF 不同，Markdown 还被设计为可以直接编辑，这使得全面一致的支持更加重要。用户应该能够在手机上阅读文档，在笔记本电脑上做出修改，然后在平板电脑上继续工作，而无需更改底层文件。这才是我们应当期待现代操作系统提供的体验。

每一种操作系统都应该支持 Markdown

我最初开始思考这个问题，是因为 Apple 各操作系统之间的体验不一致。Apple 已经为“备忘录”添加了 Markdown 导入和导出功能，我对此很高兴，但导入文档会将其转换为“备忘录”使用的富文本格式。这对于在不同应用之间移动信息很有用，但并不等同于打开原始 Markdown 文件、进行编辑并原地保存。Finder、Quick Look 和“文件”已经知道如何呈现多种类型的文档，但 Markdown 在 macOS、iOS、iPadOS 和 visionOS 上仍缺乏完整的原生查看和编辑体验。我希望能看到这种改变，因为 Markdown 文档不应该因我手里碰巧拿着哪台 Apple 设备而需要采用不同的工作流程。

然而，这并非仅仅是苹果公司的问题，我认为解决方案不应局限于苹果的生态系统。Windows、Linux、Android 以及其他所有现代计算环境都应将 Markdown 识别为一种普通的文档格式。微软通过在 Windows 11 记事本中直接引入 Markdown 格式（包括在格式化文本和 Markdown 源码之间切换的能力）取得了令人鼓舞的进展。Linux 拥有大量优秀的文本编辑器和 Markdown 工具，尽管不同发行版、桌面环境和已安装应用之间的体验各异。Android 也有许多功能强大的第三方 Markdown 编辑器，但这并不能保证通过默认的文件处理系统获得一致的格式化阅读和编辑体验。解决方案的各个部分分散在整个行业，但业界尚未形成一种共同预期，认为这种体验应当在所有地方都能正常使用。

我并不期望每个操作系统都以完全相同的字体、间距或视觉样式来渲染 Markdown。事实上，我更希望呈现方式能够尊重用户自身的系统设置和辅助功能偏好。应当保持一致的是文档的结构以及使用同一底层文件进行操作的能力。在 Linux 上创建的 Markdown 文档应该能在 Windows 上自然打开，在 Android 上保持可编辑，并在 iPhone 上正确显示。使用该文件的人不应需要了解最初是哪个应用程序创建的，也不必知道操作系统使用的是哪个 Markdown 渲染引擎。正是这种互操作性使一种格式在不同平台间真正变得有用。

我们已经拥有了相关标准。

有趣的是，就 Markdown 应如何表现达成一致所需的大量艰苦工作，实际上已经完成了。最初的 Markdown 语法留有一些行为的解释空间，最终导致不同应用程序和渲染引擎之间出现差异。CommonMark 项目通过为实现者提供定义明确的规范和大量示例，解决了这些歧义。GitHub Flavored Markdown在此基础上加入了广泛使用的功能，例如表格、任务列表、删除线和自动链接。这些约定已经支撑了互联网上流通的大量文档和书面材料。操作系统开发人员无需再发明一种文档格式来实现这一点。

总会有一些扩展是特定应用程序支持而其他应用程序不支持的。有些作者会使用脚注、数学符号、图表、嵌入式 HTML 或超越 CommonMark 和 GitHub Flavored Markdown 的专用发布语法。我并不指望每个内置文档查看器都能完全复现所有可能的扩展。我真正期待的是一个可靠的基线：它能够正确渲染普通 Markdown，同时保留应用程序无法理解的内容。打开和保存文件时，绝不应仅仅因为内置编辑器不知道如何显示某种陌生语法，就悄无声息地将其丢弃。使用可移植文本格式的全部意义就在于，应用程序不应需要控制每一种可能的功能才能保存文档。

每当操作系统渲染来自不熟悉来源的文档时，也需要考虑合理的安全问题。Markdown 预览不应执行任意脚本，不应在缺乏适当防护的情况下加载不可信内容，也不应仅因为文件引用了外部资源就暴露信息。这些都是操作系统在呈现 PDF、HTML 和其他文档格式时已经处理过的熟悉问题。渲染器可以在将底层文件视为不可信内容的同时，提供有用的格式显示。对于普通文档，它也可以完全离线工作，而不需要云服务来解释几个标题和段落。Markdown 的简单性应当使构建安全的原生体验变得容易，而不是成为把文档处理转移到别人服务器上的又一个借口。

人工智能正在让 Markdown 变得更加重要

过去几年出现了一项出人意料的发展：Markdown 在不断壮大人工智能生态系统中的存在感日益突出。语言模型经常使用 Markdown 约定来组织回答，因为它提供了一种便捷方式，可通过纯文本传达标题、列表、表格、代码及其他结构化信息。开发者使用 Markdown 编写智能体指令、项目文档、技术规范，以及 numerous files 中帮助 AI 工具理解其所处理软件的相关内容。从未编写过代码的人，也会通过导出的对话、AI 服务生成的报告和文档接触到 Markdown。这种格式实际上已成为人与软件交换结构化书面信息的一种通用语言。我预计，随着人工智能融入更多日常工作流程，Markdown 的普及度还会继续上升。

这让原生支持显得更加刻不容缓。我们正在构建日益精巧的工具，它们能够解读海量文档、总结复杂研究、编写软件并生成完整报告；然而，普通电脑可能仍需借助另一个应用程序，才能将生成的 Markdown 文件显示为排版精美的文档。我觉得这种反差有些荒谬。我们不该需要人工智能，才知道如何显示一个以井号标示的标题。操作系统早就应该懂得如何做到这一点。让 Markdown 成为文档体验的常规组成部分，将有助于普通用户使用这种格式，而不必理解其底层技术规范。

这也会促使更多应用和服务交换真正的文档，而不是迫使人们使用专有格式。如果我要求 AI 系统生成一份报告，我希望收到的是一个 Markdown 文档，我可以随心所欲地打开、编辑、归档和发布它。我不希望这份文档是否有用，取决于我是否回到创建它的那项服务。对于从写作应用导出的笔记、从网站下载的文档，或同事之间分享的信息，也同样如此。Markdown 提供了一种直接明了的结构化内容交换方式，无需每个参与者都使用相同的软件。操作系统只需要让每个人都能轻松获得这种体验。

文件应该属于创建它的人。

这是我最近在打造个人网站、探索独立互联网时一直在思考的问题。我希望人们能更好地拥有自己创作的东西，包括文章、照片、文档和个人档案。我们的数字生活有太多地方依赖各种应用和服务，而这些服务将信息存储在我们很难于其生态系统之外访问的格式中。提供服务的公司可能会改变商业模式、提高价格、停止某项功能，甚至彻底关闭。有时它会提供导出功能，但导出的材料可能很难使用，除非再找到一个能够解读它的应用程序。我们不该担心，当持有我们文字的公司决定抽身离去后，自己是否还能继续阅读这些文字。

Markdown 之所以诱人，正是因为它避免了太多此类依赖。一份文档可以存放在硬盘、U 盘、家庭服务器、云盘或 Git 仓库中，而不需要任何特殊服务来维持其存在。它可以借助早已存在的工具进行复制、搜索、版本管理、备份，并转换为其他格式。如果我明天不再使用某个写作应用，就可以在另一个应用中打开同一个文件，而无须进行一次繁琐的迁移。对于我打算长期保存的材料而言，这种自由尤其重要。相比围绕一家未来无法掌控的公司所拥有的数据库来建立个人档案，我更愿意围绕始终能够被理解的文件来建立档案。

原生支持 Markdown 将通过消除选择可移植文件时剩余的不便之一，进一步增强这种自由。用户可以使用自己喜欢的任何应用，而不必担心接收者是否安装了相同的软件。操作系统内置的查看器可提供可靠的回退方案，而专业编辑器仍可继续为有需要的用户提供额外功能。这对开发者有益，对作家、学生、教师以及任何希望让文档独立于特定应用的人也有益。当打开一种文件格式不需要任何专业知识时，它就会变得更容易上手。我认为，这是让数字所有权切实可行、而不只是停留在可能层面的关键。

我不要另一个专有文档生态系统

我最不希望看到的是 Apple、Microsoft、Google 或其他任何公司推出一个略有不兼容的 Markdown 版本，并且只在他们自己的产品中效果最佳。几十年来，我们一直在应对各种文档格式：它们会根据创建文档的应用、已安装的软件版本以及尝试打开文档的操作系统而呈现不同行为。Markdown 应成为朝相反方向发展的机会。通用约定、开放规范和纯文本存储已经提供了一个可供整个行业共享的基础。每种操作系统都可以围绕这些约定构建原生体验，而不主张拥有该文档格式。无论当前由哪个应用显示，原始文件都应始终作为权威来源。

我同样不认为原生支持会消除对专用 Markdown 应用的需求。有一些优秀编辑器提供发布工具、语法扩展、文档管理、协作、主题和工作流；这些都是无法合理要求操作系统的基本文档查看器提供的。人们当然应该继续构建和使用这些应用。原生支持只会确立一个最低体验标准，让每个人无需额外软件就能获得这一体验。图像查看器不会取代 Photoshop，内置 PDF 阅读器也不会消除对专业文档工具的需求。原生 Markdown 查看器将发挥同样作用，同时让更专业的应用能够在通用基础之上继续构建。

这种最低体验应包括：文件管理器中的格式化预览、正确的阅读视图、基本编辑器、对底层源文件的访问，以及将更改直接保存到原始 .md 文件的能力。它应支持文档结构，包括标题、段落、列表、链接、表格、图像和代码块，并配备无障碍功能，使内容能够满足不同需求的人。它应适用于本地文件以及操作系统支持的各种文件提供程序，而无需转换到其他应用的内部存储格式中。这些功能没有哪一项特别异乎寻常，而且许多功能如今已经可以通过各个独立应用获得。缺失的一环，是将这些功能变成操作系统中可靠的组成部分，而不是让用户自行发现的可选附加功能。

Markdown 理应成为日常文档

让我感到惊奇的是，尽管主流操作系统从未一致地把它当作原生文档格式对待，我们却还是让 Markdown 变得如此实用。软件开发社区已经接纳了它，出版系统依赖它，独立网站使用它，而 AI 工具正在把它介绍给一个全新的受众群体。它的持久生命力说明这种格式确实做对了某些事情，尤其是在一个技术每隔几年就更新换代的行业里。我们并不需要用 Markdown 取代现有的办公文档、PDF 或专门的出版格式。所有这些工具都有存在的空间，因为它们解决的是不同的问题。我只是认为 Markdown 已经赢得了与它们并列的一席之地，作为任何人都能打开和使用的文档格式。

我很希望看到 Apple、Microsoft、Google、Linux 桌面社区以及其他操作系统开发者能认识到这里的机会。它们都已经构建了大量所需的基础设施，用来呈现文档、编辑文本、同步文件并让信息变得可访问。妥善支持 Markdown 将把这些能力与一种已经被广泛使用、且不需要任何人放弃对自己文档控制权的格式连接起来。这会让不同设备和操作系统之间共享信息变得稍微容易一些，而计算行业至今仍把这件事弄得不必要的复杂。它也可能会鼓励更多人在创建想要保存多年的内容时选择开放格式。这将是一次有意义的改进，即便大多数用户从未对背后的技术多想过一秒。

我不认为这需要变成一项宏大的新计划，也不需要另一个复杂的应用程序来争抢我们的注意力。我希望在我的电脑上双击一个 Markdown 文件就能把它作为文档打开。我希望在手机上收到一个文件，无需安装任何东西就能阅读。我希望做出修改、保存文件后，知道原始的 Markdown 无论下次在哪里打开都依然有效。最重要的是，我希望人们能够从开放文档格式中受益，而无需理解这种开放性为何重要。我们已经有 20 多年的时间来让 Markdown 成为计算中一件普通的事，我认为现在是时候真正做到这一点了。

延伸阅读

CommonMark 文档化了一致的 Markdown 规范，而 GitHub Flavored Markdown 规范 定义了广泛使用的扩展。Microsoft 的 Windows 记事本 Markdown 公告 和 Apple 的 Markdown 导入与导出文档 展示了将这种格式引入内置应用程序的两种不同方式。