日前， Anthropic Claude Code 团队成员 Thariq Shihipar在 X 发了个小作文《Using Claude Code: The Unreasonable Effectiveness of HTML》，瞬间被 900 万 人围观。
当下，Markdown是AI Agent 与人沟通的主流格式，但Thariq 指出，AI能力变强后，Markdown已成束缚，应改用HTML作为AI输出的格式。
他直言：“我渐渐觉得，Markdown 已经成了一种受限的格式”，超过百行的Markdown“可读性极差、分享不便、缺少交互”，且如今多由AI编辑，其易用优势已失效。
Thariq还列出了HTML 的四大不可替代优势，如信息密度更高、视觉清晰易读、分享便捷、支持双向交互，可承载表格、SVG、交互控件、自定义编辑器等复杂内容，还能读取全量代码、Git、项目工具上下文。
他直言：“几乎没有任何 Claude 能够读取的信息，是你无法用 HTML 相当高效地呈现出来的”。
文中还给出了实操用法，可用于方案规划、代码评审、原型设计、自定义编辑界面等场景。
尽管HTML生成耗时是Markdown的2–4倍、版本对比困难，但他认为，“和 Claude 协作时，我能更好地掌握整体情况、实时把控进度”，值得切换。
Thariq说，他已经几乎停止为所有内容编写 Markdown 文件，转而使用 Claude Code生成 HTML，“HTML 是新的 Markdown”。
对此，很多人表示认同。比如，有网友说，“HTML 很重要，因为人类是视觉动物”。
有网友说，“现在我明白为什么 Claude Design 使用 HTML 作为默认格式了”。
但也有不同看法。比如，有行业人士只“部分同意”，认为 HTML非常适合用于原型、模型、测试和预览，但 Markdown 在文本导向的内容方面更胜一筹，如代码、计划，“当插图多于文本时，就使用 HTML”。
以下为博文全文——
《Markdown转HTML:AI 交互的更好载体》
Markdown 已成为智能代理与我们沟通时最主流的文件格式。它简洁、可移植，具备一定富文本能力，也方便人工编辑。
令人惊喜的是，Claude 甚至十分擅长在 Markdown 文件中用 ASCII 字符绘制图表。
但随着智能代理的能力越来越强，我渐渐觉得 Markdown 成了一种束缚。超过百行的 Markdown 文件，我读起来就十分吃力。
我想要更丰富的可视化效果、色彩与图表，还希望能便捷地分享这些内容。
同时，我越来越少亲自编辑这类文件，而是将它们用作技术规范、参考文档、头脑风暴产出物等。
即便需要修改，大多也是通过指令让 Claude 代劳，这就让 Markdown 最大的优势之一失去了意义。
于是，我开始更倾向于用 HTML 替代 Markdown 作为输出格式，而且我发现 Claude Code 团队里越来越多人也在这么做，背后原因如下。
（想先看示例的话，可以访问这里：https://thariqs.github.io/html-effectiveness，看完记得回来了解背后逻辑）
为什么选择 HTML？
信息密度
相较于 Markdown，HTML 能承载丰富得多的信息。它当然可以实现标题、格式排版这类基础文档结构，还能呈现各类其他信息，例如：
• 用表格展示结构化数据
• 用 CSS 呈现设计样式
• 用 SVG 绘制插图
• 用 script 标签插入代码片段
• 结合 HTML 元素、JavaScript 与 CSS 实现交互效果
• 用 SVG 和 HTML 梳理工作流程
• 通过绝对定位与画布呈现空间数据
• 用图片标签插入图像
我甚至可以说，只要是 Claude 能读取的信息，几乎都能用 HTML 高效呈现。这让模型能高效地向你传递深度信息，你也能便捷审阅。
我发现，受限于 Markdown 的表达能力，模型常会采用低效的呈现方式，比如 ASCII 字符绘图，或是我见过最特别的——像 Claude Code 的截图里那样，用 Unicode 字符模拟色彩。
（Claude Code 尝试在 Markdown 中展示色彩）
视觉清晰度与易读性
随着 Claude 能处理更复杂的工作，它产出的技术规范、方案规划文档也越来越长。实际使用中我发现，百行以上的 Markdown 文档我基本不会完整阅读，团队里其他人更是如此。
但 HTML 文档可读性要好得多。Claude 可以通过标签页、插图、超链接等方式，对文档结构进行可视化排版，优化浏览体验；还能适配移动端，在不同设备上调整展示效果。
便捷分享
Markdown 文件很难分享，大多数浏览器无法原生良好渲染，往往只能作为附件发送邮件或消息。
而 HTML 文件只需上传（例如上传至对象存储 S3），就能直接分享链接。同事可在任意设备打开查阅，引用内容。
如果技术规范、报告或代码合并申请文档采用 HTML 格式，他人完整阅读的概率会大幅提升。
双向交互
HTML 支持文档交互功能。比如你可以让它添加滑块、旋钮，用来调整设计参数，或是修改算法的各项配置，实时查看效果；还能将调整后的配置一键复制成指令，直接粘贴回 Claude Code。
想查看这类双向交互的示例，可以阅读我的演示项目文章：https://x.com/trq212/status/2017024445244924492
数据读取能力
为什么用 Claude Code 生成 HTML 文件，而非 ClaudeAI 或 Claude Design？
核心原因是， Claude Code 可读取海量上下文信息。
举个例子，撰写本文时，我让 Claude Code 遍历我的代码文件夹，找出所有我生成的 HTML 文件，进行分类整理，再制作一份包含各类示意图的 HTML 文档。
本文中的所有配图，都是这样生成的。
除本地文件系统外，Claude Code 还能通过 MCP 工具（如 Slack、Linear 项目管理工具）、Chrome 浏览器插件、Git 提交记录等获取更多上下文。
使用体验更愉悦
用 Claude 制作 HTML 文档本身就更有趣，能让我深度参与创作、更有投入感，单凭这一点就足够了。
如何上手
我有点担心大家看完这篇文章后，会把它做成 /html 指令模板之类的功能。
虽说这类模板或许有用，但我想强调，让 Claude 生成 HTML 并不复杂，你只需直接指令它“生成一个 HTML 文件”或“制作 HTML 成果物”即可。
关键是，明确你想要这个成果物实现什么功能、如何使用。
你可以后续慢慢打磨专属指令模板，但现阶段建议从零开始直接发指令，熟悉不同场景下的用法。
适用场景
为了更具象地说明，我针对不同场景制作了大量 HTML 文件，可在此查看：https://thariqs.github.io/html-effectiveness/，以下是场景概览：
技术规范、方案规划与思路探索
HTML 为 Claude 深度分析问题提供了广阔空间。我处理问题时，不再只用简单的 Markdown 方案，而是会搭建一系列 HTML 文档。
比如，我会先让 Claude Code 头脑风暴，生成多种方案思路；接着让它深化某一方向，制作原型或代码片段；方案成熟后，再生成落地执行计划。确认计划无误后，新建对话会话，导入所有 HTML 文档，让模型按方案开发。
验证环节，我也会让校验代理读取全部文档，全面掌握需求细节。
示例指令
1. 我不确定引导页该采用哪种设计方向，请生成6种风格迥异的方案，在布局、语气、信息密度上做出区分，整合在一份网格布局的 HTML 文件中，方便我横向对比，标注每种方案的优缺点。
2. 用 HTML 文件生成一份详尽的落地执行方案，务必包含原型图、数据流示意图与我需要审阅的关键代码片段，排版清晰易读。
适用场景
• 探索代码的多种实现方式
• 对比多款视觉设计方案
代码审阅与理解
Markdown 格式下的代码可读性很差。但通过 HTML，我们可以展示代码差异、添加批注、绘制流程图、梳理模块结构等。
可用来理解模型编写的代码、开展代码评审，或是向他人讲解代码合并申请内容。
我发现这种方式比 GitHub 自带的代码差异视图效果更好，现在我每次提交代码合并申请，都会附上 HTML 格式的代码解读文档。
示例指令
帮我审阅这份代码合并申请，生成一份 HTML 解读文档。我不熟悉限流/背压逻辑，请重点分析该部分；展示完整代码差异，在侧边栏添加批注，按问题严重程度用颜色标注风险点，确保内容清晰易懂。
适用场景
• 提交代码合并申请
• 审阅他人代码合并申请
• 理解代码中的技术逻辑
设计与原型制作
Claude Design 本身就基于 HTML 开发，因为 HTML 的设计表现力极强，即便最终产品并非网页端也适用。Claude 可先用 HTML 绘制设计草图，再转换成你需要的开发语言，如 React、Swift 等。
你还能制作交互原型，例如动画、点击效果等。可以让 Claude 添加滑块、旋钮，精准调试各项效果参数。
示例指令
我需要制作一个新的结算按钮原型，点击后播放动画并快速变为紫色。生成一份 HTML 文件，内置多个滑块和参数选项，方便我调试动画效果，添加复制按钮，导出最优参数。
适用场景
• 制作设计系统文档
• 调整组件样式
• 可视化组件库
• 制作趣味交互动画原型
报告撰写、调研与知识学习
Claude Code 擅长整合多源信息，生成可读性极强的报告。你可以指令它读取 Slack 聊天记录、代码库、Git 记录、网络资料等，为自己、管理层、团队生成各类深度报告。
报告形式可以是长篇 HTML 文档、交互式解读页，甚至演示幻灯片，可要求 Claude 用 SVG 绘制示意图辅助理解。
例如，我撰写提示词缓存相关文章时，让 Claude 读取 Git 记录，整理出一份 HTML 深度调研文档，梳理提示词缓存的所有更新内容。
示例指令
我不理解我们的限流器工作原理，请读取相关代码，生成单页 HTML 解读文档：包含令牌桶流程图、3–4 段带批注的核心代码片段，底部添加常见踩坑点说明，排版适配快速阅读。
适用场景
• 梳理功能实现逻辑
• 讲解专业技术概念
• 给上级提交每周工作汇报
• 向管理层提交故障复盘报告
• 制作 SVG 示意图、流程图、技术架构图等
自定义编辑界面
有些需求很难纯用文字描述。这时我会让 Claude 制作临时专用编辑器，不是完整产品或通用工具，而是仅针对当前数据的单份 HTML 文件。
核心技巧是增加导出功能：设置“复制为 JSON”或“复制为指令”按钮，将界面上的所有操作，转换成可粘贴回 Claude Code 的格式。
示例指令
我需要重新调整30条 Linear 工单的优先级，生成一份 HTML 文件，将每个工单做成可拖拽卡片，分为「立即处理/后续处理/延后处理/剔除」四列；由模型初步排序，添加“导出为 Markdown”按钮，导出最终排序结果，并为每类工单标注一句优先级理由。
这是我们的功能开关配置，请制作表单式编辑器：按业务模块分组开关，展示开关间的依赖关系，若启用前置条件未开启的开关则给出警告；添加“复制变更内容”按钮，仅导出修改后的配置项。
我正在调试系统提示词，请制作左右分栏编辑器：左侧为可编辑提示词，高亮变量占位符；右侧为3个示例输入，实时渲染填充后的模板；添加字符/令牌计数与复制按钮。
适用场景
• 工单、测试用例、反馈信息的排序、分级、归类
• 编辑结构化配置（功能开关、环境变量、带约束的 JSON/YAML）
• 实时调试提示词、模板、文案
• 整理数据集，筛选、标注样本并导出
• 批注文档、文稿、代码差异并导出批注内容
• 调试文字难以精准表达的参数：颜色、缓动曲线、裁剪区域、定时任务、正则表达式等
常见问题
我向很多人分享了改用 HTML 的经验，收到了一些高频问题，在此统一解答：
1. HTML 会不会更消耗 token？
虽然 Markdown 通常占用 token 更少，但 HTML 更强的表达能力，加上我完整阅读文档的概率大幅提升，整体产出效果反而更好。
Opus 4.7 支持百万级上下文窗口，token 消耗的增加基本可以忽略。
2. 那你现在还会用 Markdown 吗？
说实话，我几乎所有场景都不再使用 Markdown，不过我算是 HTML 的重度使用者。
3. 如何查看 HTML 文件？
我一般直接在本地浏览器打开（可让 Claude 帮你打开），需要分享链接的话，上传至对象存储 S3 即可。
4. 生成 HTML 会不会比 Markdown 更耗时？
确实会！HTML 的生成时长是 Markdown 的 2–4 倍，但我认为最终效果值得付出这份时间。
5. 版本控制怎么办？
这确实是HTM最大的缺点：对比 Markdown，HTML 的代码差异杂乱，很难审阅。
6. 如何让 Claude 做出符合我审美/企业风格的 HTML，避免样式粗糙？
前端设计插件可以辅助 Claude 优化 HTML 样式。若要匹配企业风格，可让 Claude 读取代码库，生成一份专属设计系统 HTML 文件，后续所有 HTML 文档均以此为参考。
总而言之，我选择 HTML 的核心原因，是能与 Claude 的协作更可控、信息同步更充分。
我曾担心，因为不再深度阅读 Claude 生成的方案，只能被动接受它的决策。
但改用 HTML 后，我反而能比以往更全面地把控项目进度与细节。希望你也能有同样的体验。
热门跟贴