夜雨聆风AI 输出的形态正在变
Claude Code工程师Thariq在 X上分析的一篇文章火了，文章热度已经超过300万观看。
文章说到他基本不用 Markdown 了，开始更喜欢使用 HTML 作为输出格式， Claude Code 团队中的其他人亦是如此。结果网络上又各种markdown已死，markdown被抛弃的言论，markdown才刚火起来又被按在地上摩擦了，我也是无语了。
这篇文章我也详细看了一下，其实作者并没有否定markdown的作用，他说的不是"Markdown 不好"，而是：超过一百行的 Markdown 文件，他就不太愿意读了。更不要说让公司其他人去读。他越来越不亲自编辑这些文件，而是把它们当作 spec、参考资料、头脑风暴输出，再让 Claude 修改。
所以Markdown 还是agent与人沟通时输入使用的主要文件格式，作者只是认为markdown在作为输出的时候，不够丰富，特别是在大模型足够强大的当下语境来说，HTML的特性，使得它能够成为一个输出的界面，而且仅仅是面向人类的。当然，不排除作者的文章有强调claude的强大，卖token的嫌疑。
在AI环境下，人类角色从编辑者变成审阅者，当人不再逐字编辑，而是审阅、选择、反馈——Markdown 的最大优势就消失了。
我觉得这不是格式偏好，也不是某个格式被杀死了，而是AI大模型发展到当下，工作流又产生了一些变化而已。
这件事值得认真想一想：AI 的输出，正在从"可编辑文本"变成"可操作界面"。
Markdown 的真正问题：线性化
Markdown 的成功不是偶然的。用最小的标记成本给纯文本加层次，可移植、可 diff、可版本控制，开发者工具链对它的支持极好。
但它有一个根本性的局限：它会把所有信息压扁成一条线。
空间关系、对照关系、流程关系、严重性层级、交互参数——Markdown 把这些全部线性化。当 AI 只需要写几十行方案，这没问题。但当 AI 开始写几百行的实现计划、多模块的架构设计、跨文件的分析报告，Markdown 就开始倒逼 AI 做出更低效的选择。
你怎么在 Markdown 里画一张真正的架构图？ASCII art。你怎么展示颜色？用 Unicode 字符凑。原文里贴了一张截图，Claude Code 用各种字符拼出了颜色色块——看起来既可爱又荒诞。
这是格式在限制 AI 的表达上限。
HTML 为什么有效：把人放回工作流
Thariq说，他最初有一个担心：因为不再深入阅读计划，他会不得不任由 Claude 自行做出选择，自己慢慢退出工作流。
HTML 解决了这个问题。
HTML 能做的不只是"更多功能"——表格、CSS 样式、SVG 矢量图、JavaScript 交互、响应式布局。更重要的是，它改变了人的参与方式。
他举了几个具体场景：
审查 PR 时，让 Claude 生成一个 HTML 文件，带 diff 渲染、行内注释、颜色标注严重性。比默认的 GitHub diff 视图更清晰，他现在每个 PR 都附带一份 HTML 解释文件。
做设计探索时，让 Claude 生成六种不同风格的 onboarding 页面，并排放在一个 HTML 网格里，每个标注了它的取舍。这比"列出六种方案"的文字描述有效得多。
写功能计划时，生成一个 HTML 文件，里面有模块图、代码片段、流程图、导航标签。读这个和读一份 Markdown 长文，体验天差地别。
他说，用 HTML 之后，他感觉自己比以往任何时候都更能掌控全局。这才是 HTML 的真正价值——不是装饰，而是把人重新放回 AI 工作流。
最有意思的新物种：一次性 HTML 工具
有一类用法他叫做"一次性编辑器"，是整篇文章里最有新意的部分。
不是文档，不是产品，不是可复用的工具——而是一个专门为本次任务生成的单文件 HTML，用完即丢。
比如：让 Claude 把 30 张 Linear 任务卡做成可拖拽的看板，分成"立即 / 下一步 / 稍后 / 取消"四列，预先排好序，操作完后点"复制为 Markdown"导出。
或者：给系统提示词做一个并排编辑器，左边可编辑提示词，右边实时渲染三个示例输入，带字符计数和复制按钮。
诀窍是：始终以导出结束。一个"复制为 JSON"或"复制为提示词"按钮，把 UI 里的操作结果转回 Claude Code 能接收的格式。
这背后有一个更大的变化：AI 让一次性软件变得经济了。过去为了整理 30 个任务单专门做一个拖拽工具不划算；现在让 Claude 生成一个单文件 HTML，任务完成就丢掉，成本低到可以随用随生成。
JSON：不是展示层，是机器协作层
说完 HTML，这里我要提第三个角色：JSON。
但 JSON 不是来和 HTML 竞争的。它站在完全不同的位置——不是给人读的，是给程序读的。
当 AI agent 之间需要协作，当一个 LLM 的输出要成为另一个系统的输入，你需要一个格式，可以被程序可靠地解析，字段有固定的键名，类型可验证，结构可嵌套。这就是 JSON。
OpenAI 的 Structured Outputs、Anthropic 的 tool use，本质上都是在用 JSON 定义工具接口，让模型输出结构化的函数调用。几乎所有的 agent framework，底层的数据流都是 JSON。
想象一个多步骤的 agent workflow：第一个 agent 搜索资料，第二个分析，第三个写报告。这条流水线里，每一步的输出都是下一步的输入。用自然语言传递？信息会丢失、会歧义。用 JSON，字段精确，类型明确，前后两个 agent 都能可靠地读写。
JSON 是管道里流动的数据，HTML 是管道末端给人看的界面。
三层分工
Markdown for agent workflow。
HTML for human interface。
JSON for machine protocol。
Markdown 适合 agent 工作流。写给 agent 看的 spec、注释、说明、知识库条目——这些场景里 Markdown 依然是最轻量、最高效的选择。它没有死，只是找到了自己真正的位置。
HTML 适合人类界面。当输出对象是人，当你需要审阅、比较、点击、调参、演示、分享给团队——HTML 就不再是格式，而是界面。生成速度比 Markdown 慢 2-4 倍，但实际被读完的概率高得多。
JSON 适合机器协议。不是给人读的，是给程序读的。让 AI 系统之间能够可靠地传递结构化数据，是 agent 之间通信的通用语。
这三种格式不是竞争关系，是分工关系。一个成熟的 AI 工作流里，你可能同时用到三种：JSON 在系统层流转任务状态，Markdown 在中间层写给 agent 的指令和 spec，HTML 在表现层生成可读报告和交互工具。
Markdown 诱导模型写解释，HTML 诱导模型做界面，JSON 诱导模型给结构化数据。你给 AI 的格式要求，其实是在引导模型用什么方式思考和交付。
格式选择就是工作流设计
这件事在 AI 普及之前并不那么重要。
以前你选择什么格式，主要影响的是自己的写作体验。现在，你给 AI 选择什么输出格式，直接影响 AI 能够给你呈现什么级别的信息，也直接影响你自己在这个工作流里的参与方式。
Markdown 格式的限制，会迫使 AI 在表达视觉信息时降级到 ASCII art。HTML 格式的开放，会让 AI 自然地使用 SVG、CSS、JavaScript 来表达同样的内容。JSON 格式的约束，让 AI 的输出能被程序可靠地消费，而不是让下游系统自己去解析自然语言。
所以问题不是以后该不该抛弃 Markdown。真正的问题是：这次任务里，人类下一步要怎么参与？
如果只是读一段说明，Markdown 够了。如果要审阅复杂结构、比较多个方案、调整参数、拖拽排序、复制结果再交给 AI，HTML 就不再是格式，而是界面。如果要让另一个系统继续执行，JSON 才是答案。
格式不只是包装。格式选择，就是工作流设计。
你现在让 AI 输出内容，默认用的是什么格式？在哪些场景下你切换过——或者想切换但还没试过？
欢迎在评论区聊聊你的实际用法。
