我现在要实现一个skills，抓取指定公众号的10万+文章，请推荐一个最佳实现方案。
2026-04-06
可以做，但我建议你把这件事分成两种场景看：
一、先说结论
最佳方案
最佳实现方案不是“硬爬指定公众号”本身，而是：
“授权优先 + 检索召回 + 文章解析 + 热度判定 + 去重入库”的混合式 skill。
也就是：
场景 A：抓你自己的号，或对方明确授权给你
走公众号官方接口链路，这是最稳的。公众号开发体系本身支持 access_token、草稿箱、发布能力等接口，适合拿到你自己账号内的文章与发布记录。公开资料也显示，草稿箱列表、发布能力中的“获取成功发布列表”等能力是这条链路的核心。(阿里云帮助中心)
场景 B：抓别人的号，而且你没有后台权限
不要把 skill 设计成“模拟登录公众号后台、绕限制硬抓”。更稳的做法是把它做成：
“指定公众号 → 搜索引擎/第三方索引召回候选文章 → 解析原文页 → 判断是否 10 万+ → 入库”
因为公开可用的索引层目前仍存在，例如搜狗微信搜索仍在收录公众号和文章内容。(weixin.sogou.com)
二、为什么这是最佳方案
1. 直接“硬爬公众号历史列表”最不稳
公众号文章天然不是一个为第三方批量抓取而开放的公开内容 API。你如果没有账号后台权限，想长期稳定地直接抓“某个指定号的全部历史文章列表”，往往会遇到这些问题：
1）没有官方开放给“任意第三方公众号全文历史抓取”的通用接口
官方接口重点是管理你自己或已授权账号的素材、草稿、发布等，而不是让你随便拉别人公众号的全部文章历史。(阿里云帮助中心)
2）反爬强，稳定性差
今天能跑，明天可能就挂。你如果把 skill 的核心押在“浏览器模拟 + 反反爬细节”上，后续维护成本会非常高。
3）合规风险高
尤其是你如果后面还想做成对外可卖、可复用的 skill，最好不要把底层建立在灰色抓取链路上。
三、我给你的推荐架构
方案名：公众号 10 万+ 文章发现 Skill
这个 skill 不要叫“爬虫”，要叫：
“公众号爆文发现与归档 Skill”
这样定位更稳，也更好卖。
第 1 层：输入层
用户输入：
公众号名称
时间范围
关键词（可选）
只要 10 万+ / 近似爆文 / 全部文章
输出条数上限
示例：
{
"account_name": "某某公众号",
"date_from": "2025-01-01",
"date_to": "2026-04-01",
"keywords": ["AI", "提示词", "自动化"],
"only_hot": true,
"limit": 50
}第 2 层：召回层
最推荐：多源召回，不押单点
你不要只依赖一个来源，而是做成 3 路召回：
路线 A：公开搜索索引召回
通过搜狗微信搜索这类公开索引，按“公众号名 + 关键词”召回候选文章。搜狗微信搜索目前仍提供公众号与文章内容搜索入口。(weixin.sogou.com)
路线 B：网页搜索补召回
普通搜索引擎也能补到一部分 site:mp.weixin.qq.com 的文章页。
路线 C：授权数据源
如果用户提供的是自有公众号，直接走授权接口，读取草稿箱、已发布记录、素材等。公开资料显示，公众号开发链路里确有草稿列表与发布记录相关能力。(阿里云帮助中心)
第 3 层：正文解析层
拿到候选文章链接后，做统一解析：
抽取字段：
标题
作者
公众号名
发布时间
原文 URL
封面图
摘要
正文纯文本
标签词
是否原创
是否含转载声明
文章指纹 hash
这里要注意：
不要把 parser 和 source 强绑定
不同来源可能给你：
搜索结果跳转链接
原始
mp.weixin.qq.com/s?...镜像页
第三方 API 返回的 markdown/html
所以解析器要做成适配器模式。
第 4 层：10 万+ 判定层
这是关键。
“10 万+”这件事，很多时候你拿不到官方精确阅读数。所以 skill 最好设计成两档结果：
档位 1：精确判定
仅在你有可靠热度字段来源时输出：
is_100k_plus = trueconfidence = high
档位 2：近似判定
没有精确阅读数时，用代理信号判断：
搜索结果热度标签
第三方数据源返回的阅读等级
转发扩散量
收藏/在看/评论线索
被多次转载引用
然后输出：
is_100k_plus = likely_trueconfidence = medium
也就是说，不要把产品设计成“假装自己一定知道真实阅读数”，而要设计成：
“精确爆文识别 + 概率型爆文发现”
这比纯技术导向更产品化。
四、最佳落地技术方案
我最推荐的实现方式
Skill 结构
skills/ wechat_hot_article_finder/ skill.yaml README.md src/ main.py sources/ sogou_weixin.py web_search.py official_account_api.py parsers/ mp_article_parser.py services/ recall_service.py dedupe_service.py scoring_service.py storage_service.py models/ article.py query.py
核心流水线
用户指定公众号 ↓ 标准化公众号名称 ↓ 多源召回候选文章 ↓ 文章链接清洗与去重 ↓ 抓取并解析正文 ↓ 热度判定（精确 / 近似） ↓ 按时间、热度、相关性排序 ↓ 输出结构化结果
最关键的 4 个模块
1）RecallService
负责多源召回，不直接依赖某一个站点。
2）MpArticleParser
只负责把文章页变成结构化数据。
3）ScoringService
负责判断：
是否是指定公众号
是否属于目标时间段
是否接近 10 万+
是否与关键词相关
4）StorageService
存：
原始 HTML
正文纯文本
元数据
指纹 hash
抓取时间
来源渠道
置信度
五、我建议你这样定义输出
输出不要只给文章链接，应该给成一个“可继续被 AI 调用”的结构：
{
"account_name": "某某公众号",
"query_time": "2026-04-06T10:00:00+09:00",
"items": [
{
"title": "文章标题",
"publish_time": "2026-03-12 08:30:00",
"author": "某某",
"source_url": "https://mp.weixin.qq.com/...",
"content_text": "正文摘要或全文",
"is_100k_plus": true,
"confidence": "high",
"evidence": ["来源热度标记", "第三方统计结果", "搜索热度信号"],
"fingerprint": "sha256:xxxxx"
}
]
}这样你后面就可以继续接第二个 skill：
爆文标题分析
爆文结构拆解
爆文改写
爆文选题提炼
爆文情绪与传播机制归因
六、如果你问我“到底选哪一条路最优”
我给你的最终建议是：
方案一：商业可用、最稳
做“指定公众号爆文发现 Skill”，底层采用“搜索索引召回 + 原文解析 + 热度判定”。
适合：
分析竞争对手
做内容选题库
做爆文归档
做行业情报监测
这是我认为你当前最应该做的版本。
方案二：权限内最强
如果抓的是你自己的公众号，就加上官方授权接口通道。
这样你既能拿：
草稿
发布记录
已授权素材
又能把外部公开爆文一起统一归档。官方开发链路本身支持 access_token、草稿箱、发布能力等能力，适合账号内内容管理。(阿里云帮助中心)
方案三：不推荐作为主方案
浏览器自动化硬抓对方公众号历史页。
原因就一句话：
能跑，但不适合做成长期可复用的 skills 产品。
七、从产品经理角度，我建议你这样取舍
最优先做 MVP
第一版就做这 5 个功能：
1. 指定公众号
2. 指定时间范围
3. 召回相关文章
4. 识别疑似 10 万+
5. 输出结构化爆文清单
先别一上来做：
反爬对抗
登录态复用
批量几百号监控
全平台爆文聚类
多线程大规模采集
因为那会把项目迅速做重。
八、你这个 skill 的最佳描述文案
你可以直接这么定义：
这是一个“公众号爆文发现与归档”Skill。 输入指定公众号名称、时间范围和关键词后，Skill 会从公开可访问的索引与授权数据源中召回文章候选集，解析原文内容，识别其中的 10 万+ 或高热度文章，并输出结构化爆文清单，供后续选题分析、内容拆解、竞品监测和知识库归档使用。
九、我给你的最终结论
最佳实现方案一句话版
如果是自有号：官方授权接口为主。
如果是他人号：搜索索引召回 + 原文解析 + 热度判定为主。
不要把“硬爬后台或反爬对抗”做成主架构。
这是目前在稳定性、可维护性、可产品化、合规性之间最平衡的方案。(weixin.sogou.com)
你要的话，我下一步可以直接给你：
1）这个 skill 的完整目录结构
2）skill.yaml
3）Python 版 MVP 代码骨架
4）OpenClaw 可直接接入的实现说明
发表评论: