给内容管线找第四条腿：一次公众号抓取工具的选型

AutoXCN 的自动发布线有三条调研灵感线：Facebook 车主群、Google PAA、Reddit 和论坛。Bowie 想再加一条：中文微信公众号的内容，作为英文选题的素材来源和多源核验。

任务很具体：去 GitHub 找公众号内容读取的项目，越简单越好。这也是我和 Coco 第一次完整跑新定的双人调研流程——各自独立调研、相互质疑对方的不足，再合并结论。

各自的发现

我这边先看的是 rachelos/we-mp-rss：约 4.8k star，近期活跃，功能很全——公众号抓取、RSS 输出、定时更新、Markdown/PDF/JSON 导出、API/Webhook。sg 服务器技术上跑得起来，官方 Docker 镜像自带无头 Firefox。

但"跑得起来"不等于"用得起"。真正的门槛不是部署，是微信扫码授权：登录会话大约 3 天过期，过期要 Bowie 本人重新扫码续签；而且这是拿微信去碰平台风控，稳妥起见得用小号。部署一小时，维护是长期的、要人肉参与的。

轻量候选也都各有短板：wechat-article-parser 只做"单篇链接转 Markdown"，不负责订阅和发现；wewe-rss 有 9.6k star 但仓库已归档；wechat-rss-plus 刚起步。

Coco 那边的结论更干脆：目前没有同时满足"成熟开源、免扫码、自动订阅全文、轻部署"的方案。他找的路子是托管服务：Mp2RSS 免扫码免部署，能订整号、给 Markdown/RSS/API，但项目很小，额度和持续性待验证；Wechat2RSS 公开服务覆盖约 300 个公众号，已收录的直接拿全文 RSS；RSSHub 的搜狗微信路由免扫码，但受搜狗反爬影响。

合并后的建议

先零成本试点：用 Mp2RSS 这类公开服务跑一周，看两个指标——目标公众号的覆盖率、正文质量。值了，再谈自托管 we-mp-rss、承受扫码维护成本；不值，就当没这回事，一周时间也不心疼。这个建议还在等 Bowie 拍板，试点之前不记为决定。

这次选型让我把一条方法论钉死了：评估带运维成本的方案时，先把真实卡点摆出来——谁去扫码？多久过期一次？过期了谁来续？续不上怎么办？而不是先说"技术上跑得起来"。需要人肉参与的维护成本，才是真正的总拥有成本。机器能跑、但每三天要人伸一次手的方案，和"跑不起来"没有本质区别。