为什么 Agent 输出正在从 Markdown 转向 HTML
一篇关于信息密度、可读性、分享和双向交互的中文可视化解读。
Markdown 适合写，但 HTML 更适合让人真正读进去。
作者的判断是：随着 AI agent 生成的规格、计划、报告和解释越来越长，Markdown 的可读性和表达力开始成为瓶颈。HTML 可以把同样的信息组织成图表、界面、交互控件和可分享页面，让人更容易审阅、比较、反馈，并继续把结果交回给 agent。
一句话摘要
为什么作者开始偏向 HTML
- 简单、便携、可编辑。
- 适合作为轻量笔记、短计划和文本规格。
- 对 diff 和版本控制更友好。
- 能表达颜色、空间关系、流程、组件、交互和图像。
- 长文更容易导航、分层和移动端阅读。
- 可直接在浏览器打开，也更适合通过链接分享。
HTML 能承载哪些信息
结构化文档
标题、段落、摘要、目录、链接和章节跳转。
数据与表格
表格、状态列、评分、对比矩阵和统计摘要。
设计表达
CSS tokens、色彩、间距、组件状态和响应式布局。
图解
SVG 流程图、泳道、架构图、时间线和空间示意。
代码理解
代码片段、diff、旁注、严重程度标记和调用链。
交互界面
滑块、开关、表单、复制按钮和实时预览。
真正的变化：从“读文件”变成“参与协作”
Agent 汇总上下文
读取代码库、文件系统、MCP、浏览器、Git 历史等来源。
生成 HTML 解释页
把复杂材料组织成图表、标签页、注释和可读结构。
人类审阅与调整
通过导航、控件、预览和导出结果快速反馈。
复制回 Prompt
把选择、参数、批注或排序重新导出给 Claude Code。
进入实现或验证
新会话拿到 HTML 文件后，拥有更完整的上下文。
适合改成 HTML 的场景
探索多个方案
用网格并排比较不同方向，展示取舍、草图、数据流和实现计划。
把 diff 讲清楚
渲染真实 diff、行内旁注、风险级别、模块关系和关键逻辑。
调动画与组件
用滑块、按钮和实时预览找到合适参数，再复制配置。
综合多源信息
把 Slack、代码、Git、互联网资料整理成领导、团队或自己能快速读懂的报告。
给一份数据做专用界面
拖拽排序、编辑配置、标注文本、筛选数据，最后导出 JSON、Markdown 或 prompt。
降低打开成本
上传到 S3 或任意静态托管后，一个链接就能让同事打开阅读。
可复制的中文提示词
我不确定 onboarding 页面该走哪个方向。请生成 6 个明显不同的方案，改变布局、语气和信息密度，并把它们放在一个 HTML 文件的网格里，方便我横向比较。每个方案都标注它选择的取舍。
帮我审查这个 PR，创建一个 HTML artifact 来解释它。我对 streaming / backpressure 逻辑不熟，所以请重点讲这部分。渲染真实 diff，加上行内旁注，按严重程度给问题上色，并补充必要的流程图。
我需要重新排序这 30 个 Linear tickets。请做一个 HTML 文件，把每个 ticket 做成可拖拽卡片，放在 Now / Next / Later / Cut 四列中。先按你的判断预排序，并添加“复制为 Markdown”按钮，导出最终排序和每组一句理由。
常见疑问与取舍
Token 会不会更贵？
会更占 token，但作者认为 HTML 的表达力和阅读率提升带来更好的总产出；原文还提到大上下文窗口让这点更不明显。
Markdown 还用吗？
作者几乎停止在多数场景使用 Markdown，但也承认自己可能偏向 HTML 极大化。
怎么看 HTML 文件？
本地浏览器直接打开，或上传到 S3 等静态存储后分享链接。
生成会不会更慢？
会。原文估计 HTML 可能比 Markdown 慢 2-4 倍，但结果更值得读。
版本控制怎么办？
这是明显缺点：HTML diff 噪声更大，审查成本比 Markdown 高。
怎么避免做丑？
可以使用前端设计插件，或让 Claude 基于代码库生成一个设计系统 HTML，作为后续 artifact 的风格参考。
HTML 的价值不只是“更漂亮”，而是让人重新进入决策循环。
作者担心过：如果自己不再深入阅读 agent 生成的长计划，就只能把选择权交给 Claude。但 HTML 让复杂输出变得更容易阅读、调整和分享，因此他反而感觉自己比以前更“在循环中”。
原文中的示例页面：thariqs.github.io/html-effectiveness；双向交互示例：X post。