表现力至上：我为什么让 AI 输出 HTML
叮当小鸡毛 2,673 字 · 约 7 分钟 6 张图
向 AI 提需求时，它常会先给一份 Markdown 计划供确认。简单、易编辑，Markdown 至今仍是人与智能体沟通的主要格式。
但到了 2026 年，GPT-6 和 Claude Code Fable 5 的输出能力已远超 GPT-4 时代，Markdown 开始不够用了：AI 几秒生成的内容，我们要花几倍时间才能读完、评估完。输出近乎无限，注意力却有限，这个不对称把思考的成本转嫁给了接收者。要缩小它，就得提升信息传达效率——HTML 的可视化、色彩和图表，正是值得尝试的表现形式。
今年我尝试让 AI 用 HTML 整理长文、探索网站设计、可视化代码变更，意识到要求 AI 输出 HTML，等于让它在生成内容的同时，多承担一份组织和呈现的工作，帮我们更快找到重点。
这些摸索原本零散，直到读到 Thariq Shihipar 的《The Unreasonable Effectiveness of HTML》，才发现类似实践已有人整理成一系列可直接打开的案例。接下来，我结合他的案例和自己的经历，聊聊 HTML 如何让信息更有效地从 AI 传给人，也从人传回 AI。原文与 prompt · 配套案例库
01 读长文：减少寻找和梳理信息的时间
年初，我一度沉迷于让 AI 把长文整理成带可视化图表的 HTML 文档，用多了还为此做了个自用 skill。
目的很简单：读得更有效率。面对信息量大的文章，让 AI 安排好阅读顺序：先看结构，再读论述。摘要告诉我文章讲了什么，关系图则提醒我：分散在各段的几个观点，可能依赖同一个前提。
人的时间有限，不是所有文章都值得精读。这套流程帮我完成第一轮筛选：多数文章读到这里，价值和结论已经清楚；少数值得深入的，再带着梳理出的问题回到原文精读。
Thariq 案例库里有个讲解“一致性哈希”的页面，概念说明、环形图、参数控件和术语解释放在一起，节点可增减。查看交互案例
读完说明还能调参数，看图随之变化——抽象描述和具体例子对照着看，省去在段落间来回寻找。
我还会要求 AI 保留结论的依据和限制条件，避免文档读着顺，却丢了原文的重要限定。把当时的需求重写成 prompt，大致是：
阅读 prompt｜本文整理
请把下面这篇长文整理成一份帮助我深入阅读的单文件 HTML。
开头用简短的内容地图说明文章结构；正文保留核心论点、支持证据和限制条件。适合比较的内容用表格，存在因果或依赖关系的内容用图示。
每个关键结论都标注它对应的原文小节或段落，区分原作者的说法与你补充的解释。没有数据支撑的地方，不要生成定量图表。
详细推导可以折叠，但重要的前提和反例需要直接可见。文档使用中文，适合手机阅读，并能在本地浏览器中打开。
拿到文档后，可按这些要求检查：结构是否清楚、结论能否找到依据、细节能否展开。效率的提升应体现在更容易找到并理解所需信息，而不只是页面变短。
02 做设计：通过比较，减少沟通偏差
年中我开发了 macOS 番茄钟 PomoPip，在 pomopip.com 可免费下载。
设计官网时栽过跟头：我不懂 UI 设计，需求很难说清；AI 生成的 Markdown 规划单本身没问题，可一旦生成真实页面，就得反复抠细节，改到最后仍不满意，过程很低效。
回头看，问题出在方向未定就先改起了细节——细节花再多功夫，页面也不会更接近想要的样子。
后来换了做法：先让 AI 用 HTML 产出多个主题方向，选定后再设计页面和交互。设计稿在浏览器里直接打开，排版、颜色、组件都看得见。需求传达的方式随之改变——过去要把脑中的模糊感觉翻译成文字，再等 AI 变成界面；现在对着几个具体方案直接比较，指出保留和修改的部分。前者花了小半天，最终还放弃了；后者只用一小时。
Thariq 的设计案例用了类似办法：同一个“还没有任务”的空状态，做出极简、插画、轻松活泼、操作引导四种方案，放在一起比较。查看设计案例
案例页的 prompt 可译为：
为我们的空状态组件探索四种视觉方向。直接渲染每种方案，方便比较整体风格、信息密度，以及它们在浅色和深色背景下的表现。
用在我的番茄钟网站上，我会写得更具体：
设计 prompt｜参考案例思路改写
请结合软件现有的主题风格，为对应的官网输出几个 HTML 主题提案。
保持像素游戏风格。每个提案都包含同一组内容：产品名称、一句话介绍、计时器预览和下载入口。
用真实排版、颜色和组件表达各自特点，并简要说明这种设计适合营造什么感受。先做到足够让我判断方向的程度。
给每个提案固定编号。选定后，后续页面沿用它的字体、颜色和间距规则；需要改变整体方向时，明确指出变化。
对着颜色、布局和组件直接讨论，省去大量抽象描述，每轮反馈都有明确指向——传达越准确，后续反复越少。
03 审查代码：更快建立背景，定位重点
代码审查让开头的不对称更具体：AI 不断生成新代码，人却需要时间理解每次修改的目的、影响范围和风险。生成快过审查，待理解的内容就会越积越多。
Bits of Logic 在《Diagrams In Your PRs》里介绍了类似做法：用工具读取代码变更，生成解释图附在 PR 讨论区，说明改动涉及什么。阅读文章
逐行检查之前，先看一张画清模块关系和变化的图：涉及哪些模块、关系如何改变，PR 大致内容一目了然。带着这个背景进入具体代码，不必从零拼接上下文。
我自己也照这个思路，为一个真实的 PR 生成过解释图：改了什么、靠什么机制落地、如何影响下游，一张图就能看全。
Thariq 的 HTML 审查案例则把批注放在代码差异旁，用风险标记提示重点，边看边核对。解释和它指向的代码同处一处，不必来回切换、寻找对应。查看审查案例
案例库里还有一份面向审查者的 PR 说明，编号 #312，prompt 可译为：
请为审查者撰写 PR #312 的说明。解释修改动机，逐个文件讲清改了什么、为什么改，展示修改前后的行为差异，并指出需要重点关注的地方。他们已经六个月没有接触过通知模块的代码了。
我更进一步的想法：把解释图直接做进审查 HTML，让审查者自己决定阅读顺序——先看改动目的和影响范围，再看关系图，最后对照代码。
04 给反馈：让操作直接表达决定
案例库里还有个任务分拣看板：待办事项分 Now、Next、Later、Cut 四列，拖动卡片调整安排，再导出为 Markdown。查看编辑器案例
调整优先级若全靠对话，得反复说清事项名称、原位置和新安排。有了看板，直接移动卡片、检查整体顺序、导出结果。
一份 HTML 文件就能充当这次协作的临时界面：
AI 整理候选项 → HTML 展示 → 人选择或调整 → 导出结果 → AI 继续执行
反馈 prompt｜参考案例思路改写
请把下面这些待办事项整理成一个临时使用的 HTML 决策页面。
每个事项保留唯一编号、名称和必要背景，允许我调整优先级、暂时搁置，并补充自己的理由。页面需清楚区分你的初始建议和我的最终选择。
提供“导出决定”按钮，输出事项编号、最终顺序、处理状态和我的备注。导出内容要足够明确，让下一轮 AI 能据此继续工作。
05 用人的理解成本，衡量输出的价值
回看这些场景，HTML 扮演的角色很一致：读长文时梳理信息、安排顺序；做设计时把抽象方向变成可比较的方案；审代码时快速建立背景、核对细节；给反馈时让操作直接表达决定。
所以我越来越多地让 AI 用 HTML 而非 Markdown 输出。可视化、色彩、图表和交互带来更强的表现力，最终指向同一件事：降低理解成本，提升传达效率。
当 AI 的输出越来越充裕，有限的人类注意力就更值得认真对待。让 AI 输出 HTML，是我提升信息传达效率的一种尝试：让它多做组织，让人少做寻找、猜测和反复确认。
原文与案例
案例页 prompt 为中文译写，其余按本文场景重新整理。开篇配图与图 3 为示意图，其余四张均为案例原站截图；交互效果需打开链接体验。
- Thariq Shihipar：Using Claude Code: The unreasonable effectiveness of HTML
- HTML 案例库：The unreasonable effectiveness of HTML
- Mark Golazeski：Diagrams In Your PRs
本文首发于 blog.chaxg.cn/2026/biaoxianli-zhishang/，转载请保留原文链接。