AI 时代的文档之争：为什么我不建议普通人直接跟风切 HTML？

最近科技圈有个挺有意思的讨论：Anthropic 的一位工程师 Thariq 发帖说，他在用 AI 协作时，已经彻底弃用了 Markdown，全面转向 HTML。这篇帖子在 Hacker News 上引起了热烈讨论，Karpathy 等业内大佬也下场站台，一时间 "HTML 替代 Markdown" 的声音不绝于耳。

不过，仔细翻完 Hacker News 上那 267 条评论后，我发现事情没那么简单。大多数讨论和解读，都在直接搬运 "HTML 更好" 的结论，却很少有人停下来问一句：这个结论，对我们这些普通用户、内容创作者来说，真的成立吗？

Markdown 和 HTML 的这场争论，表面看是 "器" 的选择，但往深了想，其实是 "道" 的分野——它关系到你怎么跟 AI 协作、怎么定义你产出的东西。咱们聊聊。

一、HTML 很香，但 Markdown 的位置更重要

先理解一下，Markdown 和 HTML 在你的 AI 工作流里，分别扮演什么角色。

其实，在你和 AI 协作的几乎每个环节，Markdown 都是那个 "对齐认知" 的核心桥梁。

• 最开始的需求分析，你写的可能是 research.md。
• 方案设计、拆解执行步骤，可能是 plan.md。
• 构思文章大纲，是 outline.md。
• 最终输出草稿，还是 final-draft.md。

你看，你几乎在每个环节，都在依赖这个简单的标记语言。它的最大护城河，就是 "简单" 和 "可控"——你和 AI 都能轻松理解它、修改它。它的存在，保证了协作的高效和流畅。

大部分情况下，当 AI 输出一份 Markdown 格式的成果，直接把内容复制走使用，这就够了。问题的关键在于，什么时候我们会觉得 Markdown "不够用了"？

比如，AI 给了你一份方案对比，你想在几个选项里拖动卡片、比较不同选项的效果；或者，AI 给你列了一个任务清单，你想像管理卡片一样，拖一拖来重新排序、标记状态；再或者，你有一堆提示词，希望快速搜索、一键复制、分类管理。

这些场景下，Markdown 确实捉襟见肘。你只能 "读" 它，而无法 "动手玩" 它。这里有个关键认知：

很多时候，一个好的交互式呈现，胜过千言万语。

但这是否意味着，你该把所有 Markdown 都换成 HTML？Hacker News 上那几百条评论，帮我们理清了边界。

Thariq 是 Anthropic 内部的工程师，对他的场景来说，token 几乎是没有成本的。但 HTML 比 Markdown 多消耗 2 到 4 倍的 token，生成速度也会慢上 2 到 4 倍。这是实实在在的资源成本。他负担得起，对普通用户来说，未必。

Markdown 最大的护城河，不是 "简单"，而是 "你可以直接动手改"。两个字、一段话、一个章节，你打开文件就能搞定。而 HTML 一旦生成，结构复杂、标签嵌套，你要改一个小地方，可能都得回头再让 AI 重新生成。如果你做的是方案、计划、提示词模板这种需要反复修改打磨的东西，Markdown 仍然是更理性的选择。

HTML 的输出，往往配了配色、卡片、流程图，看起来像一份完美的成品。正因为它看起来太好了，我们很容易被 "漂亮" 迷惑双眼，而忘记去咀嚼里面的内容、推敲观点的实质。

在 Hacker News 那条帖子的评论区，甚至有位国外大佬提到，自己团队由于将一份需求文档做得过于精致，下属直接把它当成最终产物发布上线了，结果导致敏感信息泄露。这个教训值得记取。

二、怎么选择？按 "任务" 来，而不是 "潮流"

存在即合理。Markdown 是 2004 年 John Gruber 和 Aaron Swartz 为解决 HTML 标签繁琐而发明的。而今天，Thariq 又让 AI 直接输出 HTML，因为对大模型来说，标签同样熟悉。这像是一个有趣的轮回。

什么时候选 HTML，判断的标准是任务本身：你的目标，是 "把规则讲清楚"，还是 "把体验呈现好"？

• 放心交给 AI 一步出结果，不需要展示和交互的任务。
• 个人笔记、日常记录、AI 中间过程的文档（如 research.md, plan.md, outline.md）。
• 需要你自己反复修改的规范、计划、提示词库。

