作者｜青苹吹果

编辑｜无心插柳柳橙汁

有人的地方就有江湖，对于AI的“格式问题”，也能吵起来、大打出手？

没错，科技圈逐渐分为两派，场面堪比“甜粽vs咸粽之争”。

不知道大家最近刷到没有，Anthropic Claude Code团队的一位大佬，Thariq Shihipar，发了篇神文，名叫《UsingClaude Code: The Unreasonable Effectiveness of HTML》

翻译过来就是：用了Claude Code后，发现HTML这玩意儿有点“不讲武德”。

要知道，在这之前，AI在日常的编程攻坚、写报告时，输出的都是我们熟悉的Markdown，因为它简洁、易懂，是AI时代的“世界语”。

这篇文章一出，整个科技圈直接“地震”，浏览量迅速突破千万。

就连Andrej Karpathy都公开表示认同，表示“非常有效”。

Markdown真的已经过气了吗？HTML难道是Agents唯一的光明未来？

不尽然。

支持者认为，Markdown的局限性正在成为AI表达能力的枷锁。

反对者则搬出“语义密度”和“Token经济性”的大旗，坚称这是一种倒退。

甚至Redis之父antirez都罕见地站了出来直接开火，而且措辞相当犀利。

他说：“每次从语义密集格式切换到语义稀疏格式，都是在亏钱。”

好家伙，公说公有理，婆说婆有理，整个一AI版“奇葩说”。

但如果我们跳出“二选一”的思维定式，会发现这场争论背后，隐藏着一个更本质的变化。

AI时代的文档，正在从“人写给人看”变成“人、模型、工具链共同消费和修改”的中转站。

AI已经强到“撑破”

Markdown

用过Claude Code、Cursor这类“AI牛马”的朋友，肯定深有体会：

你让AI分析一个复杂的屎山项目，它吭哧吭哧给你吐出一份上百行的Markdown方案。标题、列表、代码块，格式规整得挑不出毛病。

但是！你真的会从头到尾读完吗？

说实话，大部分人不会。

瞟一眼目录，扫几行关键结论，然后直接开工。

这不是你的问题，是Markdown的“信息密度”跟不上了。

当AI能同时扒拉你的代码库、Git历史、Slack聊天记录甚至Linear工单时，它掌握的信息复杂度，堪比《三体》里的二向箔，而Markdown这张“二维纸”，根本兜不住。

那位Anthropic工程师举了一个十分生动的例子：Claude曾经在Markdown里用Unicode字符“模拟颜色”，只因为它没有更好的方式来表达视觉信息。

就像一个画家，你只给他一支铅笔，他只能靠“画虚线”来表示不同的颜色，像极了巧妇难为无米之炊。

用减号和竖线拼表格、靠缩进区分层级……这些在文本时代的祖传手艺，放在今天看，简直就像用算盘打《星际争霸》。

Thariq更是坦言，超过100行的Markdown件，他基本不会认真去读。

“既然我自己都不读，那为什么还要让AI花时间生成？”

这句话直接戳中了要害。

Markdown过去最大的优势是“人读着舒服，写着方便”。

但现在AI比你还能写，这个优势就瞬间“不香了”。

于是，他把目光投向了HTML。

“亏钱”？还是

“花小钱办大事”？

HTML的好处显而易见。

表格？有！颜色？随便整！布局？拖拖拽拽！SVG插图？上才艺！甚至可拖拽的滑块、实时预览的编辑器……在Markdown里做梦都想要的功能，HTML都是“基操勿6”。

更重要的是，一个设计良好的HTML页面，人类一眼瞟过去get到的信息量，可能顶几千字的纯文本。

这叫啥？这叫“视觉外挂”。

但反对者的理由同样硬核。

Redis之父antirez之所以能引发共鸣，是因为他算了一笔让人难以反驳的经济账。

同样的内容，HTML消耗的Token可能是Markdown的2到4倍。

在上下文窗口就是真金白银的今天，用更多Token表达同样的信息，怎么看都不划算。

而这还不算生成时间。

HTML比Markdown慢2到4倍，在需要快速迭代的场景下，这种延迟确实让人焦虑。

但支持HTML的一方也有自己的算法。

他们认为，Token的“贵”要看怎么衡量。

一个500行的Markdown文档，人只读了前50行就放弃了，剩下的450行虽然Token省了，但信息根本没进到大脑里，约等于没看。

