HTML取代Markdown？Claude Code工程师深度解析AI输出格式新趋势

2026年5月8日，Anthropic Claude Code团队的工程师Thariq Shihipar在X上抛出一句断言：

“HTML就是新的Markdown。我已经彻底停止编写Markdown文件了。”

说这话的若不是他，或许只会被当成一种个人习惯。可他偏偏是打造AI编程工具的核心开发者。随推文发布的博文《HTML不合理的有效性》（The Unreasonable Effectiveness of HTML）里附带了20个他用HTML生成的输出案例。不出两天，凭借对LLM玩法先知先觉的Simon Willison转发并评论“我把默认设置改了”，连Karpathy也公开表示HTML的信息密度确实优于Markdown。

评论区随即炸开。Hacker News涌出三百多条讨论，Reddit上唇枪舌剑，中文技术圈同样跟进热烈。有声音直斥“开历史倒车”，有人拍手“早该如此”，也有人提醒“别被带偏了节奏”。

在通读Thariq的原文、Simon Willison的深度分析以及社区正反意见之后，会发现这件事远比第一眼看到的更值得玩味。

厘清概念：他究竟想表达什么？

不少读者看到标题便急了——“Markdown要死了？Claude团队背叛开发者？”

别急。Thariq说的并不是“Markdown这个格式将被淘汰”，而是：AI Agent输出结果时，HTML比Markdown更合适。 两者完全不同。

不妨回想日常的工作流：让Claude Code帮忙review一个PR，它产出一份200行的Markdown文档。你打开，扫了15行便关掉。三天后又让它review一次，因为你已经想不起上次的内容。Thariq指出的正是这个痛点：在AI输出场景下，Markdown的信息密度过低。

在他的描述里有一个扎心的细节：为了让Markdown显示颜色，Claude Code竟用Unicode方块字符来模拟。一个2026年的AI工具，却要用上世纪的方法在终端里呈现彩色文本——格式本身成了瓶颈。

HTML的独特优势：Markdown无法企及的功能

光讲概念不够，直接看实例。

1. PR Review变成交互式报告

以往让Claude Code审查PR，得到的是一大段Markdown：

## Code Review  
  
### Issue 1: Streaming Logic (High Severity)  
The backpressure handling in line 42 might cause...

Thariq的办法是让Claude直接生成HTML：

Help me review this PR by creating an HTML artifact that  
describes it. Render the actual diff with inline margin  
annotations, color-code findings by severity.

产出的效果：代码差异在页面内嵌渲染，严重程度按红/黄/绿区分，每一行批注紧挨着代码，点击即可展开详细说明。这不再是一篇文档，而是一个小型工具。

2. 技术解释内含SVG图表与交互导航

Simon Willison曾用一段混淆的Python漏洞利用代码做实验，交给GPT‑5.5并指示其生成HTML解释。最终得到的页面包含：

  • 左右分栏：左侧高层概要，右侧逐行代码解析
  • 危险的执行路径以红色高亮
  • 安全警告以醒目的黄色边框呈现
  • 每一步的分析可逐步展开

同样的内容若用Markdown输出，会变成百余行的纯文本，结构、重点全靠自己挖掘。

3. 20个案例覆盖9类场景

Thariq在 thariqs.github.io/html-effectiveness 整理了一个案例库，涵盖：

  • 代码审查报告
  • 架构决策记录（ADR）
  • 项目计划
  • 技术调研报告
  • 竞品分析
  • API文档
  • 故障复盘
  • 周报/日报
  • 学习笔记

每一个都是自包含的HTML文件，拖入浏览器即用。包含CSS样式、交互功能和图表，且无任何外部依赖，无需安装工具、构建步骤或服务器。

时机成熟的背后：Simon Willison的深度解读

“HTML比Markdown强”并非新认知。为什么偏偏在2026年5月成为引爆点？

Simon Willison在他的博客里给出了一个极为精准的回答：

