Claude Code 团队工程负责人 Thariq Shihipar 近期发表文章《使用 Claude Code：HTML 意想不到的实用价值》，提出在智能体驱动的工作流中，HTML 凭借更丰富的可视化效果、色彩展示与交互性，能显著提升人机沟通效率，其优势在复杂场景下远超默认的 Markdown 格式。当前，目标沟通、需求细化及结果复核已成为流程效率的瓶颈，而输出格式的优化或是破局关键。
Markdown 的局限与 HTML 的崛起
Shihipar 指出，随着智能体能力增强，Markdown 格式的局限性日益凸显。面对超过百行的 Markdown 文件，阅读难度极大，且开发者往往仅将其作为参考文档，不再进行手动编辑。因此，他及越来越多的团队成员开始倾向于将 HTML 作为首选输出格式。
随着智能体变得越来越强大，我发现 Markdown 格式的局限性也愈发凸显。具体来说，我发现阅读超过一百行的 Markdown 文件非常困难。
而且现在我基本不会手动编辑这类文件，只把它们当作需求规范与参考文档使用。
我开始更倾向于将 HTML 作为输出格式，而不是 Markdown，并且也注意到 Claude Code 团队里越来越多同事都在采用这种方式。
这一观点基于客观现实：智能体处理的工作流越复杂冗长，输出内容的认知负担就越重。若缺乏高效的审阅机制，开发者易因惰性直接采纳生成内容，从而埋下质量、维护及安全隐忧。在必须人工介入的场景（如目标设定、需求调研、分步纠错及结果核验）中，输出格式需兼顾信息核心的快速抓取与细节的清晰呈现。
相较于 Markdown，Shihipar 推崇利用单文件 HTML 构建适配任务目标、兼具可视化与交互性的工作空间。适用场景包括：
- 需求规范制定、方案规划与调研
- 代码审阅与逻辑梳理
- 界面设计与原型开发
- 数据探查、分析及可视化
- 其他需定制化交互界面提升效率的业务场景
实战案例：工单分类与 PR 审查
Shihipar 展示了自定义一次性 HTML 输出的实际应用。例如，在工单分类处理中，HTML 页面能加速工作进度：
另一案例旨在加速 PR（拉取请求）审查流程。相比在终端中滚动查看，HTML 输出页面提供了更便捷的浏览体验：
社区争议与技术反思
该观点在 Hacker News、Reddit 和 Medium 等平台引发热议，开发者群体意见分化。一派认可 HTML 的高密度可视化优势；另一派则担忧放弃 Markdown 纯文本简洁性带来的风险。
支持方：上下文窗口扩大改变格局
Simon Willison 等支持者认为，随着大模型上下文窗口扩大、推理提速及成本降低，默认输出 Markdown 以节省令牌的做法已非最优解。HTML 可嵌入 SVG 图表、交互式组件及页面内导航，大幅提升信息可读性。
从 GPT-4 问世以来，我就一直默认要求大多数输出使用 Markdown，当时模型仅有 8192 令牌的上下文上限，Markdown 相比 HTML 更省令牌的优势显得至关重要。
Thariq 的这篇文章让我重新审视了这个习惯，尤其是对于输出来说。如果让 Claude 用 HTML 生成内容，意味着它可以嵌入 SVG 图表、交互式小部件、页面内导航以及各种其他巧妙的方式，让信息更易于浏览。
反对方：安全性与集成难题
反对者指出，用 HTML 替代 Markdown 存在诸多弊端：源代码可读性下降、潜在的安全与基础设施风险、更高的词元开销，以及与 Git 集成欠佳（如差异对比困难）等问题。
尽管存在争议，部分开发者已开始探索中间路线，如 Greg Dogum 开发的开源工具"html-artifacts"，可根据任务类型智能切换输出格式。
核心洞察：重塑人机协作信任
Shihipar 强调，选择 HTML 的本质在于“使用合适工具完成工作”，其核心价值是增强人与智能体的连接感。
以上种种都意在说明，我使用 HTML 而非 Markdown 的真正原因是，它能让我感觉与 Claude 的联系更加紧密。随着 Claude 承担的任务越来越多，我发现自己渐渐不再仔细审阅它给出的方案，我希望能有一种方式来持续关注它做成的各项决策，而不是直接交差。HTML 恰好满足了这一需求。
当前，AI 智能体平台正积极探索改进人机交互界面，除标准文本外，引入更多交互式元素。生成式 UI 技术使智能体能根据用户需求实时定制交互界面，这或许是未来人机协作的重要演进方向。
声明：本文由 InfoQ 翻译，未经许可禁止转载。