“说实话，我现在几乎完全不用 Markdown 了。”

最近，Anthropic  旗下 Claude Code 的工程师 Thariq Shihipar 撰写了一篇引人深思的文章，他表示：“自己如今更倾向于让 Claude 直接输出 HTML，而不是过去默认的 Markdown。”

这番表态，在 AI 开发者圈子里引发了不小讨论。

有人觉得，Markdown 已经是过去十几年最成功、最轻量的内容格式之一：简单、清晰、跨平台，几乎所有 AI 工具、代码仓库、笔记软件都围绕它建立了生态。可也有人开始认同另一种声音，当 AI 的输出越来越长、越来越复杂之后，Markdown 似乎正在暴露出它的“短板”。

在 Thariq Shihipar 看来，问题并不在于 Markdown 不够优秀，而在于它越来越难承载智能代理时代的信息密度。

“动辄上百行的 Markdown 文件，读起来其实很吃力。”他提到，相比只能依赖标题、粗体、列表来组织内容的 Markdown，HTML 能提供更灵活的布局、更丰富的视觉层次，甚至交互能力。

换句话说，AI 输出的内容，或许不该再只是“一大段文本”。而这个观点，也得到了不少 AI 圈知名人物的支持。

例如，Andrej Karpathy（卡帕西）最近也公开支持这一看法，他透露自己已经开始习惯在提问最后加上一句：“以 HTML 的形式组织回答（structure your response as HTML）”，然后直接在浏览器里打开生成的文件阅读。 

卡帕西认为，音频会是人类更偏好的 AI 输入方式，而视觉（图像、动画、视频）则会成为 AI 更理想的输出方式。人类大约三分之一的大脑，其实都在处理视觉信息，它像是一条通往大脑的信息“十车道高速公路”。 

相比之下，纯文本阅读成本最高；Markdown 虽然改善了层次感，但依旧属于“文本思维”；而 HTML，则开始让 AI 输出从“文档”变成“界面”。

甚至，卡帕西还进一步畅想了一条 AI 输出形式的演化路径：

1）纯文本 —— 阅读费力、信息密度高但难消化

2）Markdown —— 增加结构化排版，成为当前默认形态

3）HTML —— 开始具备布局、图形、动画、交互能力

4）……

n）由扩散模型神经网络直接生成的交互式视频 / 模拟系统

在他看来，未来 AI 输出的终点，甚至可能不再是“文档”，而是某种实时生成、可交互、可操作的动态视觉内容。

而这，也让这场关于 Markdown 与 HTML 的争论，开始变得不只是“格式之争”那么简单。它背后真正折射出的，其实是 AI 产品形态本身正在发生变化。

过去，人们默认 AI 是“聊天机器人”，输出自然也应该是文本；但当 AI 开始一步步变成真正的智能代理（Agent），开始帮人处理任务、组织信息、生成界面、调用工具之后，人们或许也不得不重新思考一个问题：

AI 最合适的输出形式，到底还应不应该只是文本？

而有这种想法的人，其实并不在少数。

在随后的长文里，Thariq Shihipar 也进一步展示了大量 HTML 输出案例，并详细解释了为什么他认为：在 AI 时代，HTML 很可能会比 Markdown 更适合作为下一代默认输出格式。

为什么选择 HTML？

在 X 上，Thariq Shihipar 列举了五个关键点：

1. 信息密度

相比于 Markdown，HTML 能够承载丰富得多的信息。

它既可以实现标题、排版这类基础文档结构，也能呈现各式各样其他类型的信息，例如：

• 通过表格展示表格数据
• 借助 CSS 呈现设计样式
• 利用 SVG 制作插图
• 通过脚本标签嵌入代码片段
• 结合 JavaScript 与 CSS，利用 HTML 元素实现交互效果
• 运用 SVG 和 HTML 展示工作流程
• 通过绝对定位和画布呈现空间数据
• 使用图片标签插入图像

Thariq Shihipar 甚至直接表示：凡是 Claude 能够读懂的信息，几乎都可以用 HTML 高效地呈现出来。这让 HTML 成为 AI 模型向你传递深度信息、也方便你审阅内容的高效方式。

不仅如此，他发现，在 Markdown 做不到这些的情况下，模型只能用更低效的方式来凑数，比如用 ASCII 字符画图表；亦或者像 Claude Code 的这张截图里那样，用 Unicode 字符来模拟色彩展示。

Claude Code 试图在 Markdown 中用字符模拟颜色效果

2. 视觉清晰度与阅读体验

