AI时代文档该长什么样:论Notion的原生HTML功能

上个月有场挺热闹的讨论。

起因是 Anthropic 旗下 Claude Code 团队的工程负责人5月初在 X 上抛了一句话，HTML is the new markdown，还附了个配套网站，甩出9类 HTML 吊打 Markdown 的场景。

一派觉得 Markdown 早就够了，标题列表代码块链接，轻量又结构化，往上加 HTML 等于把简单的事搞复杂。另一派觉得 HTML 能加交互，折叠、切换视图、滑块参数，复杂概念一变成可交互的东西，理解成本断崖式下降。

我当时也写了一篇，观点很明确，两者不该谁取代谁，而是分层各司其职。Markdown 做底层记忆，纯净存储、版本控制友好、AI 消费起来不浪费 Token，HTML 做表现层，对外分享时高密度交互展示。国内不少博主后来也写文章，思路大差不差，都是这个「分层」的调子。

吵了半天，没什么结论。

01今天Notion 用一个功能表达了他们的观点

事儿过去有一阵子，平时呢该用md时用md，该演示时也会出html，我还是两个都混着用。

直到今天刷到一个消息，Notion 上线了原生 HTML 块。我觉得这个解法可能是更优雅的产品化方案。

具体说就是，在 Notion 文档里，你可以像插入图片、表格一样，直接插入一个 HTML 块，HTML 会在文档里就地渲染出来。不是外链跳转，不是跳出文档去看，是真的长在文档里面。

内容超过预置容器会有个展开按钮，用 Notion AI 生成的 HTML 会默认适配这个容器，官方也放了宣传视频演示整套流程。

它没选那条「HTML 取代 Markdown」的路，也没选我和很多人主张的「分层各司其职」。它给的是第三条路，融合。

底层还是文档那套块结构，Markdown 和各种块当骨架，但 HTML 作为一种原生块类型，直接嵌进文档体系里，成为文档的一部分，而不是文档的附件。

这就是用产品在投票。

02说到底，图的信息密度就是比文字高

为什么这个功能让我这么有感触？

我的核心洞察其实就一句，图的信息密度高于文本。

你想想看，同样一个系统架构，你用文字描述三层调用关系、各模块职责、数据流向，可能要写三大段，读者还得在脑子里自己拼装。你甩一张架构图上去，三秒钟看明白。

这不是什么新鲜发现，「一图胜千言」说了多少年了。但问题在于，过去文档工具能承载的「图」，太有限了。

要么是静态图片，贴一张就完事，改一下得重新出图。要么是专用组件，比如 Mermaid 画流程图，语法是限定死的，你能画的就是那几种框框和箭头。

这就到了我想说的第二点。

03HTML 的真正优势，是图形化呈现加交互性，而且泛化性碾压专用组件

很多人聊 HTML 比 Markdown 强，会说 HTML 能加交互。这话对，但没说到根上。

真正关键的是，HTML 是一种泛化能力极强的表达容器，而 Mermaid 这类专用组件，是被框死在特定场景里的。

举个实际的例子。你要在文档里放个流程图，Mermaid 能搞定，语法写两行就出来了。但如果你想放一个应用界面的线框图原型呢？Mermaid 直接抓瞎，它那套语法根本画不了 UI 草图。

可 HTML 能。一个线框图，几个 div 加点样式，几行代码的事。再进一步，你想让这个原型可点击、能切换状态、能拖拽参数看效果，HTML 加点 JavaScript 全都能撑住。

Mermaid 是那种固定款式的贴纸，给你什么贴什么，款式就那几种。HTML 是散装乐高，想拼什么拼什么。

这就是泛化性的差距。

而且一旦加上交互，信息密度会再上一个台阶。一个带参数滑块的配置演示，比一整页说明文档更能让人看懂配置逻辑。一个交互式的方案对比组件，点一下切换 A 和 B，比写三段文字描述两者差异，读者接收效率高得多。

文档场景里，HTML 比 Markdown 强的地方，归根结底就是这个，它能用图形化和交互性，把信息密度拉到文字够不着的高度，而且不局限于某一种图。

04原生嵌入和 iframe 外挂，差的不是一点半点

说到这可能有朋友会问，飞书之类的文档早就支持插 iframe 嵌网页了，Notion 这个 HTML 块，有啥本质区别？

区别大了。

iframe 外挂网页，说到底就是「在文档外面搭个棚子看东西」。你得先把 HTML 部署到某个地方，拿到一个公网可访问的 URL，再把这个 URL 塞进 iframe。目标站点要是设了 X-Frame-Options 或者 CSP 拒绝加载，直接白屏。而且这个网页是游离在文档体系之外的，它不是文档的一部分，是文档挂着的一个外挂。

原生 HTML 块不一样。HTML 代码直接写在文档里，就地渲染，就地存在，跟着文档一起走。文档复制了它跟着复制，文档导出了它跟着导出。这是深度融合，不是外挂拼凑。

打个比方。MD 是承重墙，决定文档的结构和语义，稳得很，版本控制看 diff 一清二楚。HTML 块是可变软装，决定文档的表现力和交互，随时能换。iframe 外挂呢，是在房子外面搭个棚子，棚子里的东西不算你家的，哪天人家拆了你啥也没了。

所以总的来看，以文档承载，底层是 MD，再嵌入原生 HTML 块，是一个非常好的想法。它把信息密度最高的表达形态，安安稳稳地接进了信息结构最清晰的载体里。

05这事背后还有一个更大的变量

Notion 敢做这个判断，不只是一个交互创新，它踩中了一个更大的变量。

过去一年有个巨大的变化，所有人都能通过 AI 快速生成一段 HTML 了，不只是程序员。

那结果怎样呢，HTML 作为信息载体的供给侧，彻底打开了。以前 HTML 是程序员的专属手艺，文档工具就算支持，用的人也有限。现在任何一个人，跟 AI 说一句「帮我做个带滑块的对比组件」，代码就出来了。

很多产品其实看到了这个趋势，但它们的做法是给你一个免费托管空间，让你把 HTML 部署上去，通过链接来分享。这步有用，但不够。它还是把 HTML 当成了一个外部的东西，需要跳出文档去看。

Notion 的判断反过来，既然 HTML 已经是一个信息容器了，那它就该成为文档的一部分，而不是文档的附件。

这其实是挺反直觉的选择。过去行业的默认路径是，表达越复杂，就离文档越远。你想做可交互图表，去开个新工具。你想做可调参演示，去写个小应用。复杂表达被一路推到了文档体系外面。

Notion 在做相反的事，把复杂表达拽回文档内部，让它成为原生组成部分。

文字其实只是文档里最基础的一种表达形态。表格、图表、嵌入组件、交互块、HTML，都只是不同粒度的结构单元。这次 HTML 块的功能，说到底就是拓宽了文档能承载的表达边界。

06写在最后

吵了半天没结论的事，Notion 用一个产品决策回答了。

不是取代，不是分层，是融合。文档做骨架，MD 打底，HTML 当原生块嵌进去。

我是真心期待飞书文档、钉钉文档、腾讯文档这些国内选手，能早点上类似的特性。有了 AI 之后大家太容易把文档写长，写得越长别人有效接收的效率越低，可光靠表格和流程图去补结构化表达，空间还是窄。

要是文档工具都能原生支持 HTML 块，那信息表达的空间一下子就打开了。

文档这件事，终于要从一个「只能读的载体」，长成一个「能交互的容器」了。