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

217 lines
17 KiB

1 month ago
# 业界动态解决方案探讨:爬虫与 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 约定好输出格式(如 JSON`title`、`body`、`publish_time`),便于直接落库;必要时加一层校验或回退逻辑(如解析失败时 fallback 到规则或整页存储)。
- **成本与延迟**:每条页面调用一次 AI 会带来时延与费用,可对「新站点/新模板」用 AI 抽取,对已稳定站点用缓存的选择器或规则,或仅对列表页用 AI 做「要不要抓」的过滤。
这样即可在**爬取阶段**就借助 AI只获取想要的内容减少无关信息和后续清洗成本。
---
#### 1普通网站 / 博客
- **方式一:自建爬虫**
- 使用 **Scrapy**、**Playwright** 或 **Puppeteer** 抓取目标站点
- 针对不同站点写解析规则XPath/CSS/正则),提取标题、正文、时间、作者等
- 建议:遵守 `robots.txt`,控制请求频率(如 15 秒/页),设置合理 User-Agent
#### 1.1Vue / React 等 SPA能爬取到动态数据吗
**可以**。Vue、React、Angular 等前端框架做的是**单页应用SPA**:首屏 HTML 往往只有一个壳,正文、列表等是页面加载后由 JavaScript 请求接口、再渲染到 DOM 的。用只发 HTTP 请求、不执行 JS 的爬虫(如仅用 requests + 解析 HTML拿到的多是空壳**拿不到动态渲染出来的内容**。要拿到动态数据,有两种常见做法:
| 方式 | 做法 | 优点 | 注意点 |
|------|------|------|--------|
| **无头浏览器** | 用 **Playwright**、**Puppeteer** 或 **Selenium** 打开页面,等待 JS 执行、接口返回、DOM 渲染完成,再对当前 DOM 做选择器提取(或把最终 HTML 交给 AI 抽取)。 | 与用户看到的完全一致,不关心前端用的什么框架。 | 耗资源、较慢,需设置合理的等待条件(如等某元素出现、或固定延迟),并控制并发。 |
| **直接请求接口** | 在浏览器开发者工具里看该 Vue 站点的「Network」文章列表、正文往往来自某个 REST 或 GraphQL 接口。用爬虫**直接请求这些接口**,拿到 JSON再解析入库。 | 速度快、省资源、数据已结构化。 | 需人工分析接口格式与鉴权(如 token、cookie接口变更或鉴权加强时需维护。 |
**建议**:目标站若是 Vue/React 等 SPA优先看能否抓到其**数据接口**并直接请求;若接口难找、鉴权复杂或经常变,再用 **Playwright/Puppeteer** 做无头渲染后从 DOM 里取动态内容。二者都可与前述「AI 智能提取只想要的内容」结合使用。
#### 2微信公众号
微信公众号**没有官方开放的文章列表/正文 API**。采用**公众号后台「查找文章」接口**获取文章数据:
- **思路**:拥有一个微信**个人订阅号**,登录 [微信公众平台](https://mp.weixin.qq.com/) 后,利用后台「新建图文素材」里的**超链接 → 查找文章**功能:输入目标公众号名称即可拉取该号的**历史文章列表**。该能力对应后台的搜索与文章列表接口,可用于程序化获取最新及历史数据。
- **操作路径**:登录公众号 → 管理 → 素材管理 → 新建图文素材 → 工具栏「超链接」→「查找文章」→ 输入要查找的公众号。
- **技术实现要点**(供自建爬虫参考):
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_biz`、`query=目标公众号名`、`token` 等,从返回 JSON 的 `list[0].fakeid` 得到该公众号的 **fakeid**
4. **分页拉取文章列表**:请求 `https://mp.weixin.qq.com/cgi-bin/appmsg?`,参数含 `action=list_ex`、`fakeid`、`begin`(分页偏移,每页 5 条递增)、`count=5`、`token` 等,可循环翻页直至取完;返回中有标题、链接、摘要等,可直接入库或再抓正文。
- **优点**:可拉取**更多甚至全部历史文章**,数据来自微信官方后台,结构稳定、易解析。
- **注意点**:依赖自有订阅号登录态,需保管好 Cookie/账号安全;请求频率需控制(如分页间隔 25 秒),避免触发后台风控;仅限内部使用,遵守平台服务条款。
- **参考**[python 之抓取微信公众号文章系列 2 - 腾讯云开发者社区](https://cloud.tencent.com/developer/article/1406410)(含个人公众号接口抓取思路与示例)。
### 3.3 AI 分析能力
在文章入库前/后接入 AI实现「从原文到可参考信息」的转化
| 能力 | 说明 | 典型实现 |
|--------------|--------------------------|------------------------------|
| 摘要生成 | 一段话概括文章要点 | 大模型 API如 GPT/国产大模型)|
| 分类/打标签 | 行业、主题、业务线 | 提示词 + 分类接口或 embedding |
| 关键词提取 | 便于检索与聚合 | NLP 关键词 / 大模型 |
| 情感/倾向 | 正面/中性/负面等 | 情感分析模型或大模型 |
| 与内部关联 | 与本单位业务、项目的关联 | 自定义 prompt + 知识库 |
| 趋势与周报 | 按主题聚合、生成周报 | 定时任务 + 大模型汇总 |
**技术选型建议**
- 摘要/分类/标签:调用 **OpenAI API**、**通义千问**、**文心一言**、**智谱** 等
- 若需私有化:可部署 **Llama**、**ChatGLM**、**Qwen** 等,或使用支持私有化的大模型服务
### 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 目录,供项目评审与开发参考*