为什么在 Claude Code 中应使用 HTML 而非 Markdown：来自 Anthropic 的见解

"AI 写的东西太长了，我根本不会认真看 😅"

"我每个月为 Claude Code 支付超过 15000 日元，但感觉没值回票价。"

很多人只是满足于自己用了 AI，但只有少数人真正把它转化成了成果。这是一种"感觉像是用过了"的状态。

你在使用 Claude Code 时有过这些经历吗？

周一早上让它"总结上周的竞品趋势"，它返回一份长篇报告。你扫了一眼，就放着没读。
你怀疑，如果你自己都没认真看 AI 生成的材料，那你的团队成员肯定也不会看。
你每月为 Claude Code 支付超过 3000 日元，但输出的内容从未在会议或提案中被使用过。
ChatGPT 和 Claude.ai 的输出看起来很漂亮，但为什么 Claude Code 只输出 Markdown，读起来那么累？

这篇文章就是为这些人准备的。

读完之后，你将能够自然地从 Claude Code 生成你和别人都会真正阅读的材料。

你还会获得一个视角："以什么格式输出" 比 "让 Claude Code 做什么" 更能影响用户的判断。

Anthropic 的开发者 Thariq Shihipar（@trq212）——他实际上在构建 Claude Code——在 X 上写了一篇关于公司内部正在蔓延的一种思维方式的文章，它已经成为 Claude Code 社区中保存和分享最多的帖子之一。

发布后立即获得了巨大反响。

这不仅仅是给 AI 极客的小技巧；这是一个关于构建该工具的人挑战 Markdown（AI 行业默认的标准）的故事，他说"这不再是正确的方式了"。

我认为这很重要，所以决定立即用中文解释一下。

开始阅读前有两件事：

收藏这篇文章。就在这周，留出一些时间尝试用 HTML 输出。
如果你的团队成员在使用 Claude Code，把这篇文章分享给他们。从下周开始，你的周报和 PR 审查被"阅读"的方式将发生明显变化。

我会在翻译内容的同时，结合日本商业场景进行拆解和解释👇

原帖在这里：

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

Anthropic 开发者本人已不再使用 Markdown

这是起点。写原帖的 Thariq Shihipar（@trq212）是在 Anthropic 构建 Claude Code 的开发者。Claude 在"计划模式"中向用户追问以细化需求的行为，就是他亲自实现的功能。

他说他不再接受他自己构建的工具输出的 Markdown。用他自己的话说，Markdown 对他来说已经成为一种限制性的格式。

这不仅仅是个人偏好。Thariq 提到，在 Claude Code 团队内部，HTML 的使用正在普及。构建工具的人正在放弃它产生的 Markdown，转而使用 HTML。

而且有证据可以触摸。在演示网站 https://thariqs.github.io/html-effectiveness/ 上，有 20 个独立的 HTML 示例。三种防抖搜索方法的对比、完成任务时创造成就感的微交互、设计系统令牌列表、代码示例的标签式解释、以及带有边栏术语表的阅读材料。所有这些都真实地展示了如何将"你只是扫一眼的文档"替换为"你会读到最后的文档"。你现在就可以在浏览器中打开它们。

读到这些，你应该意识到一件事。你通常在 ChatGPT 或 Claude.ai 中收到的 Artifacts——那些"带有标签的 UI"、"彩色图表"和"交互式按钮"——实际上是以 HTML 输出的。这里的领悟是："它们看起来那么好的原因，在于格式本身的差异。"现在，同样的世界可以通过 Claude Code 带到你的指尖。

到目前为止，AI 生成的文本几乎完全是 Markdown。构建它的人正在悄悄地开始反对，说"不再是这样了"。这是新闻的核心。但对于每天使用 AI 的你来说，这是一个从周一早上开始就会见效的故事。

Markdown 曾是 AI 行业的默认标准

让我们确认一下我们习以为常的假设。没有这个，切换到 HTML 可能看起来只是品味问题。

