你的AI对话，正锁在10个App里——这个6天827星的开源项目，把它们全导了出来

一

先说一件你多半没细想过的事。

过去两年，你换过几个 AI 编程工具？

Cursor、Claude Code、Codex CLI、Windsurf、Aider、Cline、Gemini CLI、OpenCode……每隔几个月，就会冒出一个"更好用"的，然后你就换过去了。

每换一次，你都以为只是换了个工具。

但你其实丢了一样东西：历史。

你和 AI 来来回回的那几百上千轮对话——它怎么帮你定位那个诡异的内存泄漏，你又是怎么一步步把需求说清楚、把它掰到正确的方向上——全都留在了上一个工具里。

换工具，等于清零。

更隐蔽的是：这些对话从来不是"聊天记录"，而是你独有的、用真金白银和真实项目喂出来的语料。它记录了你这个团队的技术偏好、踩过的坑、反复确认过的最佳实践。放在今天，这就是最值钱的东西——可以用来微调一个真正懂你项目的模型，可以拿来做个人效率分析，也可以单纯留档，免得哪天 App 一次更新就把数据库清了。

可它偏偏散落在十个 App 的十个数据库里，格式各异、位置各异，甚至没有任何一个工具愿意让你把它导出来。

9 月 11 日，GitHub 上出现了一个项目，六天拿下 827 颗星、132 次 fork。它想解决的，正是这件事。

它叫 ai-data-extractor。

二

ai-data-extractor 是什么？

一句话：把你本地各个 AI 编程助手的聊天历史，统一导出成一种格式。

它的定位很清晰——只做一件事，但做到位：你本机的、你自己的对话数据，你说了算。

它的实现干净得近乎固执：Python 写成，只用标准库，零第三方依赖，MIT 协议，允许直接用于训练机器学习模型。下载即用，不用装任何东西，不用联网，不需要 API Key。

支持的来源，覆盖了当下主流工具：Claude Code、Codex CLI、Cursor、Windsurf、Trae、Continue、Gemini CLI、OpenCode、Cline / Roo Code、Aider。

十个工具，十条不同的数据路径，一套统一的出口。

它的态度也很明确：这不是爬虫，是开锁。 数据本来就在你自己的电脑上，只是被各家 App 藏进了自己的小黑屋。这个工具做的事，是找到钥匙，把属于你的东西拿出来。

而且它是只读的。它从不往你的数据库里写任何一个字。

项目由一位开发者独立完成，代码量不大，结构却异常清楚：一个主入口 extract.py，一个装满各家适配器的 extractors/ 目录，一份讲得明明白白的 README。没有云服务，没有账号体系，没有"升级到 Pro"的按钮。它更像是一把小工具，而不是一个产品——而恰恰是这种"不图你什么"的姿态，让人愿意把 827 颗星投给它。

三

为什么这件事，值得被单独做成一个项目？

因为它背后，是一个正在加速的趋势：AI 工具在爆炸，数据却在碎裂。

三年前，你写代码可能只用 VS Code 加一个插件。今天，你同时在用命令行里的 Claude Code、编辑器里的 Cursor、终端里的 Aider，可能还有 Cline 在后台替你跑任务。

每一个工具，都声称自己"更懂你"——它记住你的项目结构，记住你的编码习惯，记住你上次为什么否掉了那个方案。而这些"记忆"，本质上都是你亲手喂给它的上下文。

问题在于：这些记忆的载体，是各家自己的私有数据库。没有标准，没有文档，说改就改。Cursor 一家就至少变过三种存储结构；Windsurf 和 Trae 干脆连 schema 都不公开。

于是形成了一个很别扭的局面：你越依赖这些工具，你越被它们锁死。 你想换，就要接受"从零开始调教一个新助手"的代价——因为过去那些宝贵的上下文，你带不走。

ai-data-extractor 的 827 颗星，本质上就是一群被这个问题卡住的人，投出的票。

它出现的时机也很微妙。就在过去一两个月，AI 编程工具市场刚刚经历了一轮密集的新品发布和版本迭代，几乎每个开发者手里都同时装着两三个。工具越多，"数据被切得越碎"的痛感就越强。这个项目没有去卷模型能力，而是转身解决了一个更底层、也更长久的问题：当工具不断换代，属于你的那份数据，怎么才能跟着你走。

这，才是它真正的价值锚点。

四

它凭什么值这个数？核心在四个地方。

第一，十个工具，一张表全拿下

表面上看，十个工具无非就是"多写几个脚本"。真正难的地方在于：这十家的数据，长得完全不一样。

Claude Code 是一会话一文件的 JSONL；Codex CLI 是"rollout"式的 JSONL；Cursor 用的是 SQLite，而且光它一家就至少变过三种存储形态——早期的 workspace 聊天、内联 composer、后来的拆分式 bubbleId composer，这个工具三种全部显式实现了。

Continue 是每会话一个 JSON；Gemini CLI 是每对话一个 JSON；OpenCode 是一套 session / message / part 的 JSON 树；Cline 和它的分支 Roo Code 存的是 Anthropic 格式的原始消息数组；Aider 最特别——它压根没有中央数据库，只有每个项目目录下的一份 Markdown 记录。

把十种"方言"翻译成同一种"普通话"，这才是它真正的工程量。

第二，三个操作系统，自动认路

你不用告诉它你在哪个系统。

它会自动识别 macOS、Linux 还是 Windows，然后按各自的惯例去翻找数据根目录——~/Library/Application Support、~/.config、~/.local/share、%APPDATA%、%LOCALAPPDATA%。

