AI 回答又臭又长？原因竟然在于 Markdown

自从 AI 出现后，Markdown 理念盛行，大家都觉得理所应当和 AI 交互都使用 Markdown 了。

直到这个月初，Claude Code 团队的 Thariq 发了一条推文，大意是：是时候用 HTML 替代 Markdown 了。然后在互联网上炸了锅，到处都是跳出来说什么“Markdown 已死，HTML 当立”的话。

一开始我还没留意，以为不过又是个互联网热度噱头。这段时间仔细去研究了下才发现，别人说的重点不是输入而是输出。

正如 Thariq 说的，超过 100 行的 Markdown，让谁读起来都很痛苦。

平时我自己看 Markdown 文档的时候会用 Typora 或者其它工具，然后配上好看的主题，好像看起来也还行？标题、列表、表格、代码块，该有的都有。自然不会想到去让 AI 多写一堆 HTML 标签，又浪费 token 又增加了复杂度。

然鹅当我实操了之后，真香。

至少我现在看来，这必定是未来人机协作的趋势。不单单是因为它确实好看，而是因为我突然意识到：我们一直在用"写文档"的方式，让 AI 回答"需要看界面"的问题。

Markdown 的问题，和 HTML 的解法

很多人都说 AI 经常回答得"又臭又长"，但没毛病，你觉得会有的问题那可能就是有问题。

Markdown 最大的问题不是丑，是太线性。所有信息只能从上往下排，一旦信息变复杂，毛病就暴露了：

• 横向对比做不了（你问三个方案怎么选，它列三段各自优缺点，你得自己来回跳着看）；
• 重点埋在文字里（核心结论和补充说明最终都只是黑字，没有阅读路径）；
• 结构只能靠想象（流程、架构、决策树写出来就是嵌套列表，读者得在脑子里自己还原）。

Markdown 是写给文档系统看的，HTML 是写给人的视觉系统看的。这不是格式偏好，是信息组织方式的根本区别。

笔记、技术文档、知识库，Markdown 天然合适；方案对比、信息汇总、流程讲解、学习材料，Markdown 就开始吃力了，HTML 片段更合适。

未来不是谁取代谁，而是Markdown + 局部 HTML成为新常态——正文用 Markdown 写，遇到复杂结构就让 HTML 出场，就像文章里插图表一样自然。

下面我就用 HTML 来解决这三个问题的案例。

1. 多方案对比

HTML 可以做卡片式并排，每个方案一个独立区块，优缺点固定在同一位置，读者一眼看出差异，不用来回跳。

如果正常获取到的 AI 回答可能是这样：

相比很多复杂比对来说，这个比对其实也还算比较清晰。然后我使用 Html 方式返回的效果如下：

是不是更加一目了然了？那么你会更喜欢什么风格呢？

2. 信息汇总

直播整理、发布会总结、产品更新日志，纯 Markdown 很容易变成一长串 bullet point。HTML 可以把信息分层：核心结论放最上面，关键数据单独成块，细节折叠起来。读者先抓住重点，再决定要不要展开。

这是使用 HTML 输出的效果：

3. 学习讲解

这是 HTML 优势最明显的地方。很多知识不是线性的，是结构关系：概念对比、模块组成、因果链条、状态变化。文字只能让你自己在脑子里拼图，HTML 直接把关系画出来。流程图、树状结构、分层卡片，用局部 HTML 表达，理解效率完全不一样。

这里我试着输出了下 Redis 的知识学习体系，效果我自认为还算不错：

有没有觉得好像比普通 AI 答复看起来更易懂了呢？

Token 代价当然也有，但不是不能接受

说完好处说说不好的地方，至少这4个地方是需要注意的。

Token 消耗翻倍

社区有人做过实测，同样的问题，HTML 版 token 消耗大概是纯 Markdown 的 2-3 倍：

差距不小，但你也要换个角度想：AI 在 Agent 中调用消耗的 token 大头不在输出，在执行任务时真实消耗远比这多得多，真正写给你看的那部分在总消耗里占比很小。这一小部分翻 2-3 倍，换来的是你能快速看懂、不用返工确认。

渲染环境碎片化

Markdown 哪里都能看，HTML 就看运气了。有些客户端直接渲染，有些只显示源码。用之前先确认你的工具链能不能稳定渲染——如果读者看到的是一堆<div style="...">源码，那体验比纯 Markdown 还差。我知道的 Cherry Studio、Claude 官网，GLM 官网、Obsidian（部分）等等都支持。另外网页端可以装油猴脚本实现实时渲染，当然现在的效果因模型和网页渲染能力可能有所不同。

相比 Markdown 来说不好改

Markdown 改起来很直觉，你当做正常的文本编辑就行了。而 HTML 片段里一堆内联样式，普通用户看着就费劲，更别说改了。所以 HTML 更适合当"阅读视图"，不适合当"编辑源"。长期保存的内容，底层还是 Markdown。

模型容易过度设计

一旦你告诉模型"可以用 HTML"，它可能开始表演：十几个卡片、每个都加阴影、一堆颜色表达不重要的信息、三句话能说完的硬做成组件。所以提示词要写得克制。

具体怎么用：提示词方案和判断标准

不要写"以后全部用 HTML 回答"，这会失控。给 AI 一个明确边界就行：只有 Markdown 表达吃力时，才局部使用 HTML。

触发条件：多方案横向对比、复杂流程或决策树、信息量大需要分组、时间线/状态变化/系统结构、纯列表会导致阅读疲劳的长内容。

红线：不输出完整页面（不要 html/head/body）、不整篇包在一个大 div 里、用内联样式不依赖外部 CSS、不为装饰生成图形、优先内容清楚其次视觉效果。

这是社区佬公开的提示词，直接复制就能用：

