The unreasonable effectiveness of HTML：文章分析
目录+
原文： https://thariqs.github.io/html-effectiveness/
这篇页面表面上是在展示 20 个 HTML 示例，实际讨论的是一个更重要的问题：AI 产出的结果，应该以什么形式交付给人看。
作者的核心观点很明确：很多原本默认用 Markdown 输出的内容，其实更适合直接生成成一个可打开、可浏览、可交互的 HTML 页面。
1. 文章核心结论
一句话概括：
当信息本身带有结构、空间关系、视觉层级或交互需求时，HTML 往往比 Markdown 更接近正确的交付形式。
作者并不是说 Markdown 没用，而是在强调：
- Markdown 更适合线性文本
- HTML 更适合结构化、可视化、可交互的信息
所以这篇文章真正要推动的，不是“网页设计审美”，而是 AI 输出介质的升级。
2. 文章在解决什么问题
现在很多 AI 输出的问题，不在于内容本身不够聪明，而在于：
- 信息被压成一整块线性文本
- 多个方案难以并排比较
- 复杂流程难以一眼看懂
- 交互、动效、状态变化只能靠描述
- 报告、设计、代码评审的空间关系被抹平
Markdown 的优点是轻量、快、通用；但它的缺点也很明显：它天然会把信息“压扁”。
而 HTML 的优势在于，它可以同时提供：
- 布局
- 视觉层级
- 颜色和强调
- 折叠与切换
- 图表与流程图
- 基础交互
这意味着，AI 不必只交付“说明”，而可以直接交付一个更接近最终使用体验的页面。
3. 文章的论证方式
这篇文章最聪明的地方，是它没有写成长篇理论，而是直接给出 20 个可运行的 HTML 示例。
这本身就在实践它的观点：
- 它不是告诉你 HTML 为什么更有效
- 而是直接让你看到 HTML 能把结果变成什么样
也就是说，这篇文章的说服力来自 展示，而不是 论证。
4. 九类典型场景
页面把 20 个示例归纳为 9 类，这 9 类基本覆盖了 AI 输出最常见、也最适合 HTML 化的任务。
4.1 Exploration & Planning
适合还在探索阶段的任务，比如：
- 三种方案并排比较
- 多套视觉方向并排展示
- 实施计划做成时间线、风险表、数据流图
这里的核心不是“说清楚”，而是“方便比较”。
4.2 Code Review & Understanding
适合代码评审和理解陌生系统，比如：
- 带批注的 PR diff
- reviewer 导向的 PR writeup
- 模块关系图、调用路径图
作者抓得很准：代码评审很多时候缺的不是解释，而是 结构可见性。
4.3 Design
适合设计系统和组件评审，比如：
- 颜色、字号、间距 token 做成可视化面板
- 组件所有尺寸、状态、语义一次排开
这说明 HTML 不只是“展示网页”，也可以是设计沟通介质。
4.4 Prototyping
适合交互和动效验证，比如：
- 动画参数调节 sandbox
- 可点击的流程原型
这类内容只靠文字很难表达，因为交互和动效必须“感受到”，不能只“被描述”。
4.5 Illustrations & Diagrams
适合流程图、说明图、博文插图，比如：
- inline SVG 图示集合
- 可点击流程图
这一类的价值在于：它不只是图，而且是 可复制、可改、可继续使用的图。
4.6 Decks
适合临时汇报和会议演示。
作者的意思很直接：一个 HTML 文件，加少量 JS，就已经可以做成 slide deck，不一定非要进 PowerPoint 或 Keynote。
4.7 Research & Learning
适合概念讲解和知识整理，比如：
- TL;DR
- 折叠章节
- Tab 代码块
- Glossary
- 边栏导航
这里的关键是：学习材料不仅是内容本身，还包括帮助读者“进入内容”的结构。
4.8 Reports
适合周报、事故复盘、状态报告。
这类内容往往容易被略读，而 HTML 可以通过：
- 时间线
- 小图表
- 颜色状态
- checklist
把原本容易被忽略的内容变得更值得看。
4.9 Custom Editing Interfaces
这是整篇文章里最有启发的一部分。
作者提出：AI 不一定只输出结论，也可以先生成一个专用的小编辑器，让用户通过拖拽、切换、筛选、调参来表达意图，最后再导出结果。
例如：
- ticket triage board
- feature flag editor
- prompt tuner
这意味着 AI 不只是“回答问题”，还可以“先搭一个帮助你提问和调整的小界面”。
5. 这篇文章最有价值的洞察
我认为这篇文章最强的地方有三点。
5.1 它抓住了 AI 的真实瓶颈
很多时候问题不在模型不会思考，而在于输出形式太弱：
- 能给方案，但不好比较
- 能解释代码，但不好快速扫懂
- 能描述设计，但不好形成判断
- 能说明流程，但不好建立空间感
作者关注的不是“模型能力”，而是 交付形式是否适合人的认知方式。
5.2 它把 HTML 从“网页技术”提升成“认知容器”
这篇文章提供了一个很值得记住的视角：
HTML 不只是前端页面技术，也可以是 AI 输出复杂信息的一种通用容器。
换句话说，HTML 在这里的角色不是“网页”，而是：
- 结构化容器
- 视觉化容器
- 最小交互容器
- 中间产物容器
5.3 它缩短了“想法到感知结果”的距离
这是最实用的一点。
很多任务里，用户真正需要的不是“关于结果的解释”，而是“先感受到结果”。
例如：
- 不要描述交互，直接给 click-through
- 不要概述设计方向，直接给几套 live layout
- 不要抽象解释系统结构，直接给模块图
- 不要只写 prompt 说明，直接给 prompt tuner
这会显著缩短：
想法 → 表达 → 理解 → 调整 → 再迭代
之间的路径。
6. 这篇文章的边界和局限
这篇文章很有启发性，但也不能过度推演。
6.1 不是所有内容都适合 HTML
如果内容本身就是：
- 简单结论
- 短 memo
- 原始数据清单
- 需要复制到别处的纯文本
那 Markdown 依然是更合适的选择。
所以更合理的结论是：
- 线性内容 → Markdown
- 结构化/可视化/交互内容 → HTML
6.2 HTML 的维护成本更高
相比纯文本，HTML 通常意味着：
- 要考虑排版
- 要考虑样式
- 要考虑交互
- 要考虑可维护性
因此它更适合：
- 高价值输出
- 需要展示或评审的内容
- 可以模板化复用的页面
6.3 容易走向“好看但不高效”
如果处理不好，HTML 也会变成：
- 装饰过多
- 信息过散
- 视觉上很热闹，实际不便浏览
所以这篇文章成立的前提是：HTML 是为了增强结构表达，不是为了炫技。
7. 对我的直接启发
这篇文章对 AI、内容、工具设计这几个方向都有很强的参考价值。
7.1 对 AI Agent
很多 Agent 的输出其实天然适合 HTML，比如：
- 每日简报
- 方案比较
- 风险清单
- 代码评审页
- 项目实施计划
如果只输出成 Markdown，经常会损失信息结构。
7.2 对博客与知识讲解
解释型文章也可以从普通笔记升级成：
- 带目录的教学页
- 可折叠的概念说明
- 带流程图的学习笔记
- 带交互 demo 的技术科普
这样内容不只是“被读”，而是更容易“被理解”。
7.3 对专用小工具
文章最后几类示例说明：很多时候，用户并不缺答案，而是缺一个让意图变得更明确的小界面。
这对：
- 笔记工具
- Prompt 工具
- 配置工具
- 编辑器插件
- Agent 工作流 UI
都很有启发。
8. 总结
这篇文章真正有价值的地方，不是展示了 20 个漂亮页面，而是提出了一个很实用的判断标准：
当 AI 的输出需要帮助人去比较、理解、浏览、评审、操作时，HTML 往往比 Markdown 更适合作为交付形式。
它本质上是在提醒我们：
- 不要把 AI 只当成“写文字的机器”
- 也不要把 HTML 只当成“网页前端技术”
在很多任务里，HTML 是 AI 更自然的结果形态。
9. 可延伸思考
基于这篇文章，可以继续思考几个问题：
- 哪些 AI 输出场景，应该默认转向 HTML 而不是 Markdown？
- 哪些 HTML 输出可以进一步演变成可交互的小工具？
- 对于博客、Agent、内部工作流，是否应该建立一套“HTML 交付模板库”？
- 当 AI 负责初稿时，人负责挑选和微调，这类页面是否会成为新的常见工作界面？
如果把这些问题继续往前推，这篇文章讨论的就不只是“HTML 很有效”，而是：
AI 时代的信息交付界面，可能需要被重新设计。