“从GPT‑4时代起，我一直默认用Markdown请求绝大部分内容，因为那时只有8,192个token的限制，Markdown在token消耗上远低于HTML，这一点极其重要。”

换句直白的话说：当年选Markdown不是因为它好，而是因为它省token。 在GPT‑4早期，上下文窗口极小，HTML的标签、属性、闭合标签会吃掉大量token，大幅挤占实际可输出的信息量，Markdown的简洁无疑是最优解。

但2026年的大模型已今非昔比。上下文窗口动辄128K甚至200K，HTML多出的那些token几乎可以忽略。当初选择Markdown的核心理由已然消失，留下的只是惯性。

Willison也坦言：“Thariq的这篇文章让我重新思考了这一点。”一位在LLM领域深耕多年的专家，愿意公开承认自己过去的选择是基于历史局限而非技术优劣——这种坦诚比文章本身更有分量。

社区争议：正反两面的真实声音

支持派

Hacker News最高赞评论一针见血：

“他文章里最犀利的一个细节，是一张截图：Claude Code用Unicode方块字符给Markdown模拟颜色——因为格式本就没有其他实现方式。媒介本身成了限制。”

Reddit上的实用派分享体验：

“我在最近一次PR review中试了HTML输出。生成的页面按文件分标签页，严重程度用颜色区分，批注直接内嵌。我第一次从头到尾看完了review，而不是只扫前20行。”

Karpathy的表态也颇具分量，虽未写长文，但在X上明确赞同HTML的信息密度高于Markdown。

反对派

反对的声音同样尖锐且并非情绪化吐槽：

Token成本计算——LinkedIn上一位名为William Liu的用户算了一笔账：

“Anthropic正加速冲向token破产。HTML制品看起来漂亮，但消耗的token是同等Markdown的3到5倍。”

他说得没错。HTML标签结构确实更费token。在大规模应用场景中，这一成本差异不可忽视。

版本控制问题——HN上有评论直指要害：

“试试diff两个HTML文件，再diff两个Markdown文件。HTML的版本管理体验简直灾难。”

Markdown作为纯文本，git diff结果清晰易读；HTML则因标签嵌套让diff变得难以辨认。在需要频繁追踪变更的场景中，这是实打实的短板。

过度工程化——知乎上有总结一语中的：

“总不能为了看个待办清单，就要生成一个带CSS动画的HTML页面吧？简单的事情被搞复杂了。”

核心判断：互补而非取代

经过反复思考，这件事不应用“谁赢谁输”的框架看待。

Markdown不会消亡。 以下场景中它依然是最佳选择：

  • GitHub的README——全球开发者的共同语言
  • 项目配置文件（CLAUDE.md、AGENTS.md等）
  • 笔记应用（Notion、Obsidian的核心格式）
  • 简短的注释与说明

HTML也不会全面取代Markdown。 但在AI Agent的输出场景里，HTML正逐步赢回属于它的位置。

一个新的分工格局正在形成：

场景推荐格式原因
人写的配置文件Markdown轻量、简洁、git友好
人写的笔记/文档Markdown所见即所得的编辑体验
AI输出的分析报告HTML信息密度高、交互丰富
AI输出的代码审查HTML颜色标注、内联批注
AI生成的可视化内容HTMLSVG图表、数据面板
人机协作的中间产物HTML程序可解析、人可直接阅读

借用搜狐那篇文章的结语：

人写的，用Markdown；AI写的，用HTML。这不是取代，而是各自找到了更适合自己的位置。

实战指南：如何引导Claude Code生成HTML

理论讲完，落到实处。如果想尝试这个方向，只需修改一句prompt。

基础Prompt模板

将原来的：

帮我分析一下这个PR的问题

改成：

帮我分析一下这个PR，输出HTML格式。用CSS做颜色标注，  
不同严重程度用不同颜色，代码和批注并排显示。

进阶Prompt（Thariq推荐）

Output HTML, neatly styled and using capabilities of HTML and  
CSS and JavaScript to make the explanation rich and interactive  
and as clear as possible.

