用 AI 写了一个公众号批量取关应用

关注一个公众号，只要看到一篇文章、顺手点一下。

取关就完全是另一回事了。你得打开公众号，进入资料页，点右上角，再取消关注。一个不算什么，几十个开始烦，几百个足够让人直接放弃。

我的公众号列表就是这么一点点涨到了 236 个。有些还在认真看，有些早就停更，有些连当初为什么关注都想不起来。微信能让我一个个取关，却没有给我一套像样的批量整理办法。

于是我做了一个 Mac 应用，名字就叫「批量取关公众号」。它先把关注列表摊开，让我搜索、筛选、加白名单；等我确认好，再生成取关清单，逐个执行。

这不是一个宏大的产品故事。说得直白一点，就是我又用 AI 给自己造了个垃圾——但这个垃圾，我真的会用。

先做自己会用的东西

这不是我第一次为自己的小问题写软件。我嫌简历模板来回调整麻烦，做了履历工坊；写公众号需要反复处理格式，做了墨排；总惦记 Codex 还剩多少用量，做了 Codex Usage HUD；Mac 和 Android 之间传一段文字还要绕路，又做了 Relay。后来还有发圈防折叠、公众号文章批量下载器、拼一下，它们解决的都是我在工作或生活里真的碰到过的问题。

它们都不是从“市场还缺什么”开始的，而是从一句很具体的抱怨开始：这个动作我每天都在重复，为什么不能更顺一点？

我现在判断一个小工具值不值得做，标准也很简单：不是它能不能卖，也不是介绍页看起来像不像一个产品，而是下周我还会不会打开它。

「批量取关公众号」的使用频率没有前面几个高。我不会每天批量取关，但每隔一段时间，列表膨胀到不得不处理时，这个需求又真切得让人烦躁。低频不等于没价值。有些工具一年只认真用几次，却能在那几次里省掉上百次机械点击。

AI 编程最适合干这种事。一个念头未必值得组团队、画商业计划，却完全值得用几个晚上做成自己手边的工具。先把自己的问题解决，再看有没有别人也需要。

公众号批量取关怎么用

这张图就是我真实整理时的状态：一共读到 236 个账号，2 个进了白名单，49 个已经取关，当前又选出了 185 个待处理账号。

使用时，我会先打开微信和应用，点击连接，再在微信里随便打开一个小程序的内容页。小程序只是用来建立本机调试连接，不需要做别的操作。

列表读出来以后，整理过程大致是这样：

1. 先把肯定要保留的公众号加入白名单。之后无论全选还是跨页选择，它们都会被自动排除。

2. 按名称或账号 ID 搜索，把还在看的、已经停更的和完全陌生的账号分开处理。

3. 勾选想取消关注的账号。可以选当前页，也可以一次选中全部可取关账号。

4. 点击「生成取关清单」。这一步只生成名单，不会立刻动微信，给自己最后一次检查机会。

5. 确认后选择执行模式再开始：超稳妥模式逐个执行并在前后核验；快速模式逐个发送但省略前后状态查询；超级快速模式最多同时发送 3 个请求。

上面不是演示数据。这个清单最终完成了 185/185 个账号，实际耗时 18 分 54 秒。当时用的是现在的「超稳妥模式」：每个账号取关前检查一次，收到微信操作回执后再查询一次关注状态，确认已经取关才继续下一个。它没有调用一个瞬间完成的“批量接口”，而是替我自动完成并核对 185 次原本需要手动重复的操作。

这次真实使用也暴露了问题：18 分 54 秒确实太久。数据里每个账号平均约 6.1 秒，耗时主要来自两次关注状态查询和重复的身份核验。所以我没有粗暴地删掉所有保护，而是把选择交给使用者：超稳妥模式保留完整前后校验；快速模式去掉关注状态的前后查询但仍然串行；超级快速模式再尝试最多 3 个并行请求。后两种模式仍会检查当前微信账号、会话和白名单，也必须收到微信的成功回执，只是结果标记为「已取关，未复核」。

后来我重新关注了一小批账号，专门试了快速模式：16 个账号，21.3 秒，平均约 1.33 秒/个。这次就舒服多了，不用挂在那里等十几分钟，几十秒就能整理完一小批。