对 Aider 这种没有固定目录的，它还会默认扫描你的主目录，以及 projects、code、dev、repos、workspace、src、Documents 这几个常见的项目根，最多下探五层，同时自动跳过 node_modules、.git 这类噪音目录。找不到也没关系，你可以用参数直接指定路径。

第三，只读，稳，不添乱

它打开 SQLite 数据库时，用的是只读模式（mode=ro）。这意味着，哪怕你的编辑器正开着，也不会被它锁住。

更细节的是，每一个读取器都被异常处理包住。哪怕中途碰到一个损坏或锁定的文件，也只会让你拿到一份"部分结果"，而不是整轮跑崩、甩你一个堆栈报错。

这种"能少一事就少一事"的克制，恰恰是这类工具最该有的品质。毕竟它碰的是你电脑上最私密的一类文件——一旦它自己出事，代价比谁都大。

第四，统一格式，面向扩展

不管你从哪个工具抽出来，输出都是同一种结构：一行一个 JSON 会话，里面是标准的 messages[] 数组，附带时间戳、会话 ID、项目路径、模型名——凡是原工具存了的，它都尽力保留。

字段会因来源略有差异，但 messages、source、session_id 这三个一定在，是你能稳定依赖的骨架。

想加一个它还没支持的工具？门槛低得出奇。每个抽取器都是一个独立小模块，只要实现两个函数——find_installations() 找到位置，extract() 返回会话列表——然后在主程序的注册表里加一行就行。作者甚至贴心地点名：抄最简单的 continue_ext.py 当模板。

它没有把自己做成一个封闭的黑盒，而是做成了一套"你随时能接管"的脚手架。

五

快速上手，几乎不需要学习成本。

先确认 Python 版本（要求 3.9+，推荐 3.10+），然后：

# 交互式：从一个编号菜单里挑要抽取哪些来源python extract.py# 或者直接驱动它python extract.py --all                                  # 抽取全部python extract.py --sources cursor,claude_code,aider     # 指定来源python extract.py --list                                 # 只看发现了什么，不抽取python extract.py --all --merge                          # 顺便合并成一个总文件

最推荐先用 --list。它会告诉你每个来源分别找到了什么，但不做任何抽取——这是一个又快又安全的预览。

真正抽取时，它会在 extracted_data/ 目录下，按时间戳生成一份份文件，一个来源一个，加上 --merge 还会多出一个 all_conversations.jsonl，把所有来源合并到一起。

六

那么，导出来能干什么？三个真实场景。

场景一：备份与迁移。

你要换电脑、换工具，或者只是担心某次 App 更新会清库。先跑一遍 --all，几年的对话就有了本地存档。工具会变，数据不会丢。

场景二：个人分析。

哪类问题你问得最多？哪个项目消耗了最多轮次？哪些反复出现的坑，其实可以沉淀成一份团队规范？过去这些没法统计，因为数据锁在 App 里。现在它是一份标准的 JSONL，随你用什么工具分析。

场景三：微调你自己的模型。

这是最有想象力的一条。README 里直接给了一段 Hugging Face 的用法：

from datasets import load_datasetdataset = load_dataset("json", data_files="extracted_data/*.jsonl", split="train")dataset = dataset.filter(lambda x: any(m["role"] == "assistant"for m in x["messages"]))

把格式统一之后，这些对话就直接是一份可以喂给训练流程的数据集。你不再只是"用别人的模型"，你可以开始训练一个懂你代码库、懂你口味的模型。

一句话总结这三件事：过去，你的对话是消耗品；现在，它是资产。

这里还有一个容易被忽略的价值：它是团队知识的入口。

一个团队里，最懂某个系统的往往只有一两个人。他们踩过的坑、总结出的模式，大多沉在他们和 AI 的对话里，从没被写进任何文档。把这些对话导出来、扫一遍，很可能就是一份现成的"团队经验清单"——那些被反复问到的同类问题，那些"下次别再这么写"的提醒，全都在里面。

数据先能流动，知识才谈得上沉淀。

七

但有一个前提，必须说清楚：隐私。

这个工具抽出来的，是你和 AI 的原始对话。里面很可能夹着密钥、内部代码、真实的文件路径。

所以作者在 README 里写了一段很负责任的提醒，值得原样记住：

导出之后，先用 detect-secrets 之类的工具扫一遍密钥；重点检查 code_context 和 tool_use 这两个字段，它们最容易藏东西；永远不要把 extracted_data/ 提交到公开仓库（它默认已经写进了 .gitignore）；如果里面含客户或私有项目的内容，就把它放在加密存储上。

还有一句底线声明：这个工具抽的是你自己机器上、你自己账号下的数据。你有责任确认自己有权处理这些数据，并遵守各个工具的服务条款。

能拿走自己的数据，是权利；怎么保管它，是责任。

八

回头看，ai-data-extractor 解决的是一个很朴素、但一直被忽视的问题：在 AI 时代，你的数据到底属于谁？

我们习惯了把聊天记录、代码历史、个人偏好，统统交给一个个 App 托管。直到某天想换工具、想训练模型、想做备份，才发现——我连把自己的话导出来，都做不到。

这个项目没有炫技，没有大模型，没有花哨的界面。它只是老老实实写了十个抽取器，把散落在十个黑盒里的数据，还原成一份你可以自由处置的文件。

六天 827 星，132 次 fork，说明被这个问题卡住的人，远比想象中多。

如果你手头正好有几个 AI 编程工具，不妨现在就跑一次 python extract.py --list。花不了一分钟，你就能看清：这两年，你到底和 AI 说了多少话，又差点丢掉了多少。

工具会过时，数据不会。先把属于你的那份，拿回来。