1. 为什么 2026 年 HTML 转 Markdown 这个方向爆发了
在 Markdown 生命周期的绝大部分时间里，管线只指向一个方向：你写带井号和星号的纯文本，生成器把它变成 HTML，浏览器渲染出结果——发布是终点，HTML 是投递层。到 2026 年，日常工作里有相当大的一块在反着跑。格式化文本产出最重的角色，变成了在聊天界面里回答问题的模型、把富文本输出粘贴进文档的 agent、以及需要干净纯文本的检索管线——而这些内容几乎都不是以「能留下来」的形式诞生的。
格式本身没有变，变的不是它。Markdown 还是 2004 年以来的那个东西——存储、diff、跨工具迁移都比周边一切格式省心的纯文本语法，这一点我们在什么是 Markdown 的入门篇里完整论证过。变的是文本的第一落点：当一个难题的答案出现在聊天窗口里时，界面已经把它渲染成了 HTML，不管有没有人做过这个选择；你复制它，离开的就是 HTML。
过去一年声音最大的那场格式之争，反而让这个方向更重要了。「HTML 是新的 Markdown」这个主张，争的从来是输出侧——当一个人要读结果时，agent 应该产出什么。捕获是另一个问题，而且答案没有争议：无论那场争论怎么收场，人们决定留下来的内容，最终都最好落在 Markdown 里，因为笔记应用、代码仓库、知识库吃进的是 Markdown，不是渲染好的页面。输出端有争论，存储端早有定论；而每一次有争论的输出，迟早都要走一趟从 HTML 回纯文本的走廊。
这个量来自寻常的个体工作，不是什么新奇的管线。创始人把模型写的市场分析粘进调研文件，开发者把框架的文档页存到依赖它的代码旁边，顾问把竞品定价页剪进放着对比方案的客户文件夹。这些人没有一个觉得自己在做「格式转换」——他们只是把内容搬进它能活下来的地方，而 HTML 转 Markdown 就是这条路上的收费站。
2. 场景一：把 AI 聊天回复变成留得住的文档
一个出色的 AI 答案，问题出在装它的容器上。聊天记录向下滚动直到消失，历史搜索要看各家界面的脸色，导出的常常是面向开发者而非笔记应用的 JSON 压缩包，你花二十分钟提示词换来的那篇回复，三周之后实际上已经找不到了。内容是耐久的，聊天不是归档。
让转换从「可选」变成「必需」的，是剪贴板的工作机制。当模型的回复里有标题、加粗术语和一张对比表时，界面早已把它们渲染成了 HTML 元素——你看到的 ## 在浏览器画出来的时候就是 <h2>，按下复制，HTML 就和平文本一起进了剪贴板。粘到纯文本编辑器里，拿到的是平面文本那一层，表格没了；粘进文字处理软件，格式留下了，容器却错了。你要的结构此刻就在，只是格式不对——转换器做的就是把它映射到对的格式上。
最轻的工作流跑在一个浏览器标签页里。打开 Floatboat 的免费 Markdown 工具，切到 Convert 标签，把复制的回复粘进去——富文本、HTML 片段、整节页面都行——它会以干净的 Markdown 落进编辑器，富文本顺手带进来的 font、span 残渣一并剥掉；转换在浏览器本地完成，内容不会离开你的电脑。接下来就是一个普通的左右分栏编辑器：修一下表格对齐，给文件起个正经名字，文档要出门时导出成 Word、PDF 或独立 HTML。
一个习惯把「建起可用归档的人」和「攒了一堆孤儿片段的人」区分开：把问题连同答案一起存。回复很少能独立成立——产出它的那条提示词承载着让答案在几个月后还能被读懂的约束和背景，所以两边都粘，删掉聊天里的水分。文件按主题而不是日期命名，笔记工具支持的话加一行 frontmatter 记下来源和模型，聊天记录就开始有文档的样子。如果你的聊天服务商提供原生的 Markdown 导出，用它——转换是给那些只隔着一个复制按钮的绝大多数对话准备的。
3. 场景二：把网页内容变成可编辑的 Markdown
第二个场景的起点是一个 URL，而不是一段对话。你想离线可用的文档页、周会上反复引用的更新日志、想跟踪一整季度变化的定价页——这些存成 HTML，得到的是一个文件外加一整文件夹的脚本、样式和追踪器；打印成 PDF，版式冻住了，引用、编辑、检索全都费劲。转成 Markdown，留下的是页面说了什么，扔掉的是页面怎么搭的。
活下来的恰好是 Markdown 能表达的那部分。标题映射成井号，列表映射成横线和数字，表格映射成管道语法，链接保持可点，代码样例落进围栏代码块。消失的是机械结构：导航栏、cookie 横幅、JavaScript 挂件、以及把内容摆到屏幕上特定位置的布局脚手架。这个切分不是局限，恰恰是全部价值所在——转换过的页面是可以在邮件里引用、在任何编辑器里改、和上个月版本做 diff、能喂给一切读纯文本的工具的页面。
真实页面通常需要两个阶段，不是一个。第一阶段是去 boilerplate——从四周的 chrome 里把正文剥出来——这条路有来历：Firefox 的阅读视图把它带向大众，独立的 Mozilla readability 库是多数现代管线借用的实现。第二阶段才是转换本身，把清理过的 DOM 映射到 Markdown 语法上。跳过第一阶段的转换器处理现代落地页，产出的 Markdown 里导航文字成了标题、页脚链接成了段落——这就是为什么粘贴 URL 类工具质量参差：差距几乎从来不在 Markdown 转换，而在正文提取。
把转换器指向整个互联网之前，有两个注意事项值得先知道。重 JavaScript 的页面把内容放在脚本里而不是初始 HTML 里，直接抓取拿到的是空壳，管线得先有渲染引擎才看得见值得转的东西。另一条是常识：把页面剪进自己的笔记是一回事，把别人的内容再发布是另一回事——版权不会因为转换器跑得很干净就蒸发，付费墙内的内容即便复制按钮技术上可用，也值得让它留在墙内。
4. 保真度：什么转得干净，什么会丢
对保真度有正确的预期，能省下大量清理时间。Markdown 表达的是一小套非常特定的结构，所以转换质量基本上取决于源文件对这套结构的映射程度——诚实的答案是：干净、语义化的 HTML 几乎完美转换，靠布局堆出来的 HTML 转出来什么样子是它应得的。下面的表格是逐元素的现实预期。
| 起手的 HTML | 得到的 Markdown | 要留意的 |
|---|---|---|
标题 <h1>–<h6> | # 到 ###### | 用标题标签控制字号、或一个页面多个 <h1> 的源 |
| 加粗、斜体、段落 | **加粗**、*斜体*、纯文本 | 靠 CSS 而非 <strong>/<em> 做的强调会消失 |
| 有序、无序列表 | 1. 和 - 条目 | 深嵌套或混合列表偶尔被压平一层 |
简单 <table> 网格 | GFM 管道表格 | colspan、rowspan、嵌套表格回退成原始 HTML |
| 链接 | 行内或引用式链接 | JavaScript 驱动的链接（href="#"）变成死文本 |
| 图片 |  | 相对 URL 在文件离开原站点后失效 |
<div> 布局、内联样式 | 什么都没有——设计使然 | 布局不是内容；只靠样式承载的含义会丢 |
| 标签页、折叠块、iframe | 原始 HTML 块，或被丢弃 | 交互元素没有 Markdown 对应物 |
整张表贯穿着两条规律。语义类的一切——标题、真正的列表、简单表格、诚实的链接——转得干净，因为 Markdown 本来就是这套构造的速记。表现类和交互类的一切都会降级，因为 Markdown 没有表达它们的词汇；又因为 Markdown 合法地允许内嵌原始 HTML，多数转换器会把不支持的片段作为 HTML 孤岛悄悄留在 .md 文件里而不是丢掉——内容保住了，但跨引擎渲染时表现不一。
保真度的另一半是渲染差异，它咬人的时机在转换之后而不是转换之中。同一个 .md 文件在 GitHub、Obsidian、Notion 里不是同一份文档——方言在表格、任务列表、脚注、内嵌 HTML 上各有出入，这个逐引擎的落差，我们在HTML 与 Markdown 做 AI 输出的对比里逐条拆过。实际结论是：按文件最终落脚的那个引擎的方言来转换，并在这个引擎里检查源文档最依赖的两三种构造——通常是表格和嵌套列表——再宣布完工。
有一个缺陷因为看不见，值得单独一段：复制来的富文本带着不间断空格和零宽字符，它们无声地穿过转换，之后悄悄弄坏搜索、diff 和脚本。为这两个字符做一次查找替换花不了两分钟，而它就是「干净的文件」和「看起来干净的文件」之间的全部差别。
5. 开发者路径：turndown、pandoc 与 MarkItDown
当转换从一次粘贴变成管线的一个阶段——检索系统的内容摄取、每晚同步的文档镜像、一批要合并进同一个知识库的存页——一次一份就不再是正确的形状了。截至 2026 年 9 月，三个工具覆盖了这片需求的大头，它们的分界在运行时，不在质量。
JavaScript 侧的参照选择是 Turndown：一个遍历解析后的 DOM、套用可扩展规则集的 HTML 转 Markdown 转换器，浏览器和 Node 里都能跑，见 Turndown 的 GitHub 仓库。它的插件接口就是团队编码自家规范的地方——代码块用什么围栏、链接走行内还是引用式。命令行上，pandoc 用一条命令处理整份文档和整个文件夹：
pandoc page.html -o note.md
这一行会保留脚注、元数据这类文档级语义，放进 shell 脚本里就能干净地循环整个文件夹，十多年来 pandoc 一直坐在格式转换的中心位置，见 Pandoc 官方手册。面向 LLM 摄取的 Python 管线则在向 MarkItDown 收敛——微软的文件与 Office 文档转换工具，HTML 也在其列，见 Microsoft 的 MarkItDown 仓库。
在三者之间做选择是路由决策，不是排名。Turndown 属于转换跑在应用或浏览器扩展里、紧贴用户粘贴动作的位置。Pandoc 属于脚本场景，以及一切需要不加新依赖、一致处理一整个文件夹文件的地方。MarkItDown 属于摄取管线的前端，那里的输入是混合格式的整份文档，而不是干净的 HTML 片段。而当源是乱糟糟的活页面而不是整洁文件时，在你选定的转换器前面接上 Mozilla 的 readability——先提取、后转换，和浏览器工具内部跑的是同样两个阶段。
6. 转换之后：干净的 Markdown 去哪里
转换是工作流的中间一节，不是终点。产出一份干净 .md 文件的意义在于之后一切变得可能，其中两个出口值得点名。
当捕获的文档要交到一个只读不编的人手里——客户、相关方、打印机——把 Markdown 转成 PDF 是一个已有成熟答案的问题，从免安装的浏览器导出到可脚本化的命令行各有路径。而当转换器的输出需要动手术——管道错位的表格、从二级跳到四级的标题——一份 Markdown 语法速查表把修理从「考古自己的记忆」变成十秒钟的查找。这两个时刻在任何真实转换任务里都会在几分钟内先后到来，所以它们理应长在同一个习惯里。
更安静的那个出口是存储约定，而它才是让捕获习惯产生复利的东西。文件按主题命名、一个项目一个文件夹、一行 frontmatter 记下内容何时来自何处——这些把一堆剪藏变成可检索、可 diff 的知识库，而这正是当初值得把它转成 Markdown 的那项性质。聊天是讨论工作的地方；仓库是积累工作的地方。
7. 结语
HTML 转 Markdown 是 agent 密集工作流里的捕获走廊：一个没人争论的方向，安静地跑在「agent 该输出什么」那场争论的底下。从上面所有内容里掉出来的工作法则很短。尽早捕获——在复制的那一刻就转换，趁结构还在剪贴板上。清理一次——查表格、查标题层级、查富文本顺手夹带的隐形字符。以 Markdown 存储，内容在这里能被检索、diff、再编辑很多年。然后按读者真正需要的格式交付——你会发现，一旦事实源是纯文本，这个方向的转换容易得多。
https://floatboat.ai/zh/blog/convert-html-to-markdown