这一句话便能让Claude Code尽数调用SVG图表、交互控件与页面内导航。

最见成效的场景

测试显示，以下场景中HTML输出的提升最显著：

  1. PR Review：代码diff + 严重度标注 + 内联批注
  2. 架构文档：SVG流程图 + 可展开细节 + 标签页切换
  3. 竞品分析：对比表格 + 数据可视化
  4. 故障复盘：时间线 + 根因分析路径
  5. 学习笔记：交互式代码演示 + 知识点高亮

不宜用HTML的场景：

  • 简单的配置说明（杀鸡焉用牛刀）
  • 需要git diff追踪的文件（HTML差异难以阅读）
  • 团队成员不习惯在浏览器中查看文档（继续用Markdown吧）

更深层的转变：AI重新定义“输出格式”

这件事更值得思考的，或许不是Markdown与HTML之争，而是下面这个判断：

过去，格式是给人读的；现在，格式需要同时满足三种读者：人、程序，以及AI本身。

Markdown解决了“人读”的问题。但在AI时代出现了新的需求：AI输出的内容不仅要能被程序精确解析，还要在不同环境下一致渲染，并承载比纯文本更丰富的信息。

HTML恰好满足这三个条件：

  • 人：浏览器打开即可阅读
  • 程序：DOM结构能够被精确解析
  • AI：标签语义明确，无歧义

举个例子：在Markdown中，要嵌套列表与代码块，写法如下：

1. 第一步  
   ```python  
   print("hello")
  1. 第二步

这段文本在GitHub、VSCode、Typora里的渲染结果可能完全不同。因为Markdown规范本身允许不同解析器存在行为差异。

但HTML不会有此问题：

<ol>
  <li>第一步
    <pre><code>print("hello")</code></pre>
  </li>
  <li>第二步</li>
</ol>

无论哪个浏览器、哪个解析器，渲染效果都是一致的。一种文件格式，三方都能无歧义处理——Markdown做不到，HTML却可以。

IKANGAI的文章中有一个观点值得重视：HTML正在被“重新发现”。Tim Berners‑Lee最初设计的浏览器是可以编辑页面的，HTML本就是用来“读和写”的。后来浏览器退化为纯查看工具，HTML变成了“交付格式”。如今LLM可以直接读写HTML，它又重新回到了那个原始角色——一个可读、可写、可交互的通用格式。

总结与反思

Thariq那篇文章最触动人的或许不是技术论点，而是这句话：

“I feel more in the loop than ever.”

采用HTML输出后，他感觉自己与AI的协作更加透明可控。正是因为HTML的信息密度高，他能快速浏览、抓住重点、做出判断，而不是面对200行Markdown一脸茫然。

这才是关键——无关格式之争，关乎人在AI工作流中的掌控感。

Vibe Coding的一个副作用是：AI做了很多事，你看不懂、记不住，也掌控不了。而HTML以更高的信息密度和交互性，让人重新回到“知道正在发生什么”的状态。

当然，也无须过分拔高。Token成本、版本控制、团队习惯——这些都是真实存在的关卡。在个人项目或小团队中尝试并无不可，可要在企业级流程里全面推行，前面还有很长一段路。

不妨给出这样一个建议：别急着站队。下次让Claude Code做code review或写分析报告时，试着一句“输出HTML”。用完之后，你会自己判断它值不值得。

毕竟，工具好坏，使用者说了才算数，而不是推特的转发量。

参考资料：

  • Thariq Shihipar: Using Claude Code: The Unreasonable Effectiveness of HTML
  • Simon Willison: Using Claude Code: The Unreasonable Effectiveness of HTML (2026年5月8日)
  • IKANGAI: HTML is being rediscovered in the Context of LLMs (2026年5月11日)
  • sudostack: Ask Claude for HTML, Not Markdown: Richer AI Outputs
  • Hacker News 讨论: Using Claude Code: The Unreasonable Effectiveness of HTML
  • Reddit r/ClaudeAI 讨论: The unreasonable effectiveness of HTML when using Claude Code