微信流：把聊天记录变成 Codex 与 Obsidian 的数据管道

最近我在折腾一个挺有意思的开源工作流把微信聊天记录转成 Markdown 和 JSON 的“流”然后直接喂给 Codex 和 Obsidian。乍一听好像有点绕但你把场景拆开就明白了我们每天都在微信里产生大量对话这些对话里有需求、有决策、有灵感、有上下文可它们被锁在微信自己的数据库里既进不了你的笔记系统也进不了 AI 助手的工作区。这个开源“微信流”方案就是把那道墙拆掉——它不只是一个导出工具而是一条可持续更新的数据管道。这篇文章我会把原理、完整跑通流程、踩过的坑以及 Codex 和 Obsidian 两侧的实际用法都整理出来适合想给自己建立个人知识库的程序员、重度笔记用户以及所有对“聊天记录变成富矿”这件事感兴趣的人。1. 先搞清楚这个工具到底解决了什么问题1.1 微信聊天记录有多有价值就有多难拿出来我见过不少人把微信当成记事本跟同事聊天时定下来的方案、群里随手分享的资料、客户发来的需求描述甚至你当时随口答应过的事都埋在几百上千条未整理的对话里。真要回过身去找某条关键信息大概率只能靠“往上翻聊天记录”这个原始动作效率极低。问题是微信聊天记录不是一个普通的文本文件它存在本地的加密数据库里。iPhone、安卓、Windows、macOS 四个平台各有各的存储形式数据库还带着加密——安卓是 AES 加密的 SQLitemacOS 又套了一层 SQLCipher。你想把它变成自己能自由查阅和加工的数据第一道坎就是解密和读取。多数人卡在这里就放弃了这也是为什么市面上虽有各种导出脚本却很少有人能长期坚持跑下来。“微信流”这类开源项目要解决的正是从“数据在微信里”到“数据在你手上”这一段路。它把解密、提取、解析、格式转换、增量更新串成一条自动化流水线最后落成一套规范化的 Markdown 和 JSON 文件你不再需要理解 SQLite 的字段结构也不用关心加密算法的细节。1.2 “流”是什么意思不是一次导出而是可持续的数据管道和“导出一次就完事”的工具不同“流”强调的是持续更新。聊天记录每天都在增长如果每次都要整库重新导出不仅慢而且后续的笔记、AI 分析反而会被重复数据拖垮。一个设计合理的微信流方案会记录一个游标通常是最后一条消息的 ID 或时间戳每次运行时只拉取新增的部分转换成新的 Markdown 片段追加到对应会话文件里。这样你的 Obsidian 笔记库始终是最新的Codex 在帮你分析时拿到的也是精确到昨天的对话。这个增量思路和数据库的主从同步、日志消费很像本质上就是一个轻量级 CDCChange Data Capture管道。只不过它捕获的不是数据库事务日志而是你每天发出的那些“XX 收到了吗”“方案我改了一版”这样的日常消息。1.3 为什么偏偏是 Codex 和 Obsidian 当接收端选定接收端不是偶然。Codex 是 OpenAI 推出的命令行编程代理它的工作方式是读取你指定路径下的文件理解内容后直接生成代码或执行分析任务。你可以让它“看完这个文件夹里最近一周的聊天记录总结出还没完成的三件事”它真的会读文件、分析、给你结构化输出甚至把待办事项写进一个新 Markdown 文件。Obsidian 则是本地 Markdown 笔记库所有内容都是纯文本文件存在你自己的磁盘上。它没有“导入”的额外成本你只要把文件放进 vault 目录它就能自动索引、搜索、建立双向链接。两个工具的共同点非常关键它们都是“直接吃 Markdown 文件”的。所以微信流只要把聊天记录转换成格式干净的 .md 文件就能同时喂给两边。数据出口统一、消费端各取所需这套设计比给每个工具单独做定制导出要省事得多。提示如果你用的是其他笔记工具或 AI 编码代理只要它们支持读取本地 Markdown/JSON 文件同样能接入这个数据管道。微信流的输出格式越通用后续能玩的花样越多。2. 数据链路拆解从手机里的加密数据库到 Codex 能读的 Markdown2.1 寻找数据源不同平台微信数据库的存储形态微信的聊天记录在本地是有落库的关键是找准文件位置。安卓平台聊天记录在/data/data/com.tencent.mm/MicroMsg/hash/EnMicroMsg.db这是微信的主数据库包含 contact联系人、message消息等核心表。加密方式经历过变化早期版本用MD5(IMEI UIN)生成数据库密码微信 7.0 之后又在很多机型上改成从进程内存里取密钥。底层原理就是你身边那台设备在运行微信时密钥必然存在于进程空间里取证工具做的就是把它 dump 出来再用它去解锁数据库文件。macOS 平台的微信则使用 SQLCipher 加密的MM.sqlitedb密钥同样与微信账号和设备信息相关可以从微信进程内存里拿到。Windows 平台相对老实一些某些版本的数据库在本地不加密或加密强度较低但也在不断升级。这里我不打算贴攻击性太强、可能被滥用的具体代码。对于普通用户最稳妥的思路是用社区里现成的开源工具它们已经把这些“脏活”封装好了。你只需要按照工具文档在你的电脑上指定微信数据目录并获取密钥剩下的解密、读取都由脚本完成。需要特别提醒一句这套方案只适合处理你自己的设备、自己有权访问的数据不要拿去处理他人的手机或账号。聊天记录里有大量第三方个人信息这是最基本的边界。2.2 数据提取核心message 表里到底藏着什么拿到了解密后的数据库核心就落在message表上。这张表的字段大概长这样msgId消息唯一 ID也是增量同步的天然游标type消息类型1 是文本3 是图片34 是语音43 是视频49 是文件/链接/小程序等isSend是自己发的还是对方发的createTimeUnix 时间戳注意是秒级talker会话标识单聊是对方微信号群聊是群 IDcontent消息内容文本消息直接就是文字图片、文件等类型存的往往是描述信息或 XML 格式的元数据实际写提取脚本时最基础的一条 SQL 类似这样SELECT msgId, type, isSend, createTime, talker, content FROM message WHERE createTime :last_run_time ORDER BY createTime ASC;然后交给 Python 或 Node.js 脚本逐条处理。这里有个挺容易被新手忽略的细节createTime是设备本地时间手机时间如果出现过回拨、跨时区调整按时间戳排序会出现“新消息插到老消息中间”的情况。所以增量游标不能只用时间要结合msgId的自增特性来做去重否则你会看到同一条消息在笔记里反复出现。2.3 结构化输出的设计一份数据两种视角原始消息是扁平的一行行记录直接丢给 Codex 也能看但效果不好。微信流方案里最关键的一步是把原始记录转成有结构的 Markdown 和 JSON。在 Markdown 层面我建议按“会话 日期”组织。单一会话的文件里每天一个二级标题下面按时间顺序输出消息。每条消息的格式可以做成## 2025-01-12 **14:23** 张三这个接口的返回字段改一下把 code 和 message 拆开。 **14:25** 李四OK我下午改完发你新版。这种格式在 Obsidian 里看起来非常干净方便阅读和全文检索对 Codex 来说它也能清楚地理解“谁、什么时候、说了什么”。文件名我一般这样组织vault/ └── WeChat/ ├── 张三/ │ └── 2025-01.md ├── 产品讨论群/ │ └── 2025-01.md └── _index.mdJSON 版本则保留更完整的字段信息供程序化处理。比如让 Codex 做统计分析、生成词频、抽取待办或者接进 n8n 这类自动化工具时JSON 比 Markdown 更可靠。{ msgId: 123456, type: 1, isSend: 0, createTime: 1736648580, talker: zhangsan, content: 这个接口的返回字段改一下 }Markdown 给人看JSON 给机器用两边互不干扰。这也是“微信流”能同时服务 Codex 和 Obsidian 的底层原因数据源只有一份但输出视图可以有很多个。3. 我跑通的完整流程与关键配置3.1 环境准备从哪找工具、哪些依赖不能少开源社区里已经有了多种实现微信聊记录导出的项目具体到“微信流”这个用法你需要准备的东西其实很统一一个能读取本地微信数据库并解密的脚本Python 项目居多Python 3.10 环境安装了pysqlite3、pycryptodome、pandas这类基础依赖Codex CLI按官方文档安装以及一个可用的模型访问配置Obsidian直接用就够了不需要额外插件当然装了 Dataview 会更方便我实测的路径是macOS 上的微信先把MM.sqlitedb导出来解密后拿到明文数据再通过脚本生成 Markdown 和 JSON。整个过程大概分三步每一步都值得单独拿出来讲。3.2 核心配置项逐一说明我用的这个开源脚本暴露了几个关键配置理解它们能帮你省掉后面很多麻烦INPUT_PATH微信数据库文件所在路径macOS 下通常要指向微信的~/Library/Containers/com.tencent.xinWeChat相关目录。这里要留意新版 macOS 微信的沙盒路径可能跟旧版不一样。OUTPUT_DIRMarkdown 输出目录我直接指向了 Obsidian 的 vault 文件夹比如obsidian_vault/WeChat。SCOPE_TALKER指定要导出的会话白名单支持通配符。默认全量导出会带来大量无效信息尤其是各种群聊的“拍了拍”“红包”“系统提示”。FILTER_TYPE消息类型过滤。我通常排除 3图片、34语音、43视频只保留文本和关键链接记录这样笔记里不会有大量“图片”空条目。INCREMENTAL是否启用增量模式。打开后脚本会记录游标文件.cursor.json下次运行只处理新消息。USE_MD5_KEY解密方式开关。老版本微信用 IMEIUIN 算密码新版本往往要从内存提取密钥这个开关要跟你的微信版本匹配。下面是我调试时用的一份参考配置input_path: /path/to/MM.sqlitedb output_dir: /path/to/obsidian_vault/WeChat scope_talker: - 张三 - 产品讨论群* - 工作群* filter_type: [1, 49] incremental: true key_source: memory注意SCOPE_TALKER里我用了一个群名前缀匹配这是为了把“产品讨论群-1月版”和“产品讨论群-新需求”这样的群合并处理。如果不做白名单你会发现导出量比想象中大得多Obsidian 的搜索体验也会被噪声淹没。提示第一次跑全量导出时别直接怼整个数据库。先用白名单挑一个你最常用、信息密度最高的会话做验证确认 Markdown 渲染正常、Codex 能读懂之后再慢慢扩大范围。3.3 Codex 侧怎么用让它基于聊天记录干活Codex 的用法其实非常直接。先进入 Obsidian vault 目录然后调用 Codex 命令cd /path/to/obsidian_vault codex 阅读 WeChat/产品讨论群/2025-01.md帮我总结这个群最近一个月的讨论主题并列出还没结论的问题输出到 todo.mdCodex 会自己去读目录里的 Markdown 文件分析之后直接生成todo.md。这个能力用在聊天记录上特别对口你不需要自己逐条翻聊天记录而是让 AI 以“浏览记录”的视角给你产出摘要、待办、决策记录。更进阶一点的用法是把 JSON 数据喂给它做结构化分析。比如导出某个时间段所有带“价格”“预算”关键词的消息让 Codex 整理成一张费用对比表codex 读取 WeChat/供应商群/2025-01.json找出所有提到报价和合同的消息按时间顺序整理成表格标记出最终确定的报价这里有个体验上的关键点不要一次性把整个WeChat目录丢给 Codex。聊天记录累积起来字数非常惊人很快就会超过上下文窗口。正确做法是利用 Obsidian 的目录结构做第一级筛选让 Codex 只读单个会话的月度文件或者通过命令行把范围缩小到具体某一天、某个关键词。3.4 Obsidian 侧怎么用让聊天记录真正“进库”把 Markdown 放进 vault 后Obsidian 会自动建立索引你可以直接用系统搜索功能搜任意聊天内容。不过更实用的做法是装一个 Dataview 插件用元数据查询来替代人肉搜索。Dataview 是 Obsidian 生态里最流行的数据查询插件。它能把每个 Markdown 文件里的 frontmatter 当作数据库记录来查询。所以我在生成 Markdown 时会在每个文件头部塞一段元信息--- talker: 张三 date: 2025-01-12 type: 单聊 exported_at: 2025-01-18T09:30:00 app: wechat-flow ---有了这个 frontmatter我就能建一个 Dataview 查询把所有和“张三”相关的聊天记录按日期列出来TABLE date, talker FROM WeChat WHERE talker 张三 SORT date DESC你甚至可以用 Dataview 做统计仪表盘每个月聊了多少条消息、哪个群最活跃、最近一周的未读决策点。聊天记录到这里才真正从“归档数据”变成了“可用的知识资产”。4. 实测中的意外状况与隐私边界4.1 版本差异导致的打不开/解不出这应该是所有人第一次折腾微信导出时都会撞上的墙。微信的数据库加密方式不是固定的它随版本、平台、机型变化。我一开始用的是老版本的计算密钥方式结果在最新版微信上直接解不开数据库。排查路径是这样的先用文件命令确认数据库文件头如果是 SQLite 格式基本能判断为未加密或明文如果文件头是乱码或直接报“file is not a database”那就是加密了需要找正确的 key。加密 key 的获取有两个方向一是通过设备信息推算二是从内存中提取。社区开源工具基本都实现了第二种方式只是不同版本的偏移量不一样所以你需要找一个活跃维护中、支持你当前微信版本的项目。这个坑没有完美绕过的办法我的建议是不要追求一次搞定所有平台先解决你最常用的那个平台我用 macOS就先解 macOS。等链路跑通了再考虑扩充到安卓或 Windows 环境。4.2 消息类型的“隐藏内容”处理文本消息的 content 字段就是纯文字但 type 49文件、链接、小程序的 content 里存的是一大段 XML。比如一个小程序分享content 是msgappmsg appid...titlexxx/titledes.../des/appmsg/msg。如果你不解析 XML 直接展示Markdown 文件里就是一堆尖括号Obsidian 渲染出来极其难看Codex 阅读时也会被噪声干扰。正确的处理方式是用正则或 XML 解析器提取title和des转成可读文本后再写入 Markdown。图片和语音这类二进制文件数据库里只有元信息真正的文件在存储目录下分散存放。我的处理策略很简单默认跳过不把附件复制进 vault。原因一是体积膨胀太厉害二是 Obsidian 里塞一堆图片文件并不比原版微信浏览体验好。如果确实需要存档图片可以单独写个脚本把附件按msgId关联复制出来但这属于后续优化项第一版不必做。4.3 隐私边界本地消费和上传模型的取舍是两码事这是我最想强调的一点。把聊天记录转成 Markdown 放在本地 Obsidian 里没有问题数据始终在你自己的磁盘上。但当你把聊天记录发给 Codex 在线模型处理时内容就出去了。聊天记录里包含大量他人的语音转述、真实姓名、手机号、公司机密这些不是你能随意转发给第三方的信息。我自己的做法是“本地导出、脱敏使用、最小化上传”三原则导出后的原始文件只留在本地不分享、不上传。给 Codex 分析前先用脚本把人名、手机号、公司名替换成占位符张三→PersonA、138xxxx→PhoneX。每次只让 Codex 读最小必要范围比如单独一天的讨论摘录而不是整月、整年的全部记录。如果你有硬性的数据安全要求比如工作群聊涉及商业机密那么可以考虑把 Codex 的模型端点切到本地模型或私有化部署的服务上。现在不少开源兼容层都支持标准 OpenAI 接口Codex CLI 的模型端点也是可配置的换成本地推理后聊天记录可以在不出内网的前提下完成分析。这样既享受了 AI 协作的效率又把数据留在自己手里。注意不管用什么方案都别忽略聊天记录里第三方信息的敏感性。导出的文件、喂给模型的内容都应该经过最基本的脱敏处理。这不是技术问题是底线问题。5. 顺着这个思路还能做什么5.1 让 Codex 帮你生成结构化周报和决策复盘聊天记录里最值钱的是“上下文”——当时讨论的背景、反对意见、最终拍板的原因。但这些东西往往散落在几十条消息里事后很难回看。有了微信流之后你可以每周跑一次脚本生成一份“本周核心会话变更”然后让 Codex 基于它先生成周报草稿。比如我每周五会执行一次这样的流程codex 阅读 WeChat 目录下本周新增的 Markdown 文件按会话维度总结每个项目/讨论的进展、决定、未决事项输出一份周报写到 weekly-review/2025-W03.mdCodex 输出的是纯 Markdown可以直接在 Obsidian 里打开。长期积累下来你会得到一份“自己拍板过的决策记录”里面有时间、有背景、有结论、有下一步比任何模板化的周报工具都贴合实际。在多人群聊场景里这个玩法尤其有效。群里的信息量是最大的也是遗忘速度最快的地方。让 Codex 按主题聚类输出每周一次相当于给每个群配了一个隐形助理。5.2 接进 n8n把微信流变成自动化工作流的一环热词里有一个我很感兴趣的组合用 n8n 和大模型搭建微信自动发布流。n8n 是开源的自动化工作流工具它可以用 webhook 接收外部事件然后调用各种服务——包括 OpenAI 的模型接口、数据库、消息通知。微信流在这里能扮演“数据源”的角色脚本每天定时导出新增聊天记录将 JSON 内容 POST 到 n8n 的 webhookn8n 里的工作流再对消息做链路处理比如筛选含“待办”“确认”“需要反馈”的消息交给大模型生成摘要最后推送到你的 TODO 应用或飞书/钉钉群。这个自动化链条的价值在于你不需要在上班时间逐条刷群消息而是让系统把“真正需要你参与”的部分挑出来送给你。聊天记录从死水变成活水再变成你日程表上的一张卡片。5.3 长期使用后Obsidian 里的“个人记忆层”微信流用得越久你的本地知识库就越像一个人口密度极高的记忆层。所有跟同学、同事、客户、家人的对话按时间线沉淀成 MarkdownObsidian 的双链和搜索把它们织成网。你完全可以做到某天突然想起“去年跟老王提过一个推广方案”在 Obsidian 里搜索“老王”和“推广”几秒钟就把当时的上下文捞出来。这种能力放在十年前得靠人工整理日记才能实现而现在的开源工具自动完成了。你付出的只是跑一次脚本的功夫得到的却是整个微信对话史的可检索化。从我个人的感受来说未来这类“个人数据管道”会越来越普及。微信、邮件、短信、浏览器历史这些散落在不同应用里的信息都可以通过类似微信流的模式变成你自己拥有的结构化数据再交给 AI 去消费。谁先把自己的数据管道跑通谁就拥有了一个别人没有的、私有的 AI 上下文库。最后分享一个小技巧当你第一次跑通全流程后别急着追求全量历史导出。从你最常聊的一位联系人、一个群开始连续跑一周增量慢慢验证脚本稳定性、Obsidian 渲染效果、Codex 输出的准确度。稳定之后再把白名单范围逐步扩大。数据管道这件事跑通远比跑满重要——毕竟聊天的数据每天都在增加今天没导出来的明天还能补上但如果你因为最初一次失败的配置就放弃了整套方案那才是真正的损失。