Markdown 如何成为人与AI的通用格式？

我们之所以还在使用 Markdown，不是因为它设计得有多好，而是因为它作为一种“协议”，已经足够失败。这种失败，恰恰是它成功的关键。

每隔一段时间，就会有人讨论 Markdown 的种种缺点：语法不明确，同样的效果有多种写法（比如用星号或下划线来表示强调）；解析规则混乱，充满了各种历史遗留问题；缺乏严格的规范…

这些抱怨都是事实。从一个严谨的、追求确定性的标记语言规范来看，Markdown 的设计堪称一场灾难。它既不优雅，也不一致，更谈不上完备。然而，一个显而易见的事实是，它赢了。从 GitHub 的 README，到笔记软件 Obsidian，再到如今大语言模型与人类交互的首选格式，Markdown 已经成为事实上的标准。

这就引出了一个问题：为什么一个在技术上如此“糟糕”的东西，能够获得如此压倒性的成功？那些设计上更严谨、功能更强大的替代品，为什么始终只是小众的选择？

答案就在于我们对 Markdown 的定位理解错了。它首先不是为机器设计的，甚至不纯粹是为了最终的渲染结果。Markdown 的核心价值主张，在于它对“写作过程”本身的优化。它是一种将人类在纯文本时代自然形成的排版习惯，进行最低限度抽象的产物。

“更好”的替代品，输在解决了错误的问题

在讨论 Markdown 的问题时，人们总会提到那些“更好”的替代品。比如 AsciiDoc，它拥有更严格的语法、更丰富的功能，可以用来写一整本书，支持文档间的引用、复杂的表格和各种语义化块。RST 也是 Python 社区的宠儿，以其可扩展性和一致性著称。

这些工具无疑是优秀的，但它们和 Markdown 解决的根本不是同一个问题。AsciiDoc 和 RST 的设计哲学，更接近于一种轻量级的 DocBook 或 LaTeX。它们的目标是成为一个强大的“文档生产系统”，让作者能够精确控制文档的结构和语义，最终生成高质量、格式统一的出版物。它们的优化目标是“输出的确定性”和“功能的完备性”。

为了实现这个目标，它们不可避免地增加了作者的认知负荷。你需要学习一套更复杂的规则，记住更多的语法。当你在 AsciiDoc 中写下一个列表时，你是在与一个严谨的解析器进行交互，你必须遵循它的规则。这个过程的本质，依然是人在适应机器。

而 Markdown 恰恰相反。它的设计哲学是“Worse is Better”的完美体现。它不追求成为最完美的工具，而是追求成为“足够好”且摩擦力最小的工具。

Markdown 的很多语法，比如用 * 或 _ 表示强调，用 > 表示引用，并不是 John Gruber 的发明，而是对当年 Usenet 和电子邮件中早已存在的纯文本排版惯例的“追认”。这是一种“顺势而为”（Pave the cowpaths）的设计智慧——观察用户已有的行为，并将其标准化，而不是发明一套全新的“理想”方案强加给用户。

因此，当一个新手打开一个 .md 文件时，即使他从未听说过 Markdown，他大概也能看懂文档的结构。# 后面是标题，- 或 * 开头的是列表。这种“源码即可读”的特性，是 Markdown 最强大的护城河。它将学习成本降到了最低，因为它本质上就是格式化了一点点的纯文本。

Markdown 的产品经理不是解析器开发者，而是千千万万需要快速记录、简单分享的写作者。它优化的不是机器解析的便利性，而是人类书写的流畅性。那些所谓的“语法不明确”，比如星号和下划线都能表示斜体，恰恰是这种理念的产物——因为在纯文本时代，这两种用法都很普遍。Gruber 的选择是兼容并包，而不是做“独裁者”。

失败的“规范”，成功的“生态”

现在我们来谈谈那个最被诟病的“失败”之处：缺乏统一、严格的规范。John Gruber 本人对标准化 Markdown 这件事一直持消极态度，他认为 Markdown 的生命力恰恰在于它的小巧和灵活，可以根据不同场景衍生出变体。

从纯粹的技术角度看，这当然是不对的。一个没有严格规范的“标准”，必然导致碎片化和兼容性地狱。这在早期确实造成了大量问题，不同的解析器对同一个文件的渲染结果可能千差万别。

