1. 想法从哪里来把聊天记录变成AI可读的个人数据流先说结论我做了一个开源的小工具叫它wechat-stream。它的作用很直接——把微信聊天记录从躺在备份文件里没法用的数据转成可以喂给 Codex 和 Obsidian 的结构化文本流。简单说你聊天记录里的每一条对话都能变成 AI 可以检索、可以引用、可以帮你写周报和追任务的素材。我为什么想做这个东西起因特别朴实。我手机上积累了四五年微信聊天记录里面有大量和技术相关的内容和同事讨论过的架构方案、帮朋友排查过的报错、客户发来的需求描述、还有我在各种群里分享过的代码片段。这些东西放在微信里搜索体验大家懂的想找一个三个月前聊过的方案翻半天翻不到。更别说让 AI 帮我把这些信息用起来——Codex 根本不认识微信聊天记录Obsidian 里也只有一个空的笔记库。所以我就想能不能在中间加一条管道把微信聊天记录导出来清洗成干净的结构化文本然后分发给两个消费端。一端是 Codex让它拥有我聊过什么的上下文另一端是 Obsidian让聊天内容变成可检索、可链接的笔记。这就是微信流这个名字的来历——它不是单个文件而是一条持续流动的数据管道。这个项目适合谁如果你符合下面任意一条我觉得你都能从里面拿到点东西程序员想把微信里散落的技术讨论变成 AI 的参考资料Obsidian 用户想建立个人对话档案库但受不了手动复制粘贴对 MCPModel Context Protocol感兴趣想找一个真实可操作的接入场景纯好奇想看看自己聊天记录的另一种打开方式。文章后面我会把整个方案拆开讲包括管道怎么设计、Codex 和 Obsidian 分别怎么接、我踩过的坑以及一些隐私和性能上的注意点。你不需要懂太深的技术也能跟着做——但如果你会一点 Python基本上就能扩展出适合你自己的版本。2. 整体架构与技术选型一条管道两个消费端我不喜欢把简单的事情搞复杂。整个微信流的设计最核心的就是一条单向管道微信备份 → 解析清洗 → 结构化输出 → 消费端。所有数据都落成本地文件不经过任何云端中转。这样有几个好处一是隐私可控数据不出自己机器二是调试方便中间任何一环出问题你直接看文件就知道哪里断了三是零依赖不需要跑一堆微服务就能用。2.1 管道拓扑从聊天记录到 Markdown 文件整个管道我简化成四个步骤导出从微信客户端导出聊天记录备份得到原始数据通常是加密的备份文件或本地数据库。解析用 Python 脚本从备份中提取会话列表、消息内容、发送人、时间戳、消息类型等字段转成 JSON。清洗与格式化过滤掉无意义的消息表情包、撤回提示、系统通知按会话和时间排序渲染成干净的 Markdown 或 JSON Lines。分发一个叫stream的输出目录同时面向两个消费端——Codex 的 MCP server 读它Obsidian 的 vault 也指向它所在或关联的目录。用文件系统作为中间介质很关键。为什么不用数据库因为 Obsidian 本身就是以文件为核心而 Codex 通过 MCP 读文件也最简单。文件系统是最通用的接口任何工具都认得它。我用 JSONL 保留全量结构化数据用 Markdown 生成人类可读的对话记录。两种格式两个用途。2.2 格式选择的考量Markdown 给 ObsidianJSONL 给 Codex先说 Markdown。Obsidian 是一个本地 Markdown 库它的一等公民就是.md文件。我把每个会话生成一个 Markdown 文件格式大致是# 会话产品团队讨论 2025-01-12 ## meta - 成员张三 / 李四 / 王五 - 时间范围14:03 - 15:47 ## 消息记录 - **14:03 张三**新版本导出报错提示“索引越界”有人遇到吗 - **14:05 李四**我昨天遇到过是旧的 xlsx 模板多了一列。 - **14:06 张三**好我改一下模板试试。这样 Obsidian 能直接读取、搜索、双向链接配合 Dataview 插件还能按人、按日期、按关键词做聚合查询。我在 Obsidian 里给每条消息加了[[人名]]的双链点一下就能看到这个人的所有发言特别好用。JSONL 则是给 Codex 的。每一行是一条完整消息包含speaker、text、timestamp、session等字段。Codex 通过 MCP 工具按时间范围、按会话、按关键词去查询返回干净的文本片段。为什么不用 JSON 而用 JSONL因为微信聊天记录天然是追加式的用 JSONL 可以直接 append 增量数据不用每次重写整个文件。2.3 关键设计增量同步与去重聊天记录是持续增长的所以管道必须支持增量。我的方案是维护一个cursor文件里面记录上一次处理到的最新时间戳。每次运行管道只解析这个时间点之后的新消息。处理完更新 cursor。去重问题也踩过坑。微信备份在多次导出后会有重复记录单纯按时间戳去重不靠谱——同一条消息可能因为网络问题在备份里出现两次。我的做法是对会话ID 发送人 时间戳 消息文本前50个字符做哈希用这个哈希作为唯一键写进一个本地的 SQLite 库。后续增量时先查哈希命中就跳过。这一步虽小但能省非常多下游去重的麻烦。3. 核心细节解析与实操要点解析、清洗、渲染一条龙这一部分是整个项目最脏最累的活。微信聊天记录的原始数据远远不是一段文字那么简单。它有文本、图片、语音、转账、小程序卡片、视频号分享、文件、位置、引用回复……如果全量保留管道会变得无比复杂。我的经验是先做减法只保留纯文本和文件路径引用其它一律过滤或降级成占位标记。3.1 消息类型怎么处理我把消息类型分成几档类型处理方式文本消息全文保留作为核心内容图片/视频/文件保留文件名与路径生成[图片: xxx.jpg]占位语音消息生成[语音: 45秒]占位如需转写再接 ASR 模型转账/红包生成[转账: 200元]这种简略占位小程序卡片保留卡片标题和链接系统消息撤回、进群、拍一拍默认过滤可配置保留这是一个很实际的经验不要把流程做到完美那是无底洞。图片语音确实有信息量但对 Codex 来说它没法直接看图片对 Obsidian 来说图片只是附件。一开始就聚焦在文本和结构上等稳定了再去扩展。3.2 数据清洗的细节原始消息里有很多噪声清洗规则要反复调试。我总结了几条高频规则合并系统消息的剔除比如你已添加了XX现在可以开始聊天了过滤纯表情包消息这类消息虽然没有文本内容但数量巨大会污染检索结果处理换行和 Markdown 冲突。微信消息里的换行符在 Markdown 渲染里会被忽略我给每个消息加上空行间隔如果消息里本身有#、|、这类 Markdown 特殊字符要转义或保留原样避免破坏 Obsidian 渲染。中文编码问题。导出的数据经常碰到\u0000或乱码我在解析层统一用 UTF-8 重新编码并在读取时加了errorsignore兜底。我还额外做了一个技术关键词预标记的功能如果消息中包含代码片段、报错信息、技术名词JVM、React、Python、报错异常等就给这条消息打上#tech标签在 Obsidian 里能一键筛选出所有技术讨论。这个不算复杂就是一个关键词表 标记写入但实用性非常高。3.3 渲染成 Markdown 时的模板策略同一份聊天记录要喂给 Codex 和 Obsidian渲染策略要稍微区分。给 Obsidian 的版本比较重要带上双链、tag、meta 信息给 Codex 的版本比较轻就是干净的时间戳 说话人 文本别加花活因为 Codex 读取时是按 token 计费的Markdown 装饰越少越好。我用同一个中间 JSONL渲染时套两套模板互不影响。我用的模板大致是这两类。Obsidian 版--- author: 张三 session: 产品沟通 date: 2025-01-12 tags: [tech, 产品讨论] --- [!info] 会话上下文 本文档由 wechat-stream 自动生成。 **张三** 在 14:03 说新版本导出报错...Codex 版则只在 MCP server 里做文本裁剪不生成独立文件直接按查询返回文本片段。这里有一个关键心得不要把所有聊天记录一次性塞给 Codex。上下文窗口有限性价比极低。正确做法是让 Codex 在你需要的时候主动查询只取相关片段。4. 实操过程把微信流接入 Codex接入 Codex 是我觉得最有意思的部分。Codex 本身是 OpenAI 的编程智能体你让它写代码、改 bug、读仓库都很强但它默认并不了解你聊天记录里的上下文。我的目标是让 Codex 能回答我和小李上次讨论的那个登录报错是什么帮我根据这个月的聊天记录生成周报以及从聊天记录里找出所有涉及数据库迁移的方案讨论。4.1 用 MCP 把微信流暴露给 CodexCodex 支持 MCPModel Context Protocol意思是可以给 Codex 挂外部工具。我写了一个很小的 MCP server暴露了三个工具search_messages(keyword, date_from, date_to)按关键词和时间范围搜索聊天记录get_session_summary(session_id)返回某个会话的摘要list_authors()列出聊天中出现过的人方便 Codex 确认对象。实现上我用 Python 的fastmcp库代码并不复杂。核心就是把之前生成的 JSONL 文件读进来按照查询条件做过滤。代码骨架大概是这样from fastmcp import FastMCP import json, os mcp FastMCP(wechat-stream) DATA_DIR os.environ.get(WECHAT_STREAM_DIR, ~/.wechat_stream) JSONL_PATH os.path.expanduser(f{DATA_DIR}/messages.jsonl) def load_messages(): with open(JSONL_PATH, r, encodingutf-8) as f: return [json.loads(line) for line in f if line.strip()] mcp.tool def search_messages(keyword: str, date_from: str , date_to: str ) - str: messages load_messages() results [] for m in messages: if keyword and keyword not in m.get(text, ): continue if date_from and m.get(timestamp, ) date_from: continue if date_to and m.get(timestamp, ) date_to: continue results.append(f{m[timestamp]} {m[speaker]}: {m[text]}) return \n.join(results[:50]) mcp.tool def get_session_summary(session_id: str) - str: messages [m for m in load_messages() if m.get(session) session_id] return \n.join(f{m[timestamp]} {m[speaker]}: {m[text]} for m in messages[:100]) if __name__ __main__: mcp.run()有了这个 server你在 Codex 里就能直接说帮我搜一下和小李讨论登录报错的消息Codex 会调用search_messages拿到结果后再做判断和回答。实测下来这种按需查询的效率极高比把整份聊天记录写进提示词里靠谱一个数量级。4.2 提示词与使用场景MCP 接好只是第一步怎么用才是核心。我实践了三个场景效果都还不错第一个是聊天记录问答。我在 Codex 里问我之前和张三讨论过用 n8n 搭建消息自动发布流他当时推荐了什么方案 Codex 会检索微信流找到相关对话然后概括出当时讨论的要点。这比我自己在微信里翻聊天记录快太多了。第二个是自动生成周报。月底的时候我给 Codex 的提示词是检索这个月所有包含任务完成上线关键词的消息按主题整理成周报草稿。它会先调用搜索工具然后把结果按项目归类。虽然生成的草稿还需要我润色但至少省了从头写的时间。第三个是需求整理。客户在微信里发的需求往往很零散我让 Codex 从聊天记录里提取需求点整理成一份条目化的需求清单存档到 Obsidian。注意提示词里一定要强调只根据聊天记录内容提取不要猜测和补充不然 AI 容易给你编需求。4.3 Codex 配置上的两个细节一是环境变量。MCP server 需要从WECHAT_STREAM_DIR读取数据目录配置 Codex 时要把这个变量也传过去。二是连接方式。我用的 stdio 模式本地进程通信没有用远程 HTTP。本地跑的好处是简单、不占网络、数据不出机器。Codex 配置 MCP server 的地方在它的~/.codex/config.toml加一个[mcp_servers.wechat_stream]配置块指定启动命令就行。具体字段名不同版本略有差异你自己敲的时候留意一下 command 和 args 的写法。5. 实操过程把微信流接入 ObsidianObsidian 那头相对简单——本质上是把聊天记录变成一堆 Markdown 文件。但我还是要说一下直接一股脑生成几百个.md文件丢进 vault 是不行的会把你笔记库的搜索体验搞崩溃。你需要一个合适的目录结构和模板策略。5.1 目录结构与双链设计我建议把微信流内容放到 Obsidian vault 下的一个独立目录比如04-archive/wechat-stream/不要和平时的笔记混在一起。目录内部再按年/月/会话名组织例如04-archive/ └── wechat-stream/ ├── 2025/ │ ├── 01/ │ │ ├── 产品团队讨论.md │ │ ├── 技术架构讨论.md │ │ └── 日常闲聊.md │ └── 02/ └── meta/ ├── members.md └── sessions.mdmembers.md是自动生成的人名词典每个出现过的人做一个[[人名]]的锚点。渲染时我在每条消息里把说话人包成双链这样在 Obsidian 里点任意一个人名就能跳到该人的字典页再从字典页的反向链接里看到这个人的所有发言。这是我用了之后感觉最爽的一个功能。5.2 Dataview 聚合查询有了结构Obsidian 的 Dataview 插件才能发挥威力。我写了一些查询比如查看这个月所有技术讨论TABLE date, file.name AS 会话 FROM 04-archive/wechat-stream WHERE contains(tags, tech) SORT date DESC LIMIT 50说实话Dataview 的语法不难难得是你得先在 Markdown 的 frontmatter 里写清楚tags和date——这也是为什么我在渲染模板里坚持要带 meta 信息。数据干净了查询就是水到渠成的事。5.3 增量同步与 Obsidian 的配合Obsidian 会自动监听 vault 文件变化所以增量同步很顺滑管道每次跑完新文件写进目录Obsidian 自动刷新。唯一要注意的是命名冲突。同一个会话如果跨天我用了会话名 日期作为文件名避免覆盖。另外如果聊天记录特别多Obsidian 首次索引会比较吃力我建议在 vault 设置里把wechat-stream目录加入排除列表等需要看的时候再手动纳入索引。这是个小技巧能明显缓解大 vault 的卡顿。6. 常见问题与排查技巧实录做这个项目踩的坑不少我挑几个最有代表性的写出来希望能帮你省点时间。6.1 聊天记录导出后是加密的怎么解析微信的备份文件不是明文直接读会是一堆乱码。这里我不展开逆向过程只给一个方向你能用到的几条正常路径是——微信电脑版的备份功能、手机本地备份恢复、以及一些开源社区维护的解析库。解析库的原理大同小异本质上是从备份的数据库中恢复出 SQLite 表再按表结构提取消息。如果你遇到读出来的文本是乱码大概率是加密 key 没有正确配置或者数据库被备份软件升级过格式。我的建议是先用一个小型备份文件做测试跑通了再处理全量数据。6.2 增量同步偶发重复数据翻倍后来排查发现微信在部分场景下会对同一会话生成不同 ID导致我的会话级去重失效。我把唯一键从会话ID时间戳文本升级成会话ID消息哈希消息哈希用sha256(timestamp speaker text[:50])。改了之后重复率降到几乎为零。另外处理全量数据前先跑一次find . -name *.md | wc -l统计文件数量方便和预期比对。6.3 Codex 查询不到内容最常见的原因是 MCP server 里的路径不对。系统提示找不到消息文件时先在命令行手动跑一下 server用 curl 或直接调函数验证能不能读到数据再回头检查 Codex 配置里的环境变量。还有一个坑是 Codex 的上下文截断——如果聊天会话太长返回给 Codex 的结果会被截断所以我的search_messages里限制了返回条数results[:50]宁可让它多查两次也不能让它读一半以为全读完了。6.4 Obsidian 里中文链接失效Obsidian 默认对[[中文人名]]是支持的但如果人名里包含空格或特殊符号链接可能失效。我在渲染阶段做了统一处理把说话人里的空格替换成下划线并且把members.md中的标题也用同样的规则保证双链能对上。这属于不遇到永远不会知道的坑写下来提醒一声。6.5 隐私与合规必须单独说这个项目处理的是你自己的聊天数据安全底线一定要守住。我自己定的几条铁律分享给你参考所有数据只存本地不传到任何云端服务生成的 JSONL 和 Markdown 文件不提交到公开的 Git 仓库如果让 Codex 分析聊天记录先确认它运行的网络环境是你自己的并且不会有第三方同步不要拿别人的聊天记录跑这个管道哪怕是同事、朋友主动给的也要谨慎。7. 我在这个项目里的个人体会如果你问这个微信流项目最值钱的部分是哪一块我的答案是它让我重新理解了信息管道的重要性。聊天记录一直在那里它不是没有价值而是因为没有流动起来。一旦你把它变成可检索、可引用、可聚合的数据流原本埋没在时间线里的信息就开始产生复利——技术讨论成了知识库客户需求成了任务清单闲聊里冒出来的灵感成了 Obsidian 里的闪念笔记。踩过几次坑之后我最大的体会是做这类工具别一上来就追全量完美。先让管道跑起来把文本消息处理好就已经解决了 80% 的问题。图片、语音、视频这些富媒体等核心稳定了再逐步扩展。增量同步和去重也最好在最开始就纳入设计否则后面数据量大了返工成本会非常高。最后再分享一个小技巧。我在管道里加了一个每日新增摘要的环节——每天自动统计当天聊天里的高频关键词和活跃联系人生成一小段摘要写入 Obsidian 的 Daily Note。隔一个月回看你会发现那些细碎的聊天记录居然能串出一条清晰的工作和个人成长轨迹。这个体验单靠微信自带的搜索是永远给不了你的。