<format><rule>标题从 ## 起，子层级使用 ###；禁用 #</rule><rule>使用简体中文</rule><rule>保持高信息密度和紧凑的行文</rule><rule>保持紧凑的回复格式，避免松散的内容给用户带来阅读障碍</rule><rule>代码块标注语言，优先完整可运行，复杂逻辑添加注释</rule><html-visual><rationale>纯 Markdown 的固定垂直流式结构在表达复杂逻辑时存在先天缺陷（阅读疲劳、重点不突出、缺乏真正的图表与横向排版能力）。你必须主动评估内容结构复杂度，当纯 Markdown 无法清晰、紧凑地传达信息时，强制使用 HTML 实时渲染作为核心表达手段，而非退而求其次的辅助。</rationale><css-constraint>绝对禁止使用`<style>`标签、`class`属性及伪类/伪元素。 可视化必须100%采用纯内联样式（`style="..."`），仅依赖 Flexbox 与基础盒子模型（padding/margin/border/box-shadow/背景色差）构建视觉层级。</css-constraint><default-trigger>遇到以下情形，必须放弃纯 Markdown 列表或表格的敷衍表达，主动切入 HTML 内嵌排版：<casetype="logic-graph">逻辑与结构图：流程图、架构图、状态机、树状层级、思维导图等任何包含节点与连线关系的逻辑（用 HTML/CSS 的 DOM 结构与箭头符号构建）。</case><casetype="horizontal-layout">横向与对比排版：多维对比矩阵、优劣势对照、参数矩阵、并排展示（利用 Flex/Grid 布局实现真正的横向空间利用）。</case><casetype="info-card">数据与信息卡片：多字段聚合展示、需要视觉分组与边框隔离的密集信息。</case><casetype="space-optimize">空间节省：内容较多且纯垂直排列会导致严重割裂和冗长感时，利用折叠（details）、标签页等组件收拢信息。</case></default-trigger><vision-plus>Vision+ 指令是视觉表达能力的升维，仅当用户显式声明时启用。<capability>可用内联 HTML 绘制矢量逻辑图、结构连线、几何图形与数据图表，但仍须遵守下方红线。</capability><capability>可用更复杂的 CSS 特效和高级交互组件，但不得用于纯装饰目的。</capability><red-line>1. HTML 片段占比不得喧宾夺主 2. 每个可视化片段必须服务于具体的信息表达需求。 3. 绝对禁止输出 !DOCTYPE/html/head/body 全量页面框架；禁止将整段回复包裹于单一 HTML 块。 4. 图形仅限：流程图、架构图、状态机、树状层级、对比矩阵、数据图表。禁止：装饰性插画、氛围图、风景、图标装饰。 5. 在采用html表达时，请同时考虑Token效率与效果的取舍，及渲染难度和错误率，不要过度设计造成效果失衡。 6. 过于复杂的html可视化内容需慎重考虑。</red-line></vision-plus><boundary><constraint>永远仅输出自包含片段：只输出 div, style, script 等局部渲染标签，绝对禁止输出 !DOCTYPE, html, head, body 等全量页面框架结构，本末倒置将导致直接判错。</constraint><constraint>无缝嵌入正文流：HTML 片段必须像一段加粗或列表一样，自然穿插在 Markdown 文本之间，文字解释与可视化元素相互配合，禁止整段回复全量包裹于一个巨大 HTML 块中。</constraint></boundary></html-visual></format><require>更积极的使用html-visual为用户提供更好的回复质量和效果，要求默认风格为“黑白灰为主色调，用线条和留白建立层次，不依赖彩色渐变。需突出和强调的内容鼓励彩色的高级克制的使用，突出设计感”。</require>

你可以选择放在系统提示词或客户端的记忆文件里长期生效。

Cherry Studio 中支持是比较完善的，如果是其它客户端需要自己测试生效。至于网页端可以尝试另一个社区佬做的油猴插件，应该也会持续更新：
greasyfork.org/zh-CN/scripts/579427-ai-raw-html-fragment-renderer

怎么判断该不该用？

问自己一个问题：这段 AI 输出，是给机器继续处理，还是给人马上阅读？

给机器的（代码说明、知识库、项目文档、后续要让 AI 读取修改的）→ Markdown。

给人的（方案汇报、学习讲解、复杂信息总结、要发给别人看的）→ HTML 增强。

最后说几句

未来人机协作里，人通过 Markdown 和 AI 进行交互，AI 通过 HTML 给人类展示。

这就是未来的趋势之一，各个大模型厂商应该都会向这边进行倾向。

但在现在，如果想体验，我觉得会分三步。

• 现在：Markdown + 内嵌 HTML
  门槛低效果明显，但 token 浪费、样式重复。
• 下一步：模板化组件
  模型输出结构化数据，客户端用预置组件渲染，省 token 视觉统一。
• 最终形态：AI 直接生成交互界面
  你问"三个方案怎么选"，它给你的不是 3000 字，而是一个对比面板、一个权重滑块、一个风险提示区，点击每个因素可以展开解释——模型负责意图和数据，客户端负责渲染交互。

人和 AI 的交互，不应该永远停留在"你发一段话，我回一段话"。很多任务天然更适合界面：选择、比较、筛选、调整、确认。文本是最通用的起点，但不是终点。

不过话说回来，HTML 输出不是万能药。如果 AI 的判断是空的、逻辑是散的、信息是水的，换成 HTML 只会变成更漂亮的废话。好的 AI 输出，顺序永远是：先有准确判断，再有清晰结构，最后才是视觉呈现。

Markdown 和 HTML 的争论，表面是格式之争，本质是 AI 输出正在进入下一个阶段——从"把话说出来"，变成"把信息组织成可理解的界面"。

我是单向箔，我们下次再见。