然而，正是这种“规范的失败”，或者说“顶层设计的缺失”，为 Markdown 带来了意想不到的活力。它没有被一个中心化的委员会锁死，而是允许生态系统中的强者通过实践来定义事实标准。其中最成功的案例就是 GitHub Flavored Markdown (GFM)。

GitHub 需要一种方式来渲染代码仓库里的 README 文件、Issue 和 Pull Request 评论。原始的 Markdown 功能太弱，连表格、删除线、任务列表和代码块语法高亮都不支持。于是 GitHub 在其基础上进行扩展，创造了 GFM。因为 GitHub 的巨大影响力，GFM 迅速成为开发者世界里最主流的 Markdown 方言。它解决的是真实世界的问题，因此获得了用户的认可。

这种自下而上的演化方式，让 Markdown 像一种自然语言一样，在不同的“地区”（应用场景）发展出了适合当地环境的“方言”。Obsidian 和其他笔记软件扩展了双向链接和标签语法，满足了知识管理的需求。一些静态网站生成器则加入了 Front Matter 等元数据支持。

这种“联邦制”的生态，远比一个“中央集权”的严格规范要更有韧性和适应性。如果 Markdown 从一开始就像 XML 那样拥有一个庞大而严谨的规范，它可能早就因为过于僵化而被更灵活的工具所取代。它的“失败”，给了生态野蛮生长的空间，而最终，网络效应决定了胜利者。

在 AI 时代，Markdown 成为新的“明文协议”

如果说以上这些还只是对过去的总结，那么展望未来，Markdown 的地位只会更加巩固。它正在成为人与 AI 协作的“中间语言”。

这背后有几个非常现实的原因。

首先是 Tokenize 效率。对于大语言模型来说，每一个 Token 都是成本。相比于 XML 或 HTML 中的冗余标签，Markdown 用更少的字符传递了同样丰富的结构化信息。重要 在 Markdown 中可能只需要写成 **重要**。在处理海量文本时，这种效率差异是巨大的。

其次，也是更重要的一点，Markdown 的“源码可读性”对 AI 同样适用。LLM 的训练数据是海量的人类自然语言文本。一个格式良好、结构清晰的 Markdown 文档，其原始文本形态本身就非常接近一篇结构化的自然语言文章，这使得模型更容易理解其层次和语义。AI 不需要像传统解析器那样去严格匹配 和 ，而是能像人一样“读懂”#代表标题的意图。

因此，我们看到，无论是要求 AI 生成一份报告、一个计划，还是给 AI 提供复杂的上下文指令，Markdown 都成了首选格式。它在结构化表达能力和自然语言的亲和力之间，找到了一个绝佳的平衡点。它既能清晰地定义代码块、列表、标题，又不会因为过多的语法噪音干扰模型对核心内容的理解。

可以说，Markdown 最初为人类设计的“低认知负荷”，无意中也成了对 AI 友好的“低解析负荷”。一个为优化人类写作体验而做的设计，最终在一个全新的技术范式中找到了更广阔的应用场景。

结语：接受不完美，拥抱“足够好”

回到最初的问题，我们为什么还在使用 Markdown？

因为在软件工程和技术世界里，最终胜出的往往不是技术上最完美、最严谨的方案，而是那个在特定场景下提供了“足够好”的价值，并且将用户摩擦力降到最低的方案。就像 SQL 有着各种设计缺陷，JavaScript 诞生之初充满槽点，但它们都通过解决真实世界的核心问题，并围绕自己建立了庞大的生态系统，从而获得了无法撼动的地位。

Markdown 的故事也是如此。它放弃了成为一种完美标记语言的野心，专注于降低书写和阅读的门槛。它用“规范的失败”换来了“生态的成功”。它那些被技术纯粹主义者诟病的“缺陷”和“不一致”，从另一个角度看，正是它保持简洁、灵活和高度适应性的源泉。

它不是一个完美的终点，而是一个足够好的起点。它是一层薄薄的、几乎透明的、覆盖在纯文本之上的“礼貌”，让信息在人和人、人和机器之间，能够以一种低成本、高效率的方式流动。这，就是它全部的价值，也是它成功的全部秘密。

我们仍在使用它，而且在可以预见的未来，我们还会继续使用它。

参考来源：Why are we still using Markdown?