如果你经常使用AI编程工具，一定会注意到一个现象：无论是Claude Code的Skills、Cursor的规则文件，还是ChatGPT的提示词，几乎都用Markdown格式。
为什么是Markdown？不是Word、不是PDF、也不是JSON？
答案很简单：Markdown是大模型最熟悉的“母语”之一。 它的训练数据里，GitHub的README、技术博客、Stack Overflow的问答，到处是Markdown的身影。你用Markdown和AI对话，就像在用它的母语交流，它理解最准、执行最稳。
那么，这个无处不在的Markdown格式，到底是怎么来的？谁发明的？为什么没有“官方标准”？AI应用用的又是哪个“版本”？
这篇文章，我们就来追溯一下Markdown的前世今生。
Markdown 是由约翰·格鲁伯（John Gruber）于2002年开始构思，2004年发布的，在语法上有很大一部分是与亚伦·斯沃茨（Aaron Swartz） 共同合作的。
🧠 创造者是谁？
| 人物 | 身份 | 贡献 |
|---|---|---|
| 约翰·格鲁伯（John Gruber） | 科技博主、Daring Fireball 博主 | Markdown 的创始人和主要设计者，2004年发布了初代 Markdown |
| 亚伦·斯沃茨（Aaron Swartz） | 程序员、Reddit 联合创始人、RSS 开发者 | 参与了 Markdown 语法的设计，贡献了大量想法 |
亚伦·斯沃茨本身是个传奇人物——他参与开发了 RSS 和知识共享组织（Creative Commons），联合创办了Reddit，后来因卷入网络犯罪案于 2013 年自杀，年仅26岁。
🎯 为什么会有 Markdown？
格鲁伯创造 Markdown 的初衷非常朴素：让写网页像写邮件一样简单。
2002年左右，格鲁伯决定专注写 Apple 相关的博客。但当时写博客需要手写 HTML——即便是加粗文字、插入链接这种基本操作，也要写一堆 、 这样的标签，不仅麻烦，还容易因为一个小错误破坏整个页面结构。
他的想法是：既然人们在邮件里用 星号 表示强调、用空行分段已经成了习惯，为什么不把这些“约定俗成”的写法变成一套正式语法，然后自动转换成 HTML 呢？
于是，Markdown 诞生了。
📜 最初的实现
2004年3月，格鲁伯发布了第一个版本的 Markdown，是用 Perl 脚本写的。这个脚本的作用很简单：把你写的 .md 文件转换成规范的 HTML。
后来，这个 Perl 脚本被移植到各种编程语言，出现了 Python、JavaScript、Ruby、PHP 等几十种不同语言的 Markdown 解析库。
🤝 没有“官方标准”的尴尬
有意思的是，Markdown 从来就没有一个“官方标准”。
格鲁伯最初只发布了一个“非正式规范”（就是一篇描述语法的文章）和一个参考实现（那个 Perl 脚本）。他一直没有把 Markdown 变成正式的标准化文档。
这导致了一个问题：不同平台、不同解析器对 Markdown 的理解不一样。比如：
- 标准 Markdown 要求标题的 # 后面有空格，有些实现不要求
- 标准 Markdown 要求换行时行末加两个空格，GitHub Flavored Markdown 取消了这一限制
- 表格、删除线、任务列表等功能，标准 Markdown 根本不支持
📏 后来的标准化尝试
2012 年，Stack Overflow 联合创始人 Jeff Atwood牵头，联合GitHub、Reddit、Meteor 等公司，发起了一个标准化项目，试图制定统一的Markdown 规范。
2014 年，他们发布了Standard Markdown项目。但格鲁伯反对使用 “Markdown” 这个名字，于是项目改名为CommonMark。
CommonMark 发布了一份完整的规范、600+测试用例、以及C语言和JavaScript的参考实现。它只规范核心语法，不添加任何新功能。
2016 年，IETF（互联网工程任务组）发布了RFC 7763和RFC 7764，正式定义了Markdown 的 MIME 类型 text/markdown，并注册了 CommonMark、GFM、MultiMarkdown 等变体。
🌟 几个重要的“变体”
| 名称 | 来源 | 特点 |
|---|---|---|
| GFM (GitHub Flavored Markdown) | GitHub | 基于CommonMark，增加了表格、任务列表、删除线、围栏代码块 |
| CommonMark | 社区标准化项目 | 只规范核心语法，不添加新功能 |
| MultiMarkdown | Fletcher Penney | 增加了脚注、引用、LaTeX 数学公式等 |
| Markdown Extra | Michel Fortin | 增加了表格、定义列表、脚注等 |
GitHub 从 2009 年左右开始使用 Markdown，并推出了 GFM。虽然Markdown没有官方标准，但GFM已经凭借GitHub的统治地位和实际技术优势，成为了AI领域的默认选择，GFM 成了事实上的“标准方言”。
📊 证据一：主流 AI 应用的选择
根据一项针对 DeepSeek、豆包、腾讯元宝、ChatGPT等主流AI应用的调研，它们在 Markdown渲染上有一个共同特征：
全部采用CommonMark标准解析器（使用Markwon库），完整支持GFM扩展语法。
这意味着无论你用哪个AI产品，它在处理Markdown时，底层都在遵循同一套规范——CommonMark核心+GFM扩展。
📊 证据二：开发工具的明确选择
Gitea 的官方文档中有一段非常清晰的表述：
"Gitea 尽可能遵循 GitHub Flavored Markdown (GFM) 。GFM 是在严格规范的 CommonMark 标准之上的扩展。CommonMark 被大多数主流网络平台（如 Reddit、Stack Overflow、Discourse）和 Git 平台（GitHub、GitLab 及 Gitea 自身）使用。"
Gitea 还特别指出： "GFM 是 CommonMark 的超集，增加了表格、任务列表、删除线、URL 自动链接等实用扩展。"
📊 证据三：开发者生态的共识
- uni-cmark插件：一个基于C语言库cmark-gfm封装的Markdown解析UTS插件，明确标注"完整支持GFM扩展语法"
- markdown-for-agents库：专为AI智能体优化的HTML转Markdown工具，基于 GFM标准
- MarkItDown：微软开源的文档转Markdown工具，专门针对大语言模型优化。
· 我发现稀土掘金平台编辑文章时，可能也使用了Markdown格式（待官方确认）。
🔗 CommonMark 与 GFM 的关系
| 名称 | 定位 | 说明 |
|---|---|---|
| CommonMark | 核心规范 | 2014 年由 Stack Overflow、GitHub、Reddit 等联合制定的严格规范，明确了标题、列表、加粗等核心语法，解决了 Markdown 长期存在的"方言"问题 |
| GFM | 扩展规范 | 在CommonMark基础上增加了表格、任务列表、删除线、@提及、URL自动链接等实用扩展 |
两者的关系： CommonMark 保证了核心语法的一致性，GFM 在此基础上增加了 GitHub 特有的实用功能。
🤖 为什么AI选择了GFM？
1. 数据训练优势
大模型的训练数据中，GitHub的代码仓库和README文件占据了极其庞大的比例。GFM是这些数据使用的格式，因此大模型对GFM的理解最准确。用GFM和AI交互，就像在用它的"母语"对话。
2. 格式测试验证
第三方测试表明，在 11 种不同格式中，Markdown-KV（键值对）的准确率最高（60.7%） ，而 Markdown-Table 也有不错的表现（51.9%）。
3. 人机两读的平衡
GFM 在保持人类可读性的同时，提供了足够的结构化表达能力（表格、任务列表、代码块语言标注等），让 AI 能精准解析语义。
✅ 总结
| 问题 | 答案 |
|---|---|
| AI 应用现在用什么标准？ | GFM（GitHub Flavored Markdown） |
| 这个标准是谁定的？ | 不是一家定的。CommonMark 是社区联合制定的，GFM 是 GitHub在其基础上扩展的 |
| 为什么用 GFM？ | 大模型训练数据里GFM最多、AI理解最准、功能最实用 |
| 和 CommonMark 什么关系？ | GFM = CommonMark（核心）+ 扩展功能（表格、任务列表等） |
本文内容基于作者的开发经验和对官方文档的理解，仅供参考。技术工具、模型参数、定价等信息可能随时间变化，请以官方最新发布为准。如有不同见解，欢迎在评论区理性交流。
本文为原创内容，首发于微信公众号[机器人与人工智能爱好者]。未经本人书面授权，禁止任何形式的摘编、复制或用于商业用途，转载须注明出处。
