AI 输出该用 HTML 还是 Markdown

嘿，是我，Nova。我一直在收到的问题——来自朋友、私信和评论——各种变体都在问同一件事：现在是不是该让我的 AI Agent 输出 HTML，而不是 Markdown？

答案取决于一个变量：**你拿这份输出去干什么。**不是抽象意义上哪个格式「更好」，也不是这个月哪个更时髦，而是这份输出要完成的活。这就是思考 AI 输出该用 HTML 还是 Markdown 的全部框架，下面我讲讲我是怎么具体应用的。

快速决策表

进入分析之前，先给你我一直记在脑子里的速查表。四个场景、两种格式、每个都给出推荐。

这是简版。文章剩下的部分，讲的是每个格子背后的「为什么」。

输出是内部、可编辑、带版本管理的：用 Markdown

Markdown 不会消失。这点我要说清楚，因为「HTML 是新的 Markdown」这类讨论，听起来就像 Markdown 坏了似的。它没坏。

以下是 AI Agent 仍然该默认用 Markdown 的场景：

**任何要进版本管理的东西。**如果输出要进 Git 仓库——README、变更日志、技术规格、CLAUDE.md 文件——Markdown 的 diff 干净可读，HTML 的 diff 纯属噪声。我试过在 pull request 里审 HTML diff，那感觉就像隔着万花筒读一份被红笔批注过的法律文件，没法用。

**Agent 到 Agent 的交接。**当一个 AI 步骤的产出要被另一个 AI 步骤消费时，没有人类会看到它。没人看，就不需要视觉层级。Markdown 能压低 token 成本、解析也简单。Markdown Guide说得很好：这个格式的设计目标，就是连原始源码本身都可读。对机器消费来说，「源码可读」这个特质无关紧要——但 token 效率要紧。

**快速笔记和草稿。**如果我让 Claude 头脑风暴十个点子或列一个项目大纲，Markdown 生成更快、编辑更容易、任何文本编辑器里都能直接读。一张看一遍就删的清单，我不需要折叠区块。

规律是：**输出要被编辑、进版本管理或给机器消费时，Markdown 赢。**这一点没变过。

需要人来查看、对比、交互：用 HTML

报告、评审、看板、规格、原型

真正的转变在这里。Anthropic Claude Code 团队的 Thariq Shihipar 发布他的AI 生成 HTML 配套示例时，打动我的不是技术论证——而是把同一份实施方案在两种格式里各打开一次，亲身感受到的差别。

Markdown 版不赖。HTML 版有吸顶的导航侧栏、按颜色分级的优先级、可折叠的区块。我把整篇读完了——平时我通常不会读完。

我是这样判断 HTML 成果物什么时候值得出手的：

**报告和评审。**凡是人类需要扫读、对比章节、在文档各部分之间跳转的场合。HTML 给你锚点链接、目录、视觉分组。一份季度评审用 Markdown 呈现就是一次长滚动；用 HTML 呈现就是一个仪表盘。

**代码评审和 PR 摘要。**Thariq 的示例里有带内联 diff 注释、按颜色标注严重程度的 PR 评审。那是 Markdown 字面上无法表达的信息架构——它没有「把这两样并排、并把左边涂成红色」的语法。

**原型和线框。**如果你的 Agent 能产出一个能跑的 HTML 原型——落地页、表单、仪表盘布局——那是交付物，不是文档。你可以在浏览器里打开它、发给客户、在上面迭代。Markdown 做不到。

**可分享的成果。**带内联 CSS 的 HTML 文件很好传：发邮件、任何设备上都能打开、不需要渲染器。Markdown 需要渲染引擎才能「像样」——而且用哪个引擎很关键，因为 GitHub 的 Markdown 渲染不等于 Obsidian 的，也不等于 Notion 的。

规律是：输出要被人类阅读、对比或据此行动时，HTML 才配得上那份额外的重量。

Token 成本与维护的权衡

我不会只说一句「看情况」就完事，但也不会甩给你一个具体的倍数——因为我看到的数字差异太大，没法诚实地复述。

我能确信说的是：

**同一份内容，HTML 通常比 Markdown 花更多 token。**结构标签和样式标签——<div>、<style>、<section>、CSS 属性——都是成本，方向就是如此。

**输出越长，差距越大。**一段三段话的摘要？Markdown 和 HTML 的 token 差距可以忽略。一份带表格、颜色编码和导航的 20 节实施方案？差距就是实打实的。HTML 需要的视觉结构越多，成本差距越宽。

**最诚实的检验方法是自己测。**用同一个提示词跑两种格式，在你选的模型里对比 token 数。我查过 Anthropic 的 API 定价文档，确认了输出 token 怎么计费——输出侧按 token 计，所以更长的 HTML 输出确实按比例更贵。但对大多数只生成单份交付物的单人创业者来说，这点差异小到完全值得换那份可读性。

还有个维护角度。Markdown 文件手改很轻松；HTML 文件——尤其内嵌 CSS 的那种——想在不弄坏布局的前提下微调就很难。如果 Agent 生成之后你还要对文档做快速改动，Markdown 宽容得多。

契合度比功能更重要。选择依据是：你会编辑这份输出（Markdown），还是原样消费它（HTML）。

给单人创业者的决策框架

问自己一个问题：我的工作流在一个普通周二到底长什么样？

如果你是单人创业者——内容、策略、交付，全是你一个人——下面是我在用的框架。按顺序问四个问题：

1. **谁会读这份输出？**如果只有你自己，或链条里的另一个 Agent → Markdown。如果有真人客户、协作者或受众会读 → 考虑 HTML。

2. **生成之后还会被编辑吗？**会 → Markdown，在任意文本编辑器里改都方便得多。如果是已定稿的交付物 → HTML 能更好地保住排版。

3. **它需要视觉结构吗？**如果只是一份平铺列表、大纲或段落 → Markdown 够用。如果需要标签页、颜色编码、导航或并排对比 → HTML。

4. **会被复用或模板化吗？**如果你反复产出同一类型的输出、又想要视觉一致性，Claude Artifacts 或 html-anything 这类本地优先的 Agent 化 HTML 编辑器可以把流程模板化。一次性请求不需要那套基础设施。

我最终落地的默认做法是：**草稿与迭代用 Markdown，交付给人时再转换或精修为 HTML。**这条混合工作流让我在思考阶段拿到 Markdown 的可编辑性，在交付阶段拿到 HTML 的可读性。这个组合我用了几个星期，感觉是对的——等我碰到更多边界情况，会知道得更准。

这套框架就这么简单，但我花了不少时间才把它磨到这么清晰。真正的区别不在 HTML 和 Markdown——而在于你是否知道眼前这份活该配哪个格式。想通这一小块，就够了。

往期文章

• HTML-Anything Review: Can AI Turn HTML Into Real Deliverables? — 我实测了 html-anything 是否真的把「HTML 是新的 Markdown」变成一条可用的工作流。

• Claude Code vs Chrome Extensions: Which Workflow Actually Saves Time? — 不是每条 AI 工作流都需要编码 Agent；这里讲讲浏览器原生工具在哪些场景更合适。

• Workspace Agents vs Chat Assistants: Why the Difference Matters — 从聊天回复到可复用的工作成果，这一步跨越改变了 AI 输出的使用方式。

• AI Workspace Agents: Why Solo Operators Need More Than Chat Windows — 当工作区本身成为工作流的一部分，丰富的 AI 输出才真正开始有意义。