直到现在，Markdown 一直是 AI 输出的事实标准。回想一下你每天看到的文本：

项目根目录中的 CLAUDE.md，Agent 定义的 *.md，技能的 SKILL.md。
Anthropic 的官方文档、Claude.ai 帮助以及各种 Claude Code 指南。
竞品 AI 开发工具、Cursor 规则、GitHub Copilot 指令和 Cline 指令都基于 .md。
内部 Wiki、GitHub README、从 Notion 导出的文本、粘贴到 Slack 的会议记录。
从 ChatGPT 聊天中复制的摘要文本。

一切都建立在 Markdown 的假设之上。在处理 AI 时，你遇到的文本信息中很难找到 Markdown 以外的格式。

Karpathy 的 CLAUDE.md 模式在 GitHub 上获得超过 80000 颗星的现象，正是因为 Markdown 是行业的通用语言。

用 Thariq 的话来说，Markdown 已经成为 Agent 的主流格式。他是在 Markdown 前提下构建工具很长时间的人。

那个人现在明确表示：Markdown 对我来说已经成为一种限制性的格式。这是 Anthropic 内部人士向整个行业所依赖的前提投下的一块石头。

简单来说：你从 Claude Code 得到的 Markdown、Cursor 读取的规则、以及你内部 Wiki 上的 AI 输出，都属于同一个"Markdown 就行"的流程。创造它的人已经开始绘制不同的渠道。

接下来，我们将深入探讨为什么 Markdown 无法触达用户，以及用什么来替代它。

Markdown 不被阅读的 5 个原因

让我们整理一下 Markdown 的局限性。这不是关于技术规格，而是关于你从周一到周五的日常体验。我通过反转原文中 HTML 的优势，列出了 Markdown 的弱点。

① 超过 100 行，连你都不会读

Thariq 本人写道，当 Markdown 文件超过 100 行时，他就停止阅读了。

当你让 Claude Code "总结上周的竞品趋势"时，你可能有过关闭 120 行响应而不滚动的经历。如果生成它的人都不读，团队里没人会读。现实是，不仅是作者，组织中的其他成员也只是在略读。

② 即使分享，在浏览器中打开也不美观，所以没人碰

Markdown 在浏览器中本身渲染得并不美观。在 Slack 中换行会乱，在邮件中格式会乱，要转换成 PDF 或截图用于提案需要花功夫。

每次分享时，总得有人把它转换成"可读的形式"。Markdown 是一种每次分享都会产生摩擦的格式，以至于链接常常甚至不被点击。

③ 没有颜色或图表，所以只能传达大纲

你想强调数字上的差异，用红色显示警告，或用箭头显示流程。在 Markdown 中要做到这些，你最终会用 ASCII 字符画图或用 Unicode 制表符表示颜色。

没人想解读这些，写的人也累。即使 Claude 努力画图，最终也会被略过。

④ 无法触摸或移动，所以只能止步于阅读

你想试试稍微柔和一点的颜色，测试动画的速度，或者看看把数值增加 1.5 倍会怎样。

在商业中，经常需要"试一试"才能做出判断。Markdown 做不到这一点。你阅读，在脑海中模拟，然后通过文本发回指令——这是一个低效的循环。

⑤ 在手机上打开时会乱

在移动中打开 Slack、邮件或 Notion。在日本商业场景中，一半的共享材料首先是在手机上打开的。

Markdown 布局不会跟随屏幕宽度。表格水平溢出，代码块换行混乱，标题层级不可见。阅读的欲望在那一刻就消失了。

让我们给这个起个名字。每次你产生不可读的 Markdown 时，发送方和接收方在打开之前就已经积累了疲劳。滚动 100 行的成本、在 Slack 中修复换行的成本、由于缺乏图表和颜色导致的沟通失败、因为无法交互而导致的判断延迟、以及在手机上显示错乱的成本。

所有这些都是每天支付的隐藏费用。在这篇文章中，我们称之为 "格式税"。

