想让 AI 帮忙翻聊天记录的人一直有，卡点也一直硬，WhatsApp 不给个人消息开官方接口。十月十八日 HN 上出现一个 Show HN，发帖人把一套只读方案摆了出来，代理能搜索并读取你自己的 WhatsApp 消息，服务跑在 Cloudflare 上。我读了仓库的 README 与整串评论，功能、部署、风险三层都有干货，也有必须说透的灰区。
主要功能
项目名 whatsapp-mcp，作者 finereli，MIT 许可，定位是只读的 MCP 服务器，让 Claude 这类代理搜索并读取你本人的 WhatsApp 消息。只读两个字是设计底线。不能发消息。媒体文件不下载，图片语音只显示一个占位标记。发帖人是 zoozla，十月十八日晚间上线，两天仓库三十多星，HN 三十来分二十多条评论，热度在 Show HN 里属于中上。刻意做成单用户，一次部署绑定一个 WhatsApp 账号与一个所有者，作者的理由很直白，部署里存着完整消息史与活跃登录凭据，一人一套各自跑，别共用。
怎么实现的
底层用开源库 Baileys，走 WhatsApp Web 同款协议，服务器以一台已关联设备的身份接入，手机仍是数据源，两者靠 WebSocket 同步。仓库用 TypeScript 写成，代码量不大，读懂不难。连接策略算得精，长连接一条不留，代理请求时先看本地副本，副本超过十分钟才触发同步，另加每天 UTC 凌晨四点的一次定时任务收离线消息，流量与计费都省。凭据与消息全部存在一个 Durable Object 的 SQLite 里，这个库兼任 Baileys 的凭据仓与消息库，登录令牌与待处理记录放 Cloudflare KV。部署流程不算长，克隆仓库，装依赖，建 KV 命名空间，设一个所有者密码，执行部署命令，最后扫码关联手机，需要 Node 二十以上，全程十几分钟能走完。
免费要打折扣
标题里的 free 按自称口径听。README 明确推荐 Workers 付费计划，每月几美元，理由是大量历史导入需要更高的 CPU 限额，作者自己没在免费计划上测过，强行免费跑要删掉限额配置，首次导入可能不稳定。想零成本跑的人先看清这一段，免费档跑得起来与跑得顺是两回事，历史消息一多，超限中断的体验会很磨人。
联系人与隐私
背景介绍里说它能连 Google 账号取联系人名，核对 README 后要更正这个说法，服务器自己不接任何联系人服务，避开云项目审批那一堆事。做法是暴露一个未命名会话工具，让代理用它已有的联系人连接器去查号码是谁，查到名字再写回本地库。举个例子，代理翻到一串裸号码，拿着号去连接器里查，查到名字写回，下一轮检索就有了人名。隐私口径方面，消息只存在你自己 Cloudflare 账号的存储里，README 称哪儿也不去，这句话同样按自称口径听。真把私人对话开放给 AI 服务，聊天对端的人可没点过头，这笔账每个人自己算。
风险与争议
最大的坑写在 README 里，WhatsApp 对个人消息没有官方 API，这套方案违反服务条款，作者评估只读关联设备的实际风险低但不为零，风险自担。HN 评论区的过来人补了实证，走 Web 协议的非官方库时不时招来封号，在拿 WhatsApp 当一切的国家这是大事，还有人抱怨 Baileys 需要周期性手动重新登录。隐私争议是整帖最热的分支，反对者质问把对端未同意的对话喂给第三方 AI 算什么，支持者拿截屏转发作类比，有人点破元数据泄露与整库搬走性质不同，也有人反过来把它当 WhatsApp 客服机器人的跳板看。
解决了什么需求
真实需求存在，找地址、对时间、翻结论、汇总群聊，这些事代理比人翻得快。方案适合能接受灰区、愿意自己部署的技术玩家，普通人别碰，封号与隐私两道坎都不轻。聊天记录是个人数据里最厚的一块，谁能读它，谁就拿到你的半个社交圈，这正是争议的根。把它当思路看也有收获，Durable Object 当小型状态库，配定时任务收增量消息，这套骨架能搬到别的只读同步场景里用。
一句收尾，能读你消息的服务，最好只有你自己部署的那一个。
来源
- HN 讨论帖 https://news.ycombinator.com/item?id=50145715
- GitHub 仓库 https://github.com/finereli/whatsapp-mcp
- 项目 README https://raw.githubusercontent.com/finereli/whatsapp-mcp/main/README.md