和之前超稳妥模式平均约 6.1 秒/个相比，这次单个账号的平均耗时明显降低了。不过，两次处理的账号和数量都不同，不能把它当成严格的性能对照。图里测的是串行的「快速模式」，不是并行的「超级快速模式」；它仍以微信成功回执为准，所以界面保留了「未复核」的提示。

接着我又试了超级快速模式：27 个账号，14.2 秒。账号更多，总用时反而更短，这次确实有了“批量处理”的感觉。

把三次实际使用放在一起看：

超级快速模式最多同时发送 3 个请求。截图里单个请求仍用了约 1.5～1.6 秒，但等待时间可以重叠，所以 27 个号只用了 14.2 秒；不能把总时间除以数量后的约 0.53 秒，理解成单个请求只需 0.53 秒。三次账号和数量不同，这是实际使用记录，不是严格的同批性能对照。快速和超级快速模式均以微信成功回执为准，没有逐项复核。

最近 30 天取消过的账号会留在记录里。如果后来发现删错了，可以跨页勾选多个号，一起重新关注。恢复时不会默认加入白名单，想保护再自己勾选；想像我一样恢复几个号测试速度，也不用再逐个移出白名单。微信明确返回已注销或公众号因违规无法关注时，应用会记下原因，跳过这个号继续处理，最后分别显示恢复和跳过的数量。

恢复关注也默认采用快速方式：收到微信成功回执就继续下一项，不再逐项查询前后状态，结果会标明“未复核”。想确认每个号确实恢复了，可以选“逐项复核”。前面 21.3 秒的数据只属于快速取关，不能拿来当作恢复关注的实测成绩。

我特意没有把它做成一个醒目的“一键清空”。公众号不是缓存文件，里面总有几个不能误删的账号。批量能力负责省时间，白名单和确认清单负责让我敢按下按钮。

做完以后，我更确定“个人软件”值得做

以前做软件，总容易先问：有多少用户？能不能收费？值不值得长期维护？

但 AI 把试错成本压低以后，问题可以换成：这件小事是不是正在反复消耗我？如果答案是，那就先给自己做一个版本。

个人软件不需要假装服务所有人。它可以只适配我的设备，只解决一条很窄的流程，甚至界面也不够精致。只要它进入了真实生活，替我省下时间，下一次需求出现时我还愿意打开，它就已经通过了最重要的验收。

当然，“给自己用”也不等于随便。越是批量操作，越要把后悔的成本算进去。所以这个工具始终保留白名单、清单确认、账号会话绑定、异常暂停和恢复关注；结果复核则由执行模式决定。AI 可以帮我更快地把东西做出来，但哪些保护必须保留、哪些等待可以让用户选择，仍然要由人决定。

下面这段，写给想折腾的人

应用外层是 Swift 和 AppKit，列表、白名单、取关记录与执行队列由本机服务管理。它通过开源项目 WMPFDebugger 连接微信的小程序调试通道，再调用微信已有的关注状态和取关能力。

这里有一个容易误解的地方：界面里已经能看到公众号，不代表实时连接还在。列表可以来自上次保存在本机的缓存，所以断线后仍能搜索、筛选和生成清单；真正执行取关时，才需要重新打开一个小程序恢复连接。现在应用会把“缓存列表”和“实时连接”分开提示，不再让人对着已有列表猜为什么还要开小程序。

涉及批量操作，我给执行流程设了几道不随模式关闭的刹车：清单绑定当前微信账号与会话；白名单在执行前再次拦截；必须收到微信的成功回执；超时、身份变化或结果异常就暂停。默认的超稳妥模式还会在每项操作前后查询关注状态。快速模式和超级快速模式不做这两次查询，因此界面会明确写「未复核」，不会把微信回执冒充成状态确认。

下载 Apple Silicon 版 DMG · 查看源代码

因为项目包含 GPLv2 的 WMPFDebugger，整个仓库也按 GPLv2 开源；如果分发修改版，需要继续提供对应源码并保留许可证。当前版本还没有经过 Apple 签名和公证。第一次打开时，请在 Finder 的“应用程序”文件夹里右键点击「批量取关公众号.app」，然后选择“打开”。

如果你也有一个堆了几百个公众号的微信，可以先从一两个不重要的账号试起。至于它以后会不会变成一个“正式产品”，我还没想那么远。我先关心的是：下一次想整理公众号时，我终于不用再点两百遍了。