随着 Claude 能够处理愈发复杂的任务，它编写的技术规范、方案规划文档也变得越来越长。

实际使用中，Thariq Shihipar 发现，超过一百行的 Markdown 文档，自己都很难耐心读完，更别说让团队里其他人去阅读查阅了。

而 HTML 文档的阅读体验要好得多。Claude 可以从视觉层面优化整体结构，通过标签页、插图、超链接等形式，让文档浏览起来十分顺畅。

HTML 还支持移动端自适应布局，能根据你使用的设备屏幕自动适配阅读版式。

3. 便于分享

Markdown 文件的分享相当不便，大多数浏览器都无法原生良好渲染这类文件，往往只能作为附件放在邮件或消息里发送。

而 HTML 文件只需上传到服务器（比如 S3 对象存储），就能直接分享链接。同事可以在任意设备上打开查阅、随时引用。

如果用 HTML 格式撰写技术规范、工作报告、PR 说明文档，别人愿意认真阅读的概率会高出非常多。

4. 双向交互

HTML 支持人与文档进行交互。比如你可以让它加入滑块、调节旋钮，用来调整设计参数；也可以微调算法里的各项配置，实时查看效果变化。

还可以把这些调整后的配置一键复制，直接粘贴到 Claude Code 的提示词里继续使用。

• 数据与上下文接入

为什么要用 Claude Code 来生成 HTML 文件，而不直接用 Claude 网页版或 Claude Design？

「最关键的原因之一，是 Claude Code 能够读取海量本地上下文」，Thariq Shihipar 写道。

基于此，他举了个例子，在撰写这篇文章时，让 Claude Code 遍历了他自己的代码文件夹，找出其过往生成的所有 HTML 文件，进行整理分类，再自动生成一份汇总 HTML 文档，用图表展示每一类文件。

上文中出现的所有图表，都是这样直接生成的。

除了本地文件系统，Claude Code 还能通过 MCP 工具获取更多外部上下文，比如 Slack、Linear 等协作工具，搭配 Chrome 中的 Claude 插件读取浏览器内容，以及调取 Git 版本历史记录等等。

5. 创作体验更愉悦

用 Claude 制作 HTML 文档本身更有乐趣，能让人更有参与感和投入感，单凭这一点，就足够让人选择它了。

上手使用建议

不过，Thariq Shihipar 也担心，很多人看完自己的观点后，会把它简单理解成一种新的“/html 技巧”或者固定提示词模板。

他强调，这件事其实没有大家想象得那么复杂，也不需要专门设计一套复杂 Prompt。

很多时候，你只需要直接告诉 Claude：“帮我生成一个 HTML 文件”，或者“生成一个 HTML 成品文档”，它就已经能很好地完成这件事。

真正关键的是想清楚这份 HTML 成品要实现什么功能、你会如何使用它。你后续可以慢慢沉淀出专属指令模板，但现阶段建议直接从零自然下达指令，慢慢熟悉在不同场景下该怎么运用。

应用场景

为了更具体地说明这一点，Thariq Shihipar 针对不同场景制作了多种 HTML 文件，给想要尝试的小伙伴提供参考，可以在此查看全部示例：https://thariqs.github.io/html-effectiveness/。

下面是整体概览。

规范、规划与探索

在 Thariq Shihipar 看来，HTML 本质上像是一块“更丰富的画布”，能让 Claude 更深入地进入问题本身。

他提到，自己现在处理问题时，已经很少再满足于一份简单的 Markdown 计划文档，而是更倾向于让 Claude 逐步生成一整套彼此关联的 HTML 文件。

例如：

• 一开始，他会先让 Claude Code 进行头脑风暴，探索不同方案，并生成对应的分析页面；
• 随后，再让它围绕其中某个方向继续展开，制作更详细的设计稿、Mockup，或者代码示例；
• 等到思路逐渐清晰之后，再让 Claude 输出最终的实现计划。

而当自己确认方案没问题后，他通常会重新开启一个新的会话，并把前面生成的这些 HTML 文件一并交给 Claude，让其直接进入实现阶段。

不仅如此，在验证环节，他也会让负责校验的 Agent 一起读取这些文件。这样一来，验证模型能够获得比传统 Markdown 文档更完整、更丰富的上下文信息，从而更准确地理解整个项目真正需要实现的内容。

示例提示词：

我不确定引导页该采用哪种方向，生成 6 种差异明显的方案——改变布局、语气和信息密度——并在一个 HTML 文件里用网格布局并排展示，方便我对比。每种方案都标注出它的取舍。

