微信里的聊天记录在过去一直是个“信息孤岛”消息发完就躺在手机里想找一条老记录要翻半天更别说把它喂给 AI 用了。但最近开源社区里开始流行一个叫“微信流”的玩法——把自己的微信聊天记录导出来结构化整理成 Markdown然后直接丢给 Codex 当上下文或者让 Obsidian 做知识库管理。我大概是两周前开始折腾这套流程踩了不少坑也真正把它跑通到了日常使用里。这篇就把我的完整实操过程、方案选型、排查经验都写出来希望能帮你少走弯路。先说清楚这东西解决了什么问题Codex 虽然能读文件、能写代码但它对你的“历史信息”一无所知而 Obsidian 则是本地 Markdown 仓库数据喂进去就永远属于你。把微信聊天记录变成一条可持续更新的“流”本质上是在给 AI 补上“你最近和谁聊了什么”这块记忆拼图。这篇文章适合三类人想给 Codex 喂真实语料的开发者、正在折腾 Obsidian 知识库的朋友以及单纯想把微信记录变成自己数据资产的普通用户。1. 微信流到底是个什么东西1.1 先讲我遇到的痛点我的微信里大概存了五六年工作聊天记录里面全是技术讨论、方案确认、客户反馈。以前我需要做月度复盘时只能回手机里一条条截图、翻聊天记录效率极低。我也试过把聊天记录导出成文本但导出来的东西格式混乱时间线、发言人都混在一起AI 根本没法用。后来我在开源社区看到一个思路把微信当作一个“信息源”像 RSS 一样持续读取、清洗、归档最后生成结构化的 Markdown 文件。这个思路被打包成工具之后就是大家说的“微信流”。它不是一个独立的聊天软件也不是什么云端服务本质是一套本地运行的数据管线。1.2 链路是怎么组成的微信流的核心链路可以拆成四段导出、解析、清洗、投喂。导出阶段解决“数据怎么从微信里弄出来”的问题。目前最稳妥的方式是走微信官方提供的备份与迁移机制把你手机里的聊天记录备份到电脑生成一份可以解析的本地数据。这里要注意聊天记录属于你的个人数据但微信客户端本身没有提供“一键导出全部文字”的功能所以必须借助备份路径。解析阶段解决“备份内容怎么变成可读文本”的问题。很多开源项目做的事情就是从备份数据里提取出联系人、时间、消息类型、内容然后整理成 CSV 或者 JSON。这个环节是整个流程里技术含量最高的地方也是最容易出幺蛾子的环节。清洗阶段是把解析出来的原始数据做标准化去除系统通知、合并连续消息、给发言人和时间补全格式、把语音消息标记为TODO、过滤掉群聊里的 提醒。这一步直接决定后面 AI 读起来顺不顺。投喂阶段是最后一步把清洗好的 Markdown 文件通过文件路径、目录扫描或外部工具交给 Codex或者复制到 Obsidian 的仓库里让它自动索引。1.3 为什么这两个工具是绝配Codex 是我用了很长时间的 AI 编程工具它的核心优势是能理解你指定目录里的文件然后基于这些内容写代码、改代码、回答问题。它非常适合充当“消费端”因为聊天记录里往往藏着需求变更、Bug 描述、用户反馈这些都能直接转化成编码任务的上下文。Obsidian 则是“沉淀端”。它不依赖任何云端账号所有笔记都是本地 Markdown 文件天然适合存隐私数据。把聊天记录按照日期、联系人、项目三个维度拆成多个文件然后用双链和标签串起来Obsidian 就能变成一个可以按时间回溯、按人物搜索的“微信档案库”。我实际用下来这两个工具一个管“现在干活”一个管“以后查找”配合起来非常顺手。2. 动手前的准备数据、工具与安全边界2.1 聊天记录从哪里来先搞清合规路径很多朋友一上来就想找那种“直接读微信数据库”的 Python 库我劝你先冷静。微信电脑版的本地数据库是加密的直接读取涉及逆向和绕过机制既可能违反用户协议也可能踩到法律红线。我推荐的路径是先通过手机微信里的“聊天记录备份与迁移”功能把聊天记录备份到电脑或者用手机系统自带的整机备份把微信的沙盒数据一并备份出来。这个动作是官方支持的后面再用开源工具做解析属于“你处理自己的数据”。我实测下来备份到电脑的数据是完整的包含文字、图片缩略图、语音文件索引只是格式不通用。开源工具做的事情就是在你拥有这份备份的前提下把里面的内容翻译成通用格式。这一点想清楚之后后面所有操作都不慌。2.2 开源工具怎么选目前社区里的工具大致分成三类解析型、展示型、转换型。解析型工具专注于从备份里提取结构化数据通常会输出 SQLite 或 CSV展示型工具会自带 Web 界面方便你直接浏览聊天记录转换型工具能直接把解析结果变成 Markdown、HTML、PDF。我的建议是先把工具跑起来但不要一上来就用“全家桶”。我自己先选了源代码量小、依赖少的一个只做解析的工具输出 CSV 和 JSON后面所有转换逻辑都用自己写的脚本控制。这样做的原因是聊天记录格式千差万别很多开源工具内置的“一键导出 Markdown”模板太死板无法满足我按联系人分组、按项目打标签的需求。选工具的检查清单也很简单看仓库最近有没有更新、看 issue 里有没有人反馈“解析失败”、看它是否支持增量解析否则你可能要全量重新解析很慢、看输出字段是否完整至少要有时间、方向、类型、内容、联系人。2.3 安全与隐私的红线这是我最想强调的部分。微信流处理的是高度敏感的数据你必须从一开始就划定安全边界。第一条红线是“只处理自己的数据”。千万不要拿别人发给你的备份文件来试工具哪怕对方说是测试数据。聊天记录里包含大量第三方个人信息擅自处理可能构成侵权。第二条红线是“本地优先离线优先”。所有解析脚本、中间结果、最终 Markdown 都只保存在你自己的电脑上不要上传到任何云端网盘也不要放在代码托管仓库里。我在本地建了一个专门目录权限设置成仅当前用户可读。第三条红线是“做好脱敏再分享”。如果你要写博客、做演示必须把联系人昵称、手机号、群聊名称全部替换成无意义代号。我见过有人把真实聊天记录做成公开示例库这非常危险。安全策略总结下来就是一句话微信聊天记录是比代码更敏感的资产宁可不做也不要图方便滥用数据。3. 核心实操把聊天记录变成 Codex 的上下文3.1 先理解 Codex 的读取方式Codex 并不直接“连接”微信它只负责读取你指定的文件。这意味着聊天记录必须以文件的形式存在于本地而且最好是 Markdown 文本。Codex 命令行工具有一个 exec 模式可以直接在终端里执行任务比如codex exec --help可以查看可用命令。我会把聊天记录目录直接放在工作目录下然后用相对路径去引用。有个细节Codex 每次执行时会读取文件内容到上下文窗口窗口大小是有限的所以你不能把一整年的聊天记录塞进一个文件。我的做法是按月拆分每个文件控制在 30KB 以内。如果某个群聊特别活跃就按周拆分。这样既方便 Codex 读取也方便 Obsidian 管理。3.2 清洗与排版让 AI 看得懂原始解析出来的聊天记录是有很多噪音的。系统消息、撤回提示、小程序卡片、表情包链接这些对 AI 毫无价值。我在清洗脚本里做了三件事第一过滤。把所有非“文本消息”且不包含有效内容的记录删掉比如“你撤回了一条消息”“XXX分享了小程序”这些直接不入流。第二标准化。把用户昵称替换成简称避免同一人在不同对话里出现多个昵称导致 AI 混乱。时间格式统一成YYYY-MM-DD HH:mm时区问题也一并处理掉。第三加头信息。每个生成的文件开头都会有 YAML frontmatter记录这个文件对应的联系人、群聊、时间范围、消息条数。这个头信息后面给 Codex 和 Obsidian 用都非常关键。下面是清洗脚本生成 Markdown 的核心逻辑不复杂但很实用import csv from pathlib import Path def build_markdown(records, contact): lines [] lines.append(---) lines.append(fcontact: {contact}) lines.append(fstart: {records[0][time]}) lines.append(fend: {records[-1][time]}) lines.append(fcount: {len(records)}) lines.append(---) lines.append() for r in records: direction 我 if r[is_sender] else r[sender] content r[content].replace(\n, \n ) lines.append(f### {r[time]} {direction}) lines.append(f {content}) lines.append() return \n.join(lines) records read_csv(chat_records.csv) md build_markdown(records, 产品讨论群) Path(stream/2025-05-产品讨论.md).write_text(md, encodingutf-8)3.3 三种喂给 Codex 的方式我实测下来给 Codex 喂聊天记录有三种场景分别对应不同的做法。第一种是临时询问比如“根据这月聊天记录梳理产品需求优先级”。直接用codex exec加上文件路径就能搞定codex exec -- 读取 stream/2025-05-产品讨论.md列出所有被提到2次以上的需求并按紧急程度排序第二种是会话内持续引用适合需要多轮对话的场景。把聊天记录目录放到 Codex 工作目录下然后在提示词里说明“你可以在 stream/ 目录下查找任何历史聊天记录”。这样 Codex 会在需要时自己去检索省得把内容全塞进提示词。第三种是把聊天记录写成 Codex 的 AGENTS.md 或项目记忆文件让它变成一个长期背景。这种方式适合你每天都要用 Codex 处理同一个项目的情况。我会把最近三天的高价值聊天内容摘要写进AGENTS.md的“最新动态”一节等于手动给它做了一次记忆更新。三种方式没有优劣之分区别在于你希望聊天记录扮演“一次性上下文”还是“长期记忆”。建议先从第一种开始跑通之后再逐步升级。3.4 一个真实小案例聊天记录自动生成周报我每个周五下午都会做一件事让 Codex 读本周群聊记录自动生成一份周报初稿。这里的 Prompt 我调了很久最后稳定在用这个模板你是我的项目助理。请阅读 stream/2025-05-产品讨论.md完成以下任务 1. 列出本周讨论最多的三个主题 2. 每个主题下提取关键结论和待办事项 3. 识别出需要我在下周跟进的人或事项 输出格式Markdown 列表待办事项用 - [ ] 开头Codex 给出的结果基本能直接粘贴进周报文档。偶尔会有张冠李戴的问题比如把 A 群的观点说成 B 群的观点但因为我给每个文件都加了 frontmatterCodex 能准确区分来源。生成完之后我会把周报存入 Obsidian然后原聊天记录文件继续保留。这套流程跑了一个月每周省下至少一小时整理时间。4. 核心实操同步到 Obsidian 知识库4.1 Obsidian 里的目录规划Obsidian 本身也是个“文件读取器”它扫描仓库里的 Markdown 文件建立索引。所以同步的本质就是把生成的 Markdown 文件放进仓库目录并保证命名规范。我的目录规划是这样的wechat/ 00_inbox/ # 待处理的新聊天记录 10_contacts/ # 按联系人归档的完整记录 20_projects/ # 按项目主题合并的跨人对话 90_templates/ # 导入模板00_inbox 用来接收新同步进来的文件我每天看一眼把重要的内容打上标签再移动到对应分类。10_contacts 目录下每个联系人或群聊一个子目录文件名是YYYY-MM-联系人.md。20_projects 目录下则是把多个联系人里同一个项目的聊天合并成一个文件方便做项目复盘时一起看。这个分层的好处是既保留原始时间线又允许你按业务维度重组。在 Obsidian 里你不需要复制文件用双链引用就能同时出现在两个地方。4.2 模板与元数据设计为了让 Obsidian 的 Dataview、Templater 插件能自动处理我必须在每个 Markdown 文件里塞足够规范的元数据。我的模板是这样的--- type: wechat-chat contact: 产品讨论群 contact_type: group start: 2025-05-01 09:00 end: 2025-05-31 18:00 count: 356 tags: [工作, 产品] --- # 产品讨论群 2025年5月 ## 群聊摘要 - 讨论话题登录流程改版、消息推送优化、数据看板需求 - 关键人物李工 王强 ## 聊天记录 !-- 下面是按时间排序的原始记录 --有了这些字段我可以在 Obsidian 里写一个 Dataview 查询比如列出某个项目的所有聊天记录文件TABLE contact, start, end FROM wechat/20_projects WHERE project 消息推送优化 SORT start DESC实际使用经验是不要把原始聊天记录的全文直接当作笔记正文否则 Obsidian 搜索时全是一堆碎碎念反而干扰。我建议正文只保留“清洗后的时间线”然后在文件顶部人工维护一个“重要信息”区块记录本周最有价值的三个结论。这部分我从下半年开始一直在用效果比单纯堆聊天记录好太多。4.3 增量同步脚本同步最怕的是重复昨天导入过一遍今天再导入又把全部记录塞了一遍。我的解决办法是给每条聊天记录计算一个稳定的 hash以contact time type content作为输入。每次同步时先读取目标目录里已有文件的 hash 集合只处理新增的部分。脚本逻辑大致是这样的import hashlib import pickle def record_hash(r): raw f{r[contact]}|{r[time]}|{r[type]}|{r[content]} return hashlib.sha256(raw.encode(utf-8)).hexdigest() seen load_existing_hashes(stream/.hashes.pkl) new_records [] for r in all_records: h record_hash(r) if h not in seen: seen.add(h) new_records.append(r) save_hashes(stream/.hashes.pkl, seen)这个脚本的好处是可以断点续跑。你把整个流程挂在 cron 或系统定时任务里每 10 分钟跑一次解析和同步就能做到接近实时的“微信流”效果。我平时开着电脑就让它跑新消息大概在 1 到 2 分钟内出现在 Obsidian 里。需要注意增量同步必须保证源数据顺序稳定否则一条记录的错误拼接会导致 hash 变化进而重复导入。所以我固定使用 UTC 时间戳不依赖消息在 CSV 里的自然顺序。5. 常见问题与排查技巧5.1 解析出来的记录缺字或乱码微信聊天记录里的表情、图片链接、语音消息经常会导致解析结果残缺。我遇到最多的情况是表情解析成类似[表情]的占位符有时候占位符内部还包含换行直接破坏 Markdown 结构。解决办法是在清洗阶段统一用正则把[.*?]替换成空字符串或者如果表情有特殊含义就换成[表情]三个字原样保留。另一个乱码来源是编码问题。解析出的 CSV 有可能是 UTF-8 带 BOM也可能不带。如果直接读会导致开头出现\ufeff。我的经验是先检测文件字节流统一转成 UTF-8 无 BOM 再处理。图片和语音消息我的处理方式更粗暴不保留链接引用只保留类型标记。比如[图片][语音]这样 Markdown 不会被长链接撑爆。如果你需要查原图可以直接去备份工具里按时间和联系人找。5.2 Codex 一次性读太多被截断我给 Codex 投喂聊天记录时踩过一次大坑把一个月的群聊记录 200KB 全塞进去结果 Codex 只回复“我只能读取前一部分”。后来我总结出几个控制文件大小的技巧单文件控制在 30KB 以内一般够放一周的量。高价值对话单独提取比如老板的重点批示、客户确认的每一条需求单独放一个stream/important.md。提示词里明确告诉 Codex“只需要读取最晚的三条关键消息”它就会先去文件里查找而不是全盘扫描。Codex 上下文窗口再大也有上限真正好的用法是提前筛选而不是指望模型在海量闲聊里捞针。5.3 Obsidian 双链失效和 Dataview 不显示Obsidian 会自动索引仓库里的文件双链应该不会失效。如果发现[[联系人]]链接打不开多半是文件名里有特殊字符比如空格、中文标点。我在处理昵称时会把空格换成下划线把-保留这样链接就稳定了。Dataview 不显示通常是因为 frontmatter 格式错误。最常见的是日期字段没有用YYYY-MM-DD HH:mm这种合法时间格式或者字段值里带了冒号但没加引号。如果你写完 frontmatter 后页面是空白先用 Obsidian 的“阅读视图”看有没有报错十有八九是字段值里的冒号导致的 YAML 解析错误。5.4 增量同步脚本重复导入重复导入的最大嫌疑是 hash 算法里用到了不稳定的字段。比如我一开始把消息的seq序号也参与 hash结果每次解析序号都变导致一条记录出现好几个副本。后来我干脆不依赖序号只用contact time type content。另一个坑是时区早上 8 点发的消息解析时可能因为时区设置变成前一天晚上hash 就会跟着变。解决办法是统一在解析时把时间转成 UTC 字符串再参与 hash。如果已经出现了重复文件我写了一个清理脚本它读取每个文件的 frontmatter 里的start和count把完全重复的记录在正文中去重。但最好还是从源头控制把 hash 逻辑修好之后以后再也不会重复。6. 我的个人经验与扩展思路6.1 我用微信流做了什么这套流程跑通之后我最大的变化不是“技术上有多炫”而是复盘变得极其轻松。以前季度复盘要翻几百条聊天记录现在只要在 Obsidian 里打开对应项目的笔记看摘要就行。Codex 也会根据这些记录帮我写下一周的待办它连我说过的“这个功能别拖了”这种话都能识别成优先级信号很有意思。还有一个意外收获我发现把聊天记录放进 Obsidian 之后很多“以为记得但实际忘了”的承诺都能被翻出来。比如两个月前客户随口说的一个要求居然在聊天记录里出现过靠 Obsidian 全文搜索一下就找到了。这个价值甚至比喂给 Codex 更直接。6.2 还能怎么扩展目前我在准备两个扩展方向。第一是语音消息转文字微信里很多长语音对我来说是信息死角。开源社区有一些 Whisper 的本地方案可以定期把语音文件批量转成文本再顺着时间线插回 Markdown。第二是自动打标签我打算根据聊天内容做关键词匹配给每个文件自动补上“需求”“Bug”“决策”之类的标签减轻手动整理负担。如果你经常做团队管理还可以把“和团队成员的聊天记录”单独做成一个知识库每周自动生成“沟通密度”“待办事项”报告。这套逻辑和数据管线都是现成的就差按需调 Prompt。6.3 最后的建议折腾微信流最大的门槛不是技术而是数据规划和耐心。第一次全量解析可能很慢增量同步也需要反复调试 hash 和路径。但一旦跑通你就拥有了一个持续更新的、完全属于自己的聊天记录知识库。记得第一原则是合规和安全所有数据留在本地不要拿别人的数据开刀。工具是开源的流程是透明的数据是你自己的这套玩法才真正有价值。如果你也想开始建议先不要上太重的架构。只要一台电脑、一个解析脚本、一个 Obsidian 仓库就够了。跑通最小闭环之后再决定要不要接 Codex、要不要上定时任务。我个人的体会是把微信聊天记录从手机里捞出来那一刻你对信息的掌控感会提升很多而这种感觉值得你花一个周末去折腾。