• 给老板、客户、非技术读者看的报告（HTML 才能真正让人愿意读完）。
• 设计方案、原型、动效设计（Markdown 无法表达）。
• 流程图、架构图（Markdown 只能画 ASCII 符号）。
• 一次性小工具：数据整理、分类、搜索（Markdown 做不到交互）。

• 用 Markdown 写内容、做中间稿，最后让 AI 渲染成 HTML 做最终呈现。

这样一来，你既保留了 Markdown 对大模型的高效友好度，又拿到了 HTML 对目标读者（甚至就是你自己）的可读性。Hacker News 上不少实操者正是这么干的，Karpathy 自己也是这样。

三、两个来自实践的对比案例

Thariq 官方放了 20 个示例，涵盖了 9 大类场景，可以直观感受到 HTML 在特定场景下的优势。我结合自己的使用经验，也分享两个案例，看看 Markdown 和 HTML 在不同需求下的实际体验差异有多大。

（一）我的研究稿，到底用 Markdown 还是 HTML？

我习惯在写一篇深入文章前，先做一份研究稿，把来源、受众、核心发现、判断、甚至 demo 选型都梳理清楚。

左边是 Markdown 版本，长长的文字列，灰扑扑的，你得从头读到尾。右边是 HTML 版本，顶部用 SVG 画了流程脉络图，下面是数字看板，关键信息被 "砸" 出来，章节之间有 tab 可以快速跳转，核心判断用色块表格做了视觉强调。从 "理解" 的角度，显然是 HTML 版本赢了——你一秒钟就能抓住主线。

但为什么我最终还是会选择 Markdown 版作为工作底稿？因为：

• 这份选题分析，是写给我自己看的，核心诉求是 "表达清晰、准确"。
• 这份文档还会不断调整，我或者 AI 都要频繁修改。
• 这份文档是后续多份文档（大纲、任务拆解、素材设计）的基础，文本形式更容易被 AI 理解和调用。

所以我的判断是：

如果希望从一份文档生成漂亮的 HTML 呈现，可以直接用下面这个提示词：

帮我把以下研究稿（或学习材料、长 markdown 报告）做成一个 HTML 单页。要求：
1. 单文件 HTML，浏览器直接打开，不依赖外部资源
2. 顶部用 SVG 画一张脉络图，帮我一眼看清整份内容的结构
3. 关键数字做成看板，一眼能抓住
4. 主要章节做成 tab 切换或卡片并列
5. 关键观点用色块表格或引号块加视觉强调
6. 配色克制温暖，参考 Anthropic 官网风格

内容：
[贴入你的 markdown 原稿]

（二）提示词工具台

另一个很实际的场景是：你搜集了一堆好用的提示词，扔在备忘录、收藏夹里。结果就是吃灰——想用的时候想不起来，凭印象去找也找不到。

同样的整理需求，交给 AI 来处理，结果会完全不同。

AI 给到你的不再是 "一份文档"。它是一个可以搜索、分类、一键复制提示词的工具台。你和它的关系发生了质变：从 "翻文档" 变成了 "用工具"。这种场景下，我会毫不犹豫地选择 HTML。

这也正是 Karpathy 想表达的那个逻辑区分：

四、3 条很容易踩的坑

1. 别急着做模板和 skill。
   
   Thariq 自己在原文里提醒过："我有点担心大家读完就立刻做一个 /html skill。" 他建议先在不同场景里一次次地从零 prompt，沉淀出自己的感觉后，再考虑模板化。先把场景摸熟，别给工具上瘾。

2. 别让 HTML 的好看掩盖了内容的薄弱。
   
   排版越精致，越容易让你沉迷于表面。调样式、配颜色，越调越高兴，但内容本身是不是经得起推敲？这才是更值得关注的事。好看的废话，仍然是废话。输出形态升级了，质量把关的标准也应当同步提升，而不是下降。

3. 注意真实代价。
   
   HTML 生成比 Markdown 慢 2 到 4 倍，token 消耗更高，甚至在做版本对比时，由于 HTML 结构的复杂，diff 的噪音也会更多。不是每个任务都值得为 "好看" 买单。按需选格式，不按潮流选格式。

说到底，Markdown 和 HTML 这场争论，本质上不是哪个技术 "更厉害"，而是在 AI 协作的新时代里，你如何重新定义和参与 "产出" 的过程——是生产一份文档，还是交付一个工具？两者的定位完全不同，选对工具，比争论谁 "更好" 重要得多。