You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
wx.sstbc.com/doc/业界动态-爬虫与AI方案探讨.md

17 KiB

业界动态解决方案探讨:爬虫与 AI 技术方案

一、需求与目标

核心需求:定时爬取、分析指定公众号与网站的文章,将内容纳入系统供内部参考,形成可检索、可分析的「业界动态」信息库。

目标

  • 自动采集:按计划抓取指定公众号、网站的最新文章
  • 智能分析:用 AI 对文章做摘要、分类、关键词提取、趋势判断
  • 系统沉淀:结构化入库,支持检索、订阅、报表与决策参考

二、方案可行性结论

结论可以通过爬虫 + AI 实现定时爬取与分析,但公众号与普通网站在实现难度和合规性上差异较大,需分场景设计。

数据源类型 技术可行性 主要难点与约束
普通网站/博客 反爬、频率控制、版权
微信公众号文章 中~高 无公开 API可通过后台「查找文章」接口需自有订阅号

三、技术方案概览

3.1 整体流程

[定时任务] → [爬虫采集] → [清洗与去重] → [AI 分析] → [入库与索引] → [系统展示/检索]
                ↑                              ↑
         公众号 / 网站                   摘要、分类、标签、趋势

3.2 爬虫技术方案

3.2.0 借助 AI 智能获取「只想要的内容」

可以。在爬取网站时,用 AI 参与「抓什么、取哪块」,能减少为每个站点写死规则,并只保留真正需要的内容。

思路 做法 适用场景
AI 辅助正文/字段提取 爬虫先拿到整页 HTML或简化后的 DOM/文本),把「页面片段 + 需求描述」交给大模型,用自然语言说明要提取的字段(如:标题、正文、发布时间、作者)。由 AI 直接返回结构化结果,或指出对应区块的语义描述,再映射到 DOM。 站点多、页面结构各异,不想为每个站维护 XPath/CSS
AI 判断「是否想要」 先抓列表页或整页文本,对每个链接/段落用 AI 做一次相关性判断(如:是否属于「业界动态」、是否与指定主题相关)。只对判定为「想要」的链接再请求正文,或只入库通过筛选的段落。 目标站内容杂,需要过滤噪音、只留相关文章
AI 生成/推荐选择器 给 AI 一张样例页的 HTML 或 DOM 树摘要,让 AI 输出「标题 / 正文 / 时间」的 XPath 或 CSS 选择器,人工审核后写入配置,爬虫仍按传统方式用选择器抓取。 希望减少手写规则,但保留规则可审、可改、可回滚

实现要点

  • 输入控制:整页 HTML 可能超长,可先做正文预提取(如用 readability、trafilatura 等库)再送 AI或只送主要区块的 HTML 片段,以节省 token、提高稳定性。
  • 输出约定:与 AI 约定好输出格式(如 JSONtitlebodypublish_time),便于直接落库;必要时加一层校验或回退逻辑(如解析失败时 fallback 到规则或整页存储)。
  • 成本与延迟:每条页面调用一次 AI 会带来时延与费用,可对「新站点/新模板」用 AI 抽取,对已稳定站点用缓存的选择器或规则,或仅对列表页用 AI 做「要不要抓」的过滤。

这样即可在爬取阶段就借助 AI只获取想要的内容减少无关信息和后续清洗成本。


1普通网站 / 博客

  • 方式一:自建爬虫
    • 使用 ScrapyPlaywrightPuppeteer 抓取目标站点
    • 针对不同站点写解析规则XPath/CSS/正则),提取标题、正文、时间、作者等
    • 建议:遵守 robots.txt,控制请求频率(如 15 秒/页),设置合理 User-Agent

1.1Vue / React 等 SPA能爬取到动态数据吗

