微信聊天记录里藏着大量有价值的信息但官方客户端只给你一个封闭的搜索框想批量分析、做知识库、跑自动化几乎无从下手。WorkBuddy 这类本地 AI 助手出现之后很多人第一反应就是能不能把微信本地聊天记录接进去让 AI 直接读我的聊天内容答案是可以的但中间涉及数据库定位、解密、结构解析、字段映射、增量同步等一连串工程细节坑非常多。这篇就把我实际跑通 WorkBuddy 接入微信本地聊天记录的完整链路拆开讲清楚从环境准备、数据库结构、解密思路到 WorkBuddy 侧的数据接入与自定义指令配置全部给到可复现的步骤和参数适合有一定 Python 基础、想折腾本地 AI 知识库的开发者参考。1. 先搞清楚微信本地聊天记录到底存在哪动手之前必须先把数据在哪、长什么样这件事摸透否则后面全是盲人摸象。微信 PC 端的聊天数据并不是一个简单的文本文件而是一整套 SQLite 数据库加媒体文件的组合理解它的存储布局是整条链路的地基。1.1 PC 微信数据目录的典型结构以 Windows 版微信为例默认数据根目录一般在文档\WeChat Files\下面每个登录过的账号对应一个以 wxid 开头的文件夹。进入账号目录后你会看到几个关键子目录Msg核心目录聊天记录数据库就在这里按Multi、Media等子目录再细分。FileStorage图片、视频、文件等媒体资源按月份分文件夹存放。config账号配置、部分缓存信息。Msg\Multi多账号或分片存储的数据库文件常见命名如MSG0.db、MSG1.db。真正要接入 WorkBuddy 的是Msg目录下的数据库文件。这里有个容易踩的坑不同微信版本目录结构会变尤其是 4.x 之后数据库文件名和加密方式都做了调整所以第一步永远是先确认自己客户端的具体版本再对照目录去找文件不要照搬网上旧教程的路径。1.2 为什么不能直接双击打开这些 db 文件很多人第一次拿到MSG0.db会直接拖进 DB Browser for SQLite 打开结果要么报file is not a database要么打开后表结构一片乱码。原因有两个层面第一微信对数据库做了加密处理文件头不是标准 SQLite 的SQLite format 3魔数而是被替换成了自定义的加密头。SQLite 引擎识别不了这个头自然打不开。第二即使某些版本没加密微信用的也是 WAL 模式数据可能还在-wal和-shm文件里没落盘单独打开主 db 会看到数据不全。所以正确的顺序是先判断是否加密再决定解密方案最后才谈解析。跳过这一步直接写代码读库100% 会卡在第一步。1.3 判断数据库是否加密的快速方法用十六进制工具比如 HxD或者 Python 直接读前 16 字节看文件头。标准 SQLite 文件的前 16 字节是固定的 ASCII 字符串SQLite format 3\0。如果读出来是这串说明没加密可以直接用 sqlite3 打开如果是别的字节序列基本可以确定是加密库。with open(rD:\WeChat Files\wxid_xxx\Msg\Multi\MSG0.db, rb) as f: header f.read(16) print(header) # 正常 SQLite: bSQLite format 3\x00 # 加密库: 会是一串无规律字节这一步花不了两分钟但能帮你省掉后面几小时的无效调试。我见过太多人上来就写解析代码跑半天报错最后发现根本没解密。2. 数据库解密整条链路里最需要谨慎的一环解密是绕不过去的一步但也是最需要强调合规和边界的一步。这里只讨论在自己设备上、处理自己账号数据的技术原理任何涉及他人数据、绕过安全机制的行为都不在讨论范围内。2.1 微信数据库加密的基本原理微信 PC 端数据库加密采用的是基于密钥的页级加密方案。简单说它把 SQLite 的每个数据页默认 4096 字节用密钥做异或或 AES 处理同时把文件头替换掉。密钥并不是随便生成的而是和当前登录账号、设备信息绑定通过一定算法派生出来。理解这一点很关键密钥是每账号每设备的换台电脑、换个账号密钥就变了。所以网上那些通用解密工具基本不靠谱真正能用的方案必须从你自己的运行环境中提取密钥。2.2 密钥获取的常见思路业界比较成熟的思路是从微信进程内存中读取密钥。微信在运行时会持有解密所需的密钥通过读取进程内存并匹配特定特征可以定位到密钥所在位置。这类操作通常借助调试工具或内存扫描脚本完成。需要明确的是这类操作有明确前提必须是自己的设备、自己的账号、自己有权处理的数据。同时微信版本更新频繁内存特征会变工具也需要跟着更新。我实测下来版本不匹配是这类方案失败的头号原因所以动手前务必确认工具支持的版本范围。2.3 解密后的验证步骤拿到密钥、完成解密之后不要急着写业务代码先做三步验证用十六进制工具确认文件头已经变回SQLite format 3。用 DB Browser for SQLite 打开确认能看到表列表。随便查一张表的前几行确认数据可读、中文不乱码。# 用 sqlite3 命令行快速验证 sqlite3 decrypted_MSG0.db .tables sqlite3 decrypted_MSG0.db SELECT count(*) FROM sqlite_master;这三步都过了才说明解密真正成功。任何一步失败都要回头检查密钥是否正确、版本是否匹配、解密是否覆盖了所有页包括 WAL 文件。提示解密后的数据库建议单独复制一份到工作目录再操作不要在原目录直接改避免污染原始数据导致微信异常。3. 读懂微信聊天记录的数据库表结构解密只是拿到能打开的库真正要接入 WorkBuddy还得把里面的表结构、字段含义、消息类型全部搞清楚。微信的库设计得比较工程化字段名大多是缩写不查资料很难猜。3.1 核心表消息主表与联系人表不同版本表名略有差异但核心就两张消息表通常叫MSG或类似名称存所有聊天消息字段包括本地 ID、服务端 ID、消息类型、发送方、接收方、时间戳、内容等。联系人表通常叫Contact或Friend存好友、群、公众号的基本信息字段包括 wxid、昵称、备注、类型等。消息表里最关键的是消息类型字段它决定了内容字段该怎么解析。文本消息直接是字符串图片、语音、视频、文件、引用、系统提示等各有各的编码方式不能一视同仁。3.2 消息类型字段的常见取值下面这张表是我在实际解析中整理出来的常见类型对照不同版本可能有细微差别但大方向一致类型值含义内容字段处理方式1文本消息直接读取注意 XML 转义3图片消息内容里是 XML需提取路径或 md534语音消息XML 描述指向语音文件43视频消息XML 描述指向视频文件49应用/引用/文件等内容为 XML需按子类型再解析10000系统提示如撤回了一条消息类型 49 是最麻烦的它是个万能类型文件、链接、小程序、引用回复、转账等都走这个类型必须解析 XML 里的子类型字段才能区分。我一开始没注意把所有 49 都当文件处理结果聊天记录里全是乱码。3.3 时间戳与发送方向的坑微信消息表里的时间戳一般是 Unix 秒级时间戳但要注意时区问题直接转 datetime 可能差 8 小时需要显式指定时区或用本地时间转换。发送方向也不能想当然。有的版本用IsSender字段0/1标识有的版本靠发送方和接收方字段对比判断。如果不确认清楚接入 WorkBuddy 后会出现我发的消息显示成对方发的这种尴尬情况。建议先手动查几条已知消息对照字段值确认逻辑再写批量处理代码。4. 把聊天记录喂给 WorkBuddy 的完整链路前面都是准备工作这一节才是真正的接入。WorkBuddy 本身是个本地 AI 助手框架它的强项是读取本地文件、执行自定义指令、结合大模型做问答。所以接入思路不是让 WorkBuddy 直连微信数据库而是把微信数据转换成 WorkBuddy 能读的格式。4.1 为什么选择导出中转而不是直连有人会想能不能让 WorkBuddy 直接读解密后的 db技术上可行但不推荐原因有三第一微信数据库结构复杂、版本多变直连意味着每次微信更新都可能要改代码维护成本高。第二WorkBuddy 的检索和上下文管理更适合处理结构化的文本或 Markdown而不是原始 SQLite 表。第三直连会持续占用数据库文件可能和微信本身产生锁冲突。所以更稳的方案是写一个 Python 脚本定期把微信数据库解析成结构化的文本比如按会话分文件的 Markdown 或 JSONL再让 WorkBuddy 去读这些导出文件。这样职责清晰微信归微信AI 归 AI。4.2 导出脚本的核心逻辑导出脚本要做四件事连库、查消息、关联联系人、按会话输出。核心代码结构大致如下import sqlite3 import json from datetime import datetime def export_chat(db_path, out_path): conn sqlite3.connect(db_path) conn.row_factory sqlite3.Row cur conn.cursor() # 先加载联系人映射 contacts {} for row in cur.execute(SELECT * FROM Contact): contacts[row[UserName]] row[NickName] or row[Remark] or row[UserName] # 再按会话拉消息 cur.execute(SELECT * FROM MSG ORDER BY CreateTime ASC) with open(out_path, w, encodingutf-8) as f: for msg in cur: sender contacts.get(msg[StrTalker], msg[StrTalker]) ts datetime.fromtimestamp(msg[CreateTime]).strftime(%Y-%m-%d %H:%M:%S) content parse_content(msg[Type], msg[Content]) if content is None: continue f.write(json.dumps({ time: ts, talker: sender, type: msg[Type], content: content }, ensure_asciiFalse) \n) conn.close()注意字段名UserName、StrTalker、CreateTime等在不同版本里可能不一样跑之前先用.schema MSG看一眼实际表结构别硬套。4.3 内容解析函数的写法parse_content是整个脚本里最需要打磨的部分。文本消息直接返回XML 类消息用正则或 XML 解析器提取关键字段媒体类消息返回一个占位描述比如[图片]并记录文件路径。import re def parse_content(msg_type, raw): if raw is None: return None if msg_type 1: return raw if msg_type 3: return [图片] if msg_type 34: return [语音] if msg_type 43: return [视频] if msg_type 49: # 提取 XML 里的 title 或 des 作为摘要 m re.search(rtitle(.*?)/title, raw) return m.group(1) if m else [应用消息] if msg_type 10000: return [系统消息] return None这里有个经验不要试图把所有类型都解析得完美先把文本和常见类型跑通媒体类用占位符等整体链路稳定了再逐步细化。我第一版就是贪多结果卡在某个冷门类型上好几天其实那类消息占比不到 1%。4.4 增量同步别每次都全量导出聊天记录会不断增长每次全量导出既慢又浪费。正确做法是记录上次导出的最大消息 ID 或时间戳下次只导出新增部分。# 记录上次同步位置 last_id load_checkpoint() cur.execute(SELECT * FROM MSG WHERE localId ? ORDER BY localId ASC, (last_id,)) # 导出完成后更新 checkpoint save_checkpoint(max_local_id)增量同步的关键是选对游标字段。优先用本地自增 ID它单调递增且稳定时间戳可能因为消息补发、时区问题出现乱序不如 ID 可靠。5. WorkBuddy 侧的数据接入与自定义指令配置数据导出成 JSONL 或 Markdown 之后接下来就是让 WorkBuddy 真正用起来。这一步的核心是把导出文件纳入 WorkBuddy 的知识范围并配置合适的自定义指令让它能针对聊天记录做问答。5.1 把导出文件放进 WorkBuddy 的工作目录WorkBuddy 读取本地文件通常基于工作目录或指定的知识库路径。建议单独建一个目录比如workbuddy-wechat-export把导出的 JSONL 按会话或按月份分文件放进去。分文件的好处是检索时能缩小范围避免一次性加载几万条消息导致上下文爆炸。目录结构可以这样组织workbuddy-wechat-export/ ├── 2024-01.jsonl ├── 2024-02.jsonl ├── contacts.json └── README.mdcontacts.json存联系人映射方便 WorkBuddy 在回答时把 wxid 翻译成昵称。README.md写清楚数据来源、字段含义、更新方式既是给 WorkBuddy 的上下文提示也是给自己留的文档。5.2 自定义指令怎么写才有效WorkBuddy 的自定义指令本质是给模型的行为约束和角色设定。针对聊天记录场景指令要解决三个问题数据在哪、怎么查、怎么答。一条实用的自定义指令大致长这样你可以访问 workbuddy-wechat-export 目录下的聊天记录导出文件。 每条记录包含 time、talker、type、content 四个字段。 当用户询问某段时间或某人的聊天内容时先按 talker 和 time 过滤再总结。 回答时引用具体时间和原话不要编造未出现在记录中的内容。 涉及隐私的内容只做客观转述不做主观评价。这里最关键的是最后两条一是不要编造聊天记录问答最怕模型幻觉凭空生成不存在的对话二是客观转述避免模型对私人对话做价值判断。这两条能极大提升结果可信度。5.3 检索策略关键词还是语义聊天记录问答有两种检索方式关键词匹配和语义检索。实测下来两者结合效果最好。关键词匹配适合查具体的人、时间、专有名词比如上周三和张三聊了什么。语义检索适合模糊查询比如我之前是不是提过要买相机。WorkBuddy 如果支持向量检索可以把导出的文本做 embedding 后入库如果不支持就靠模型直接读文件加关键词过滤。我的做法是先用脚本按 talker 和时间做粗筛把候选消息控制在几百条以内再交给模型做精读和总结。这样既快又准还省 token。5.4 定时任务让数据保持新鲜手动导出容易忘建议用系统定时任务Windows 的任务计划程序或 Linux 的 cron每天跑一次增量导出脚本。脚本跑完自动更新 checkpointWorkBuddy 下次问答时读到的就是最新数据。# Linux crontab 示例每天凌晨 2 点增量导出 0 2 * * * /usr/bin/python3 /path/to/export_wechat.py /var/log/wechat_export.log 21日志一定要留出问题时能快速定位是脚本挂了、数据库锁了还是密钥失效了。我踩过一次坑微信更新后密钥变了脚本静默失败结果 WorkBuddy 连着几天读的都是旧数据还以为是模型变笨了。6. 实操中真正会卡住你的那些坑前面讲的是应该怎么做这一节讲实际做的时候会在哪翻车。这些坑网上教程基本不提但每一个都能让你卡半天。6.1 版本不匹配导致的连锁失败微信版本、解密工具版本、数据库结构三者必须匹配。微信一更新密钥派生方式可能变、表结构可能变、字段名可能变。我遇到过最离谱的一次微信小版本更新后消息表多了一个字段导致我按固定列序读取的代码全部错位内容全乱。解决办法只有一个所有涉及表结构的代码一律用列名读取row[Content]绝不用列索引row[5]。同时把微信版本号记录在导出文件的元信息里方便排查。6.2 数据库被占用导致读取失败微信运行时会对数据库加锁脚本直接连可能报database is locked。两个应对方案一是复制一份数据库副本再读二是设置较长的 timeout 并加重试。conn sqlite3.connect(db_path, timeout30)复制副本更稳妥但要注意 WAL 文件也要一起复制否则数据不全。我一般用shutil.copy2把.db、.db-wal、.db-shm三个文件一起拷到临时目录再操作。6.3 中文乱码与编码问题导出时如果没指定encodingutf-8Windows 默认会用 GBK导致中文乱码。另外微信内容里可能包含 emoji 和特殊字符写 JSON 时要用ensure_asciiFalse否则会变成一堆\uXXXX虽然不算错但可读性差。还有一个隐蔽的坑某些消息内容里含有未转义的 XML 特殊字符直接用 XML 解析器会报错。稳妥做法是先做一次容错处理解析失败就退回正则提取。6.4 隐私与合规的边界这一点必须单独强调。聊天记录涉及大量个人隐私接入 AI 之前要想清楚几件事数据只在自己设备上处理不上传到任何第三方服务。如果 WorkBuddy 背后调用的是云端大模型要确认聊天内容是否会被发送出去必要时改用本地模型。导出的文件要放在受控目录不要随手丢进同步盘或共享目录。涉及他人的对话内容使用时注意分寸不做传播和二次加工。技术能跑通不代表可以随便用这条线心里要有数。6.5 性能几万条消息怎么不卡聊天记录动辄几万几十万条全量加载进内存会爆。几个优化点导出时按会话或按月分文件避免单文件过大。查询时先按时间范围过滤再加载。如果做向量检索分批 embedding别一次性全塞进去。WorkBuddy 侧配置合理的上下文窗口别把整个文件都塞进 prompt。我实测下来按月分文件 时间过滤的组合能把单次查询的候选集从几十万条压到几百条响应速度从几十秒降到几秒。7. 几个能明显提升体验的进阶玩法基础链路跑通之后可以做一些增强让这套东西真正好用起来。7.1 按联系人建独立知识库如果你经常需要回顾和特定人的对话可以按 talker 拆分文件每个人一个知识库。这样问我和张三的项目讨论时检索范围直接锁定到张三的文件准确率和速度都大幅提升。7.2 结合关键词做主题归档聊天记录里往往散落着重要信息比如地址、账号、约定时间。可以写脚本用关键词规则如地址是电话是约在自动抽取生成一份重要信息摘要单独喂给 WorkBuddy。这样问上次说的那个地址时能直接命中摘要不用翻原始记录。7.3 用自定义指令固化常用查询把高频查询写成自定义指令模板比如总结我和某人本周的对话要点找出所有提到 deadline 的消息。WorkBuddy 支持自定义指令的话这些模板能一键触发省去每次手打 prompt 的麻烦。7.4 定期备份与版本管理导出文件建议纳入版本管理或定期备份。一方面防止脚本出错导致数据丢失另一方面可以对比不同时间点的导出结果排查同步是否正常。我一般保留最近 30 天的导出文件更早的归档压缩。整套流程跑下来从微信数据库到 WorkBuddy 可问答的知识库核心其实就是解密—解析—导出—接入四步。真正花时间的不是写代码而是搞清楚每个版本的数据库结构差异以及处理各种边界情况。我个人的体会是别追求一步到位先把文本消息这条最短路径跑通能问答了再逐步加媒体类型、加增量同步、加检索优化。每加一层都验证一次比一口气写完再调试要省心得多。另外提醒一句微信版本更新后第一件事就是重新验证整条链路别等 WorkBuddy 答非所问了才发现数据早就没同步上。