用 HTML 生成一份完整的实施计划，务必包含原型图、数据流展示和我需要审阅的关键代码片段，保证易读易懂。

使用案例以及适用场景：

• 探索代码的多种实现方式
• 探索多个视觉设计方案

代码评审与理解

代码在 Markdown 里很难阅读，但用 HTML 可以渲染差异对比、注释、流程图、模块结构图等。你可以用它理解 AI 生成的代码、完成代码评审，或是向他人解释你的 PR。

Thariq Shihipar 指出，这种方式比 GitHub 默认的差异视图更好用，现在他自己提交的每个 PR 都会附上一份 HTML 代码说明。

示例提示词：

帮我生成一份 HTML 文档来评审这个 PR，我不太熟悉流式处理/反压逻辑，请重点讲解这部分。渲染真实的代码差异，加上行内边注，按严重程度用颜色标注问题，并补充一切能把概念讲清楚的内容。

适用场景：

• 创建 PR
• 评审 PR
• 理解代码中的知识点

设计与原型

Claude Design 基于 HTML，因为 HTML 在设计表达上能力极强——即便你的最终产品不是网页。

Claude 可以用 HTML 画出设计稿，再转成你需要的语言，比如 React、Swift 等。

你还可以制作交互动效原型，比如动画、点击行为等。可以让 Claude 加上滑块、旋钮等控件，精确调到你想要的效果。

示例提示词：

我想做一个新的结算按钮原型，点击后播放动画并快速变成紫色。用 HTML 做一个带多个滑块和选项的页面，让我调试不同动画参数，并加一个复制按钮，把好用的参数复制出来。

适用场景：

• 生成设计系统产物
• 调整组件
• 可视化组件库
• 制作直观流畅的动画原型

报告、研究与学习

Claude Code 非常擅长整合多源信息，并转换成易读的报告。你可以让它检索你的 Slack、代码库、Git 历史、网络信息等，生成清晰易读的报告，供自己、团队或管理层使用。

输出形式可以是长文档、交互式讲解页，甚至幻灯片。可以让 Claude 用 SVG 做图表，让内容更直观。

比如写关于提示词缓存的文章时，可以让 Claude 读取 Git 历史，用 HTML 生成一份深度研究文件，汇总所有提示词缓存相关改动。

示例提示词：

我不懂我们的限流机制到底怎么运行。读取相关代码，用单个 HTML 页面讲解：包含 token-bucket 流程图、3–4 段带注释的关键代码，底部加一个“注意事项”部分。尽量让人读一遍就能懂。

适用场景：

• 总结功能运行原理
• 讲解技术概念
• 给上级的周报
• 给管理层的事故报告
• SVG 插图、流程图、技术图表等

自定义编辑界面

有些需求很难只用文字描述清楚。

这种情况下，Thariq Shihipar 透露，自己会让 Claude 为当前任务做一个一次性专用编辑器——不是产品，也不是通用工具，只是一个专为当前数据量身打造的 HTML 文件。

核心技巧是：最后一定要加导出功能。比如“复制为 JSON”“复制为提示词”按钮，把界面上的操作结果转成文本，贴回 Claude Code 继续使用。

示例提示词：

我需要重新排序这 30 个 Linear 任务。做一个 HTML 页面，每个任务是可拖拽卡片，分成“立即做/下一步/以后做/砍掉”四列。按你的判断预先排序，加一个“复制为 Markdown”按钮，导出最终顺序，并为每类任务写一句简要说明。

这是我们的功能开关配置，做一个表单编辑器，按业务分组展示开关，标明依赖关系。如果开启了依赖未满足的开关，给出警告。加一个“复制差异”按钮，只输出被修改的键值。

我在调试系统提示词。做一个左右分栏编辑器：左边是可编辑提示词，高亮变量插槽；右边是三个示例输入，实时渲染填充后的结果。加字符/Token 计数器和复制按钮。

适用场景：

• 排序、分类、归类任何内容（任务、测试用例、反馈）
• 编辑结构化配置（功能开关、环境变量、带约束的 JSO/YAML）
• 带实时预览的提示词、模板、文案调试
• 数据集筛选、审批、打标、导出选中项
• 文档注释、转录文本注释、差异注释并导出
• 选择难以用文字表达的参数：颜色、缓动曲线、裁剪区域、定时规则、正则表达式

关于 HTML 一些常见问题

随着这篇关于“从 Markdown 转向 HTML”的文章在开发者社区持续传播，Thariq Shihipar 也发现，越来越多人开始主动和他讨论这种工作流。

有人好奇：HTML 会不会让上下文变得更重？

也有人担心：生成这么多 HTML 文件，会不会反而增加复杂度？

还有不少开发者关心，HTML 到底只是“更好看”，还是它真的会改变 AI Agent 的协作方式。

针对这些高频问题，Thariq Shihipar 也在后续内容里集中给出了自己的解释与回应。

问：会不会更耗 Token？

Thariq Shihipar：虽然 Markdown 通常用更少 Token，但 HTML 表达力更强，我也更愿意去读，整体产出效果反而更好。Opus 4.7 支持 100 万上下文窗口，Token 增加几乎感知不到。

问：你现在什么时候还用 Markdown？

Thariq Shihipar：说实话，我几乎完全不用 Markdown 了，我可能算是极端的 HTML 拥护者。

问：怎么查看 HTML 文件？

Thariq Shihipar：我一般直接在本地浏览器打开（也可以让 Claude 帮你打开）；需要分享就上传到 S3 生成链接。

问：生成时间比 Markdown 更长吗？

Thariq Shihipar：确实更长！HTML 生成时间大约是 Markdown 的 2–4 倍，但我觉得效果值得。

问：版本控制怎么办？

Thariq Shihipar：这确实是 HTML 最大的缺点之一。HTML 的差异对比杂乱，比 Markdown 难审阅。

问：怎么让 Claude 做出符合我审美、不丑的页面？

Thariq Shihipar：前端设计插件能帮助 Claude 生成好看的 HTML。想匹配公司风格，可以让 Claude 读取代码库，生成一份设计系统 HTML 文件，之后用它作为参考生成其他页面。

保持参与感

Thariq Shihipar 表示，总而言之，自己使用 HTML 的真正原因是能更深度地参与到 Claude 的工作流程中。

“我曾经担心，因为不再深度阅读方案，我只能放手让 Claude 自己做决定。但现在我可以开心地说：用 HTML 时，我比以往任何时候都更有掌控感。希望你也能有同样的体验。”Thariq Shihipar 说道。

HTML 会去掉 Markdown 吗？

不过，围绕“用 HTML 取代 Markdown”这件事，开发者社区里也出现了不少不同声音。

一些网友担心，一旦开发流程开始全面转向 HTML，人类（也就是开发者自己）与大模型“共同编辑同一份文档”的能力，反而可能会被削弱。

如果生成的内容只是供自己阅读的说明页面，这当然问题不大；但在更复杂的项目里，很多开发者其实非常依赖一种能力——能够直接深入文档内部，对大模型生成的内容进行手动修改、补充和重构。

而这一点，Markdown 显然比 HTML 更轻量，也更直接。

相比结构复杂、包含大量标签与样式的 HTML，Markdown 更接近“可编辑文本”本身。开发者既能快速阅读，也能随时插入、删改内容，不需要额外处理布局和页面结构。

有人指出，虽然理论上完全可以重新给大模型发送 Prompt，让它帮忙修改 HTML 内容，但现实问题在于：当开发者自己脑海里已经非常清楚该怎么表达时，再通过 Prompt 中转一次，反而会让修改路径变长，甚至打断思路。

也正因为如此，一些人开始担心：如果“默认输出 HTML”逐渐成为主流，人和大模型之间原本那种“共同创作”的模式，或许会进一步弱化。

过去，开发者更像是在和 AI 一起写文档；但未来，大家可能会越来越倾向于把语气风格、内容组织、视觉布局，甚至表达方式本身，全都直接交给大模型决定。

还有网友提出了一个更现实的问题：

“手写 HTML 这件事，人类已经干了几十年了。但并不是所有软件工程师，都是前端开发者。”

换句话说，HTML 的优势，很大程度上建立在“视觉化输出”之上；可一旦开发者需要亲自修改、维护、协作这些内容时，它会不会又重新变成一种新的复杂性？

那么，你是否已经尝试过让 AI 使用 HTML 作为输出格式？相比 Markdown，它的体验到底是更进一步，还是只是“看起来更高级”？而在 AI Agent 时代已经到来的今天，Markdown 真的会因此逐渐退出历史舞台吗？

欢迎分享你的看法。

参考：

https://thariqs.github.io/html-effectiveness

https://x.com/trq212/status/2052809885763747935

https://news.ycombinator.com/item?id=48071940

https://simonwillison.net/2026/May/8/unreasonable-effectiveness-of-html/

本文来自微信公众号“CSDN”，编译：苏宓