AI 们的柴米油盐：为什么一句“加粗”也要精打细算

2004 年，一个叫 John Gruber 的程序员拍出了一份 Perl 脚本。他的本意很简单：写博客的人不用每回都手敲 HTML 尖括号，该多好。

那个时候，没人把这份脚本当回事。但二十一岁的年轻人万万没有想到，2026 年，横跨硅谷到中关村的全部 AI 巨头——从 ChatGPT 到 Claude，从 GitHub Copilot 到飞书里的智能体——早已把这份脚本演化出的语法，当成了他们与人沟通的“统一电报码”。

这桩陈年的轻量级标记语言，就是 Markdown。而那些满嘴高算力、大吞吐的 AI 模型们，偏偏对这种纯文本格式爱得深沉。这并不是因为智能体的审美停留在某个极客聚集的远古 BBS 时代。恰恰相反，在无数种表达可能性之中，Markdown 恰好是那个最现实的生存策略。

账本上的底线星号

在大厂高管的办公室里，或许看不到一行 Markdown 代码，但在各大云服务的财务后台，AI 对 Markdown 的选择极为精明。对一个大语言模型来说，每一段输出的背后都是冰冷的 Token 计费。表达同样的结构，能省一个字绝不多花一个字。

以加粗为例：HTML 格式下要写成尖括号加属性名，耗费 10 个字符；而 Markdown 只需前后各两个朴素的星号，硬是省下近一半的字节消耗。单个看这完全不是回事，但如果算上天量级的对话请求，哪怕每次只省下微不足道的几十个 Token，一年累计下来的成本差就能让财务总监们侧目。

同时，轻量化带来的不仅是省钱，更带来响应速度的跃升。更短的输出意味着更少的逐 Token 生成次数，大模型在零点几秒内就要决策如何最经济地表达强调与层次时，那些井号和星号就像它在符号丛林里下意识的安全区。如果非要让 AI 输出一份格式嵌套混乱、属性值缺失的复杂 HTML，它会像考场上找不着笔的学生，产生更高的困惑度，输出的内容随时可能崩坏。

一条文本，各自表述

但如果认为 Markdown 的统治纯粹是因为抠门，那也小看了这些 AI 的狡猾。

对于那些穿越在聊天泡泡、飞书文档、Notion 页面和开发者笔记深处的一条文本来看，适配的广度才是真正的护城河。很多开发者曾做过思想实验：将同一份食谱分别用纯文本、HTML 以及 JSON 输出，结果各自见了分晓。纯文本是一堵毫无轻重缓急的字墙；HTML 在多数不解析它的聊天窗里，只会暴露出一堆丑陋的代码标签；至于 JSON，那冰冷的数据结构，注定把“菜名”变成晦涩的字段名，任何非技术圈的用户都只会立刻关掉窗口。

只有 Markdown，在聊天窗里被渲染得干净有序；复制到笔记软件里，它落地生花，变成一份格式利落的人类文档；甩给静态博客生成器，它又摇身变为一抹耐看的网页。这种“一次写作，各处可用”的横跨能力，卸掉了智能体与人类之间对于审美的暗中较劲，让格式甘心退让，把“想说什么”重新浮到水面上。

而更深远的影响在于，这种适配的广度撬动了更深一层的利益链。从 Slack 到 Discord，从飞书到 GitHub，全球对话基础设施早已给 Markdown 铺好了上好的轨道。当全世界的平台都用脚投了票，AI 智能体根本没得选，只有把列车开上去才算上道。

星号底下的共谋

其实，Markdown 还暗地里替 AI 充当了一层缓冲剂。它将表达圈定在简洁的层级、列表和链接里，断然舍弃了花里胡哨的字体与页边距。这种极致的单调，反而成为交流中一种理所应当的坦诚——没人会苛求一个只能用井号做标题的助手去做海报。于是输出的内容被心安理得地安放在“草稿”或“信息”的心理位置上，弱化了机械套用模板的僵硬感，也拉大了容错的生存空间。

当然，随着交互前端进入 2026 年，也有人不服。Claude 内部的工程师就在吹新风：HTML 的多媒体交互性与卡片式的表达能力远远超越 Markdown，Markdown 早该退场了。但即便在那篇极尽鼓吹之能事的论文里，写作者也在文本的底层承认道：HTML 只是前台呈现方案，并没有挑战 Markdown 作为底层工作记忆、上下文载体的地位。

所以，当你的智能体助手又在某个深夜铆着执拗的劲头发来一排“### 核心结论”时，先别嫌它冷冰冰。那一排齐整的井号背后，站着的是一整串由 Token 成本、平台生态、人类阅读习惯和工具链条环环相扣的逻辑链。

这些不起眼的星号，代替了无数真实世界里需要砸下去的真金白银推理时长，替无数深夜赶报告的苦命人省去了繁杂的重新排版。AI 并非非得用 Markdown，只不过在所有它能说的语言里，这是目前唯一一种能让算账、做事与对话三者同时保持体面与温饱的方式。

(文章来源：公众号退一步看看)