引言
最近，Claude Code 工程师 Thariq 的一篇文章在 X 上引发了超过 300 万次浏览的热议。他说自己越来越少用 Markdown，转而让 AI 输出 HTML 格式。网络上随即涌现出"Markdown 已死"的声音。
但我读完全文，感受截然不同——不是某个格式死了，而是 AI 工作流正在进化，三种格式各自找到了自己的位置。
更重要的是，这篇文章描述的，恰好是我在开发 AI 驱动产品时亲身踩出来的路。我不是读完文章才明白这件事，而是先做出来了，再读到文章时，发现彼此完美印证。
这篇文章，我想从实践者的视角，讲清楚一件事：
“在 AI Agent 工作流中，Markdown、HTML、JSON 不是竞争关系，而是三层感知通道。缺少任何一层，闭环就会断裂。
”
一、先从一个真实的开发场景说起
我最近在开发一个需要 AI 持续生成并自我检查视觉输出结果的产品。产品的核心逻辑是：AI 根据需求生成内容，渲染出可视化结果，再判断结果是否符合预期，不满足则自动修改，循环迭代直到达标。
听起来简单，但实现起来有一个根本性的难题：AI 生成了内容，但它自己看不见渲染效果。
最初的做法是：让 AI 生成内容 → 我手动打开浏览器查看 → 发现问题 → 再描述给 AI → AI 修改。这个流程里，**人是唯一的"眼睛"**，效率极低，每一轮迭代都需要我介入。
后来我引入了一套三层格式管线：
-
用 Markdown 写给 AI 的设计指令和约束规范 -
用 HTML 渲染可视化结果，让 AI 通过浏览器控制工具"看见"自己的输出 -
用 JSON 在多个程序模块之间传递状态、反馈和任务数据
结果是：AI 能够自己检查渲染效果，自己发现问题，自己驱动下一轮修改，人退出了审阅环节，闭环自动运转。
传统人工迭代与 AI 视觉自检自主闭环的对比，如图1所示。
图1：传统人工审阅迭代（左）与引入感知通道后的 AI 自主闭环（右）效能对比
这不是理论，是跑通了的实践。
二、Markdown：写给 Agent 的语言，不是写给人看的文档
很多人对 Markdown 的理解还停留在"写文档"的阶段。但在 AI 工作流里，Markdown 的核心角色是指令载体——它是人类和 Agent 之间沟通的语言。
为什么是 Markdown 而不是纯自然语言？
因为 Markdown 有结构。标题层级、列表、代码块、加粗——这些标记不是装饰，而是在告诉 AI：这是一个约束条件，这是一个步骤，这是一段需要执行的代码。结构化的输入，会引导模型产生结构化的思考。
在我的开发流程里，每一条给 AI 的设计指令都是 Markdown 格式：
## 生成约束
- 禁止设计过于复杂的细节结构
- 控制在规定的尺寸范围内
- 优先使用标准组件，避免异形件
这不是给人读的文档，是给 Agent 执行的 spec。Markdown 的轻量性让它成为最高效的指令格式——没有多余的渲染开销，直接进入模型的上下文窗口。
Thariq 文章里也明确说了：他不是不用 Markdown，而是不再把它当输出格式。Markdown 依然是 Agent 工作流里最重要的输入格式。
三、HTML：AI 的眼睛，不只是人的界面
Thariq 文章里说，HTML 的价值在于"把人重新放回工作流"——让人能够更好地审阅、比较、交互。这个观点没错，但我认为还不够完整。
HTML 不只是给人看的界面，它也可以是 AI 的感知通道。
当 AI 生成了一段内容，它本身无法判断渲染出来的视觉结果是否符合预期。但如果把这段内容嵌入 HTML，通过浏览器渲染，再用 Chrome DevTools 协议让 AI 截图或读取页面状态——AI 就有了"眼睛"。
这个闭环的结构是这样的：
AI 生成内容（Markdown 指令驱动）
↓
嵌入 HTML，浏览器渲染（视觉化）
↓
AI 通过 DevTools 截图 / 读取渲染状态
↓
发现问题 → JSON 记录反馈
↓
Markdown 指令驱动下一轮修改
↓
循环，直到满足约束条件
在这个流程里，人完全退出了审阅环节。AI 自己看，自己判断，自己改。这才是 HTML 在 AI 时代最深层的价值——不只是让人看得更清楚，而是让 AI 也能"看见"。
这个以 HTML 作为感知媒介的技术闭环具体流转过程如图2所示。
图2：以 Agent Core 为核心、以 HTML 渲染和 DevTools 采集为视觉通道的自动迭代闭环
Thariq 提到的一次性 HTML 工具也印证了这一点：生成一个专为本次任务设计的单文件 HTML，用完即丢。这背后的逻辑是，AI 让一次性软件变得经济了。过去为了一个临时任务专门做一个交互工具不划算；现在让 AI 生成一个单文件 HTML，任务完成就丢掉，成本低到可以随用随生成。
四、JSON：流动在管道里的神经信号
如果说 Markdown 是语言，HTML 是眼睛，那么 JSON 就是神经信号——在各个模块之间高速、精确地传递状态。
在我的开发管线里，JSON 承担的是跨模块通信的职责：各个处理阶段的输出成为下一阶段的输入，状态、反馈、修改建议都通过 JSON 结构化地流转，确保信息在模块间传递时不失真、不歧义。
为什么不用自然语言传递这些信息？因为自然语言会丢失精度，会产生歧义，无法被程序可靠解析。JSON 的字段精确，类型明确，前后两个模块都能可靠地读写。
OpenAI 的 Structured Outputs、Anthropic 的 tool use，本质上都是在用 JSON 定义工具接口。几乎所有的 Agent framework，底层的数据流都是 JSON。这不是偶然，而是工程实践筛选出来的必然结果。
一个多步骤的 Agent workflow，如果没有 JSON 作为数据协议，各模块之间的信息传递就会退化成自然语言的"口口相传"——信息衰减，错误累积，系统越复杂越不可靠。
五、三层缺一不可：断掉任何一层，闭环就会失效
这三种格式的分工，不是理论上的优雅，而是工程上的必要：
|
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
这三层感知通道在系统运行中的协作架构如图3所示。
图3：指令层 (Markdown)、感知层 (HTML) 与协议层 (JSON) 的层级堆叠与控制流/状态流反馈闭环
我在开发早期曾经尝试过只用 Markdown + JSON，不引入 HTML 渲染环节。结果是：AI 能执行任务，能传递数据，但无法感知视觉输出的质量。内容生成出来，但效果异常，AI 自己发现不了，只能靠人肉眼检查。
引入 HTML + 浏览器控制之后，这个问题消失了。AI 开始能够自主发现渲染异常，自主触发修改，迭代速度提升了数倍。
这就是三层格式分工的工程价值：不是让工作流更优雅，而是让闭环真正能跑起来。
六、更大的视角：格式选择就是工作流设计
回到 Thariq 文章的核心观点：格式不只是包装，格式选择就是工作流设计。
这句话在 AI 时代之前并不那么重要。以前你选择什么格式，主要影响的是自己的写作体验。现在，你给 AI 指定的输出格式，直接影响：
-
AI 能够呈现什么层级的信息——Markdown 格式会迫使 AI 用 ASCII art 画架构图；HTML 格式会让 AI 自然地使用 SVG、CSS、JavaScript 表达同样的内容。 -
AI 自身的感知能力——没有 HTML 渲染环节，AI 就是"盲的"；没有 JSON 协议，AI 模块之间就是"聋的"。 -
人在工作流中的参与方式——格式决定了人是审阅者、编辑者，还是可以完全退出，让 AI 自主运转。
这是一个被严重低估的设计决策。很多人在搭建 AI 工作流时，花大量时间调优提示词，却很少认真思考输出格式的选择。但实际上，格式选择往往比提示词优化更能影响系统的整体效能。
结论
Markdown 没有死，它找到了自己真正的位置——AI 工作流的指令层。
HTML 不只是更好看的文档，它是AI 的感知通道，让模型能够"看见"自己的输出，实现自主迭代闭环。
JSON 是机器协作的神经信号，让多模块 Agent 系统能够精确、可靠地传递状态。
三者的分工，不是格式偏好的问题，而是 AI Agent 系统的工程架构问题。在一个成熟的 AI 工作流里，你需要同时用好这三种格式：JSON 在系统层流转任务状态，Markdown 在中间层驱动 Agent 执行，HTML 在感知层让 AI 和人都能"看见"结果。
缺少任何一层，闭环就会断裂。
这不是理论，是跑通了的实践。
参考文献
-
[1] Thariq Shihipar：为什么我越来越少用 Markdown，转而用 HTML -
[2] Anthropic Claude：Tool Use 与 Structured Outputs 文档 -
[3] OpenAI Structured Outputs 官方文档 -
[4] Chrome DevTools Protocol 官方文档