可以。Vue、React、Angular 等前端框架做的是单页应用SPA:首屏 HTML 往往只有一个壳,正文、列表等是页面加载后由 JavaScript 请求接口、再渲染到 DOM 的。用只发 HTTP 请求、不执行 JS 的爬虫(如仅用 requests + 解析 HTML拿到的多是空壳拿不到动态渲染出来的内容。要拿到动态数据,有两种常见做法:

方式 做法 优点 注意点
无头浏览器 PlaywrightPuppeteerSelenium 打开页面,等待 JS 执行、接口返回、DOM 渲染完成,再对当前 DOM 做选择器提取(或把最终 HTML 交给 AI 抽取)。 与用户看到的完全一致,不关心前端用的什么框架。 耗资源、较慢,需设置合理的等待条件(如等某元素出现、或固定延迟),并控制并发。
直接请求接口 在浏览器开发者工具里看该 Vue 站点的「Network」文章列表、正文往往来自某个 REST 或 GraphQL 接口。用爬虫直接请求这些接口,拿到 JSON再解析入库。 速度快、省资源、数据已结构化。 需人工分析接口格式与鉴权(如 token、cookie接口变更或鉴权加强时需维护。

建议:目标站若是 Vue/React 等 SPA优先看能否抓到其数据接口并直接请求;若接口难找、鉴权复杂或经常变,再用 Playwright/Puppeteer 做无头渲染后从 DOM 里取动态内容。二者都可与前述「AI 智能提取只想要的内容」结合使用。

2微信公众号

微信公众号没有官方开放的文章列表/正文 API。采用公众号后台「查找文章」接口获取文章数据:

  • 思路:拥有一个微信个人订阅号,登录 微信公众平台 后,利用后台「新建图文素材」里的超链接 → 查找文章功能:输入目标公众号名称即可拉取该号的历史文章列表。该能力对应后台的搜索与文章列表接口,可用于程序化获取最新及历史数据。
  • 操作路径:登录公众号 → 管理 → 素材管理 → 新建图文素材 → 工具栏「超链接」→「查找文章」→ 输入要查找的公众号。
  • 技术实现要点(供自建爬虫参考):
    1. 登录与 Cookie:用 Selenium/Playwright 等打开 https://mp.weixin.qq.com/,完成扫码或账号密码登录,将登录后的 cookies 持久化(如保存到本地),后续请求携带。
    2. 获取 token:访问首页后,从跳转 URL 中解析出 token=(\d+),后续接口均需携带该 token。
    3. 搜索公众号得到 fakeid:请求 https://mp.weixin.qq.com/cgi-bin/searchbiz?,参数含 action=search_bizquery=目标公众号名token 等,从返回 JSON 的 list[0].fakeid 得到该公众号的 fakeid
    4. 分页拉取文章列表:请求 https://mp.weixin.qq.com/cgi-bin/appmsg?,参数含 action=list_exfakeidbegin(分页偏移,每页 5 条递增)、count=5token 等,可循环翻页直至取完;返回中有标题、链接、摘要等,可直接入库或再抓正文。
  • 优点:可拉取更多甚至全部历史文章,数据来自微信官方后台,结构稳定、易解析。
  • 注意点:依赖自有订阅号登录态,需保管好 Cookie/账号安全;请求频率需控制(如分页间隔 25 秒),避免触发后台风控;仅限内部使用,遵守平台服务条款。
  • 参考python 之抓取微信公众号文章系列 2 - 腾讯云开发者社区(含个人公众号接口抓取思路与示例)。

3.3 AI 分析能力

在文章入库前/后接入 AI实现「从原文到可参考信息」的转化

能力 说明 典型实现
摘要生成 一段话概括文章要点 大模型 API如 GPT/国产大模型)
分类/打标签 行业、主题、业务线 提示词 + 分类接口或 embedding
关键词提取 便于检索与聚合 NLP 关键词 / 大模型
情感/倾向 正面/中性/负面等 情感分析模型或大模型
与内部关联 与本单位业务、项目的关联 自定义 prompt + 知识库
趋势与周报 按主题聚合、生成周报 定时任务 + 大模型汇总

技术选型建议

  • 摘要/分类/标签:调用 OpenAI API通义千问文心一言智谱
  • 若需私有化:可部署 LlamaChatGLMQwen 等,或使用支持私有化的大模型服务

3.4 系统架构示意

┌─────────────────────────────────────────────────────────────────┐
│                        调度层(定时任务)                          │
│  Cron / Celery Beat / 云函数 等,按日/周触发采集与分析             │
└─────────────────────────────────────────────────────────────────┘
                                    │
                                    ▼
┌─────────────────────────────────────────────────────────────────┐
│                        采集层                                     │
│  网站爬虫(Scrapy/Playwright)  │  公众号(后台「查找文章」接口)           │
└─────────────────────────────────────────────────────────────────┘
                                    │
                                    ▼
┌─────────────────────────────────────────────────────────────────┐
│                        清洗与去重                                 │
│  正文提取、时间归一化、URL/标题去重、简单反作弊检测                 │
└─────────────────────────────────────────────────────────────────┘
                                    │
                                    ▼
┌─────────────────────────────────────────────────────────────────┐
│                        AI 分析层                                  │
│  摘要 | 分类 | 关键词 | 情感 | 与业务关联度                        │
└─────────────────────────────────────────────────────────────────┘
                                    │
                                    ▼
┌─────────────────────────────────────────────────────────────────┐
│                        存储与检索                                 │
│  数据库(MySQL/PostgreSQL) + 全文检索(Elasticsearch/Meilisearch)   │
└─────────────────────────────────────────────────────────────────┘
                                    │
                                    ▼
┌─────────────────────────────────────────────────────────────────┐
│                        应用层                                     │
│  业界动态列表、检索、订阅、看板、周报/月报导出                     │
└─────────────────────────────────────────────────────────────────┘

四、实现要点与注意事项

4.1 合规与版权

  • 版权:爬取内容仅供内部参考,不对外全文再发表;建议在系统内标注来源、链接,并控制传播范围
  • ** robots.txt**:遵守目标站点的 robots 规则
  • 服务条款:注意目标站与公众号平台的服务条款,避免违反约定用途
  • 个人信息:若抓取到评论、作者信息等,需符合《个人信息保护法》等要求(脱敏或取得同意)

4.2 反爬与稳定性

  • 控制访问频率,避免对目标站造成压力
  • 必要时使用代理池、更换 User-Agent但需权衡合规与伦理
  • 页面结构变更时,解析规则需可配置、可快速调整(如规则配置表 + 版本管理)

4.3 公众号特殊说明

  • 通过**公众号后台「查找文章」**所对应的接口获取目标号的文章列表(见 3.2 节),再抓正文与做 AI 分析;需保管好订阅号登录态并控制请求频率,仅限内部使用、遵守平台服务条款。

4.4 成本粗算

  • 爬虫:开发与维护人力;若用云主机/代理,有少量机器与带宽成本
  • AI:按调用量计费(摘要/分类等),可先对部分文章采样,再全量开启
  • 第三方数据:若目标站有数据 API如新榜等可按条或按订阅量采购公众号采用后台「查找文章」接口则无此项费用

五、推荐实施路径

阶段一MVP最小可行

  1. 先做网站 + 链接录入
    • 支持「添加目标网站 + 简单爬虫规则」或「手动/半自动录入文章 URL」
    • 爬虫只抓正文落库标题、来源、URL、正文、抓取时间
  2. 接入一种 AI
    • 仅做「摘要 + 35 个标签」,便于快速浏览与检索
  3. 简单列表与检索
    • 按时间、来源、标签筛选,关键词全文检索

阶段二:增强

  1. 增加分类、关键词、情感等 AI 能力
  2. 引入公众号:采用后台「查找文章」接口(需自有个人订阅号)获取目标号文章列表,再抓正文与做 AI 分析
  3. 增加订阅与通知(如按标签/来源推送日报、周报)

阶段三:深度用起来

  1. 趋势与报表:按主题/行业聚合,自动生成周报/月报
  2. 与业务关联:用 AI 判断文章与本单位业务、项目的相关度,并打标
  3. 对爬虫规则、AI 提示词做配置化与版本管理,便于扩展更多公众号与站点

六、小结

问题 结论
能否用爬虫+AI 做业界动态? 可以,技术上可行,需区分「网站」与「公众号」分别设计。
爬取时能否借 AI 只取想要内容? 可以AI 辅助字段提取、AI 过滤相关性、或 AI 生成选择器再人工审核。
Vue/SPA 动态站能爬吗? 可以用无头浏览器Playwright/Puppeteer等渲染后再取 DOM或直接请求前端调用的数据接口。
公众号如何获取? 公众号后台「查找文章」接口:自有个人订阅号登录后,通过后台接口获取目标号文章列表,再抓正文与做 AI 分析。
直接请求接口 vs 无头浏览器? 直接请求接口易触发风控;无头/有头浏览器更接近真人,相对更顺利,但仍需控频与反检测,无头并非万能。
如何发挥 AI 价值? 摘要、分类、标签、关键词、趋势汇总、与业务关联度分析等。
主要风险 版权与合规、公众号来源不稳定、反爬与维护成本。

将上述方案落地为「定时爬取 + 清洗去重 + AI 分析 + 入库检索」的闭环,即可在系统内形成可持续更新的业界动态参考库;实施时建议从网站与少量公众号试点,再逐步扩大数据源与 AI 能力。


文档版本v1.0 | 建议放置于 doc 目录,供项目评审与开发参考