这不是一笔小税。Claude Code 价值的一半以上不是由输出的内容决定的，而是由"它能触达谁以及触达多远"决定的。通过以无法触达用户的格式输出，你基本上浪费了一半的订阅费。

如何切换：只需添加"输出为 HTML 文件"

你不需要想得太复杂。要做的事情比你想象的要少得多。

只需在你通常的 Claude Code 请求末尾添加一行。以下三种说法意思相同：

"输出为 HTML 文件"
"输出为单页 HTML"
"做成 HTML，让读者可以直接打开"

如果你觉得用英文写更舒服，"make a HTML file" 或 "make a HTML artifact" 也可以。结果是一样的。

Claude Code 可以从 MCP、浏览器、git 和文件系统中拉取上下文。Claude Code 的优势在于，它可以将比 ChatGPT 或 Claude.ai 的网页聊天版本更广泛的信息源打包到一个 HTML 中。

这又回到了我们之前讨论的内容。你在 ChatGPT 或 Claude.ai 中收到并认为"漂亮"的 Artifacts，都是以 HTML 输出的。

你现在可以在 Claude Code 端接收到同样的世界。这不是一个困难的技术故事；通过改变提问方式中的一行，真正能触达用户的材料就会出来。

Thariq 在他的文章中强调了一点："我不希望这被做成一个 /html 技能；我希望人们先通过提示词来习惯它。"尽管他是 Claude Code 团队中制作技能的开发者。

他并不是否定将其做成技能。他说的是："如果在用法固化之前就打包，你会错过真正有效的部分。"

在 Anthropic 内部，已经变得频繁的 HTML 输出开始被组件化为 Playground 插件之类的东西。与其一开始就等待一个成品，不如先用一行提示词尝试，找到适合你工作的模式。只有达到那个点之后，才应该转向将其做成技能。

在每个提示词中写"输出为 HTML"可能看起来像一项任务，但选择格式本身并不是任务。从 Claude 输出 Markdown 切换到 Claude 输出 HTML 的那一刻，你已经向"在等待预先设计的技能之前设计输出"的人迈进了半步。

仅通过切换到 HTML 就能改变的 5 个业务场景

本章对从周一到周五的实际工作有效。我按照在日本商业场景中出现的频率重新排列了原文中的五个用例：周报/研究摘要、提案的并行比较、设计调整、决策编辑屏幕、以及 PR/规格审查。

每个场景都总结了当前问题、Before/After，最后给出了给 Claude Code 的示例指令。

[场景 1] 用图表交付周报和研究摘要

日本商业中的常见情况。周一早上，你的老板说："总结一下上周的趋势。"

Before：你将 120 行 Markdown 粘贴到 Slack 中。换行乱了。你老板没打开。它没有被纳入管理会议材料。你最终口头解释："我让 Claude 做的。"

After：你将 Slack 日志、Linear 或 Notion 工单历史、git 日志和内部文档整合到一个 HTML 页面中。使用 SVG 包含一个简单的业务流程图，并在底部用彩色块放置三个关键点。

如果你把它放在内部存储中并分享 URL，你老板可以在通勤时用手机打开，管理层可以引用它，还可以粘贴到会议记录中。

这里的关键是 Claude Code 可以从 MCP、浏览器、git 和文件系统中拉取上下文。即使你让网页聊天"做一个 HTML"，也很难将这么多信息源打包到一个文件中。这是只有 Claude Code 才能创建的周报。

Thariq 本人写道，他通过让 Claude Code 读取他代码文件夹中的所有 HTML 并将它们总结到一个页面中，来制作他文章的图表。一份"会被阅读的周报"和一份"会被阅读的解释性文章图表"在结构上是相同的。

▼ 示例指令：

"读取上周所有的 Slack 互动、Linear 工单完成情况和 git 日志，输出一份我老板能在 1 分钟内掌握的周报，作为单个 HTML 页面。用 SVG 包含一个简单的业务流程图，并在底部用彩色块放置三个关键点。确保在智能手机上打开时不会乱。"

