你有没有经历过这种时刻在某个技术群里有人贴出一段很精彩的方案讨论你当时心里默念“回头整理一下”然后这个“回头”就再也没有发生过。微信聊天记录里其实藏着一座金矿方案取舍、报错日志、产品反馈、代码片段、临时的灵光一现。但它的默认形态是聊天框按时间线堆在那里既不适合回顾也没法和 AI 工具直接对话。过去半年我把主要工作流几乎全搬到了 Codex 和 Obsidian 上一个负责写代码做 code review一个负责沉淀知识库和项目笔记。唯一一直接不进来的数据源就是微信聊天记录。这个叫“开源微信流”的方案解决的正是这个问题。它把微信聊天记录从本地数据库里结构化拉出来然后直接喂给 Codex 和 Obsidian前者能拿到真实的业务上下文后者能把聊天内容沉淀成可检索的双链笔记。这篇文章是我自己的实测记录从整体架构到部署实操从 Codex 和 Obsidian 两侧的具体玩法到一堆踩坑过程包括最终给这套管道划下的隐私红线一次讲清楚。适合谁看如果你和我一样靠 Codex 写代码、用 Obsidian 做知识管理又舍不得丢聊天记录里的信息这篇文章可以直接照着抄。如果你只是好奇一个开源项目怎么把零散的聊天记录变成“数据流”架构部分也有不少可以借鉴的设计思路。1. 为什么我一定会做一条“微信流”管道1.1 聊天记录是“时间线形态”的信息而不是“知识形态”我加了不少技术群、行业群真正有价值的讨论往往不是长文而是三五个人的碎片对话有人说“RAG 召回率低可以先看 chunk 粒度”另一个人接一句“chunk 切成 256 试试overlap 用 16”然后话题就过去了。这些内容的共同点是时间线上看非常有价值事后找却毫无头绪。微信自己的搜索能搜到关键词但它把结果按照时间线平铺给你没有结构、没有上下文、没有关联。更致命的是你很难把这些片段“搬运”到别的工具里继续加工。截屏保存一批过两周连自己都懒得看收藏一堆语音和链接最后收藏夹变成垃圾堆。所以核心矛盾是信息有保存价值但它的形态决定了它只能躺在聊天框里“死亡”。1.2 现有导出工具的尴尬能导出但不能消费市面上的工具我几乎试了一遍。WeChatMsg、PyWxDump 这类开源工具能帮你把微信的本地数据库解密把消息导成 HTML、CSV、TXT 或者 JSON。做到这一步当然很不容易但问题在于导出结束链条也就断了。CSV 躺在文件夹里没有引擎去消费和没导出几乎没有本质区别。你仍然需要手动把讨论“塞”进某个工作流比如打开 Obsidian 复制粘贴或者把关键问题重新描述给 Codex。如果聊天记录是几十万条这种手动搬运根本不现实。我一度想过自己写脚本采集但每次想要维护增量、去重、清格式就又放下了。1.3 Codex 和 Obsidian恰好是这个闭环的两端后来我把思路换了不要“导出完就结束”而是要一条“管道”。数据源是微信出口要连接我真正每天都在用的两个工具。Codex 是代码侧它需要的是放在项目目录里的文本上下文Obsidian 是知识侧它需要的是 Markdown 文件、双链、标签结构。一个持续运行的流式管道把微信聊天记录往这两个出口分别推送闭环就成了。这正是“开源微信流”这个开源项目的设计初衷也是我 fork 它、改配置、跑了两个月之后决定写篇文章记录下来的原因。这个思路本身并不复杂难的是每一步的取舍。下面顺着架构讲。2. 微信流的技术选型为什么是“数据库导出 JSONL 双导出器”2.1 数据源微信本地数据库导出与解密环节先明确一点这个管道不碰网络协议不做实时抓包更不去做任何“机器人”行为。它的数据入口只有一个你本机已经存在的微信聊天数据库。Windows 微信的聊天记录本质是一个 SQLite 数据库但内容做了加密直接用数据库工具打开是乱码。WeChatMsg、PyWxDump 这类开源工具就是解决这一步的它们通过读取本机进程内存里的密钥或者通过你手动导出的备份文件把数据库解密成明文。微信流在我这边的参考实现是把这一步封装成了一个 exporter 前置任务最终产出一份 JSONL 原始数据文件。这里我想强调一个操作习惯解密导入的时候先把微信客户端完全退出再读数据库文件。我刚开始跑的时候图省事微信开着就启动导出结果数据库文件被占用导出到一半直接报错还出现过一次拿到的是旧缓存数据。后来我统一把采集环节放在微信退出以后用定时任务在空闲时段执行问题就再没出现过。2.2 中间层为什么用 JSONL 而不是 CSV / HTML解密之后的数据格式选择决定了后面所有环节的稳定性。我见过不少人直接拿 CSV 做中间格式但 CSV 有个致命短板字段顺序一旦变化脚本就崩。聊天记录里有文本、图片、引用、转账、系统通知字段类型非常复杂CSV 的列漂移问题几乎是必然的。微信流选择的是 JSONL也就是每行一个 JSON 对象。下面是实际跑起来之后一份非常典型的消息记录{sid: wxid_xxxx, room: 车库咖啡技术群, sender: 阿伟, type: text, content: RAG 召回率低的话先看 chunk 粒度, ts: 1749110400, seq: 88321}这种格式的优点是显而易见的每行独立不会因为某条消息格式不对就把整个文件搞坏逐行读取就能做增量后续转 Markdown、转摘要、转 Anything都只用读一条处理一条。它比 JSON 数组更稳也比 CSV 更灵活。微信流的主要同步逻辑都建立在这份 JSONL 之上。2.3 增量游标与去重状态的设计聊天记录是持续增长的所以管道不能每次全量跑必须做增量。微信流里维护了一个state/cursor.json状态文件记录每个会话已经消费到哪一条消息序号。{ 车库咖啡技术群: {last_seq: 88321, last_ts: 1749110400}, 项目A作战群: {last_seq: 12034, last_ts: 1749096000} }每次运行时只处理seq大于游标的记录处理完成后更新游标。遇到崩溃、断电、进程被杀状态文件已经持久化重启后不会重复消费也不会漏掉中间的数据。去重则依赖消息的唯一 ID处理侧会对新拿到的消息做一次 hash 比对确保不会把同一条消息写入 Obsidian 两次。这里有个细节值得单独说不要完全信任导出工具给出的时间戳排序。时间戳可以被修改或者因为系统时区问题出现微小偏移但消息里的seq序号在主库里是严格递增的。微信流的排序键一律用seqts只作为展示字段。2.4 双导出器机制一份数据两个出口管道设计的最后一块是“双导出器”。微信流把消费端做成了两个独立模块Codex exporter把原始 JSONL 渲染成 Codex 项目可以直接引用的 Markdown 上下文文件。Obsidian exporter把消息按日/按群聚合写入 Obsidian vault 的指定目录同时自动生成 frontmatter、双链和标签。两个 exporter 互不依赖配置上可以独立开关。我现在的习惯是 Obsidian 出口常开Codex 出口只在需要把聊天记录当上下文喂 Agent 的时候才开避免项目目录里堆太多用不上的文件。为什么非要设计成插件式而不是一步到位因为两个消费端对数据的组织方式差异太大了。Codex 要的是“按主题打包的决策摘要”Obsidian 要的是“按时间线展开的完整消息”。如果共用同一个导出逻辑必然有一方被拖累。3. 部署实操半小时让聊天记录流进 Codex 和 Obsidian3.1 环境准备这套方案对环境的要求不高我用的是一台 2020 年的 Intel MacBook Pro16GB 内存跑全量同步时 CPU 占用大概在 30% 左右不影响日常开发。你需要准备的是Python 3.11 或更高版本GitCodex CLI已经能正常用一个 Obsidian vault目录无所谓但建议先建好微信 PC 客户端用于导出本地数据库依赖安装没什么特别老流程git clone https://github.com/your-fork/wechat-flow.git cd wechat-flow python3.11 -m venv .venv source .venv/bin/activate pip install -r requirements.txt3.2 第一步解密导出为 JSONL这里需要先借助上面提到的开源工具完成解密。我的推荐路线是先把微信 PC 端的数据目录导成明文数据库再用微信流脚本转成 JSONL。具体导出的命令取决于你用的解密工具但核心产出是一份统一格式的原始数据文件python main.py export --db ~/Library/Containers/com.tencent.xinWeChat/.../msg.db --output raw/output.jsonl为什么先落成 JSONL 而不是让管道直接连数据库因为我不建议让这个常驻管道和生产环境的微信客户端抢数据库文件。文件锁、误删、写坏这些都是实际风险。先导出成独立文件后续怎么折腾都不会影响到原数据。3.3 第二步修改 config.yaml微信流的配置集中在一个config.yaml里。下面是我目前实际在用的配置经过了两个月调优可以直接参考source: jsonl_path: ./raw/output.jsonl state_dir: ./state filters: rooms: - 车库咖啡技术群 - 项目A作战群 senders: - 老板 skip_rooms_startswith: [闲聊, 水群] exporters: codex: enabled: true output_dir: ./codex-context/wechat format: summary # full or summary summary_days: 7 obsidian: enabled: true vault: /Users/me/Documents/MyVault subfolder: 00-inbox/微信流 frontmatter: true link_by_name: true daily_file: true过滤器这一步非常关键。我一开始把全量聊天记录都灌进了 Obsidian结果一周后文本库增肥了 1.2GB检索体验直线下降。后来加了skip_rooms_startswith把水群全部挡在管道外面体量瞬间降下来剩下这才是真正值得沉淀的内容。3.4 第三步全量同步到增量同步先跑一次全量验证链路是否通畅python main.py run --config config.yaml --once首次全量同步的耗时取决于数据量。我的数据库解密后有 50 多万条消息跑完全量大约用了 40 分钟输出目录占了几百 MB。增量同步就快得多日常跑批基本都是秒级结束。确认全量没问题后再把它变成常驻增量同步python main.py run --config config.yaml验证方式很简单盯住state/cursor.json里的last_seq是否在增长同时观察codex-context/wechat/和 Obsidian vault 里是否持续新增 Markdown 文件。3.5 两个下游目录的接入姿势Codex 这边我在项目根目录里建了一个AGENTS.md把codex-context/wechat/声明为“可以按需引用的外部上下文目录”并在启动 Codex 时直接通过wechat/2025-06-12-summary.md这样引用文件Codex 会把它作为上下文读取。Obsidian 这边更简单把配置里的subfolder直接指向 vault 内路径脚本就会自动写入。我额外装了 Obsidian Git 插件让 vault 每隔一段时间自动 commit 一次这样所有聊天记录都带上了版本历史改错或者误删都能回溯。这里要提醒一句第一次配置 Obsidian Git 时记得确认自动提交是在微信流写入之后才触发避免写入还没落盘就先提交了。优先级配置成“等待 5 分钟再提交”能稳妥很多。4. Codex 侧让聊天记录成为 Agent 的长期上下文4.1 Codex 怎么消费这份聊天上下文Codex 的上下文加载机制是基于文件系统的。启动时它会读取项目里的AGENTS.md作为规则说明同时可以读取你在对话中显式引用的文件。微信流做的事情就是让聊天记录落到这些文件里使得 Agent 能够以极低门槛“看到”真实的讨论过程。我的使用方式是先在 Codex 对话里说明任务然后直接引用微信流生成的摘要文件codex 根据 wechat/2025-06-12-车库咖啡技术群.md 里的讨论要点整理一份需要落地的 TODO如果讨论里已经给出结论直接标出来。这句对话背后Codex 会读取我引用的文件里面的内容已经被微信流处理成了带会话上下文的 Markdown既有每个人的原话摘录也有自动生成的要点总结。4.2 我最常用的三个 Codex 场景场景一把群里聊出来的需求直接落地成代码。群里面经常会有“如果能做个脚本自动抓一下这个接口就好了”这种需求过去只能记在脑子里。现在微信流会把当天讨论同步成文件我随手引用给 Codex它能把需求转成技术方案甚至直接给出可运行的代码骨架。场景二让 Agent 沿用群聊里的技术决策。比如某个群老早之前详细讨论过“为什么这个项目不能用 Redis 做任务队列”我把那段讨论喂给 Codex它就不会在后续代码里引出一个已经被否定的方案这比在需求文档里写一百句注意事项都管用。场景三报错现场复盘。群友贴过的报错日志和对应解法微信流都会结构化写进 Obsidian同时 Codex 出口的摘要里也会带上。之后再遇到同类报错我可以让 Codex 先翻微信流里有没有类似问题的讨论再决定排查路径。4.3 一个真实案例从群聊讨论到代码骨架某天技术群里有人分享了一个想法用 LLM 给本地文档做自动标签。大家从向量化、标签体系、增量更新讨论到索引结构全程大概 40 多分钟信息密度很高。当晚我打开微信流生成的摘要文件看到里面已经按主题拆出了几段内容于是直接引用给 Codexcodex 结合 wechat/2025-06-12-文档自动标签讨论.md帮我设计一个最小可运行的 Tagging Pipeline优先保证增量处理、本地运行、不需要额外服务。Codex 基于聊天里的讨论把架构拆成了三个模块文档加载器、LLM 标签生成器、索引更新器。它给出的骨架在我这里至少有 60 分可用我后来花一个晚上补全了细节。如果没有微信流我需要重新回忆起讨论里的所有约定这个启动成本会高很多。4.4 上下文控制别把 Agent 喂吐给 Codex 喂聊天记录最忌讳“贪多”。全量模式下的一个月聊天记录token 量轻松爆炸Agent 反而抓不住重点。我建议把 exporter 保持在summary模式按天聚合把每个人说的核心观点抽取成要点。一份一天的技术群讨论摘要实测下来基本能控制在两千 token 以内即使是讨论炸了一天的群也很少超过一万 token。这个体量对 Codex 是非常安全的。另外补充一句Codex CLI 本身支持配置为 OpenAI 兼容接口的方式使用第三方模型不管用官方模型还是其他服务商消费微信流的上下文逻辑是一样的管道跟模型选择关系不大。5. Obsidian 侧Markdown 化之后的检索和双链玩法5.1 笔记目录与 frontmatter 设计Obsidian 出口最核心的工作是把聊天记录从“流水账”改造成“可管理的知识对象”。微信流写入每条记录时会自动生成标准的 frontmatter--- title: 2025-06-12-车库咖啡技术群-晚场讨论 type: wechat-flow room: 车库咖啡技术群 date: 2025-06-12 21:30 tags: - 微信流 - 群聊 - RAG --- ## 消息摘录 [[阿伟]]RAG 召回率低的话先看 chunk 粒度 [[林一]]chunk 切成 256 试试overlap 用 16 [[老王]]关键词过滤 向量召回双通道效果会稳很多这个设计最大的价值是“可检索、可聚合”。type: wechat-flow让所有微信流内容可以一键筛选room保留来源tags则根据消息里的技术词自动打标后面查“所有关于 RAG 的讨论”时直接搜标签就能拉出来。5.2 双链、别名、Dataview 检索微信流在导出时会自动维护两个对象人名页面和群聊页面。每条消息都改成[[阿伟]]这样的链接点击名字就能看到这个人在不同群、不同时间里的完整发言脉络。这个维度是微信自带搜索永远给不了你的。配合 Dataview 插件可以做动态查询。下面这个查询会列出所有微信流里提到“RAG”的消息按时间倒序TABLE sender, date FROM 00-inbox/微信流 WHERE contains(msg, RAG) SORT date DESC我把它做成了一个 Obsidian 页面每次想看某个技术话题在群里被讨论的历史直接看这个表就行不用手动翻聊天记录。5.3 把 Obsidian 的 AI 检索也接进来很多人问我在 Obsidian 里怎么接 AI其实思路和微信流天然配合。我是用 Smart Connections 这类支持本地向量索引的插件它会后台读取 vault 里的 Markdown 文件构建本地向量库。之后我可以直接在 Obsidian 里问“这个月群里关于向量库的讨论有哪些结论”它会给出带来源引用回答。这套链路里的关键点是微信流的 Markdown 文件都是有完整 frontmatter 和正文结构向量化质量比直接把一顿聊天记录丢进去要高得多。有人纠结要不要用官方的笔记 AI 预览功能说实话没有太大必要本地向量插件够用。如果要接更强的大模型做问答Obsidian 里也有支持自定义接口地址和密钥的插件把微信流目录指给它就行。5.4 归档与维护节奏我现在的节奏是微信流常驻跑增量Obsidian 侧每周归档一次。归档的动作很简单把上个月每天的聊天摘要移动到一个archive/文件夹同时在页面最顶部留一行说明链接到对应的原始消息文件。这样日常工作只面对最近一个月的活跃文件查询历史时才去 archive。Obsidian Git 插件做自动版本管理跑批完成后的文件变更会全部提交。我建议对00-inbox/微信流这个子目录做单独一条同步策略避免和手工编辑笔记的提交混在一起冲突会少很多。6. 踩坑记录乱序、重复、接口报错与性能问题6.1 解密导出环节拿不到 key、数据库被占用第一次跑解密导出时我遇到了典型的“拿不到密钥”问题。导出工具提示找不到加密 key。排查过程是这样的先确认微信客户端是否在运行结果它正在后台挂着。微信的数据库被进程锁住内存里的密钥读取也不稳定。我关闭微信后再试问题解决了大半。随后又遇到一个权限问题在 macOS 上微信的数据目录在容器目录里终端默认没有访问权限需要在系统设置里给终端授予完全的磁盘访问权限。这两步完成后导出才正常。给后来人的建议先关微信再授权终端磁盘访问最后再考虑更复杂的备份路线。如果还是拿不到密钥可以在微信设置里做一次“备份与恢复”把聊天记录备份文件导出再针对备份文件解包这条路更稳。6.2 消息乱序问题Obsidian 里时间线出现跳动的当晚我怀疑是导出时排序出了问题。把原始 JSONL 拉出来一查发现导出工具输出的消息按消息 ID 的字符串顺序排的而字符串字典序不等于时间序。例如“1002”会排在“999”前面整个时间线全乱了。排查到最后解决方式就是前面提到的统一按seq序号排序时间戳只做展示字段。这个改动是一次性的但直接影响 Obsidian 时间线的正确性。以后你如果遇到“时间线乱跳”优先检查自己是不是用了 ID 字典序或者纯时间戳排序。6.3 消息重复消费大约运行到第二周我发现 Obsidian Git 提交记录里出现了很多重复的消息条目。现象是同一段内容被 append 了好几次每个文件的体积都在悄悄膨胀。排查链路是这样的先看state/cursor.json发现游标没有更新给状态文件目录加了写权限后问题消失。但几天后问题复发这次原因是定时任务和手动执行用到了不同的 Unix 用户用户 A 写的游标用户 B 不认。统一 cron 任务的运行用户后重复消费彻底解决。这个坑很小但很隐蔽。如果你在系统里用 root 跑同步自己还用普通用户验证很容易踩到同样的问题。6.4 Codex 接口报错的排查记录运行一段时间后Codex 侧出过一次接口报错。日志里提示的是“切换服务商配置后 local 请求转发失败”出错位置在/responses端点。这个报错的典型特征是Codex 已经能启动但一问问题就立刻报连接错误。排查顺序是这样的先检查 Codex CLI 的配置文件确认模型服务商 provider 是否写对。再看当前 shell 环境变量里有没有残留旧的接口地址如果之前改过网关类配置重启 shell 后没有清理会出现路由指向错误。最后检查本机是否有一个旧的本地网络转发服务还在占用端口把新请求的路由串到了错误端口上。我最终是把所有旧接口配置和网络转发服务完全退出然后重启 Codex CLI问题消失。这个报错和微信流本身没有关系但因为它发生在接入 Codex 的同一个工作流里排查时很容易误认为是数据管道出了问题。6.5 磁盘膨胀与性能优化跑了大概一个月我发现输出目录从几百 MB 膨胀到 3GB 多Obsidian vault 的体积也在快速增长。排查发现是 Codex exporter 默认把所有历史摘要文件都保留在输出目录里导致文件越堆越多。优化策略是按天分文件并启用“最近 30 天原始 JSONL、更早的合并成月度摘要”的归档规则。聊天文本的膨胀率本来就不高按天拆分之后每次同步只需要处理当天的增量文件性能开销反而更小。图片、视频、语音这类二进制内容微信流默认不导出只保留它们的元数据这能省掉绝大部分磁盘占用。6.6 Obsidian Git 与手工编辑冲突微信流持续往 vault 写文件我偶尔也会手工编辑同一批 Markdown冲突在 Obsidian Git 自动提交时频繁出现。问题的本质是“两个写者操作同一批文件”。我的解决办法是微信流输出目录统一放在00-inbox/微信流手工编辑后的内容会移动到10-projects或20-archive等其他目录两批文件尽量不交集。即便有交集也遵循“手工编辑优先”的原则微信流第二次写入时如果发现文件已被手工修改就转而创建新文件而不是覆盖。配置里加一个conflict_policy: create_new即可。7. 隐私边界不是所有聊天内容都该进流7.1 只处理自己的数据这条底线不能破很多人看到这种项目第一反应是“能不能用来监控别人的聊天记录”。我的看法非常直接不能而且也不应该。这个工具的正确用法是处理自己账号导出的数据它从体系上就不该被设计成系统性地采集他人的信息。我 fork 之后做的第一件事就是把采集端限制为“只读取本机已导出的 JSONL 文件”不提供任何网络接口或者远程抓取能力。这样别人拿到这个仓库也只能处理自己机器上已有的数据。7.2 输入端过滤器人与内容的最小化隐私问题不只是“谁的数据”还包括“哪些数据值得进流”。微信流在输入端提供了两层过滤器维度上是联系人、群聊和消息类型内容上可以配置敏感词列表。我自己会在 filters 里跳过“闲聊群”“水群”也会把家庭群、工作群明确列进黑名单只保留技术讨论价值最高的几个群。内容层再配合一个敏感词表凡是命中“银行卡、身份证、家庭住址”这类关键词的消息直接不进管道。这样即使某一个群整体有价值其中的个人隐私片段也不会被写入任何文件。7.3 输出侧的隔离加密、不公开、最小化共享即使过滤之后微信流生成的 Markdown 也是包含真实人名和对话内容的。这些文件默认只放在本机不会上传到任何云端。如果你像我一样用了 Obsidian Sync 或者其他同步工具建议对00-inbox/微信流目录做加密处理。最简单的方案是用系统磁盘加密或者把微信流输出单独放到加密卷里。这条要单独强调别把微信流输出目录放进公开 Git 仓库。哪怕你是想给别人展示双链效果也要用一段脱敏后的样例数据做演示而不是真实的聊天记录。我仓库里的示例文件全是捏造的假对话就是这个考虑。7.4 这版代码里被我砍掉的功能开发过程中我写过一段“根据关键词自动聚类并生成关系图谱”的代码看起来确实很酷把所有人按讨论话题聚成网络一目了然。但想想就知道这等于把每个人的社交关系和研究兴趣全量建模了信息密度远超直接读聊天记录非常危险。最终这个图谱功能被砍掉了。类似的还有“全量导出所有联系人消息”的选项。表面上是图方便但容易让使用者失去对数据边界的感知。我的处理是默认只允许选择指定群和联系人任何“全量导出”都需要在配置里显式声明。这不仅是安全考虑也是一个提醒工具帮你整理数据但你不该把所有数据都丢给工具。最后再分享几个实操里的小技巧这套微信流管道跑通之后我最受益的是“低摩擦”群里的技术讨论不再需要刻意记录它会自己变成 Obsidian 里的结构化笔记也会在需要时出现在 Codex 的上下文中。只付出一次部署成本后面每天自动收获。如果你也想上手我的建议是先从小范围开始只选一个技术群、跑一周增量看看生成的数据是不是你真正想要的再逐步放开。别一上来就把十年的聊天记录全量导入 Obsidian那只会得到一堆没法消化的文本。最后分享一个让我效率翻倍的小技巧把常用的 Codex 启动命令写成一个 shell 别名例如wx自动带上当天微信流摘要文件的引用路径。这样每次想基于群聊讨论快速出方案一个词就能完成上下文加载。这个项目未来我打算还会接一个自托管知识库手机上的讨论流转到笔记端和 Agent 端的路径已经通了剩下只是把更多出口接进来而已。