AI 智能体什么时候适合用 HTML 代替 Markdown

我用了将近二十年 Markdown，但我觉得我们正在让它承担太多任务。Claude Code 团队的 Thariq 探索了用 HTML 作为智能体生成内容的替代格式，Andrej Karpathy 也讨论过让模型输出 HTML。我想看看它在哪些地方有帮助，以及 Markdown 在哪些地方仍然适用。

Thariq 的观点从一个熟悉的问题开始：智能体生成的计划、规格和解释很长，人们可能不会读完。Markdown 便于携带和编辑，但如果大部分编辑工作由智能体完成，对某些输出而言，更丰富的视觉结构可能更有价值。

示例包括用于规划和探索的独立 HTML 文件。我在一些生成页面中认出了重复的设计风格，并不喜欢。精美格式不会自动带来好内容，自动 AI 文本检测器也不能确证某段文字是人写的还是模型写的。

一个示例并排比较了几种防抖搜索方案，列出取舍并给出建议。聊天回复也许足够，但当并排布局能让选择更容易检查和讨论时，HTML 文件就可能有用。

另一个示例展示了任务为空时的四种界面设计。我经常让智能体在不同路由上生成多个不同方案，方便直接比较，而不是一遍遍要求再来一个。一次生成是否真的更有多样性，需要用自己的提示词和模型测试。

实施路线图和拉取请求摘要也可以采用这种方式。我喜欢审查界面中的层级和可折叠部分，但有些视觉计划比我喜欢阅读的 Markdown 更繁杂。更多装饰未必让解释更清楚。

浏览器文档可以结合标题、表格、CSS、SVG、代码、图片和交互。这种表达能力有助于展示纯文本中难以说明的空间关系和视觉解释。但生成的图片地址或嵌入数据可能有误，因此需要检查来源和视觉结果。

长 Markdown 文档可能难以导航，而 HTML 可以增加标签、链接、响应式布局等结构。但响应式设计必须真正实现：我在手机上检查一个示例时发现效果并不好。每增加一个功能，也会增加代码和可能的输出 token。

我想知道，吸引力有多少来自更好的信息层级，又有多少来自新鲜感。如果每个人都发送大型 HTML 报告，新鲜感可能会消退。关键在于产物能否帮助受众找到并理解相关信息。

交互是更强的优势。页面可以提供滑块或其他控件，让人探索设计或算法，再把选中的设置复制成提示词。这样，输出不仅供人阅读，也能用于引导下一步。

拥有授权的智能体可以读取文件系统、代码库历史或连接服务中的上下文，再整理成可视化。我曾这样处理本地数据。访问范围必须符合用户权限，最终摘要也仍需对照输入核查。

零散的产物说明可以设计可复用的工作流：规定页面结构、设计约定和生成文件的位置，避免临时输出让代码库变得杂乱。我在考虑为此制作一个 skill，但首先想直接尝试任务本身。

Thariq 说，更有吸引力的输出让他能持续参与。我认为这很重要：如果展示方式鼓励人们检查、质疑并引导智能体的工作，就可能改善协作。愉悦感有价值，但不能代替正确性检查。

可以先从简单的做起：要求生成 HTML 文件，并说明它要帮助你完成什么。先尝试任务，观察模型做对或做错了什么，留意反复使用的指令。然后再把稳定部分整理成可复用的 skill；也可以直接把 skill 文本当作提示词测试。

在规划阶段，智能体可以先生成多个方案，把其中一个扩展成模型和代码片段，再制定实施计划。Thariq 随后开启新会话并传入这些产物。我也会用新会话带入选定的上下文，但最佳方式取决于工具和任务。

这些文件也可以帮助另一个验证智能体理解原本的意图。例如，可以要求生成六种标注取舍的引导页布局，或者生成包含模型、数据流和重要代码片段的实施计划。审查者仍需将产物与实现和来源证据对照。

我不同意代码在 Markdown 中天然难读。好的渲染器可以根据代码块标注的语言进行语法高亮。生成自定义 HTML 渲染器会增加工作量，也可能引入错误。应根据信息选择格式，而不是遵循一条一刀切的规则。

差异内容更适合使用专门视图。智能体可以组织相关修改、添加注释，并解释组件如何交互。我喜欢一些按相关性而非文件顺序组织修改的审查工具；我与其中一家赞助商有既有关系，所以这只是我的个人体验。

有针对性的审查产物可以要求智能体重点解释修改中不熟悉的部分，例如流处理和背压，并在差异旁添加注释。它能帮助审查者导航，但实际代码和测试仍是事实依据；智能体摘要可能遗漏缺陷。

即使最终产品采用其他界面技术，HTML 也能用于设计原型。交互控件可以让人在实现前调整数值或比较动画。产物是需要结合真实约束验证的草图，并不能证明最终应用无障碍或可直接用于生产。

在报告和学习场景中，智能体可以综合项目系统、代码、历史记录和网络中的授权数据，生成解释页面或类似幻灯片的内容。每周工作摘要可能帮助团队理解进展，但应检查原始记录，并只向预期受众分享敏感信息。

提示智能体制作解释内容时，应明确读者的视角。即使我理解某个实现，也可能要求它为初学者制作解释，包含图示、标注代码片段和简短的注意事项。这样，输出就从给我自己的笔记变成面向受众的材料。

一次性编辑器是另一种用法：生成一个专门处理某份数据的页面，再将结果导出为 JSON、CSV 或提示词。工具不必变成永久产品才有价值。实验代码帮助我作出决定后，我经常将其丢弃。

我展示了一个 token 成本计算器，它接受输入，并支持导入或导出 CSV。生成的界面对我有用，虽然我在托管页面遇到了加载缓慢的问题。计算器方便并不代表公式或输入正确，仍需独立检查。

HTML 可能比简洁 Markdown 消耗更多 token，其版本控制差异也可能更嘈杂。如果可视化或交互能改善决策，额外成本可能值得；但大上下文窗口并不能消除金钱成本、延迟或审查负担。

可复用的设计系统参考可以帮助智能体贴合团队的视觉风格。生成页面也需要明确的存放位置和分享方式。打开或发布不可信 HTML 产物前，应检查脚本和外部资源，并使用适当隔离的环境。

我从 Thariq 的结论中得到的重点是持续参与。更丰富的产物可能让人更容易检查计划，而不是把所有选择交给智能体。我打算继续实验，而不是立刻替换所有 Markdown 文件。

Karpathy 认为视觉输出和音频输入可能成为更有用的 AI 界面，并推测未来可能出现交互式模拟或生成视频。我觉得这个方向有趣，但它是对未来界面的假设，不是已经确立的结果，也不是所有用户的共同偏好。

我已经会用截图和标注，将智能体引向屏幕上的某个部分。能够显示粘贴图片的图形界面，有助于我理解自己发送了什么上下文。我参与开发的 T3 Code 就是这类界面之一；推荐它时，这个背景需要说明。

我想知道，智能体界面能否呈现自定义 HTML 回答，并提供分享方式。人们如何输入、检查输出和引导工作，仍有很多值得探索的地方。HTML 可以与 Markdown 等格式一起作为有用的起点，但不是所有任务的最终答案。