夜雨聆风大家好，欢迎来到高老三聊AI，我是高老三。
Andrej Karpathy 在 X 上发了一条很有意思的长推。
如果你长期关注 AI，应该对卡帕西不陌生：他是前 OpenAI 研究员、特斯拉前 AI 总监，也是过去几年最擅长把复杂 AI 概念讲清楚的人之一。
这次他没有聊模型参数，也没有聊 benchmark，而是给了一个非常具体的使用建议：
在你的问题最后加一句：
structure your response as HTML，然后把生成的文件放进浏览器里看。
原帖地址在这里：Karpathy 关于 HTML 输出的讨论[1]。
这句话翻译成人话就是：别只让 AI 给你 Markdown，让它直接给你一个 HTML 页面。
我刚看到这条的时候，第一反应是：这不就是让模型换个格式输出吗？
但卡帕西真正想说的不是「HTML 比 Markdown 高级」这么简单。他把这个小技巧放进了一个更大的判断里：AI 和人类之间的输入输出形态，正在重新洗牌。
仔细读完 Karpathy 的完整观点，再结合过去两年几个公开产品和研究线索——Anthropic 的 Claude Artifacts、OpenAI 的 ChatGPT Canvas、Google 的 Gemini Canvas，以及 Google Research 对 Generative UI 的讨论——我觉得这事不是「格式之争」，而是一个更大的方向：AI 的默认输出，正在从文本答案变成视觉界面。
• Karpathy 的核心观点不是「HTML 比 Markdown 高级」，而是 AI 输出正在从文本向视觉、交互、模拟演进。 • 输入端，人类更偏好语音；输出端，人类更偏好视觉。因为大脑有大量资源用于视觉处理，视觉是进入大脑的信息高速公路。 • Markdown 是当前 AI 输出的默认值，但它只解决了「更好读一点」的问题；HTML 进一步把答案变成了可布局、可交互、可运行的界面。 • Claude Artifacts、Canvas、Generative UI 这些产品，本质上都在做同一件事：让 AI 不再只「回复你」，而是直接「给你一个可操作的东西」。 • 现阶段最值得立刻尝试的动作很简单：在复杂问题后加一句 「请把结果组织成一个 HTML 页面」。
一、Karpathy 到底说了什么？
Karpathy 这条推文里，有一句话我觉得特别关键：
audio is the human-preferred input to AIs but vision is the preferred output from them.
翻译过来就是：音频是人类更喜欢给 AI 的输入方式，而视觉是人类更喜欢从 AI 那里接收的输出方式。
这个判断非常有意思。
过去我们讨论 AI 产品形态，最常见的说法是「自然语言交互」：你打字问，AI 打字答。后来语音模型成熟了，大家开始说「语音才是更自然的输入」。
但 Karpathy 往后多想了一步：输入可以是语音，但输出未必也应该是语音或文字。
原因很简单。人类的大脑不是为了读长文本优化的，而是为了看世界优化的。Karpathy 的说法是，大约三分之一的大脑资源都可以看作一个大规模并行的视觉处理器，视觉是进入大脑的「十车道高速公路」。
这也是为什么同样的信息：
• 写成 2000 字文档，你可能看不下去； • 做成一张图，你 10 秒就懂了； • 做成一个可交互页面，你不只是懂，还能自己探索。
所以他提出了一个输出形态的演进序列：
1. Raw text：纯文本，读起来最费劲。 2. Markdown：有标题、加粗、表格，已经比纯文本友好很多，这也是现在的默认值。 3. HTML：底层仍然是代码，但有更强的图形、布局和交互能力，正在成为新的默认方向。 4. 更往后：交互式神经视频、模拟器、由扩散模型直接生成的动态世界。
这不是在说 Markdown 明天就会消失，而是在说：Markdown 可能只是 AI 输出进化史里的一个中间站。
了解了 Karpathy 的核心判断，接下来我们看为什么 HTML 会在这个时间点突然变得重要。
二、为什么偏偏是 HTML？
如果放在十年前，说「以后大家都该用 HTML 写文档」，大概率没人理你。
因为 HTML 对人类来说太麻烦了。你要写标签、写 CSS、考虑布局，还要处理浏览器兼容。Markdown 之所以能火，本质上是因为它对人类友好：# 表示标题，** 表示加粗，几乎不需要学习成本。
但 AI 改变了这个前提。
以前的核心问题是：人写起来方不方便。
现在的核心问题变成了：AI 生成之后，人看起来、用起来方不方便。
这两个问题的答案完全不同。
Markdown 的优势是「易写」。但如果大部分内容都由 AI 写，易写就没那么重要了。HTML 的优势是「易呈现」：它可以做布局、配色、图表、动画、按钮、交互，浏览器还能直接打开。
举个简单例子。
你问 AI：「帮我分析一下这三个技术方案的优缺点」。
如果默认输出 Markdown，它通常会给你一个表格，再加几段解释。
但如果你最后加一句「请组织成 HTML」，它可以给你：
• 左右分栏的方案对比卡片； • 用颜色标出风险等级； • 用 SVG 画出架构流程； • 加一个筛选器，让你按成本、复杂度、收益切换排序； • 甚至加一个「复制最终决策 prompt」按钮，把你的选择重新变成下一轮输入。
这就不只是「答案更好看」了。
它变成了一个小工具。
Claude Artifacts 也是这个方向。Anthropic 在发布 Claude 3.5 Sonnet[2] 时，把 Artifacts 定义为一种新的使用 Claude 的方式：当用户要求生成代码片段、文档或网站设计时，这些内容会出现在对话旁边的独立窗口里，用户可以实时查看、编辑、继续构建。Anthropic 当时的说法很明确：这标志着 Claude 从「对话式 AI」走向「协作式工作环境」。
OpenAI 后来推出的 ChatGPT Canvas[3] 也沿着类似方向走：官方介绍里说，这是一个用于写作和编码项目的新界面，面向的是那些「超出简单聊天」的任务。
Google 在 2025 年 3 月推出 Gemini Canvas[4] 时，也把它定义为 Gemini 里的一个交互式空间：用户可以在里面创建、编辑、分享文档和代码，甚至生成并预览 HTML/React 原型。再往研究侧看，Google Research 对 Generative UI 的表述也很接近：AI 不只是返回一段文字，而是根据任务动态生成丰富、定制、可交互的用户体验。
所以 HTML 的价值，不在于它是一个老技术，而在于它刚好站在三个条件的交汇点上：
• 模型会写代码：LLM 现在已经能稳定生成可运行的 HTML/CSS/JS。 • 浏览器无处不在：HTML 生成之后，不需要安装专门软件就能打开。 • 人类偏好视觉：相比长文本，布局、图表和交互更符合大脑的信息处理方式。
这三个条件叠在一起，HTML 就从「网页开发语言」变成了 AI 输出容器。
了解了为什么是 HTML，接下来我们再往前走一步：它到底改变了人和 AI 的协作方式？
三、从「聊天」到「交付物」
过去我们使用 AI，默认心智是聊天。
你问一句，它答一句。即使它输出了很长的内容，本质上仍然是一段文本。你要自己读、自己判断、自己复制、自己整理。
但 HTML 输出会把这个过程往前推进一层：AI 不只是告诉你答案，而是把答案包装成一个可以直接使用的交付物。
这件事在很多场景里都非常明显。
3.1 学习一个复杂概念
比如你让 AI 解释 Transformer。
Markdown 版本通常是：注意力机制是什么、多头注意力是什么、位置编码是什么。
HTML 版本可以是：左边是概念地图，中间是 token 流动动画，右边是每一步的解释。你点击某个 token，页面高亮它和其他 token 的注意力关系。
这时候你不是在读一篇解释，而是在操作一个学习界面。
3.2 做技术方案评审
比如你让 AI 对比三种架构方案。
Markdown 版本是一张表。
HTML 版本可以是一组卡片，每个方案有成本、风险、交付周期、维护复杂度四个维度。你可以拖动权重滑块，页面实时重新计算推荐结果。
这时候 AI 输出的不再是「建议」，而是一个轻量决策系统。
3.3 做产品原型和演示
比如你想验证一个新功能的交互。
以前你可能要先写 PRD，再找设计师画图，再找前端做 demo。
现在你可以让 AI 先用 HTML 做一个可点的原型：按钮能点、状态能切换、流程能跑。它未必能直接上线，但足够用来讨论、评审、推翻或迭代。
这也是为什么 Claude Artifacts、v0、ChatGPT Canvas、Gemini Canvas 这类产品会越来越重要。它们不是单纯让 AI 「写代码」，而是让 AI 生成可被人感知和操作的中间态。
这中间态非常关键。
因为很多需求不是靠文字讨论清楚的，而是靠看见、点击、拖动之后才会暴露出来。
了解了 HTML 如何把答案变成交付物，接下来我们聊 Karpathy 提到的另一个方向：输入端也还远远没结束。
四、输入端也不只是语音
Karpathy 说，音频、文本、视频单独看都不够。
他提到一个很具体的体感：当他和 AI 协作时，会想指着屏幕上的某个地方、做一些手势，就像旁边真的坐着一个人一样。
这个细节特别真实。
我们和真人协作时，很少只靠语言。你会说：
• 「这里不对」——同时手指指向屏幕某个区域； • 「这个往上挪一点」——同时做一个向上的手势； • 「保留这个，删掉旁边那块」——同时框选某个区域； • 「你看这个趋势」——同时划过一条曲线。
这些动作本质上都是输入。
但现在的大多数 AI 产品，仍然把输入压缩成一个文本框。即使支持语音或截图，也经常是分离的：你上传截图，再用文字描述；你说一段话，但 AI 不知道你眼睛正在看哪里、手指正在指哪里。
真正自然的人机协作，可能需要把这些信号合在一起：
• 语音：表达意图最快； • 鼠标/手势：定位对象最准； • 屏幕上下文：提供当前任务环境； • 视觉反馈：让 AI 的结果能被快速验证； • 交互页面：把下一轮修改变成可操作的动作。
这就是 Karpathy 所说的 mind meld：人和 AI 的输入输出逐渐融合。
它还远没有到 Neuralink 那种脑机接口的阶段。更现实的路径，是先把我们已经有的设备用到极致：麦克风、屏幕、摄像头、鼠标、触控板、浏览器。
换句话说，真正的下一代 AI 交互，不一定先发生在脑机接口里，反而可能先发生在一个普通浏览器窗口里。
五、现阶段最值得试的 5 个 Prompt
说了这么多，回到今天最实用的部分：普通人现在怎么用？
你不需要等什么新产品，也不需要安装复杂工具。直接在复杂问题后面加一句「请用 HTML 组织输出」就可以。
我给你 5 个可以直接复制的版本。
5.1 复杂概念学习
请解释这个概念，并把结果组织成一个单文件 HTML 页面。要求包含：概念地图、关键术语卡片、一个流程图、三个常见误区，以及适合初学者的交互式小测验。
5.2 技术方案对比
请对比这几个方案，并输出为 HTML。要求用卡片展示每个方案的优缺点，用颜色标出风险等级，最后给一个可调整权重的决策矩阵：成本、复杂度、长期维护、上线速度四个维度。
5.3 代码理解
请阅读下面这段代码，并生成一个 HTML 讲解页面。要求包含调用链图、关键函数说明、状态变化流程、可能的 bug 点，以及适合新人 onboarding 的阅读顺序。
5.4 会议纪要转行动看板
请把这份会议纪要整理成一个 HTML 行动看板。按负责人、优先级、截止时间分组，提供筛选按钮，并在顶部给出本周最重要的 3 个风险。
5.5 产品原型探索
请基于这个需求生成一个单文件 HTML 原型。要求至少包含 3 个页面状态、可点击的主要流程、移动端宽度适配，以及每个交互背后的设计意图说明。
注意，这里有一个小技巧：不要只说「输出 HTML」。
你最好顺手告诉它这个 HTML 应该承担什么角色：学习页面、决策矩阵、代码讲解、行动看板、可点击原型。角色越明确，AI 越容易从「写文章」切换到「做界面」。
「我的一点看法」
Karpathy 这条推文让我感兴趣的地方，不只是他推荐了一个「让 LLM 输出 HTML」的小技巧，而是他把这个技巧放进了一个更大的判断里：AI 的输出不应该被默认锁死在文本里。
「structure your response as HTML」这个细节特别能说明问题——它不是让答案变得花哨，而是让答案从线性文本变成可布局、可导航、可交互的信息界面。这背后的假设是：当 AI 负责生产内容时，人类真正稀缺的不是写作能力，而是理解、判断和操作的带宽。
这和当前很多「聊天机器人」产品走的是完全不同的路：大多数产品还在优化回答本身，而 Karpathy 指向的是回答的载体。前者是在把文本写得更好，后者是在问：这个结果能不能直接变成一个工具、一个画布、一个模拟器？
另外，输入端的「指点和手势」也很值得关注。它提醒我们，所谓多模态不是简单把文字、语音、图片都接进来，而是要让这些信号围绕同一个任务上下文协同工作。这对于未来的 AI Agent 来说，是非常值得借鉴的交互模式。
最后，今天就可以试一下
如果你想立刻体验 Karpathy 说的这个方向，可以从最简单的一句话开始：
请把你的回答组织成一个单文件 HTML 页面，我会在浏览器里打开查看。
再进阶一点，可以补充：
1. 说明页面用途：学习、评审、决策、演示、原型。 2. 要求包含交互：筛选、展开、滑块、按钮、复制结果。 3. 要求单文件：HTML、CSS、JS 都内联，方便直接保存打开。 4. 让它输出下一轮 Prompt：把你在页面里的选择，整理成可以继续喂给 AI 的文本。
这可能是目前最便宜、最容易上手的一次 AI 交互升级。
不需要新硬件，不需要脑机接口，也不需要等什么终极产品。
你只需要在下一次提问最后，加一句：「请用 HTML 呈现。」
以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧，如果想第一时间收到推送，也可以给我个关注～谢谢你看我的文章，我们，下次再见。
引用链接
[1] Karpathy 关于 HTML 输出的讨论: https://x.com/karpathy/status/2053872850101285137[2] Claude 3.5 Sonnet: https://www.anthropic.com/news/claude-3-5-sonnet[3] ChatGPT Canvas: https://openai.com/index/introducing-canvas/[4] Gemini Canvas: https://blog.google/products-and-platforms/products/gemini/gemini-collaboration-features/
