2026 年 5 月 8 日，Anthropic Claude Code 团队的工程师 Thariq Shihipar 发表了一篇文章，让 AI 开发者社区停下了滚动。标题是："Using Claude Code: The Unreasonable Effectiveness of HTML"。
48 小时内，这篇文章在 X 上获得了超过 75 万次浏览、14,000 个赞、30,000 个书签和 1,600 条引用帖。Simon Willison 称其发人深省。开发者生态系统中涌现出一个之前从未被认真提出过的问题：如果 Markdown——我们一直用来与 AI 代理通信的格式——实际上是错误的格式呢？
Thariq 在文章旁发布的 20 个生产级 HTML 作品画廊所支持的答案，正在重塑开发者对代理输出的思考方式。
Markdown 为何赢下了第一回合
要理解这次切换为何重要，你必须先理解 Markdown 最初为何成为默认选择。
2022 年，当 ChatGPT 以 8,192 token 上下文窗口发布时，每一个 token 都很珍贵。对于相同的内容，HTML 消耗的 token 大约是 Markdown 的三倍——HTML 文档约 8,000 token，而等效的 Markdown 约 2,800 token。当你的全部上下文预算只有 8K token，且输出会挤占输入空间时，节省 5,000 token 意味着保住了原本会丢失的整段上下文。
Markdown 在成本上赢下了那场战斗。在当时约束条件下，这是理性的选择。
Simon Willison——AI 开发者社区中最具影响力的声音之一——上周承认了这一点。自 GPT-4 时代以来，他正是出于这个原因一直为 LLM 编写 Markdown。他并没有错。在当时的数据计算下，没有人是错的。
但数据变了。
Claude Opus 4.7 搭载了 1,000,000 token 上下文窗口。这比让 Markdown 成为默认值的 8K 窗口大了 122 倍。当你的预算是 100 万 token 时，2,800 和 8,000 之间的差异只是噪音。造就 Markdown 默认值的约束已经消融——但这个默认值本身却存活了下来，近四年间无人质疑。
HTML 能承载而 Markdown 不能的 8 件事
Thariq 的文章以一个简单的清单开篇，列举了将代理输出强行塞入 Markdown 时所失去的东西。这个清单值得全文阅读，但以下是八个类别：
1. 支持对齐和跨行跨列的真实表格。 Markdown 表格在简单网格之外的任何场景都会崩溃。HTML 表格支持列合并、行合并、对齐，并且可以通过样式在一瞥之间高亮重要行。
2. CSS 美化的视觉层级。 在 Markdown 中，强调仅限于粗体、斜体和代码块。HTML 增加了颜色、大小、间距、边框和布局——使信息可快速浏览的视觉语汇。
3. 内联 SVG 图表。 这是最大的区别。在 Markdown 中，Claude 只能求助于 ASCII 艺术：用竖线字符表示柱状图，用 Unicode 方块表示色样，用破折号表示箭头。而在 HTML 中，它绘制真正的矢量图形——可缩放、精确且真正可读。
4. JavaScript 交互性。 可折叠区块、分标签的代码示例、实时过滤器、拖拽操作。Markdown 是静态媒介。HTML 是运行时环境。
5. 单文件内嵌图片。 Base64 编码的图片随 HTML 一起传输。没有损坏的引用链接，没有"文件未找到"的对话。
6. 空间画布局。 并排对比、网格布局、旁注、标注框。Markdown 从上到下流动。HTML 可按你的指示向任何方向流动。
7. 带可点击节点的工作流图。 用方框和箭头绘制的部署流水线，点击某个步骤即可显示运行内容、耗时和失败路径。Markdown 只能给你一个编号列表。
8. 自包含、可分享的产出物。 一个 .html 文件。双击它。它在任何浏览器中打开，所有图表、样式和交互性都完好无损。无依赖、无构建步骤、无配置意外。
共同线索：Markdown 是为人类撰写文章而构建的。HTML 是为渲染丰富信息而构建的。当输出是计划、报告、评审或原型——而不是 README 时——为丰富信息而构建的格式胜出。
ASCII 图表税
Thariq 画廊中的一个例子比任何论证都更能说明问题。
让 Claude Code 分析数据集并以 Markdown 输出结果，它会生成类似这样的内容：
Q1 Sales by Region
| Region | Revenue |
|---------|----------|
| North | ████████ | $2.4M
| South | ██████ | $1.8M
| East | ████████ | $2.6M
| West | ████ | $1.2M
这就是 Claude 被迫通过 1990 年代 README 格式时所做的事。它即兴发挥。它用 Unicode 方块字符伪造柱状图。它将 token 花费在外观近似上，而非数据上。
提出同样的问题并告诉 Claude 输出 HTML，它会绘制出一个真正的 SVG 柱状图，带有正确的轴、比例柱、标签和图例。同样的数据。同样的代理。但第二个输出是你的同事真正会打开、阅读并采取行动的东西。
我们自己测试过：相同的数据集、相同的 Claude Code 会话、两种不同的格式指令。HTML 版本在浏览器中无需编辑即可渲染。Markdown 版本需要三轮澄清——最终仍然停留在用 Unicode 方块字符近似柱状图。当格式约束代理时，输出质量随之下降。
Thariq 的论点归结为：当你给代理一个具有表达空间的媒介时，它会使用它。当你将其限制在 ASCII 时，它会补偿——但效果很差。
Token 成本之辩（及其为何不再重要）
对 HTML 代理输出最常见的反对意见是可预见的：它消耗更多 token。
确实如此。Thariq 对此很坦诚：HTML 输出使用的 token 约是等效 Markdown 的 2 到 4 倍。一个 2,800 token 的 Markdown 文档变成一个 8,000 到 11,000 token 的 HTML 文档。
但如 Thariq 等人所指出的，这个反对意见建立在 2022 年成立、现在已过时的假设之上。当你的上下文窗口是 8,192 token 时，5,000 token 的开销是毁灭性的。当你的上下文窗口是 1,000,000 token 时，这只是预算的 0.5%。
Claude Opus 4.7、Gemini 3、GPT-5.5——2026 年中期的前沿模型都在数十万到数百万 token 范围内运行。让 Markdown 成为必要选择的 token 节约经济已被让 HTML 变得可行的丰裕经济所取代。
更重要的是，Thariq 认为 token 成本是错误的指标。正确的指标是输出是否被使用。一个无人阅读的 2,800 token Markdown 计划消耗了一切却没有交付任何东西。一个被打开、理解并付诸行动的 8,000 token HTML 计划消耗更多 token 却交付了价值。
HTML 胜过 Markdown 的 5 个生产用例
Thariq 的 20 个 HTML 作品画廊横跨九个类别。以下五个可以超越 Claude Code 推广到任何 AI 代理工作流：
1. 规格说明和实施方案
Markdown 规格说明和 HTML 规格说明之间的差异，是文字墙与一份包含时间线、数据流图、内联原型和色标严重程度风险表的文档之间的差异。你的实施者打开第二份。他们略读第一份。
2. AI 代码审查
带有旁注、严重程度标签和跳转链接的差异对比，从根本上比在终端中滚动更容易浏览。HTML 版本还支持前后并排渲染——这种空间布局比任何顺序格式都能更高效地传达变更。
3. 设计和原型
HTML 是你的设计系统交付的媒介。Token 变成色样。组件变成联系表。带有持续时间和缓动滑块的运动沙箱在五秒内告诉你一段文字永远无法传达的内容。四个通过真实点击行为连接的屏幕是一个你可以感受而不只是阅读的原型。
4. 研究和报告
带有可折叠区块、分标签代码示例和页边词汇表的说明文，读起来与线性倾泻的同样文字截然不同。带有小型图表和彩色时间线的周报，将人们略读的内容变成他们真正阅读的内容。带有逐分钟时间线和日志摘录的事后复盘，是你的团队会参考而非忽视的文档。
5. 自定义编辑界面
这是最激进的类别。Thariq 展示了一次性 HTML 编辑器——一个工单分类面板，你可以将 30 个工单拖拽到 Now、Next、Later 和 Cut 各列，并将结果导出为 Markdown；一个带有依赖警告和差异复制按钮的功能开关编辑器；一个支持实时重新渲染的提示词调优器。
这些不是产品。它们是按需生成、使用一次即丢弃的一次性工具。这类产出物在 Markdown 中不存在。只有当代理能够以 HTML、CSS 和 JavaScript 作为输出原语时，它才会存在。
真正的原因：我不再阅读 Markdown 计划
在 DIY Smart Code 视频分析接近结尾处，隐藏着解释整个转变的一句话：
我不再阅读 markdown 计划，让 Claude 做出每一个选择。
这就是 Thariq 切换的真正原因——它比 token 数量、SVG 保真度或任何功能比较都更重要。
当代理输出是一堵不可读的 Markdown 之墙时，人类退出了循环。你不审查计划。你没发现错误。你没有运用你的判断力。你只是说看起来不错然后发布——或者更糟，你甚至不打开文件。代理工作得很好。格式让它的工作变得不可见。这正是 限制当今 AI 代理交付能力的差距 背后的同一动态：输出在技术上是正确的，但在实际中不可用，因为格式无法触及需要它的人。
HTML 输出逆转了这一动态。当输出是可视化、结构化和可浏览的时候，人类重新进入循环。你看到图表并想这个流程不对。你打开可折叠区块并发现一个错误假设。你在分类面板上拖拽工单并调整优先级。格式决定了人类是留在决策过程中还是完全委托。
这是任何构建 AI 辅助工作流的人都应该最重视的论点。目标不是最小化 token 成本。目标是最大化人类-代理协作的质量。而让协作更容易的格式，就是产生更好结果的格式——无论 token 数量如何。
如何发布 AI 生成的 HTML
一旦你的代理生成了一个自包含的 HTML 文件——一份带有 SVG 图表的研究报告、一份带有注释差异的代码审查、一个带有可点击屏幕的原型——你就面临第二个问题：它存放在哪里？
你本地文件系统上的 .html 文件只对你自己有用。代理输出的价值在拥有 URL 时会成倍增长——当你可以与团队分享、嵌入 Slack 话题或发送给利益相关者时。一个能写 HTML 但不能发布的 AI 代理，就像一个能起草但不能印刷的作家。输出存在，但它没有触达任何人。
以下是开发者目前使用的三种方法，从最手动到最自动：
GitHub Pages
推送到仓库，等待 CI 构建，获取一个 URL。适用于永久文档页面和项目网站。对于代理今早生成的一次性报告来说过于笨重。每次发布都需要一次 Git 提交——这意味着代理需要仓库访问权限，而且每件一次性产出物都会创建永久历史。
手动云上传（S3、R2）
将 HTML 文件上传到存储桶，配置公共访问，管理 CORS，处理缓存失效。这可以工作，但这是基础设施工作——你本希望代理替你处理的那类事情。如果你正在配置存储桶策略来发布代理报告，自动化早已破裂。
代理原生发布平台
第三类是专为 Thariq 描述的工作流而构建的：代理生成输出，发布层在无需人工干预的情况下处理其他一切。
这些平台专为程序化访问而设计——无 Web 仪表板、无手动配置、无 CMS 登录。它们通过 CLI 或 API 接受内容，渲染它，并返回一个公共 URL。代理始终掌控整个流水线。
例如，像 AnyCap 这样的平台为代理提供了一组能力，构成完整的发布流水线——与我们的 AI 即时 Web 发布指南 中所涵盖的模式相同：
- 云存储（Drive）——代理将生成的图片、CSV 导出和其他资产上传到持久云存储。无损坏的文件路径。无手动上传步骤。
- 页面部署——一条命令将 HTML 或 Markdown 文件转变为可公开访问的在线网页。
anycap page deploy report.html --title "Q2 分析"就是整个发布步骤。 - 多格式支持——平台原生渲染 Markdown 和 HTML。代理可以从 Markdown 开始以提高速度，在需要 SVG 图表、样式化表格或交互元素时切换到 HTML——全部通过同一命令部署。
- 统一 CLI——发布页面的同一工具也处理网络搜索、图片生成和网页爬取。代理无需在五个服务之间切换来完成一个任务。它从单一运行时研究、生成图表并发布。
完整的流水线在实践中的样子：
# 1. 代理研究主题
anycap search --prompt "最新 Q2 业绩数据" --json > research.json
# 2. 代理生成主图表为 SVG
anycap image generate --prompt "Q2 营收柱状图，简洁企业风格" \
--model nano-banana-2 -o chart.png
# 3. 代理上传资产到云存储
anycap drive upload chart.png
# 4. 代理将报告编写为自包含 HTML
# （Claude Code 输出包含嵌入图表的 HTML 文件）
# 5. 代理发布页面——一条命令，即时 URL
anycap page deploy q2-report.html \
--title "2026 年 Q2 业绩报告" \
--description "AI 生成的季度分析，含交互式图表"
没有人接触过 CMS。没有配置过托管。代理研究、创建可视化并发布——全部通过单一 CLI 完成。
你应该使用哪种方法？
| 方法 | 最适合 | 代理友好？ | 所需设置 |
|---|---|---|---|
| GitHub Pages | 永久文档、项目网站 | 部分（需要仓库权限） | 仓库 + CI 配置 |
| 手动 S3/R2 | 已有基础设施的团队 | 否（每个文件手动操作） | 存储桶 + IAM + CORS |
| 代理原生平台 | 代理生成的报告、原型、一次性页面 | 是（CLI/API 原生） | 安装 CLI，一步认证 |
正确的选择取决于你的工作流。如果你的代理每周输出 10 份需要与团队分享的报告，代理原生发布层立即就能收回成本。如果你每月发布一页，GitHub Pages 就足够了。
格式切换——Markdown 到 HTML——和分发切换——本地文件到即时 URL——是同一枚硬币的两面。一个让输出值得阅读。另一个让它值得分享。
何时对代理输出使用 HTML vs Markdown
向 HTML 的切换不是教条主义的。某些输出更适合 Markdown。决策框架很简单：
| 使用 Markdown 当…… | 使用 HTML 当…… |
|---|---|
| 输出是配置文件（CLAUDE.md、SKILL.md） | 输出是供人类阅读的 |
| 输出输入到另一个期望 Markdown 的工具 | 输出包含受益于可视化结构的数据 |
| 输出是一个简单列表或段落 | 输出包含对比、图表或多部分布局 |
| 输出将被版本控制和差异比较 | 输出将被分享、展示或引用 |
| 你在低于 32K token 的上下文中操作 | 你在 200K+ 上下文的模型上（你很可能是） |
Thariq 隐含提出的经验法则：如果你预期人类会阅读它，考虑 HTML。如果是纯机器对机器，Markdown 就可以。
最终结论
Markdown 成为 AI 代理输出的默认格式，不是因为它是最好的格式，而是因为在一个 token 严重受限的时代，它是最便宜的格式。那个时代已经结束了。
Thariq Shihipar 所倡导并凭借 20 个生产级产出物所展示的转变，其实无关 HTML 与 Markdown。它关乎我们是将 AI 代理输出视为供机器解析的东西，还是供人类消费的东西。四年来，我们为前者优化，因为经济性迫使我们这样做。经济性不再迫使我们。
代理在变得更好。上下文窗口在变得更大。输出在变得更复杂。是时候让格式跟上步伐了。
由 AnyCap 团队撰写。我们分析塑造开发者使用 AI 代理构建方式的工具、格式和工作流。
延伸阅读：