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

This file contains ambiguous Unicode characters!

This file contains ambiguous Unicode characters that may be confused with others in your current locale. If your use case is intentional and legitimate, you can safely ignore this warning. Use the Escape button to highlight these characters.

# 业界动态解决方案探讨:爬虫与 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 目录,供项目评审与开发参考*