1. 为什么导出豆包对话是个真需求也不是小工程上礼拜一个做运营的朋友找我说跟豆包聊了好几天的类目规划想把对话存档做成复盘文档结果在网页端翻了一圈也没找到“导出全部记录”的按钮最后只能一屏一屏截图。这其实不是他一个人遇到的问题。豆包现在确实是很多人日常用的 AI 工具网页版、App、桌面端都能聊但“对话导出”这件事产品层面一直做得比较隐蔽。官方没有像文档工具那样给一个“一键打包下载”所以大多数人只能靠复制粘贴搬数据。这篇内容我按自己实际折腾过的路径把导出豆包对话的主流办法理一遍从手机和网页的手动复制到浏览器控制台脚本、书签小工具、油猴脚本再到抓接口拿完整数据。每种办法的适用人群、操作步骤、容易踩的坑我都会讲到。不管你是只想导出一两条聊天记录做备份还是想把几十屏长对话整理成知识库语料应该都能在里面找到对应的方案。1.1 豆包的几种使用形态决定了导出的难度不一样豆包不是一个入口而是好几个入口都在用。网页版在浏览器里打开就能聊手机端有独立的 App电脑上还能装客户端。每个入口的导出方式都不同难度也不一样。网页版数据渲染在浏览器里我们可以通过控制台、书签脚本、浏览器扩展去操作手段最丰富也是这篇文章的主角。手机 App界面是一个封闭的客户端你只能依赖 App 提供的复制、分享按钮或者截图后做 OCR 识别再整理。桌面客户端如果底层是 Electron 之类的壳子理论上还能扒到页面渲染资源如果客户端的聊天界面逻辑在原生层那基本只能复制文本。API/开放平台用豆包大模型的 API 接入开发的话对话记录存在你自己的服务端里想怎么导就怎么导但这属于开发者的玩法不适用于平时的网页聊天。不同入口导出的颗粒度完全不一样。网页端可以拿到相对完整的结构化文本手机端就得看 App 给不给你“复制全文”这种入口。搞清楚自己手上是哪个入口再选方案效率会差出好几倍。1.2 哪些场景真正用得上这些对话记录可能有人觉得“导出聊天记录”是小事真要用的时候才知道多麻烦。我接触到的典型场景有这么几类知识沉淀和豆包讨论了一整套工作流程、选题思路聊完想整理成文档放进团队知识库这时候需要的是干净的、分角色的纯文本。写作素材整理用豆包生成了几版文案、几个故事框架聊完想统一存进素材库按角色和内容拆分保存。数据迁移换设备、换工具想把豆包里的对话搬运到其他笔记软件或 AI 工具里做继续对话。二次加工把聊天记录变成 Excel 表格、Word 文档、Markdown 笔记甚至整理成语料喂给本地知识库或做模型微调。合规存档公司项目里用豆包讨论过技术方案需要留下过程记录方便以后追溯。这些需求共同指向一个东西你需要的不是屏幕截图而是结构化的文本数据和对话的元信息角色、时间、顺序。截图只能满足“看一眼”满足不了后续的整理和检索。1.3 为什么豆包没有给你一个一键导出按钮先说结论到目前为止豆包官方并没有在网页端提供一个把全部对话一键导出成文件的入口。对话历史都保存在云端账号体系下但它给用户的入口只有“继续聊”“复制单条消息”“分享链接”这些功能。站在产品角度我能理解这种设计。聊天记录是很隐私的个人数据如果做粗糙的全量导出功能容易带来数据泄露风险同时平台也倾向于让你留在产品生态里持续使用而不是把数据交到你手上之后顺手就迁移到竞品那边。但站在用户角度这确实不方便。所以现实就是想导出豆包对话多数时候得靠自己用浏览器端的技巧去实现。这正是这篇文章价值所在下面进入具体操作。2. 不装任何东西的笨办法也能导出复制、分享与截图先聊最朴素的方案。如果你只需要导出零星几条对话不需要完整结构那么手动复制完全够用。这个方案零门槛手机电脑都能做。2.1 网页端复制最快路径在豆包网页版里鼠标移到某条消息上一般会浮现复制图标或者你直接用鼠标拖动选中文字再 Ctrl C 也能复制。如果遇到长回答页面会自动分屏显示建议先滚动到消息最底部确保整段回答渲染完整再从头选中复制。不然你复制到的可能只是当前可视区域里的部分内容。复制出来的文本默认是纯文本粘贴到 Word 或 Markdown 编辑器里会丢失部分格式比如加粗、代码高亮。如果对话里有代码块复制后代码的缩进和换行有时会被压缩需要手工修一下。这里有一个小技巧选中消息的时候不要只选内容区域尽量选内容容器本身比如右键检查后找到包含整条消息的 div 节点再复制outerText。这样能避免把时间戳、操作按钮这些 UI 文案带进来。不过这样做效率仍然不高如果对话超过二十条手动复制会很痛苦。2.2 手机端气泡复制与分享链接手机 App 的操作逻辑和网页端不太一样。豆包 App 里长按某条消息气泡会在底部弹出“复制”和“分享”选项。点“复制”是纯文本直接粘贴到备忘录、微信文件传输助手都行。点“分享”通常有两条路复制链接或生成图片。复制链接会把这一轮会话生成一个加密链接发给别人后对方也需要登录豆包才能打开不是所有人都方便访问。生成图片则是把当前消息区截成一张长图适合直接塞进文档或发群里演示但图片里的文字没法二次检索后续编辑比较麻烦。手机端还有一个隐藏技巧iOS 的“快捷指令”或安卓的“剪贴板自动同步”可以把手动复制的文本自动追加到同一个备忘录这样你从上到下依次点复制最后能拼出一整篇文本。操作还是繁琐但至少不用自己一条条粘贴。2.3 笨办法的局限性什么时候你该转入脚本方案手动复制最大的问题不是慢而是容易漏。对话一长你就会发现三个痛点顺序容易乱从中间开始复制粘贴时忘了上下文顺序整理要额外花时间。内容容易混选中的区域经常把按钮文案、时间戳、提示信息一并带出来导出结果像一堆爬虫抓的脏数据。结构容易丢你没有区分“我”和“豆包”的角色也没保留消息的层级关系后续想做数据分析或知识库语料时就傻眼了。所以我一般这样判断如果对话少于十条手动复制没问题如果超过十条或者说需要把整段对话做成可复用的文本资产直接跳到下一章用脚本方案。别在一页页复制上浪费时间。3. 用浏览器书签和 F12 控制台把对话批量抓成文件这是豆包网页版导出对话最实用的方案也是我日常最常用的路子。原理很简单豆包页面上你看到的所有消息本质上都是浏览器里渲染出来的 HTML 节点而浏览器提供了完整的 JavaScript 执行环境我们可以在当前页面里运行一段提取脚本把消息节点遍历出来拼成 Markdown、JSON 或 CSV 文件并下载。3.1 先说原理聊天记录在页面里就是一堆节点你平时看到的“豆包说了一段话”在浏览器内部只是一段被层层包裹的文本。打开开发者工具F12后点左上角的箭头图标再点击页面上的某条消息你能看到它对应的 HTML 结构。豆包的前端会为每条消息设置类似message、chat-item、bubble这样的 class 名称开发者工具的选中区域会把这条消息的容器高亮出来。提取脚本要做的就是三件事用querySelectorAll找到所有消息节点。读取每个节点的文本内容innerText或outerText。按顺序拼成一个文件触发浏览器下载。这个原理对所有网页版 AI 工具都通用不管你用的是豆包还是别的聊天助手只要页面里消息是以文本节点渲染的就能用脚本提取。区别只在于选择器写法。3.2 书签小工具把对话提取为 Markdown我建议你做一个书签小工具以后每次想导出对话点一下浏览器书签栏里的按钮就能完成不需要每次打开控制台敲代码。操作步骤在浏览器书签栏新建一个书签名称随意比如“导出豆包对话”。把地址栏的内容替换成下面这段 JavaScript 代码javascript:(function(){ const selectors [[class*message],[class*chat-item],[class*bubble],[class*msg-item]]; const nodes []; selectors.forEach(sel { document.querySelectorAll(sel).forEach(el { const text (el.innerText || ).trim(); if (text text.length 2) nodes.push(el); }); }); if (!nodes.length) { alert(没有找到消息节点请先按 F12 检查页面 DOM 结构); return; } nodes.sort((a, b) { const r1 a.getBoundingClientRect().top; const r2 b.getBoundingClientRect().top; return r1 - r2; }); let md # 豆包对话导出 new Date().toLocaleString() \n\n; nodes.forEach((el, idx) { const text (el.innerText || ).replace(/\n/g, \n).trim(); if (!text) return; md ## 消息 (idx 1) \n\n text \n\n---\n\n; }); const blob new Blob([md], {type: text/markdown;charsetutf-8}); const a document.createElement(a); a.href URL.createObjectURL(blob); a.download doubao-chat- Date.now() .md; document.body.appendChild(a); a.click(); a.remove(); alert(导出完成消息总数 nodes.length); })();打开豆包网页版进入你想要的对话页面。如果对话很长先手动滚动到页面最底部触发历史消息加载完成再滚动回顶部这一步是为了让消息节点全部渲染在 DOM 里。点击书签栏里的“导出豆包对话”浏览器会自动下载一个.md文件。这段代码里有几个细节值得注意。选择器数组是尽量匹配豆包不同版本可能用到的 class 名。如果豆包前端更新后改了节点类名脚本找不到节点你就按 F12 检查当前消息节点的实际 class把对应类名加进selectors数组即可。另外我用getBoundingClientRect().top做了排序防止页面滚到中间时节点顺序错乱。最后用一个a标签配合URL.createObjectURL触发下载这是前端生成文件下载最常见的做法。3.3 升级玩法导出成 CSV 或 JSON方便转 Excel 和知识库很多时候 Markdown 还不够你想把对话整理成表格结构比如做成“序号、角色、内容”三列。这时候可以换个脚本思路直接生成 CSV 文件。用逗号分隔的内容在 Excel 里打开就是一张表。下面是一个可直接在控制台执行的 CSV 导出脚本const nodes [...document.querySelectorAll([class*message], [class*chat-item])]; const rows []; nodes.forEach((el, idx) { const text (el.innerText || ).replace(/\n/g, \n).trim(); if (!text) return; rows.push({ id: idx 1, role: text.startsWith(我) ? user : assistant, content: text }); }); let csv \ufeff [id,role,content].join(,) \n; rows.forEach(r { csv [r.id, r.role, r.content.replace(//g, ) ].join(,) \n; }); const blob new Blob([csv], {type: text/csv;charsetutf-8}); const a document.createElement(a); a.href URL.createObjectURL(blob); a.download doubao-chat.csv; a.click();这个脚本里我做了一个角色判断豆包网页版你发的消息通常渲染在右侧AI 回复在左侧但 DOM 结构里不一定直接写明了角色。我上面用了最简单的关键词判断逻辑你可以根据自己页面的实际结构改成读取class中的标识比如>const collected new Map(); const seen new Set(); function collect() { const nodes document.querySelectorAll([class*message], [class*chat-item]); nodes.forEach(el { const text (el.innerText || ).trim(); if (!text || text.length 2) return; const key text.slice(0, 50); if (seen.has(key)) return; seen.add(key); collected.set(key, { el, text }); }); } function autoScrollAndCollect() { return new Promise(resolve { const box document.querySelector(.chat-list) || document.querySelector([class*scroll]); if (!box) resolve(); const timer setInterval(() { collect(); box.scrollTop 0; // 滚动到顶部触发历史加载也可以反方向操作 const reachedBottom box.scrollHeight - box.scrollTop - box.clientHeight 50; if (reachedBottom) { clearInterval(timer); resolve(); } }, 800); }); }这个思路里滚动方向要看你当前处于对话的哪一端。豆包的会话历史是往上翻还是往下翻不同版本不一样。建议你先手动滚一下确认方向再修改脚本里的scrollTop赋值。另外要注意长时间自动滚动时页面可能比较耗内存如果对话特别长建议分段落导出不要一次收集几千条消息。4.3 浏览器扩展能做到什么程度如果你不太想维护油猴脚本也可以搜索现成的浏览器扩展比如“导出浏览器页面为 Markdown”“复制页面全文”这类通用工具。它们的作用范围更广不针对豆包做适配但通常能把你看到的整页内容转换成 Markdown 文件。这类扩展的好处是零代码装完就能用缺点也明显豆包的对话区域是动态渲染的扩展只会抓取它自己在页面加载完成后读取到的 DOM 快照如果你不预先滚动加载完所有消息扩展导出的内容一样是残缺的。另外一些扩展会在导出时把左侧导航栏、右侧推荐位之类的页面结构也夹带进来需要后续再清理。所以我的建议是如果只是偶发导出需求书签小工具最强如果经常要导出油猴脚本值得折腾一次扩展适合对格式要求不高、只需要快速保存一份页面内容的人。5. 从接口层导出用网络请求把完整记录挖出来手动复制和脚本方案的本质都是在“页面渲染后的文本”上做文章。如果你需要完整保留对话的元信息、想拿到服务端返回的原始数据结构或者需要批量导出多个会话那就得打开开发者工具从接口层面动手。5.1 DevTools 里定位聊天接口打开豆包网页版按 F12 进入开发者工具切到 Network网络面板勾选 Fetch/XHR 过滤项。然后在豆包对话输入框里随便发一句话观察面板里新出现的网络请求。你会发现带chat、message、conversation、ai这类关键词的接口。点开某个返回 JSON 的请求在 Preview 或 Response 标签页里就能看到完整的数据体。豆包这类产品的聊天接口往往不是一次性返回全部文本的而是采用流式输出。也就是说你在 Network 面板里可能会看到多条text/event-stream类型的响应每条响应只包含一小段增量文本需要把分片拼接起来才能还原完整对话。这不是什么奇怪的 bug而是流式响应下的大模型应用标准做法。如果你想在接口层导出完整对话需要把这些流式分片收集起来按顺序拼接工作量比从 DOM 提取要大不少。5.2 有效利用接口返回的 JSON假设你成功拿到了一个完整的接口响应里面通常会包含这些结构对话 IDsession id / conversation id消息角色user / assistant消息内容可能还包含引用、思考过程、工具调用等字段时间戳对话状态完成、生成中、被用户中断相比从页面脚本拿到的纯文本接口层的数据干净且结构化非常适合用来做后续的知识库预处理、模型微调或数据统计。你可以把 JSON 存下来再用脚本转换成 Markdown 或 CSV。这个链路也回答了很多人问的“如何把豆包对话做成知识库文件”——最标准的做法就是把接口数据清洗成角色和内容两列再入知识库。不过我要提醒一点抓接口拿数据这件事不同的产品可能有各自的反爬策略。如果你的账号是个人账号只导出自己的对话用于整理问题不大但如果要做大规模数据爬取、抓取别人账号的数据甚至用于商业用途这不仅不合规也有隐私和法律风险。自己用数据和个人学习场景没问题批量采集第三方账号数据坚决别碰。5.3 什么人适合接口方案接口方案不是给所有人准备的。我的判断标准有三个你需要全量数据而不是页面文本比如做知识库语料完整 JSON 里附带的时间、角色、工具调用记录都比页面文本有用。你有一定的代码基础知道怎么看 Network 的请求 URL能写一点fetch或curl能看懂 JSON 结构。你需要批量导出多会话手动进页面一个个点脚本效率太低接口层面可以按会话 ID 批量拉取。如果你只是想把一次聊天内容发给朋友看接口方案对你没有任何必要用分享链接就够。反之如果你在做个人知识管理相关的事建议花点时间学会接口层导出得到的结构化语料未来会很有价值。6. 导出后的整理工作与常见问题速查导出一份对话文件不是终点后面还有很多整理工作。我在这部分把常见问题一次性讲透顺便给自己常用的处理流程做个记录希望对你也有参考价值。6.1 导出后的文本清洗与格式转换脚本导出的原始文本通常有几种不干净的地方整理时按顺序处理即可。去掉操作按钮残留用正则把“复制”“点赞”“重新生成”“分享”这类关键词清理掉。如果是在 DOM 层提取的可能还会混入“已读”“刚刚”这类状态词。统一换行与空格Markdown 文件容易残留多余空行用\n{3,}替换成\n\n即可。中英文之间可以统一加空格排版更舒服。角色标记导出的文本如果没有按角色拆开可以用“用户”“豆包”这类前缀手动标记。若对话量特别大建议按原有 DOM 结构或接口数据里的 role 字段做自动化标记。格式转换需要 Word 就粘贴进 Word 里套用标题样式需要 Excel 就把 CSV 转成 xlsx需要入库就把 JSON 按字段映射成结构化记录。如果你是做知识库文件我特别不建议直接拿脏文本入库。知识的边界划分和角色切换标记会影响后续检索质量。至少要保证每条记录是“一条完整问答”把长对话切成逻辑独立的问答对入库召回效果会明显更好。6.2 常见问题速查表我把遇到过的问题整理成一张速查表方便遇到对应情况时快速定位问题现象可能原因解决方法复制出来的是残缺文本长回答没有加载完整或选中范围不够先滚动到最后再从头选中使用脚本时先加载完所有历史脚本提示找不到节点豆包前端改版class 名变了F12 检查当前节点实际 class更新选择器数组导出的内容包含按钮文案选择器选中了包含控件的父节点改用更内层的消息文本容器或正则清理常见按钮词对话顺序是乱的虚拟滚动复用了节点脚本按 DOM 顺序取到旧节点用getBoundingClientRect().top排序或去重后重新排序Excel 打开 CSV 中文乱码文件没有 BOM 头Excel 默认按 ANSI 解码导出时加\ufeff或用“从文本/CSV导入”显式选择 UTF-8长对话导出卡死一次收集太多节点或长时间自动滚动分段导出控制单次收集量分批合并手机端复制太麻烦App 没有全量导出入口用分享链接到电脑端打开再走网页脚本方案或用 iOS 快捷指令自动追加备忘录内容被截断不完整对话在生成中被中断或超过了单次输出上限先在豆包里点“继续生成”补完再导出Api 接口地址不知道把网页端和开放平台 API 混淆了个人网页端看不到 API Key需要 API 的话去火山引擎开放平台申请6.3 一些经验之谈与提醒最后分享几个我自己的使用习惯。我日常工作流里最常用的是书签小工具配合一个简单的 CSV 清洗流程。遇到重要的长对话我会先滚到底加载完然后点书签导出 Markdown如果这个对话要进入知识库我会再用接口层拉一次 JSON 做结构化处理确保时间和角色字段完整。这个组合不复杂但能满足绝大多数场景。还有一个提醒导出对话这件事最好养成“聊完就导”的习惯。豆包里的对话记录虽然会保存一段时间但产品过期策略、账号异常、误删会话这些情况谁都说不准。用自己的劳动成果和知识素材早点备份到本地才是对自己负责。我自己的素材库里专门建了一个豆包对话备份文件夹按日期归档比临时要找时到处翻强太多。说到扩展结合 JSON 结构化导出后续你还可以把历史对话做成个人问答知识库或者作为模型微调的候选语料。对话文本的整理本来就是个人知识管理的重要环节豆包只是其中一个数据源。把导出的链路打通以后不管换什么 AI 工具这套方法论都能复用。