「形而上者谓之道，形而下者谓之器。」Markdown 和 HTML 之争看着是器，其实是道。
Anthropic Claude Code 团队工程师 Thariq 那条 200 万浏览的帖子，提到他选择弃用 Markdown，并选择 HTML 作为替代。国内已经有不少翻译和解读，我不赘述了。
其实不光是 Thariq，AI 圈大神 Karpathy（特斯拉前 AI 总监、OpenAI 创始团队成员）几乎同一时间站台了 HTML ，有意思的是，Karpathy 自己内部还在用一套基于 Markdown 的「LLM Wiki」做知识库，对外输出才用 HTML。
但我发现一个问题：大多数解读直接搬运了 Thariq 的结论，觉得 HTML 好，就提倡大家切换。很少有人停下来问一句，这个结论对我们普通用户是不是也成立？
带着这个疑问，我去读了原帖下 Hacker News（一个高质量英文技术社区）上 的267 条讨论，发现并不是简单的“替代”。接下来，和我一起来了解吧。
在你和 AI 协作的几乎每个环节，Markdown 都是核心：
一开始的需求分析（research.md） 中间的方案设计、架构设计 任务拆解（plan.md） 文章大纲（outline.md） 最终的输出文档（final-draft.md）
Markdown是你和 AI 对齐认知和目标的桥梁。这个位置短期内不会被替代。
就像我写这篇文章时，从 research.md 整理 HN 评论和翻译稿，到 plan.md 拆解执行步骤，到 demo_plan.md 设计素材案例，到 outline.md 设计大纲，再到草稿，全部是 Markdown。
大部分情况下，CC 输出一份 Markdown 结果，直接拿走使用就够了。
只是有时候，当 Claude 给你一份方案对比，你想切一下不同选项看效果；或者一份任务清单，你想拖一拖卡片重新排序；又或者一份提示词整理稿，你想快速搜索到想要的提示词，点一下就直接复制用。
那Markdown 给不了你这个能力。你只能“读”它，没办法“动手玩”它。
读懂内容 ≠ 看懂内容，经常有“一景胜过千言万语”的佳话，这也是Thariq想表达的含义。
但这不意味着你应该把所有 Markdown 都换成 HTML，HN 上的百条评论帮我们把边界看清楚了。
1. 你和 Thariq 的资源条件不一样
Thariq 是 Anthropic 内部员工，token 对他来说几乎没成本。这不是说他的方法不好，是说他的场景跟我们不同。HTML 比 Markdown 多消耗 2 到 4 倍 token，生成速度也慢 2 到 4 倍。他可以不在意，你不一定可以。
2. HTML 失去对齐的手段
转向 HTML 后，你失去了和 AI 共改文档的能力。
Markdown 的最大护城河不是“简单”，是你能直接动手改。两个字、一段话、一个章节，你自己就能搞定。HTML 一旦生成，结构复杂、标签嵌套，你要改一个小地方都得回头让 AI 重写。
如果你做的是 spec、计划、提示词、个人笔记这种需要反复修改调整的东西，Markdown 仍然是更好的选择。
3. HTML 的精致会让你放松审视
HTML 的效果往往色彩斑斓、结构清晰，是美感与内容的极致组合，它的输出加了配色、卡片、流程图，看起来就像一份成品。正因为效果好，我们很容易沉迷表面，而忘记去研读表层下的本质。
在 HN 的评论中，甚至有一位国外大佬提到，由于需求文档使用 HTML 设计的过于精致，他的手下误将这份 HTML 一起上了生产环境，导致敏感信息泄露。
存在即合理。
Markdown 当年被发明出来，是为了让人们绕过 HTML 标签的繁琐。2004 年 John Gruber 和 Aaron Swartz 把博客作者在邮件里早就在用的约定（斜体、粗体、> 引用）整理成规范，可以借助工具自动转成 HTML。
而今天 Thariq 让 AI 直接输出 HTML，因为对 AI 来说，标签再熟悉不过。一个轮回。
什么时候选择 HTML，判断的核心是任务本身。
如果你的任务用文字就能表达清楚规则，Markdown 足够了。如果你的任务更适合图形、表格、可交互的方式呈现，那就用 HTML。如何把事情高效地表达清楚，才是重要的。
下面是我整理的判断场景。
用 Markdown 就够的场景：
放心交给 AI 一步出结果的任务，不需要展示和交互 个人笔记、日常记录、AI 中间过程文档（research.md / plan.md / outline.md 这些） 需要你自己反复修改的 spec、计划、提示词模板
该切 HTML 的场景：
给老板、客户、非技术读者看的报告（HTML 真正会被读完） 设计方案、原型、动效（markdown 表达不了） 流程图、模块图、架构图（markdown 只能 ASCII） 一次性小工具：数据整理、分类、排序（markdown 做不到交互）
中间方案（推荐大多数人上手）：
用 Markdown 写内容、做中间稿，让 AI 渲染成 HTML 做最终呈现
你同时拿到了 markdown 对大模型的友好度，和 HTML 对人类的可读性，不用二选一，实际上HN 上不少实操者正是这么干的，Karpathy 自己也是。
Thariq 官方放了 20 个示例（文末有链接），覆盖 9 大类。大家可以直观感受到 HTML 适用的场景。
我从自己使用的角度，选了两个案例，分享给大家，看一下 Markdown 与 Html 在不同场景下的体验。
（一）我的研究稿，到底用 markdown 还是 HTML？
我写每篇公众号文章前都会先做一份，把来源、受众、关键发现、判断、demo 选型一一讨论清楚之后，才会动手写正文。research.md 就是这篇文章的底气。
左侧是 markdown 版的选题需求讨论，长长一列、灰扑扑、要从头读到尾。
右边 HTML 版，顶部 SVG 把「需求对齐 → 信息来源 → 关键发现 → 判断 + demo」四步研究脉络一眼看清；下面 4 个数字看板把 200 万浏览、267 条 HN 评论、9 大类 20 示例、4 篇中文解读漏点直接砸出来；4 个 tab 让我跳到关心的那一节；判断地图用色块表格代替文字。
从展示效果的角度， 是 HTML 版本胜出。同样是 AI 给你的内容，Markdown 版是「我得花十分钟读完」，HTML 版是「我一分钟就抓住了主线」。
但从实用的角度，我会选择 Markdown，因为：
这份选题分析文档是给我自己看的，对它的核心要求是：表达清晰、准确。 这份文档还会不断调整，我和 AI 都会对内容修订 这份文档也是后续多份文档（如大纲设计、任务拆解、素材设计）的基础，文字更容易让 AI 理解
如果希望从一份文档生成 HTML，可以借助下面的提示词：
帮我把以下研究稿（或学习材料、长 markdown 报告）做成一个 HTML 单页。要求：
1. 单文件 HTML，浏览器直接打开，不依赖外部资源
2. 顶部用 SVG 画一张脉络图，帮我一眼看清整份内容的结构
3. 关键数字做成看板，一眼能抓住
4. 主要章节做成 tab 切换或卡片并列
5. 关键观点用色块表格或引号块加视觉强调
6. 配色克制温暖，参考 Anthropic 官网风格
内容：
[贴入你的 markdown 原稿]
（二）提示词工具台
搜集了一堆好用的提示词，扔在备忘录、收藏夹、聊天记录、各种笔记软件里，结果就是吃灰。想用的时候想不起来，凭印象去找也找不到。某天心血来潮，想整理一下。
同样的整理需求，给到 AI，会发生什么？
Markdown 时代，你拿到一份清单文档，分类列好、标题正文齐全。但你还是要打开它、翻、找、复制、关掉。
HTML 时代，你拿到的不是文档了。
它是一个能搜、能筛、能一键复制的提示词工具台。同样是一句提示词生成的东西，但你和它的关系变了：从“翻文档”变成“用工具”。
这种场景下，我就会选择用 HTML。
这也是 Karpathy 说的那个逻辑：Markdown 表达「内容」，HTML 表达「产物」。
1. 别急着做模板和 skill。
Thariq 自己在原文里提醒过：“我有点担心大家读完就立刻做一个 /html skill”。他建议先在不同场景里每次从零 prompt，沉淀出感觉再考虑模板化。工具上瘾不如先把场景摸熟。
2. 别让 HTML 的好看掩盖了内容的薄弱。
HTML 的视觉效果好，调样式调配色，越调越高兴。但内容本身是不是经得起推敲，才是应该被关注的。
好看的废话仍然是废话。输出形态升级了，质量把关的标准要相应提升，不要下降。
3. 注意真实代价。
HTML 生成比 Markdown 慢 2 到 4 倍，token 消耗更高，版本管理的 diff 噪音大。不是每个任务都值得为好看买单。按需选格式，不按潮流选格式。
回顾 Markdown 与 HTML 之争，我认为本质不是说 HTML 有多么厉害，而是你重新参与到了 AI 的产出过程里，谁更适合在当前的场景中去用。