而一个结构清晰、带图表和颜色标注的HTML页面，人可能从头看到尾，吸收率翻倍。

从这个角度看，多出来的Token成本其实是“买”了阅读意愿和认知效率。

两边说的都有道理。

问题不在于谁对谁错，而在于不同场景下，谁在扮演“甲方”。

场景决定格式

成年人当然是全都要

仔细看那场争论，会发现一个有意思的现象。

两派举的例子，压根不在一个频道上。

antirez说的“语义密集”，指向的是源文档和上下文层。

当一份文档要被AI反复翻牌子、做摘要、改写、被代码审查工具“审视”时，去掉一切花里胡哨，用最少的Token表达最干的信息，确实是优解。

就像你跟数据库打交道，肯定传JSON，不会传一个带<style>标签的HTML。

而支持HTML的人，强调的是呈现和交互层。

当AI输出的东西是给人看、给人点、给人做决策时（比如一份周报、一个事故复盘PPT、一个方案对比面板），视觉清晰度、交互能力就成了硬指标。

你愿意看一份干巴巴的纯文本事故报告，还是一个带时间轴、流程图、甚至还有高亮标注的网页？

这两种需求本身并不矛盾。

真正的问题是，我们现在习惯“一个文档打天下”。

写的时候用Markdown，读的时候还是Markdown，AI消费的时候也是Markdown。

这个单层结构，在今天已经不够用了。

Cloudflare最近搞了个骚操作，很有意思。

他们推出了“Markdown for Agents”，通过HTTP的Accept头做内容协商。

简单说就是同一个链接，人类访问给漂亮的HTML，AI访问给精简的Markdown。通过HTTP的Accept头做“内容协商”，大家各取所需。

这其实就是分层思维在基础设施层面的落地。

源文档用Markdown写，省钱、省Token；呈现层转成HTML，好看、好懂；中间再加一层格式转换和协商，让不同角色都舒服。

这种分工，Markdown的发明者二十年前就说清楚了！

Markdown不是HTML的替代品，一个是写作格式（写给机器看的草稿），一个是发布格式（给人看的成品）。

AI时代没有推翻这个分工，反而让它变得更明确了。

从“写文档”到“搓界面”

下一站又会是什么？

如果说分层是当下的务实解法，那“一次性编辑器”的思路，可能指向一个更野的未来。

那位Anthropic工程师在文章里分享了一个“细思极恐”的用法：

当你需要做一件用文字很难描述清楚的事，比如给30个工单重新排序、调整一组“牵一发而动全身”的功能开关、微调一段玄学systemprompt。那就别跟AI在那儿尬聊了，直接让AI给你生成一个HTML文件。

这个文件里，有可拖拽的卡片、有按区域分组的表单、有左右分栏的实时预览。你像用普通软件一样操作，调好了点一个“复制结果”按钮，把最终参数贴回对话里。

关键是，这个东西用完即弃！

它就是一个为当下这件事量身定做的、用完即弃的“一次性界面”。

这意味着什么？意味着AI输出的东西，不再只是“文档”，而是一个轻量级的交互应用。

它可能是几行代码生成的滑块、一张可筛选的图表、一个实时调参的面板。

这些事，Markdown做不了。

到不是因为它不好，只是它的“出厂设置”就没点这个技能树。

顺着这个“脑洞”往下想，Karpathy最近有条推文说得更透：他画了一条从文字到视觉的进化路线：

纯文本→Markdown→HTML→？

至于终点是什么，他猜可能是扩散模型直接生成的交互式视频。

听起来有点科幻，有点遥远。

但看看最近那些病毒式传播的神经渲染demo，也许没那么远。

至少在当下，HTML是这条路上最成熟、成本最低的落脚点。

浏览器是全球最大的运行时环境，而AI正在学会往这个环境里直接生成“半成品应用”。

写在最后

回到最初那个问题：Markdown会死吗？

大概率不会，立个flag在这儿。

它会退到它最擅长的位置，成为AI时代的“中间格式”。

如同JSON之于API、AST之于编译器、SQL之于数据库，Markdown可能也会变成模型之间、模型与工具链之间交换信息的“纯文本协议”。

至于那些真正要给人类看、给人类操作的东西？

它们会越来越像界面，越来越像应用。

纵观这场争论最有趣的地方，不是HTML赢了还是Markdown赢了。

现在AI，既是生产者又是消费者，因此，那些为“纯人类中心”设计的规则，将被一条条推翻、重写。

格式只是开始。后面还有很多。