
图片来源于网络,如有侵权,请联系删除
从ChatGPT的输出到GitHub+Copilot的提示,从Claude的记忆存储到智能体的工作流配置,Markdown (简称“md”)文件仿佛无处不在。
所谓的Markdown 其实不是很新的东西。2004 年,John Gruber 提出 Markdown,它的定位就是面向网络写作者的 text-to-HTML conversion tool。简单来说,就是让写作者先用接近普通文字的方式把内容写完,再通过工具把它转换成 HTML。

图片来源于网络,如有侵权,请联系删除
智能体偏爱用 Markdown 输出,并不是因为它的审美停留在某个技术论坛的远古时代,而是在无数种表达可能性之中,Markdown 恰好是那个让它活得最久、跑得最省、适配得最广的生存策略。
账本上的星号
我们不妨先摊开一本隐形的账本。对一个大语言模型来说,每吐出一个字符,背后都有费用在跳动。按 token 计费的模式,注定了“表达同样的结构,能不能少说几个字”会成为一种本能。拿加粗举个例子:在 HTML 里要写成 <strong>关键信息</strong>,加上尖括号和属性名,耗费 10 个字符;而 Markdown 只需要 **关键信息**,前后各两个星号,一共省下 5 个字符。看起来微不足道,但假设一个智能体每天处理一千万次对话,每次输出里哪怕只减少 20 个 token,一年累计节省的成本就足以让财务侧目。
这还没把推理耗时算进去——更短的输出意味着更少的逐 token 生成次数,响应延迟进一步被压缩。当智能体在零点几秒内就要决定如何最经济地表达层次、强调与分隔时,Markdown 那种“用最少笔墨勾出结构”的特质,几乎是一种下意识的节能选择。
与此同时,Markdown 还暗地里替智能体降低了认知负担。大模型并不是真正理解“加粗”的美学意义,它只是在概率的海洋里寻找最可能跟随的符号序列。在训练数据中,文章、文档、代码库里的 Markdown 标注往往高度统一且简洁,极少出现 HTML 那种标签嵌套不一致、属性值缺失的混乱。简洁的规则让模型更容易生成稳定的结构,困惑度更低,输出的内容也更不容易崩坏。于是,星号和井号成了它游刃有余的安全区。
一条文本,各自表述
但如果认为 Markdown 统治智能体的输出,纯粹是因为抠门,那又太过小看它了。一条带着井号的文本从服务器出发,要奔赴的目的地实在太不相同。它可能被塞进一个聊天泡泡里,在即时通讯软件里被渲染成带层级的小卡片;也可能被用户直接复制,扔进飞书文档、Notion 页面或者 Obsidian 笔记库,成为当天的素材;还有可能就此躺进一个 .md 文件,安静地待在开发者的项目目录里,等着下次提交时被当成文档的一部分。
这种跨度剧烈、几乎没有转换摩擦的场景适应力,才是 Markdown 真正的护城河。
我们不妨做一个思想实验:让智能体将同一份食谱分别用纯文本、HTML 和 JSON 输出,然后看看它们各自会遭遇什么。纯文本无法标记步骤的强调、无法清晰地绘制表格,当用户想把配方分享出去,对方看到的是一堵字墙,读感大打折扣。HTML 虽然能渲染出精美的样子,但大多数聊天窗口并不会解析它,用户看到一堆 <ul>、<li> 和 <table>,只会觉得错乱;即使复制到网页里,还得小心样式冲突与 XSS 风险。
JSON 则走向了另一个极端,结构清晰到冰冷,但“菜名”“食材”“步骤”变成字段名,任何一个非技术用户都不会愿意直接阅读这样一份嵌套括号清单。而 Markdown 呢?在聊天窗,它被渲染得干净有序;复制到笔记软件,它落地成一篇格式妥当的文档;甩给静态博客生成器,它又瞬间变成美观的网页。同样是智能体的输出,Markdown 让它拥有了一种“一次写作,各处可用”的飘逸,不必预先知道用户下一刻会把它抛进什么容器里。
这种适配的广度,还撬动了更深一层的连锁反应。大量产品界面开始主动拥抱 Markdown 渲染,从 Slack 到 Discord,从飞书到 GitHub,都在鼓励用户与智能体用这种轻量标记交流。平台的支持反过来又固化了模型的输出习惯——毕竟,当整个数字世界的对话基础设施都已经为 Markdown 铺好轨道,智能体自然会把列车开上去。于是我们看到的不再是一种格式的孤立成功,而是一个巨大生态在用脚投票。
轻量的坦诚
除了成本和功能的考量,Markdown 或许还在无意间给了我们一个朴素的心理暗示。它把表达框定在简单的层级、列表、强调和链接里,舍弃了字体、颜色、页边距那些无穷的排版选择。这种限制反而变成了交流中的一种坦诚——你大概不会去苛求一个只能用井号做标题的助手做出视觉惊艳的海报,于是它的输出被天然地安放在“草稿”和“信息”的角色中。
格式的退让,让内容重新浮到最表层,也卸掉了对话双方对于审美的暗中较劲。当闪烁的光标前只剩字符和少量标记,智能体和人类都更容易专注于“想说什么”,而非“看起来够不够漂亮”。
这种轻量感,也与智能体目前的能力谦逊地相称。它偶尔会搞错你的意图,会生硬地套用模板,Markdown 恰好用朴素的外衣弱化了这种机械感——毕竟,在一份简单标记的文本里,生硬更像是克制;而如果智能体给你生成一份花里胡哨的排版精美的文档,内里却逻辑混乱,那种反差才会让人真正感到不安。所以 Markdown 无形中还充当着一层缓冲,降低了期待,让容错空间变大了。
当然,某种趋势也在暗示,未来智能体也许能直接输出结构化的交互卡片、动态表单,甚至可执行的微应用。但直到那一天真正普及之前,Markdown 依然是那个能穿越最多信息栈、惹最少麻烦的载体。它像是一种被分发出去的通用的“认知容器”,无论里面的内容换成什么,容器的形状都刚好能塞进大多数人的工作流里,不松不紧。
井号之下,是共谋的精明
所以下一次当你的智能体助手又一次执拗地发来“### 核心结论”,先别急着抱怨它缺少人情味。那一排井号背后,站着一整条由 token 成本、平台生态、人类阅读习惯和工具链需求共同编织的逻辑链。
它不是什么格式原教旨主义,而是过去几千个实验和无数次工程权衡之后,沉淀下来的一种集体选择。每一颗不起眼的星号,都在替真实世界里的某个服务器节省一丁点儿推理时间,替某个深夜赶报告的人省去一次重新排版的烦恼。因此智能体并非非得说 Markdown,只不过在它所有能说的语言里,这是目前唯一能让算账、做事和对话三者同时保持体面的那种。





