突然觉得，你的常识今天要崩塌了。说实话，99% 的人还在用 Markdown 搭配 Claude Code。Anthropic 的 Claude Code 团队内部人员说了这么一句话：“快停下。”他说：“用 HTML 代替 Markdown 输出，效果完全碾压。”
因为随着 Claude Code 的输出越来越复杂，Markdown 不仅难读、难传达，而且很难分享。
而用 HTML 呢：
- 可以画图
- 可以分颜色
- 可以用标签页组织
- 甚至能做滑块和按钮
- 还能直接在浏览器里分享
换句话说，要让 Claude Code 发挥真正价值，重要的不只是“你输出什么”，而是“你用什么格式输出”。
我敢这么说：
在 Claude Code 时代，最优解不是 Markdown，而是 HTML 优先。
事实上，早在本文发布之前，ClaudeCodeStudio 就已经在利用这个方法，让幻灯片材料一次输出就达到这种质量 👇
如果你坚持读到最后，我想你就能理解为什么能做到这样了，请务必看完！
话说回来，你有没有遇到过这种情况？
- 让 Claude Code 写了个计划，结果超过 100 行就失去兴趣了
- 把 Markdown 规格说明分享给团队，结果没人读完
- 看着 ASCII 艺术图，心想“……这是啥？”
- 想用颜色或版式整理信息，但 Markdown 表达不了
- 把计划粘贴到 Slack 里，结果被当成附件沉了
所有这些问题，都是“输出格式的问题”。
Claude Code 开发团队的一员 Thariq（@trq212）写的文章《Using Claude Code: The Unreasonable Effectiveness of HTML》正在 X 上爆火，浏览量超过 1100 万 😳
Thariq 是 Anthropic 的 Claude Code 团队成员，也是 YC W20 的工程师。换句话说，就是一位每天都在一线使用 Claude Code 的人发出了“我不用 Markdown 了”的宣言。
这次我会结合具体提示示例，把内容讲得通俗易懂 👇
原文在此：https://x.com/trq212/status/2052809885763747935
■ Markdown 有什么问题？
多年来，Markdown 一直作为 AI 代理和人类之间的沟通工具。它简单、随处可用，还能写出一定程度的富文本。Claude Code 默认也是用 Markdown 输出。
但说实话，是不是觉得很熟悉？
随着 Claude Code 能处理的任务越来越复杂，它输出的计划和规格说明也越来越长。你真的会读完一份超过 100 行的 Markdown 文件吗？
Thariq 在文章中写道：
“我发现超过一百行的 markdown 文件很难读下去。”
而且现在，我们甚至自己手动编辑文件的机会也越来越少了。更多是把它当作规格说明的参考，或者头脑风暴的输出。就算要编辑，也是让 Claude 来“帮我改一下”。也就是说，Markdown 最大的优点——“方便人类手动编辑”——已经没意义了。
这段话一针见血，把很多 Claude Code 用户潜意识里感受到的问题说清楚了。
■ 为什么 HTML 选项“效果非常强大”
Thariq 提出的方案是：把 Claude Code 的输出格式从 Markdown 改成 HTML。
你可能会想：“HTML 不是用来做网页的吗？”但 HTML 的表现力是 Markdown 没法比的。
来看看 HTML 具体能表现什么：
- 用表格展示结构化数据
- 用 CSS 做设计和颜色
- 用 SVG 做插图和图表
- 用 script 标签展示代码片段
- 用 JavaScript 和 CSS 实现交互
- 用 SVG + HTML 做流程图
- 用绝对定位或 canvas 展示空间数据
- 用图片标签嵌入图片
Thariq 断言：
“我敢说，Claude 能读取的任何信息，几乎没有不能用 HTML 高效表达的。”
如果你曾经让 Claude 画 ASCII 图表，或者用 Unicode 字符表示颜色，你就明白这句话的分量。你将摆脱那种“开法拉利去便利店”的低效。
■ 信息密度天差地别
HTML 最大的优势就是“信息密度”。
同样的内容，用 Markdown 和 HTML 分别写，HTML 能传达多得多的信息，而且更容易阅读。可以用标签页切换、用颜色区分、或者嵌入图表。
哪怕你不想读 100 行的 Markdown，但同样量的信息用 HTML 配合标签和颜色组织好，就能直接印入脑海。
这不只是“外观问题”。一份没人读的规格说明，跟不存在一样。用容易被阅读的格式输出，直接关系到工作质量本身。
■ 易于分享
如果你想跟别人分享 Markdown 文件，通常流程是这样的：
- 在 Slack 里作为附件发送 → 没人打开
- 在邮件里附件 → 没人打开
- 放到 GitHub 上 → 非工程师没法访问
而 HTML 呢，上传到 S3 然后发个链接就行。有浏览器的人都能看。还能做成响应式，方便在手机上阅读。
Thariq 的原话：
“如果规格说明、报告或 PR 描述用 HTML 写，别人真正去读的概率会高非常多。”
这是一个细微但实际工作中至关重要的点。
■ 双向交互的革命
这才是 HTML 的真正厉害之处。
HTML 不只是用来“读”的。它可以操作。
比如做设计的微调。让 Claude Code 输出“一个带滑块的 HTML 文件”，它就会生成一个文件，你可以实时调节动画速度、缓动效果和颜色。找到喜欢的参数后，按一下“复制”按钮，再粘贴回 Claude Code 就行。
这种双向交互，让精细度达到了单靠文字提示永远无法企及的水平。
你再也不用为“再往右一点”、“再快一点”、“不是这个颜色”这种描述而烦恼了。直接拖动滑块就好。
■ 具体使用案例（附提示示例）
Thariq 在文章中通过具体的提示示例，介绍了 HTML 的利用模式。这些示例非常实用，我这里直接搬过来。
𝟭. 设计、规划与探索
当你在 Claude Code 中处理复杂任务时，不要只用一个 Markdown 计划，而是用多个 HTML 文件来撒开一张“探索网”。
提示示例：
“我在 onboarding 屏幕的方向上拿不定主意。请生成 6 种完全不同的方案，在布局、色调和信息密度上做变化，并放在一个 HTML 文件里用网格排列，方便我对比。给每个方案贴上优缺点标签。”
“创建一个详细的实施计划 HTML 文件。包含模拟图、数据流和需要审核的关键代码片段。让内容易于阅读和理解。”
𝟮. 代码审查与理解
可以创建比 GitHub 的 diff 页面更容易阅读的代码审查。
提示示例：
“创建一个 HTML 产物来审查这个 PR。我对 streaming/backpressure 逻辑不熟悉，请重点关注。渲染实际的 diff，并在行内添加边距注释，按重要性用颜色区分。”
Thariq 写道：“现在，我的每个 PR 都会附带一个 HTML 格式的代码说明。”
𝟯. 设计与原型
就像 Claude Design 的基础是 HTML 一样，HTML 在设计表达上极其擅长。即使最终实现是用 React 或 Swift，先用 HTML 画草图再重写的流程也很高效。
提示示例：
“我想做一个新的结算按钮原型。点击时按钮应动画变为紫色。创建一个 HTML 文件，让我可以用滑块和选项来尝试每个动画参数。包含一个复制按钮，用于复制效果好的参数。”
𝟰. 报告、研究与学习
Claude Code 很擅长跨多个数据源综合信息，并总结成易读的报告。可以让它搜索 Slack、代码库、git 历史和互联网，来创建领导报告或事故报告。
提示示例：
“我不理解限流器的工作原理。请阅读相关代码，并创建一个 HTML 说明页面。包含令牌桶流程图、3-4 个带注释的关键代码片段，最后加一个‘易踩坑’部分。优化成一次阅读就能理解。”
𝟱. 自定义编辑界面
这个用例对我来说最震撼。用一次性的 HTML 编辑器，实现那些很难用文本框描述的操作。
提示示例：
“我想重新排列 30 个 Linear 工单的优先级。创建一个 HTML 文件，每个工单是一张可拖拽的卡片，并分成四列：现在 / 下一个 / 以后 / 砍掉。先根据你的推测排序。包含一个‘复制为 Markdown’按钮，导出最终顺序，并为每个分类写一行理由。”
“我在调整这个系统提示。创建一个并排编辑器。左边是可编辑的提示（高亮变量插槽），右边是三个示例输入，让模板实时反映变化。包含字符/令牌计数器和复制按钮。”
这个想法是不是很赞？按需生成必要的 UI，只为了当前这个任务。不需要复用，不需要完美。但比单纯用文字做效率高 100 倍。
■ 常见问题解答
Thariq 在文章中还回答了关于 HTML 的常见问题。
“这样不会消耗更多令牌吗？”
→ 确实比 Markdown 用得多。但考虑到表现力和“实际被阅读的概率”，总体上是高效的。Opus 4.7 的 100 万令牌上下文，多出来的部分根本不算什么。
“生成时间不会变长吗？”
→ 比 Markdown 多花 2-4 倍时间。但 Thariq 本人觉得结果值得。
“版本控制怎么办？”
→ 这确实是个缺点。HTML 的 diff 噪音比 Markdown 多，审核起来更麻烦。目前这是 HTML 最大的短板之一。
“设计出来会不会很丑？”
→ 用 Claude Code 的前端设计插件就能改善。另外，让 Claude Code 读取你公司的代码库，创建一个“设计系统 HTML 文件”，之后以此为参考，就能统一风格。
■ 为什么是“现在”？
这篇文章之所以有共鸣，是因为时机正好。
现在 Claude Code 能够处理复杂任务，输出内容又长又密集。继续用 Markdown 这种“只比纯文本好一点”的格式来接收，已经成为瓶颈。
Thariq 的结论是：
“用 HTML 时，我感觉自己比以往任何时候都更掌控全局。”
不是把一切交给 Claude Code，而是通过 HTML 输出，形成“人类理解、判断、反馈”的循环。这才是与 AI 协作的本质。
■ 实践要点总结
- 不需要什么复杂技巧或设置。直接告诉 Claude Code “生成一个 HTML 文件”就行。
- 一开始不需要做成技能文件。先用原始提示试试。
- 从“想让别人读的东西”开始，比如计划、审查、报告、原型。
- 有意识地加入“交互性”，比如滑块和复制按钮，效果翻倍。
- 生成的 HTML 在浏览器里打开，或者上传到 S3 分享。
Markdown 并不差。但既然 Claude Code 的输出已经进化到这种程度，接收端也该升级了。
下次让 Claude Code 做计划时，试着加一句：“用 HTML 做。”你一定会惊讶于其中的不同。
如果你觉得这篇文章有那么一点帮助：
𝗖𝗹𝗮𝘂𝗱𝗲 𝗖𝗼𝗱𝗲 𝗦𝘁𝘂𝗱𝗶𝗼 @ 𝗝𝗮𝗽𝗮𝗻（@ClaudeCode_love）
是一个由三位 Claude Code 爱好者运营的账号。
我们每天发布关于 CLI 实战应用和自动化的内容。
目前正在与一家上市公司共同开发 AI 代理。
我们的日常推文 👇
- 使用 Claude Code 和 Claude 的实际产品开发案例
- 整理 Claude Code 应用 / Vibe Coding / 开发趋势
- 海外 Claude Code 的最新信息
从开发理念到设计、实施和改进，
我们不只是“做完”，而是提炼海外和一手信息，直到能发布一个可用的产品。
如果你感兴趣，请关注我们 👀 我想一定会有帮助！
