Claude Code 团队工程负责人 Thariq Shihipar 近期发表了一篇题为《使用 Claude Code：HTML 意想不到的实用价值》的文章。文中提出，HTML 具备更丰富的可视化效果、色彩展示与交互性，在诸多场景下能提升人类与智能体之间的沟通效率，相较默认输出格式 Markdown 优势尤为突出。在智能体驱动的工作流中，目标沟通、需求细化、输出结果复核正逐步成为流程效率的瓶颈。
Shihipar 道出了开发人员经常需要面对的一个痛点：
随着智能体变得越来越强大，我发现 Markdown 格式的局限性也愈发凸显。具体来说，我发现阅读超过一百行的 Markdown 文件非常困难。
而且现在我基本不会手动编辑这类文件，只把它们当作需求规范与参考文档使用。
我开始更倾向于将 HTML 作为输出格式，而不是 Markdown，并且也注意到 Claude Code 团队里越来越多同事都在采用这种方式。
主张使用 HTML 的论据建立在这一客观发现之上：随着智能体越来越多地被用于复杂且冗长的工作流，输出的复杂性和长度也随之增加，这给人类带来了认知负担瓶颈。支持 HTML 方案的人认为，面对这一挑战，开发者很容易偷懒，直接不经审核就全盘采纳智能体生成的内容，从而可能在日后引发质量、维护和安全方面的问题。
该观点认为，在那些必须人工介入、无法完全自动化的工作流程中（例如目标与执行路径设定、需求调研与细化、分步纠错引导），或是需要人工强制核验、确认结果的场景中，智能体的输出格式应当既能让人快速抓取信息核心与细节，又能贴合用户设定的目标。
相较于 Markdown，Shihipar 更推崇使用单文件 HTML 创建适配当前任务目标、兼具可视化与交互性的工作空间。具体来说，他认为以下各类场景都适合使用 HTML：需求规范制定、方案规划与需求调研；代码审阅与逻辑梳理；界面设计与原型开发；数据探查、分析及可视化；以及所有能够借助定制化交互界面提升处理效率的业务场景。
在这篇博文的配套文章中，Shihipar 提供了一个自定义一次性 HTML 输出的示例，用于加快工单分类处理的工作进度：
另一个示例旨在加速 PR 审查流程。相较于在终端里来回滚动查看内容，HTML 输出页面更便于快速浏览查阅：
Shihipar 的观点在 Hacker News、Reddit 和 Medium 上引发了广泛讨论，开发者们由此分成两派：一派认可 HTML 的高密度可视化展示优势，另一派则警告不要放弃 Markdown 的纯文本简洁性。
针对 Shihipar 提出的初步思路，Simon Willison 提出了他的看法：如今大模型上下文窗口不断扩大，推理速度更快、使用成本更低，默认输出 Markdown 或许已经不再是最优方案。
从 GPT-4 问世以来，我就一直默认要求大多数输出使用 Markdown，当时模型仅有 8192 令牌的上下文上限，Markdown 相比 HTML 更省令牌的优势显得至关重要。
Thariq 的这篇文章让我重新审视了这个习惯，尤其是对于输出来说。如果让 Claude 用 HTML 生成内容，意味着它可以嵌入 SVG 图表、交互式小部件、页面内导航以及各种其他巧妙的方式，让信息更易于浏览。
也有人认为，用 HTML 替代 Markdown 是一种倒退，即便在前述各类场景中也是如此。他们指出了各种弊端：源代码可读性的丧失、不安全的 HTML 带来的安全和基础设施风险、HTML 相比 Markdown 的词元开销，以及 Git 集成欠佳（例如差异对比）。
尽管如此，一些开发人员仍在创建自定义工具（例如，html-artifacts，由 Greg Dogum 开发的开源 Claude 技能，它使用识别启发式方法可根据当前任务切换成 HTML 输出）。
归根结底，Shihipar 的观点可能只是一个使用合适工具完成工作的案例：
以上种种都意在说明，我使用 HTML 而非 Markdown 的真正原因是，它能让我感觉与 Claude 的联系更加紧密。随着 Claude 承担的任务越来越多，我发现自己渐渐不再仔细审阅它给出的方案，我希望能有一种方式来持续关注它做成的各项决策，而不是直接交差。HTML 恰好满足了这一需求。
AI 智能体平台正在积极寻求改进人机交互界面的方法，包括在标准文本机制之外增加更多交互式界面。生成式 UI 能够让智能体根据用户需求实时生成定制化交互界面。
查看英文原文：https://www.infoq.com/news/2026/06/anthropic-html-markdown-agent/
