AI时代的来临，意外地让曾经小众的 Markdown 语言迎来了自己的春天：提示词要写 Markdown、知识库要存 Markdown、AI 输出首选 Markdown，这种带着井号、星号和方括号的纯文本格式，俨然成了人机交互的 “通用语”。
这让多年来一直喜欢 Markdown、推荐 Markdown （虽然成功率极低）的我，产生了一些微妙的情绪。正如任何流行并被寄予厚望的技术那样，Markdown 也被投注了过多的一厢情愿。虽然 Markdown 终于获得了更广泛的认可，但原因却和它自己的初衷相去甚远。本文尝试略作梳理。
前史：早期互联网与纯文本
互联网上的文字，一开始都是纯文本（plain text），一切都很简单，也很朴素。后来，网页出现了，文字开始有样式，变得更好看、更生动了，但撰写内容却也开始变成一件苦差事。
因为网页使用HTML语言，这就意味着任何想要用网页呈现文字的写作者，都要徒手给每个段落加上<p>标签、用<a href="">来记录超链接、用<h2>标记二级标题。这些操作理论上可行，但却令人非常痛苦，也让审阅文字变得难以忍受。
说到底，这些标签是写给机器看的指令，而非写给人看的表达。它从不照顾人的习惯与偏好，只服从机器的解析规则。难怪 Aaron Swartz 当时要惊呼自己“已经受够了不得不迁就计算机的行为”，并动手编制了一套被他称作 atx 的纯文本格式来替代复杂的 HTML 格式。
很多人都将 atx 视为 Markdown 的前身，因为二者不仅在试图解决同一个问题，就连语法设计也高度相似，据说 Swartz 本人也确实参与了关于 Markdown 最早的讨论。但更准确地说，它们其实是共享了同一个灵感源头。因为这种标记文字的方式，既不是巧合，也不完全是他们的原创，而是来自于人们在邮件、新闻组里使用纯文本交流时，自发地形成的一套标记习俗。
Swartz 的洞见在于，他并没有生造一套规则，而是把这些已经约定俗成的做法融入到自己的设计之中。这种 “向人的习惯靠拢，而非让人向机器妥协” 的技术观，也成了后来 Markdown 最珍贵的精神底色。
诞生：让写作回归写作
2004年，科技博主 John Gruber 发布了 Markdown。
在其最早的设想里，Markdown 是一款为在网上写作的人（web writer）制作的文本转网页（text-to-HTML）工具。这款工具由两部分组成：一套纯文本的标记格式规范 + 一款用 Perl 写的格式转换工具。
简单来说，Markdown想要把“写作”和“网络发布”这两个过程分离——用纯文本进行写作，再将纯文本文件自动转换成规范的 HTML 页面发布。
虽然 Markdown 吸收了许多“文本转网页”工具“前辈”的启发（除了之前提到的atx，还有Setext、Textile、reStructuredText、Grutatext和EtText ），但和Swartz 一样，他最大的灵感来源还是人们使用纯文本写作时自然形成的习惯和直觉：星号的醒目感、行首短横的秩序感，哪怕不经任何渲染，人们也可以轻松感知到这些符号的含义。
Gruber 希望编写 Markdown 的感觉更像写作，而非编程，因此Markdown的语法必须足够直观，不增加不必要的复杂性，甚至到了“如果原文看着别扭，那语法就不该这么设计” 的程度。
这种做法保持了 Markdown 在理念上的纯粹，但也埋下了问题的隐患。原版规范只覆盖了最常用的场景，但却没有考虑表格、任务列表、代码块等其他场景的需求。后来，不同使用者按照各自的理解补充规则，渐渐衍生出五花八门的 “方言”，也造成了同一份源文件在不同的编辑器里可能会输出不同解析结果的情况。
虽然这种混乱的现象倒也符合 Markdown 野生的气质，只是随着 Markdown 使用者数量的不断增加，标准问题成了社区不得不面对和解决的命题。
发展：在自由与规范之间
Markdown 发布的2004年，恰逢个人博客浪潮兴起。许多经历过 HTML 写作之苦的博主，成了 Markdown 最早的使用者。这套轻量格式经受住了时间的检验，证明了它切中了一个真实的痛点：人们需要一种既能轻松写作、又能优雅发布的网络文本格式，而 Markdown 提供了一个足够好的方案，也因此逐渐吸引到了更多拥有技术背景的用户。
2008年，软件开发者论坛 Stack Overflow上线运营，其最核心的问答内容从一开始就支持 Markdown 格式。2009年，Tom Preston-Werner 发布了静态网页生成工具 Jekyll，并把Markdown 设为默认内容格式。2011年，Github 发布了自己的 Markdown 变体 Github Flavored Markdown (GFM)，让 Markdown 成了开源项目文档的通用标准。
用户量的上涨，让原版语法的局限性变得越来越明显。表格、脚注、任务列表、代码高亮…… 各种需求层出不穷，各个平台各自扩展，标准模糊的问题愈发尖锐。
2012 年，Jeff Atwood、John MacFarlane 等一群程序员发起了为 Markdown 制定统一标准的计划，于是才有了后来的 CommonMark。但Gruber 本人对此并不买账，他认为不同的站点和用户有不同的需求，不会有一个统一的语法可以让所有人满意，也不该去追求一套统一的标准。在他看来，那些模糊与混乱，恰恰是 Markdown 的开放性与生命力所在。但现实用户对统一标准的需求实在太过强烈，CommonMark 逐渐成为了事实上的行业基准。
回看这场关于标准化的争论，其本质从来都不是技术细节的分歧，而是两种技术观的碰撞：一边是机器的效率与精准，一边是人的自由与弹性。而这场关于人与机器的交锋，也像一个预言，提前映照了 Markdown 在 AI 时代的处境。
当代：AI vs Human
这一波人工智能的火热，“意外地”让 Markdown 进入了更广泛的大众视野。因为大语言模型处理的主要对象就是文字，而一般的文件格式（比如 doc、pdf 等）在文字之外还保存了大量与内容无关的格式信息，不仅平白增加了token消耗，还会不同程度地干扰模型的理解精度。
为了应对这种情形，人们再次关注到了纯文本这种格式。对于文字信息，纯文本格式似乎是最自然的选择，但纯文本缺少结构表达能力。而在 “内容” 与 “形式” 之间取得了优雅平衡的 Markdown，恰好成了最优解：它本质仍是纯文本，不增加机器的解析负担；同时又能用极简的符号保留标题、列表、层级、链接等结构信息，让文档逻辑清晰、信息密度更高。
提示词工程教人们用 Markdown 结构化提问，知识库用 Markdown 存储语料，AI 的输出也往往采用 Markdown 格式。这种曾经为了方便人类读写而生的格式，如今却似乎变成了AI读写的基础设施。
可问题的关键在于，Markdown 的出现是为了解放人，让人回归自己的表达，而不是削足适履地去满足机器的要求。在这个过程里，人既是书写的主体，也是文字最终的读者。但当 AI 开始替人写作、也替人阅读，人在这个过程里的位置就开始变得暧昧：如果文字不再需要人来读写，那么人对格式的感受还有意义吗？
我们在 AI 时代追捧 Markdown，但却似乎在逐渐抛弃那个让 Markdown 出现的人本主义前提。我们想要追求的是更高的解析精度、更少的 token 用量，却不再在意它是否让人用得更舒服。可以想象的是，如果未来出现一种更适配AI 的信息格式，哪怕它对人类极不友好，这些拥趸也大概率会毫不犹豫地转向下一个 “机器最优解”。
这多少有些买椟还珠的意味。
也许，Markdown 这个名字本身就是一个提醒：它是一种标记语言（markup），也是一种“迁就人类的设计”（mark down for human）的语言。它的灵魂从来不是 “让机器更高效”，而是 “让人更舒服”—— 那些从纯文本传统里继承来的符号、那些手指敲击带来的温润感、那些不追求绝对精准的规范，本质上都是对人的尊重。
AI 可以生成 Markdown，也可以读懂 Markdown，但文字的终极对象，从来都不该是机器。在我看来，Markdown 并不是什么新鲜的流行玩意，而是数字时代里的一种古典主义。只要还有人愿意为了表达本身而书写，只要文字的终点还是另一个人的眼睛，Markdown 所代表的 “为人类写作” 的精神，就应该永远有它的位置。
（题图：Markdown 最早的发布界面，来自daringfireball 网站）
