Meta AI会话批量导出全攻略：手工复制到脚本自动化

有人问我Meta AI 左侧那一排会话能不能一次性全导出注意不是导出某一个会话里面的几十轮对话是把左侧列表里的一堆会话批量备份到本地。这个问题听起来像个偏门需求真上手做的时候却很有代表性。我见过不少人有同样困惑想把一个账号下的AI对话历史整理走换个工具继续用或者给自己留一个可检索的知识库。但问题是找遍界面也找不到一个“全选导出”按钮。这篇我就从产品现状讲起给你手动、接口、脚本三条路线最后放一个能改着用的批量导出脚本顺带把路上会踩的坑都标出来。1. 先搞清楚“导出多个会话”到底要导出什么1.1 别把“复制当前页”当成导出很多人一开始觉得导出不就是把文字拷出来嘛。实际操作起来才会发现页面里能选中的文字只是当前这个会话、当前屏幕显示出来的内容。左侧那一长串会话列表压根不在你的选中范围里。真正意义上的“导出多个会话”至少要包含三个层次的数据。第一层是会话的元信息比如会话标题、创建时间、最后一次更新时间第二层是会话里的每一轮消息包括用户提问、AI回答以及角色标识第三层是结构化的格式能够被其他工具读取比如 JSON 或 Markdown。这些需求叠加在一起就跟“复制粘贴”完全不是一回事了。所以做方案之前我会先问自己一句到底要导到哪一层是要一个能阅读的文档还是要一份能程序化处理的原始数据这两种目标后续方案完全不同。1.2 你的目标格式决定了整个方案这里我列过一个简单的需求分级你可以对照着看需求级别典型场景推荐导出格式实现难度单条消息复制临时引用某段回答纯文本最简单单个会话导出把一次长对话存成笔记Markdown 文档中等多会话批量备份换工具迁移、知识库整理JSON Markdown 双份较高全量数据审计分析对话模式、统计用量结构化 JSON最高我用下来最有感触的是想要“批量导出”的人大多数其实是要第三个层次。他们不是缺某一段文字而是想把一整个会话库带走。2. 先说结论官方目前没给这个能力2.1 平台上现有的导出入口有哪些以我目前能看到的产品形态来说Meta AI 的会话管理做得比较轻。常见的操作基本是这些单条消息旁边会有复制按钮你可以把某一次回复单独复制走有些入口支持分享会话链接把整个对话通过链接给别人看语音类的消息可以单独另存为音频文件。但是“左侧列表 → 批量选择 → 导出为文件”这个入口在我见过的版本里是没有的。不仅 Meta AI 没有市面上大多数类似产品在这方面都不约而同地保守。你很难找到一个 AI 助手允许你把全部历史会话一次性打包下载。所以如果你正盯着左侧列表发愁很正常不是你不会用是产品压根没有把入口放出来。2.2 为什么批量导出迟迟不来很多人想不通一个导出按钮而已为什么这么难做我之前也好奇过后来结合行业里的普遍情况有几点推测。从产品优先级看AI 助手这类产品把精力都放在生成质量、响应速度、多轮理解上会话管理属于基础功能定期清理就够了。批量导出这种低频需求排期大概率会一直往后放。从数据开放看批量导出意味着把完整对话历史交给用户这本身涉及数据格式设计、权限控制、隐私保护。对一个团队来说每多一个导出格式就要多维护一套兼容逻辑。只要不是付费点优先级就很难提上去。从商业角度看就更直接了。平台通常希望你把对话留在自己的生态系统里导出得越顺畅用户迁走的成本就越低。所以“官方不做批量导出”很多时候不是做不到而是权衡之后选择不做。3. 官方没有那就自己动手三条可行路线3.1 路线A纯手工整理适合十几个会话以内如果你的会话数量很少比如就五六个那最靠谱的办法反而是纯手工。具体操作是逐个点开会话从第一轮消息全选到最后一轮粘贴到一个支持 Markdown 的编辑器里然后手动补上会话标题、日期、备注。最后另存为本地.md文件。听起来简单实际操作有两个坑。第一个坑是长会话自动滚动。页面在加载历史消息时会自己跳位置容易把你正在选的文本弄乱。我的做法是先把页面滚动速度调慢选定文本后立刻用鼠标右键复制不要等全选动画跑完再操作那基本会失败。第二个坑是代码块缩进。直接从页面全选复制代码块经常丢掉换行和缩进这个一般无解只能靠编辑器里的格式化功能补救。这条路最大的优点是不依赖任何额外工具也不会触发风控。缺点是会话一多就废超过二十个你会复制到怀疑人生。3.2 路线B从浏览器开发者工具里拿JSON懂一点网页技术的话可以用开发者工具直接从接口层取数据。这条路比手工稳定也比脚本轻量。操作流程是把 Meta AI 页面打开按 F12 进入开发者工具切到 Network 面板勾选 Fetch/XHR清空现有记录然后刷新页面。接下来你能看到页面在后台发出不少请求。这时候要在这些请求里找跟会话列表相关的。通常名字里会带 conversation、thread、history 这类关键字。点开请求看 Preview如果是 JSON基本就是数据源。会话列表接口一般会返回所有会话的标题和 ID点开单个会话的时候又会有一个请求返回当前会话的所有消息。找到之后右键那个请求选 Save as HAR 或者 Copy response把内容存成.json文件原始数据就到手了。这条路比手工靠谱因为它拿到的就是结构化数据包含角色、内容、时间戳这些字段。缺点是每次都要手动操作而且接口的字段名很乱需要自己花时间解析。3.3 路线C脚本自动化批量导出适合大量会话当你面对的会话数量到了几十上百个手工和开发者工具都不够用了。这时候最合适的是写一个自动化脚本让浏览器自己跑一遍登录、滚动左侧列表加载更多会话、逐个点击、读取消息、存成文件。我自己的经验是第一次搭这套脚本需要一两个小时但建好之后以后每次备份都是几分钟跑完的事。而且脚本跑出来的结果是固定格式后续整理成知识库、迁移到别的工具都非常顺手。唯一需要留神的是别开太猛。脚本模拟真人操作每步加一点随机延时通常不会有问题。如果你疯狂并发、无视频率去点就会触发平台的风控后面我会专门讲这个问题。4. 跑一个能用的批量导出脚本4.1 设计思路和工具选型自动化方案我推荐用 Python 加 Playwright而不是 Selenium 或者纯 HTTP 请求。原因有三点Playwright 自带自动等待能减少页面没加载好就点击的报错它支持持久化用户目录第一次手动登录之后之后跑脚本不用重新登录它的选择器引擎也更强能根据文本、角色、层级关系定位元素改起来方便。安装环境很简单pip install playwright playwright install chromium如果你用的是其他 Chromium 内核的浏览器也可以指定 channel 参数复用不一定非要下载它自带的浏览器。4.2 主脚本代码和关键点说明下面这个脚本是个通用骨架。我故意不把选择器写死因为界面只要改版任何提前写死的选择器都会失效。你需要跑之前打开开发者工具找到自己页面上会话列表和消息区的真实选择器替换到代码里。 批量导出 Meta AI 会话列表 用法先手动登录一次之后脚本使用持久化登录态 from playwright.sync_api import sync_playwright import time import random import json from pathlib import Path OUT_DIR Path(meta_ai_exports) OUT_DIR.mkdir(exist_okTrue) def main(): with sync_playwright() as p: browser p.chromium.launch_persistent_context( user_data_dir./playwright_userdata, # 持久化登录态 headlessFalse, # 有头模式方便观察 localezh-CN, ) page browser.new_page() page.goto(https://www.meta.ai/) # 换成你实际访问的入口 input(请在浏览器中手动登录登录完成后回到这里按回车继续...) # 第一步滚动左侧会话列表触发懒加载 for _ in range(30): page.mouse.wheel(0, 1000) time.sleep(random.uniform(0.6, 1.2)) # 第二步找到所有会话入口 # 注意这个选择器需要根据实际页面调整 threads page.query_selector_all(a[href*chat], [rolelistitem]) print(f发现 {len(threads)} 个会话) # 第三步逐个点开会话抓取内容 for idx, thread in enumerate(threads, 1): try: title thread.inner_text().strip() or fconversation_{idx} thread.click() time.sleep(random.uniform(1.5, 3)) # 第四步读取消息区域 # 注意这里的选择器是核心界面变化时需要现场调整 message_nodes page.query_selector_all( [data-testid*message], [class*message] ) lines [] for node in message_nodes: lines.append(node.inner_text()) payload { title: title, source: meta_ai, exported_at: time.strftime(%Y-%m-%d %H:%M:%S), content: \n.join(lines), } (OUT_DIR / f{idx:03d}.json).write_text( json.dumps(payload, ensure_asciiFalse, indent2), encodingutf-8, ) print(f[{idx}] 已导出{title[:30]}) except Exception as e: print(f[{idx}] 失败{e}) browser.close() if __name__ __main__: main()这段脚本有几个设计细节值得说。第一步滚动左侧列表时我用的是一轮一轮慢慢滚每轮之间加随机延时目的是触发页面的懒加载又不让操作节奏看起来像机器。如果你发现滚完 30 轮还是没加载完全部会话可以把数字调大或者改成滚到页面底部之后等待 2 秒再继续。第三步点击会话的时候我用inner_text()先拿到标题再点击这样即使选择器匹配到多个元素也能知道每一个处理的是谁。导出文件名用序号加标题可以避免文件名里出现非法字符。4.3 导出之后把JSON整理成Markdown原始 JSON 适合程序处理但不适合人看。所以我会在跑完脚本之后再执行一个小转换把 JSON 变成 Markdown 存一份。这样一份是数据、一份是笔记两不误。from pathlib import Path import json for fp in sorted(Path(meta_ai_exports).glob(*.json)): data json.loads(fp.read_text(encodingutf-8)) md_lines [f# {data[title]}, ] md_lines.append(data[content]) md_lines.append() md_lines.append(f导出时间{data[exported_at]}) md_path fp.with_suffix(.md) md_path.write_text(\n.join(md_lines), encodingutf-8) print(f已生成{md_path.name})如果你希望 Markdown 里也能区分用户和 AI 的回答那就不能像我上面这样简单把文本拼成一大段。更好的做法是在脚本里把每个消息节点分别打上“用户”或“AI”的角色标签然后再转 Markdown。这需要在页面里找到每个消息节点对应的角色容器通常通过 aria-label 或者父节点的 class 能判断出来。界面结构清楚之后这是一步很小的改动但整理出来的东西会专业非常多。5. 踩坑实录这些问题我基本每次都会遇到5.1 会话列表只抓到一截后面全是空的这是最常遇到的问题。场景是脚本统计到了 5 个会话但左侧列表肉眼看着明显有三四十个。原因基本是懒加载没有彻底触发。页面只在滚动到靠近底部的时候才去加载下一批会话而脚本滚得太快或者还没等加载完成就继续滚最后一截数据始终没进来。我的解决办法分两步。第一步是控制节奏不要连续快速滚动改成“滚动一下停下等 1 秒再滚动一下”让网络请求有时间返回。第二步是判断加载状态如果页面里有 loading 指示器或者骨架屏等待它消失再继续滚。如果实在判断不准还有一个笨办法滚动到底之后等待 3 秒再滚回顶部重新统计一次会话数量跟第一次的数量做对比一致才继续。5.2 点开会话之后取到的消息不完整另一个高频问题打开一个特别长的会话脚本只读到了开头几段后面的内容没有出现。很多页面用了虚拟滚动尤其是 AI 对话这种消息列表特别长的情况页面只渲染屏幕范围内的消息节点滚出视口的节点会被销毁。所以你不能指望打开页面之后一次性拿到所有内容。好的做法是点开会话之后找到消息列表的滚动容器然后模拟“从上往下慢慢滑”的操作每滑一段就把新读到的内容追加到数组里一直到滚动容器高度不再变化。这个过程比较费时间但这是虚拟列表下唯一稳妥的路径。还有个细节有些页面会在你向上滚动时自动展开更早的历史记录这时候你看到的顺序是倒着的。我的做法是每次滚动后给新追加的内容前面加上窗口序号最后再统一排序拼接避免顺序错乱。5.3 登录态、限流、验证码这类账户问题脚本跑着跑着突然要求重新登录或者干脆收到限流提示这事我也踩过。原因通常是操作频率过高被判定为异常行为。面对这类问题首先是别图快。我在脚本里加了随机延时目的就是让每个操作之间的间隔不太规律。其次如果长时间运行宁可中间暂停一下再继续也别开着脚本去吃饭让它在极端时间内发起几百次请求。最后登录态尽量不要每次都重新登录用持久化用户目录可以大大减少验证次数。第一次手动登录之后之后的会话只要能恢复 Cookie 就是安全的。另外如果脚本是在特殊网络环境下跑的页面上偶尔会弹出额外的安全验证步骤。这种情况只能手动介入判断到页面 URL 变成验证页时主动停下来等人工处理。5.4 导出到了最后分不清哪些没抓到脚本跑完不代表完事。我经常跑完之后发现导出的文件里少了某几个会话但它们并没有报错只是静默跳过了。要避免这种情况就得在脚本里留审计信息。每次处理完一个会话把会话标题写进一个清单文件整个脚本跑完把清单跟左侧列表的总数做对比。如果总数对不上就把缺失的标题打印出来单独补抓一次。我在脚本里已经放了打印标题的逻辑你再加一步把同一个清单追加进一个exported_titles.txt。这样每次导出都有痕迹哪里断了也能一眼看出来。6. 最后说点实在的我自己用这一套流程给人迁过不少对话数据最大的体会是真正的难点往往不在脚本本身而在于你根本没想清楚自己要导出什么。格式定清楚了脚本怎么改都很顺手格式没定清楚再好的工具导出来也是一堆用不上的文本。如果你只是想把三五个重要会话备份走手工复制反而比写脚本更快不要上来就追求自动化。但如果你面对的是几十上百个会话批量导出脚本能帮你省下一个完整的下午。最后提醒一句批量导出的数据基本属于个人使用范畴用作备份和迁移没有问题但如果你要把导出的内容拿去二次分发或者做商业化用途请一定好好看一遍平台的服务条款。尊重数据边界工具才能长长久久地用下去。