前言
现在 AI 工具愈发强大，无论日常的搜索、问答，还是工作向的策划、方案，和 AI 聊一聊、头脑风暴一下，都能获得一个不错的结果。
我最近一段时间就深度使用了大厂的 AI ，在各种主题下讨论碰撞观点，积累了不少会话内容。我翻了一下和几个大模型产品的聊天记录。有些对话长达数千条，涉及一个完整的技术方案从0到1的演进过程——需求分析、架构选型、接口设计、踩坑记录、优化思路。如果把这些整理出来，足够写一篇不错的技术博客。
但它们就躺在那个聊天框里，和后面几十个无关话题混在一起。我想把它们批量提取出来，发现只有几个指定的选项：DOC、PDF、图片或者网页链接，而且要么会话整体导出，要么逐条勾选我所需要的记录，总而言之一切并不轻松：
DOC的排版阅读起来还行PDF把大部分内容变成了图片- 图片 就更不用说了 —— 没法搜索、没法编辑。
导出过程就已经比较繁琐了，导出的结果又属于人可读但
AI不好用，它们不是纯文本，二次喂给AI，token消耗量大速度又慢。
一个能把高质量对话沉淀下来的功能，对于每天都在用 AI 辅助工作的人来说，应该是刚需。但大厂们似乎并不这么认为。它们的导出功能更像是“我有这个功能”的打卡项，而不是真的想让你把数据带走。
使用过程中我还注意到另一个问题，数十轮对话下来，AI 会记住我的项目背景、业务场景、甚至我的写作风格。我不再需要每次从头交代背景，它似乎越来越懂我了。
- 但实际上，当对话累积到成百上千轮，就会发现：
- 早期的关键决策、技术选型理由、被否决的方案，慢慢被后来的对话稀释
AI的回答开始“跑偏”，因为它更关注最近的几条消息，而忽略了开头约定的规则- 想回顾两周前某个精彩的设计思路，只能手动往上翻几百条消息
后来我了解到这是 长上下文污染：超长的上下文导致 AI 的注意力被太多历史信息分散了。解决方案也很朴素：把有价值的对话片段沉淀成外部记忆，需要时再喂回去。
于是这就回到了最初的问题，如何高效地导出会话记录供人机展开后续阅读使用？
最理想的介质当属 Markdown 文档：
- 人能读：纯文本，任何编辑器都能打开，有良好的视觉排版能力
- 机能吃：
LLM对Markdown的理解远优于PDF/DOC，纯文本也能降低token成本 - 生态广：
Obsidian、Notion、GitHub、Typora……全都原生支持 Git可diff：版本管理天然友好
所以问题的答案变得清晰：
我需要一个由我自己控制的、能从网页里把原始对话数据拿出来的工具。
不要 PDF，不要 DOC，只要干净的 Markdown。代码块还是代码块，表格还是表格，公式还是公式。人能读、机能吃、Git 可 diff。
本专栏适合有一定前端基础（了解HTML/CSS/JavaScript）、希望掌握数据自主权、乐于动手折腾的技术爱好者。如果你是纯小白，也不必担心，我们会尽量讲得通俗易懂。
一、Pandoc 方案的尝试与失败
有了目标，第一反应往往是找现成的工具。
我的想法很简单：既然大厂提供了 DOC 导出，那我找个工具把 DOC 转成 Markdown 不就行了？于是网上了解了一下，这类工具还不少 —— Pandoc 是其中最知名的一个。
Pandoc的安装使用可参考本专栏 0.1篇-用 Pandoc 一站式搞定
Pandoc 是一个文档格式转换工具，能把 DOCX、LaTeX、HTML、Markdown 等几十种格式互相转换。社区活跃，文档齐全，命令行一行搞定。看起来完美匹配我的需求：
pandoc chat.docx -o chat.md
于是我把它加入了工作流：在 AI 端导出 DOC 文档，拖进终端跑一行命令，得到 Markdown。一开始用着还行，段落、列表、粗体斜体基本都能保留。我以为问题解决了。
但我很快发现，这只是假象。用了快一个月之后，我开始逐步回看整理这些会话内容，我发现了不对劲。
事情发生在一次技术方案讨论的导出上。那场对话里有大量的代码块 —— Java、JS、bash命令，还有文字字符绘制的流程图等等。导出成 DOC 再转 Markdown 之后，各种代码块相关内容全部消失了。对话里讲到展示核心代码，接着就是代码如上的总结，中间最重要的内容却不翼而飞，这样的会话记录导出来又有何意义？
我起初以为是 Pandoc 的参数没调对，试了 --wrap=preserve、--from docx+empty_paragraphs 等各种组合，结果都一样，遇到代码块就丢了。
我开始意识到，问题可能不在转换工具上，而是数据源头有问题。于是我开始对照 DOC 查看 Markdown 缺失的对应内容，发现DOC文档里代码块流程图的地方，都被包裹在一个文本框中，文本框带有灰色背景、圆角边框、等宽字体。看起来像是有人把代码复制进了 Word 的文本框组件里。
我试着查了一下 Pandoc 的文档和社区讨论。结论是：Pandoc 并非完全不能处理文本框里的内容，通过 --extract-media 参数可以把文本框内的图片提取出来，配合 Lua filter 也能尝试解析文本框中的文本。但问题是：
- 每个文本框的样式不同，有的带背景色，有的不带，解析规则难以统一
- 文本框内的换行和缩进经常丢失，代码格式化全乱
- 如果文本框里嵌套了图片（比如流程图截图），提取出来也是一张静态图，没有任何语义
简而言之，Pandoc 能做，但做不干净。每次转换都需要人工检查和修复，遇到复杂的文档，修复的时间比自己重新整理一遍还长。
这条路虽然走得通，但走不远。它不是一次性的技术问题，而是每次导出的结果都存在不确定性，还需要后续的纠偏。我想要的是一个能稳定产出可用 Markdown 的方案。
所以我放弃了 Pandoc 这条线，开始往另一个方向看 —— 在数据被封装成 DOC 之前，直接从网页里拿到原始内容。
二、Tampermonkey 脚本
放弃 Pandoc 之后，我开始重新思考这个问题：我要的到底是什么？
并非"把 DOC 转成 Markdown"，只需"从 AI 聊天页面里拿到原始的对话数据，输出为 Markdown"。这两件事的区别在于：前者是在下游做格式转换，后者是在上游做数据捕获。
那怎么从网页里拿到原始数据？
最直接的办法是看浏览器里发生了什么。例如，在腾讯元宝的网页版中，我就通过 Network 面板抓取到了结构清晰的JSON数据。刷新页面，开始一轮对话，观察网络请求。很快就能发现规律：每次发送消息和接收回复，浏览器都会向后端接口发起请求，返回的数据通常是 JSON 格式，里面包含了消息的完整内容——包括代码块、表格、公式，全都是结构化的文本，没有被渲染成图片。
也就是说，在数据到达浏览器、被渲染成 DOM、再被导出为 DOC 之前，它还是干净的。如果能在这个阶段把数据截住，就能绕过所有格式损失的问题。
那么问题变成了：如何在浏览器层面拦截这些网络请求，拿到响应数据，然后组装成 Markdown？
有几个可选方案：
| 方案 | 优点 | 缺点 |
|---|---|---|
| 浏览器扩展 | 功能完整，可长期运行 | 开发门槛高，需熟悉 Manifest V3、事件监听、权限声明等 |
| 书签脚本 | 轻量，无需安装额外工具 | 只能在页面加载完成后执行，无法拦截早期发起的请求 |
Tampermonkey 脚本 | 开发简单，跨浏览器，支持 GM_* API，可拦截 XHR 和 Fetch | 依赖宿主环境，需额外安装扩展 |
对于个人工具来说，Tampermonkey 用户脚本的优势很明显：
- 上手快：只需要会
JavaScript和基本的DOM操作，不需要了解扩展的复杂生命周期 - 跨浏览器：Chrome、Firefox、Edge 都支持
Tampermonkey，一套脚本到处跑 - 拦截能力强：通过
@run-at document-start可以在页面最早阶段注入代码，覆盖 XHR 和 Fetch 两种请求方式 - 存储方便：
GM_getValue/GM_setValue提供了简单的键值存储，不需要操心 IndexedDB 或 Chrome Storage API
综合来看 Tampermonkey 用户脚本，便是目前理想的方案。在 AI 聊天页面拦截网络请求，拿到原始 JSON 数据，组装成 Markdown 文件，下载导出，它完全胜任，而且轻量。
三、门槛与局限
用户脚本方案虽然看起来很不错，但也并非完美无缺：
- 依赖
Tampermonkey这个宿主环境，用户需要额外安装一个浏览器扩展并配置 - 脚本的撰写需要一定的编程基础，需要耐心分析接口和数据结构
- 网页改版可能导致选择器失效，需要自行维护更新
- 当消息量达到几千条时，纯
DOM操作会遇到性能瓶颈
认识到其局限性，便于确立我们对工具的期待边界。对于初期目标 —— 拿到几百到一千条对话，输出为可用的 Markdown ，用户脚本是完全够用的。至于更大的规模、更高的稳定性，那是后续工具升级要考虑的事情，后续篇章再行展开。
在继续阅读前，请确认你是否具备以下条件：
- 安装了最新版
Edge浏览器- 了解最基本的
JavaScript语法- 能接受网页改版导致工具失效的风险
四、专栏交付物
整个专栏围绕一个目标展开：一个能把 AI 对话从网页中提取出来、输出为干净 Markdown 的工具。它不是一个概念验证的 demo，而是一个真正能用的脚本，并且附带完整的构建流程。
具体来说，交付物包括：
4.1 可直接运行的 Tampermonkey 脚本
这是核心产出。安装 Tampermonkey 后，导入脚本，打开 AI 聊天页面就能看到导出按钮。点击即可将整场对话导出为 Markdown 文件，代码块、表格、公式均保持原始格式，不做任何转换或降级。
目前的脚本选用的 AI 平台为 腾讯元宝，并会在后续迭代中持续适配。
4.2 一份完整的开发实战记录
光有脚本是不够的。如果哪天平台改版导致脚本失效，需要有能力自己修复，甚至根据自己的需求定制功能、适配更多平台。
因此，专栏会从零开始讲解脚本的开发过程：
- 如何安装
Tampermonkey扩展 - 如何分析 AI 聊天页面的网络请求，定位数据接口
- 如何拦截
XHR和Fetch，拿到原始JSON - 如何将
JSON数据组装成结构完整的Markdown - 如何处理长对话的分页加载
- 如何利用
GM_* API实现配置持久化和菜单交互
五、线路图
整个专栏共六篇，按"需求→基础→核心→工程→进阶"的脉络展开。下表列出了每篇的主题和核心内容：
| 篇目 | 标题 | 核心内容 |
|---|---|---|
| (1) | 需求与决策 | 本文。从 Pandoc 失败到 Tampermonkey 选型的完整推导过程 |
| (2) | 环境搭建与项目结构 | 初始化 browser-tools 仓库，划分 shared/userscript/extension/ 目录，配置开发环境 |
| (3) | 消息池与 shared 层 | 设计消息数据结构，实现消息池的增删改查，抽离平台无关的核心逻辑 |
| (4) | 拦截对话流与 MD 组装 | 拦截 XHR/Fetch 获取原始 JSON，解析消息内容，组装为结构化 Markdown |
| (5) | 构建脚本与自动更新 | 编写 build.js 打包脚本，部署到 Gitee Raw 实现脚本自动更新 |
| (6) | 进阶方案与架构升级 | DOM 拦截升级为 API 分页拉取全量数据；评估用户脚本迁移至浏览器扩展的必要性与成本 |
总结
本篇我们从一次日常的需求（想把 AI 对话导出为可复用的 Markdown）出发，经历了一条从工具选型到方案推翻再确立的探索路径：
Pandoc转换方案存在瓶颈：大厂导出的DOC已经把代码块和流程图封装成了文本框，下游工具难以无损还原。- 从"格式转换"到"数据捕获"：对比浏览器扩展、书签脚本和
Tampermonkey用户脚本三种方案，最终选择了开发成本最低、跨平台最好、拦截能力足够的用户脚本路线 - 用户脚本的局限：依赖宿主环境、需要编程基础、面临网页改版风险、大规模对话下存在性能瓶颈。认清这些局限，不是为了劝退，而是为了让工具的预期边界清晰可见。
- 专栏整体路线预览：从需求逐步推进到方案的落地与进阶。
接下来的篇章，我们将从环境搭建开始，一步步把这个脚本从零实现出来。
本文首发于个人博客「阶进遐的技术随笔」
博客中配有完整专栏目录、可复制配置与长期更新，适合沉浸式阅读。
欢迎来博客逛逛，这边有任何疑问也可直接评论区交流。
