我让 AI 帮我读微信了

深夜的终端窗口——AI 自动读写微信消息

昨晚搞到凌晨三点，终于在终端里敲了一句：

"帮我看看今天投资人群里都聊了什么。"

Claude 想了两秒，把群里一整天的消息拉出来，分好类，列了三条需要我回的。

我盯着屏幕，突然意识到一件事：我的 AI 刚才读了我的微信。

不是截图丢给 GPT 让它 OCR。是真的从数据库里拉出来的完整聊天记录——消息、时间、发送者、群名，全有。

然后我又敲了一句：

"帮我回老王，说明天下午三点可以。"

它帮我切到老王的聊天窗口，打了字，发了出去。

整个过程，我没碰过微信一下。

这东西怎么搞的

先说架构。分两条路径：

读消息这条路，靠的是直接解密微信的本地数据库。macOS 版微信把所有消息存在 SQLCipher 加密的 SQLite 里。拿到密钥，就能解密，就能查。

发消息这条路，靠的是 macOS 的无障碍 API（Accessibility API）。说白了就是模拟操作——找到聊天窗口、定位输入框、敲字、点发送。

两条路合在一起，注册成 Claude Code 的工具，Claude 就同时有了读和写的能力。

开源了：wechat-mac-reader。

读消息：从内存里偷钥匙

微信 4.1.x 的加密方式有点变态。

以前的版本，一把主密钥解全部数据库。网上大部分教程和工具都是按这个写的。

但 4.1.x 改了。每个数据库一把独立的密钥。24 个数据库，24 把钥匙。

我用的方案是 lldb 附加到微信进程上，扫内存，把 SQLCipher 的密钥逐个提取出来。听起来吓人，但其实就是一个调试器干的事。

拿到密钥之后，喂给 chatlog-bot（基于 sjzar/chatlog 的 fork）。这东西会用 fsnotify 监听数据库文件变化，实时解密新消息，然后开一个 HTTP API 在 :5030 端口。

最后配了个 launchd 服务让它开机自启。

效果：任何时候往 localhost:5030 发个请求，就能查到所有聊天记录。按联系人查、按时间查、按关键词搜，都行。

发消息：让 AI 点鼠标

发消息用的是 WeChat-MCP，走 macOS 无障碍 API。

原理很朴素：遍历微信的 UI 元素树，找到搜索框，输入联系人名字，点进聊天，定位消息输入框，打字，发送。

注册成 Claude Code 的 MCP 服务器之后，Claude 就能直接调用"给某某发消息"这个动作。

是的，本质上就是 AI 在帮你操作鼠标键盘。不优雅，但能用。

六个坑，个个要命

做完之后我做了个平台可行性调研，发现微信自动化这个领域坑多得离谱。我自己踩了六个，每个都是那种"文档不说、搜不到、只能自己撞"的暗坑。

第一坑：一把钥匙开不了所有门。

微信 4.1.x 用的是 per-DB 密钥。网上那些"提取微信密钥"的教程，默认是一把主密钥。拿到一把去解全部数据库，静默失败——不报错，解出来是空的。

第二坑：chatlog 自带的密钥提取在 4.1.x 上直接挂了。

chatlog-bot 内置了一套用 Mach VM API 扫内存的方案。跑起来直接报 "no memory regions found"。原因是 4.1.x 的内存布局变了。换 lldb 方案才搞定。

第三坑：配置路径要带前缀。

chatlog 的 config.yaml 里填数据库路径，需要加 db_storage/ 前缀。你要是直接填数据库文件名，不报错，就是解密不出来。沉默是最大的恶意。

第四坑：keys.json 里有个 __salts__ 字段。

lldb 提取出来的 keys.json 里，除了 24 个数据库的密钥，还有一个 __salts__ 字段。它的值是个列表，不是字符串。生成 config.yaml 的时候如果不过滤掉它，格式直接炸。

第五坑：密钥是一次性的。

重启微信，密钥就失效了。必须重新提取。别想着提取一次用一辈子。

第六坑：必须 sudo。