[场景 2] 并排展示 6 个提案/研究选项

下周的提案应该走哪个方向？在策划、销售和企业规划中，经常需要创建多个选项并与决策者对齐。

Before：你将六个选项分别放在六个 Markdown 文件中发送。客户无法逐个打开并比较。他们问："你的首选推荐是哪个？"你才意识到你自己也没有完全比较过。

After：你将六个具有不同语气、密度和目标受众的选项排列在单个 HTML 页面的网格中。在每个选项下添加一行权衡说明。决策者在一个屏幕上比较所有选项，并立即回应："我想混合这个和这个"或"使用 #3 的目标受众和 #1 的密度。"当你并行展示时，讨论的解决速度就改变了。

对于决策者来说，接收六个文件和在单个屏幕上看到六个选项所需的判断时间是天壤之别。这与其说是"让他们阅读"，不如说是"让他们能够做出决策"。

▼ 示例指令：

"为下周的演示创建 6 个提案选项，具有不同的语气、密度和目标受众，并将它们排列在单个 HTML 页面的网格中。在每个选项下写一行权衡说明。同时，在底部添加一个按钮，一旦做出决定，可以将结果复制为 Markdown。"

[场景 3] 通过触摸来决定设计和原型

当决定颜色、大小或动效时，你应该放弃通过文本来对齐。这是营销、公关和策划在感谢邮件或落地页按钮上反复来回的场景。

Before：你用"稍微柔和一点的蓝色"或"让动效更流畅"这样的词语沟通。接收者的想象每次都偏离。看到一轮后回来的版本，你添加更多词语："不，不是那种柔和。"

After：你让 Claude Code 创建一个 HTML，其中你可以通过滑块调整颜色和动画速度。你为感谢邮件按钮或 LP CTA 按钮创建原型作为单个 HTML 页面，并将 URL 发送给利益相关者。每个人都可以触摸它，决定最佳值，然后将这些值复制回 Claude。文本来回减少，达成一致的时间缩短。

与此相关，Anthropic Labs 开始将这种"触摸决定并将操作复制回 Claude"的概念正式化为 Playground 插件。HTML 输出不仅仅是一个小技巧；它是 Anthropic 本身正在作为一种模式培养的方向。

▼ 示例指令：

"创建一个 HTML，让我可以通过三种类型的滑块来决定感谢邮件中按钮的颜色和动画速度。在底部添加一个按钮，用于复制已决定的值。"

[场景 4] 在 3 分钟内制作一个判断屏幕

哪些措施应该分配给 Now、Next、Later 或 Cut？整理 30 个工单来决定优先级是 PdM、策划和企业规划的典型"判断任务"。

Before：你在电子表格中排列 30 个项目，并手动逐个填写优先级列。你排序、重新思考、移动到另一个工作表、再移回来。有些日子你花了 30 分钟还没有结论。

After：你让 Claude Code "创建一个 HTML，让我可以将项目拖放到四个列中：Now、Next、Later 和 Cut。"一个专用的编辑屏幕在 3 分钟内就准备好了。你拖动 30 张卡片，完成后复制结果。判断任务的时间缩短了一个数量级。

这里有一个容易被忽视但非常有效的设计原则。就是 Thariq 写的那句话："始终以导出结束。"在制作编辑屏幕时，始终包含"复制为 JSON"、"复制为提示词"或"复制为 Markdown"的按钮。

没有这个，你就无法将排序结果返回给 Claude，它最终只是一个任务工具。只有当你在 HTML 中判断，然后将结构化文本结果返回给 Claude 时，编辑屏幕才成为一个判断装置。

同样的想法可以用于编辑功能标志、并排系统提示词编辑器、或数据集批准/拒绝/标记。"在 3 分钟内创建一个专用的、一次性的 UI"是 Claude Code 真正价值最清晰的体现。

▼ 示例指令：

"创建一个 HTML，让我可以将下个季度的 30 项措施拖放到四个列中：Now、Next、Later 和 Cut。最后，放置一个'复制为 Markdown'按钮，以便我可以输出每项排序结果及其原因。"

[场景 5] 用颜色编码的差异来交接 PR 审查和规格共享

最后，是与工程师协作的场景。即使你不读代码，作为 PdM、总监或编辑，你可能被叫来参与 PR 审查或规格确认。

Before：你被要求打开 GitHub 差异屏幕。仅通过查看，你无法判断差异的哪一部分重要、哪一部分可以忽略。你必须阅读评论才能跟上故事。不读代码的人通常只会说"有什么情况告诉我"然后关掉。

After：你让 Claude Code "将这个 PR 变成一个 HTML 审查文档，让不读代码的人也能在 30 秒内掌握。"在差异旁边附加评论，用颜色编码显示影响范围，并在最后总结三个关注点。如果你将其上传到内部存储并分享 URL，PdM 和总监可以一键提供反馈。与工程师协作的人终于可以参与审查了。

HTML 不是工程师的语言；它是传递故事的工具。差异的含义、风险和影响范围——这些"需要解读的信息"通过注释、颜色和布局来传递。这就是 HTML 转换的意义。

▼ 示例指令：

"将这个 PR 变成一个 HTML 审查文档，让不读代码的人也能在 30 秒内掌握。在差异旁边附加评论，用颜色编码显示影响范围，并在最后总结三个关注点。"

当你继续在这五个场景中输出 Markdown 时，格式税正在悄悄地但每天都在累积。你是否在注意到它的那一刻就停止，将是下周开始的分水岭。

切换时产生的 6 个问题

读到这里，你可能会想到几个问题。我按照日本商业读者可能遇到的顺序重新排列了原文中的 FAQ 部分。

■ 它会消耗更多 Token 吗？

是的，会。原文指出，生成时间比 Markdown 长 2-4 倍。然而，Opus 4.7 拥有 100 万 Token 的上下文，因此由于返回 HTML 导致对话因上下文限制而中断的风险几乎消失了。

Thariq 的结论是："数字增加了，但如果你选择被阅读的结果，它对总工作量来说是值得的。"这是一个选择：是用你每月 3000 多日元的合同来生成 1000 行无人阅读的 Markdown，还是一页会被打开的 HTML。

■ 设计会不会很丑？

这是一个合理的担忧，但有应对措施。

一种是使用 Claude Code 的前端设计插件。另一种是向 Claude 提供你公司网站或现有材料的 HTML 样本。如果你提供一个参考文件并说"用这种语气"或"用这种字体和调色板"，Claude 会输出与你公司外观匹配的 HTML。在你的代码库中保留一个类似 design-system.html 的文件，这样每次都可以引用它。

■ 编辑 HTML 不是很麻烦吗？

你不需要自己编辑。

Thariq 本人写道，他不直接碰 HTML。如果你告诉 Claude，"把这个颜色调柔和一点"或"把第三部分缩小一点"，它会帮你修复。只要你用它来做规格、头脑风暴或参考材料，你可以把所有编辑工作留给 Claude。

■ 如何打开它？如何分享它？

打开很容易。只需在浏览器中本地打开 Claude Code 生成的 HTML 文件。

你甚至可以让 Claude "打开这个文件"，它可能会在你的浏览器中为你打开。分享时，最简单的方法是将其上传到内部存储或 S3，并提供 URL。如果你在 Slack 或邮件中粘贴链接，接收者可以在他们的浏览器中打开。将 Markdown 转换为 PDF 的额外步骤完全消失了。

■ 版本控制怎么办？

老实说，HTML 不太适合 Git 差异管理。修复一行可能会因为格式化设置而移动其他地方的差异。Thariq 本人写道，HTML 是版本控制的最大弱点。

因此，实用的解决方案是："给人看的交付物"用 HTML，"想保留历史的规格或记录"用 Markdown。这不是废除 Markdown，而是切换到根据输出目的选择格式的心态。

■ 我可以完全停止使用 Markdown 吗？