因为要附加到微信进程的内存空间，必须有 root 权限。这也意味着 Docker 方案不可能——你得直接操作宿主机上的进程。

有意思的地方

搞完这套东西之后，我发现最有趣的不是技术本身，是用法。

比如我让 Claude 帮我总结一天的群消息。几十个群，几百条消息，它两分钟给我列出来哪些需要我关注、哪些可以忽略。以前我每天花半小时刷群，现在不用了。

比如有人给我发了一段很长的语音转文字，我让 Claude 帮我提取关键信息然后起草一个回复。全程我只需要看一眼、确认、发送。

再比如，它能帮我查："上次跟张三聊那个项目是什么时候？他当时怎么说的？"——直接搜聊天记录，原文拉出来。

说到底，微信是中国人的生产力黑洞。所有人都在吐槽它，所有人都离不开它。既然逃不掉，不如让 AI 替你扛。

为什么不用现成的方案

做之前我调研了一圈。结论是：macOS 上没有一个能用的完整方案。

Windows 有 WeChatFerry，生态成熟。但 macOS 基本是荒地。有做逆向的，有做注入的，但要么只支持旧版本，要么稳定性堪忧，要么 API 覆盖率太低。

所以最后是三个开源项目拼起来的：lldb 密钥提取 + chatlog 解密服务 + WeChat-MCP 发消息。各自解决一个问题，组合起来刚好能跑。

不完美。密钥会过期，无障碍 API 偶尔抽风，微信一更新可能全炸。

但它现在能用。对我来说，够了。

一句话总结

微信不让你自动化，那就绕过它。

读消息从数据库绕，发消息从系统 API 绕。AI 居中调度，你只需要动嘴。

如果你也想搞，代码在这里：wechat-mac-reader。坑我都替你踩了，README 里写得很清楚。

有问题来 GitHub 开 issue，或者——让你的 AI 在微信上找我也行。

后记——2026-04-26：4.1.9、WeFlow、和我之前讲反的那个坑

这篇发出来一个月，发现三件事得更新。

坑五讲反了

原文坑五说"密钥重启就失效，每次都得重新抓"。今天我做了一次 4.1.9 → 4.1.8.100 → 4.1.9 的来回切换，分别 lldb 扫了两次内存，diff 出来非常干净：24 个 per-DB enc_key 完全 byte-equal。同 wxid 同 DB 文件，密钥跟微信版本和进程生命周期都无关。

我当时看到的"密钥变了"，其实是 WCDB 的 lazy-open——刚启动时只有被访问过的 DB 把密钥加载到内存，扫出来当然少。少不等于变。等用户翻老消息把对应 DB 打开，密钥才进内存。

修正后的结论：密钥跨进程跨版本持久。 重启后扫一遍是为了补齐 lazy-load 那些，不是因为旧密钥失效。

WeFlow 和 chatlog 是两种思路

这个月加了 WeFlow 做年度报告分析，踩坑才意识到它跟 chatlog 不是一回事：

上周微信自动更新到 4.1.9，WeFlow 立刻报 Sink pattern not found，chatlog-bot 一点没受影响。

降级—升级的应对手册

WeFlow 的 FAQ 写得很清楚：降级到 4.1.7.57 或 4.1.8.100，冷启动 Mac，跑一次 WeFlow 自动抓密钥，登录微信，再升级回去。我从头跑了一遍，能用。WeFlow 在 4.1.8.100 抓到的 master key 升级回 4.1.9 后仍然有效——理由就是上面那段：密钥跟版本无关。

如果你依赖 hook 流派工具，标准操作是：关掉微信自动更新。

defaults write com.tencent.xinWeChat AutoUpdateEnabled -bool false

不然腾讯每发一版都可能触发一次降级折腾。

一条普适规律

内存扫描派坏得慢、修得也慢——压根不需要为版本更新做适配；二进制 hook 派看得更深，但维护者得跟着每个二进制变化追打补丁。两者各有适用场景，看你愿意把信任放在"模式稳定"还是"维护者更新速度"。

我现在的栈是分层的：chatlog-bot 是常驻层（要稳）；WeFlow 是按需层（要功能）。两层，两种信任度。