不。记录、变更历史以及你想保留在仓库中的结构化文本应该保持为 Markdown。

CLAUDE.md 和 SKILL.md 如果保持为 Markdown，更容易管理和跟踪差异。HTML 适合"交付给人"、"让人触摸"、"排列多个选项"和"让人用颜色判断"。如果你大致理解为"与 AI 交互用 Markdown，分发给人类用 HTML"，你就不会迷失。

到现在为止，你最初的疑虑应该已经消除了。一篇包含缺点的文章更值得信赖——这是我作为写作者的信条。

你是继续支付格式税，还是转向设计侧？

最后，让我们提升视角来收尾。

我们之前讨论过"提示税"——在 Claude 中重复输入相同前提的成本。然后，我们谈到了使用 .claude 文件夹进入设计层的故事。这个"格式税"是该系列的第三个主题。在对话层和设计层之后，我们现在解决了输出层的问题。

让我们定义一下"格式税"，以便与读者分享：

如果你一直选择没人看的输出格式，疲劳感会在打开之前就累积起来，对你和他人都是如此。你每月为 Claude Code 支付超过 3000 日元，但交付物从未在会议上被使用。这种感觉源于没有对格式选择做出判断。这就是格式税。

用 Markdown 输出是一项任务。选择 HTML 是一个判断。即使使用同样的 Claude Code，格式选择上的一个判断也会显著改变交付物所能触及的距离。

而且 HTML 不是工程师的语言。它是创建能被阅读的材料的工具。暂时放下构建网站的想法。只需尝试用 HTML 输出你这周要写的周报、提案或评审文档。这就够了。

让我们谈谈更大的图景。

Markdown 作为 AI 行业隐含标准的时代正在 Anthropic 内部悄然结束。虽然 CLAUDE.md、SKILL.md 和 Cursor 规则都建立在 Markdown 的前提上，但输出格式已经开始率先切换。见证标准变化时刻的读者可以领先半步。

当然，一旦你意识到"我每周都做这个"，你就可以选择将其演变成一个技能。

在 Anthropic 内部，像设计相关的 Playgrounds 这样频繁使用 HTML 输出的模式正逐渐被培育成组件。不过，对于第一周来说，一行提示就足够了。今晚，尝试只用 HTML 输出一份周报。下周，尝试在一个网格中排列六个提案选项。从那里开始，格式税就会悄然开始减少。

Thariq 本人在文章结尾写道："我曾担心停止深入阅读 Markdown 并将判断完全交给 Claude。自从切换到 HTML 后，我感觉自己更多地回到了与 Claude 的互动循环中，而且最重要的是，创作本身变得有趣了。"

选择格式是一个开关，让你在与 AI 合作时重新掌握主动权，同时也是一个为日常工作增添一点热度的开关。

你是要继续产出无人阅读的 Markdown，还是转向选择格式的一方？接下来的一周将是分界线。

总结

在 Anthropic 开发 Claude Code 的开发者宣布他不再使用 Markdown。HTML 的采用正在内部团队中蔓延。
直到现在，Markdown 一直是 AI 的隐含标准——从 Claude Code 和 Cursor 到 GitHub Copilot、Cline、内部 Wiki 和 ChatGPT 输出。现在，创造者挑战了这一行业标准。
Markdown 不被阅读有 5 个原因：超过 100 行难以重读 / 分享时格式错乱 / 没有颜色或图表 / 无法触摸判断 / 在移动端显示异常。这些隐藏成本就是"格式税"。
要切换，只需添加一行："输出为 HTML 文件。" 将其变成技能可以等到用法稳定之后。
5 个商业场景——周报、并行提案、设计调整、判断屏幕和 PR 评审——只需切换到 HTML，就能转变为被打开、被判断和被返回的材料。
选择格式是一个判断，而不是一项任务。用 Markdown 输出是一项任务；选择 HTML 是一个判断。Claude Code 用户之间的差距就在这里拉开。

如果你觉得这篇文章有帮助：