# 多平台资讯自动化收集项目设计方案

## 1. 项目定位

本项目用于自动化收集闲鱼、小红书、X（Twitter）和 Reddit 等平台上的公开资讯、商品线索、用户讨论和趋势信号，并把它们转化为可检索、可分析、可通知的结构化数据。

推荐把项目定位为“合规的数据聚合与情报工作台”，而不是简单爬虫。这样可以在架构上兼顾平台规则、账号安全、数据质量、后续分析和长期可维护性。

## 2. 典型使用场景

### 2.1 商机/需求发现

- 监控用户在小红书、Reddit、X 上表达的痛点、购买意向、替代方案和吐槽。
- 监控闲鱼上的二手商品价格、上新频率、成交线索和热门品类。
- 根据关键词和语义标签发现潜在需求，例如“求推荐”“避雷”“平替”“哪里买”“转让”。

### 2.2 竞品与舆情监测

- 跟踪品牌名、竞品名、产品型号、活动名称和核心人物。
- 统计不同平台上的声量、情绪倾向、传播节点和高互动内容。
- 自动生成日报、周报和异常波动提醒。

### 2.3 选品与内容选题

- 从闲鱼价格变化、小红书种草内容、X 热点讨论和 Reddit 社区反馈中提炼趋势。
- 建立“关键词 - 平台 - 热度 - 情绪 - 机会评分”的选题或选品看板。

## 3. 设计原则

1. **合规优先**：优先使用官方 API、授权导出、RSS、公开数据集或人工上传数据；不绕过验证码、登录风控、隐私设置和付费墙。
2. **平台适配解耦**：每个平台独立 Connector，统一输出标准数据模型，避免平台变化影响核心系统。
3. **增量采集**：用游标、时间戳、内容 ID 或查询窗口做增量更新，减少重复请求。
4. **可观测性**：所有采集任务要记录请求量、成功率、失败原因、延迟、去重率和入库量。
5. **人工可控**：高风险操作、平台授权、敏感关键词和批量导出都应有人工确认或权限控制。
6. **先小后大**：先打通一个稳定数据源的 MVP，再逐步扩展到多平台、多语言、多模型分析。

## 4. 总体架构

```text
          ┌────────────────────┐
          │  采集配置/规则中心 │
          └─────────┬──────────┘
                    │
┌───────────────────▼───────────────────┐
│              调度与任务队列             │
│ cron / queue / retry / rate limit       │
└───────┬────────────┬────────────┬───────┘
        │            │            │
┌───────▼──────┐ ┌───▼──────┐ ┌───▼──────┐
│ X Connector  │ │ Reddit   │ │ 其他平台  │
│ API / export │ │ API      │ │ 授权数据  │
└───────┬──────┘ └───┬──────┘ └───┬──────┘
        │            │            │
        └────────────▼────────────┘
                原始数据层 Raw Store
                    │
        ┌───────────▼───────────┐
        │ 清洗/标准化/去重/质检  │
        └───────────┬───────────┘
                    │
        ┌───────────▼───────────┐
        │ 结构化数据库 + 搜索索引 │
        └───────┬─────────┬─────┘
                │         │
        ┌───────▼───┐ ┌───▼────────┐
        │ 分析评分层 │ │ 通知与报表层 │
        └───────┬───┘ └───┬────────┘
                │         │
        ┌───────▼─────────▼───────┐
        │ Web Dashboard / API / Bot │
        └──────────────────────────┘
```

## 5. 模块划分

### 5.1 采集配置中心

用于管理所有监控规则，建议包含：

- 平台：X、Reddit、闲鱼、小红书等。
- 查询条件：关键词、排除词、语言、地区、社区、账号、价格区间、发布时间窗口。
- 采集频率：实时、每 10 分钟、每小时、每天。
- 优先级：高优先级规则先执行，并拥有更严格的通知策略。
- 合规状态：是否已确认平台规则、授权方式、频率限制和数据保留策略。

### 5.2 平台 Connector

每个平台实现独立 Connector，负责认证、请求、分页、限速、错误处理和原始数据解析。

建议接口：

```text
Connector.search(rule) -> List[RawItem]
Connector.fetch_detail(item_id) -> RawItemDetail
Connector.normalize(raw_item) -> NormalizedItem
Connector.health_check() -> ConnectorStatus
```

平台建议：

- **X**：优先使用官方 API 或授权数据服务，适合关键词、账号、列表和话题监控。
- **Reddit**：优先使用官方 API，适合 subreddit、关键词、帖子和评论监控。
- **闲鱼**：如果没有官方授权接口，建议先从人工导出、商家后台授权数据或低频人工辅助采集开始，不建议绕过平台风控。
- **小红书**：如果没有官方授权接口，建议以合规的数据合作、人工整理或品牌账号自有数据为主，不建议绕过登录、验证码或反自动化机制。

### 5.3 原始数据层

保存每次采集得到的原始响应，便于回溯、重新解析和排查问题。

建议字段：

- `source_platform`
- `source_rule_id`
- `source_item_id`
- `request_url_or_query`
- `raw_payload`
- `fetched_at`
- `fetch_status`
- `schema_version`

### 5.4 标准化数据层

把不同平台内容统一为标准结构：

```text
Item
- id
- platform
- source_item_id
- url
- title
- body
- author_id
- author_name
- published_at
- fetched_at
- language
- media_urls
- metrics: likes/comments/shares/views/upvotes
- tags
- matched_rules
- content_hash
- dedupe_key
```

针对闲鱼这类商品信息，可扩展：

```text
CommerceItem
- price
- currency
- location
- condition
- category
- seller_id
- seller_rating
- availability_status
```

### 5.5 清洗、去重与质量控制

建议处理流程：

1. HTML/Markdown/emoji/链接清洗。
2. 语言识别和文本规范化。
3. 基于 `platform + source_item_id` 的强去重。
4. 基于标题、正文、图片、URL 的相似去重。
5. 垃圾内容、广告、机器人内容、低相关内容过滤。
6. 低置信度数据进入待审核队列。

### 5.6 分析与评分

第一阶段可以使用规则评分，后续再引入 LLM 或传统 NLP：

- 关键词命中分。
- 互动量分。
- 新鲜度分。
- 作者可信度分。
- 情绪/意图分。
- 商业价值分。
- 风险分。

示例评分：

```text
opportunity_score = keyword_score * 0.25
                  + engagement_score * 0.20
                  + freshness_score * 0.15
                  + intent_score * 0.25
                  + author_score * 0.15
```

### 5.7 通知与报表

建议支持：

- 即时告警：飞书、企业微信、Slack、Telegram、邮件。
- 每日摘要：新增线索、高分内容、异常波动、待处理事项。
- 每周报告：平台趋势、关键词趋势、竞品趋势、机会列表。
- 导出能力：CSV、Excel、JSON、Notion/Airtable 同步。

### 5.8 Web Dashboard

建议页面：

- 规则管理页。
- 采集任务状态页。
- 线索列表页。
- 内容详情页。
- 趋势图表页。
- 通知配置页。
- 合规与授权状态页。

## 6. 推荐技术栈

### 6.1 MVP 技术栈

- 后端：Python + FastAPI。
- 任务队列：Celery/RQ + Redis，或轻量级 APScheduler。
- 数据库：PostgreSQL。
- 搜索：PostgreSQL Full Text Search，后续再升级 Elasticsearch/OpenSearch。
- 前端：Next.js 或简单 Admin UI。
- 部署：Docker Compose。

### 6.2 成熟阶段技术栈

- 编排：Airflow、Dagster 或 Temporal。
- 消息队列：Kafka、Redpanda 或 RabbitMQ。
- 搜索分析：OpenSearch/Elasticsearch + ClickHouse。
- 向量检索：pgvector、Qdrant 或 Milvus。
- 监控：Prometheus + Grafana + Loki。

## 7. 数据流设计

1. 用户创建监控规则。
2. 调度器根据频率生成采集任务。
3. Connector 按规则请求平台或读取授权数据。
4. 原始结果写入 Raw Store。
5. 标准化服务转换为统一 Item。
6. 去重服务判断新增、更新或忽略。
7. 分析服务生成标签、摘要、情绪和机会评分。
8. 高分或异常内容触发通知。
9. Dashboard 展示搜索、筛选、趋势和报表。

## 8. 权限与安全

- 平台令牌加密存储，避免写入代码仓库。
- API Key 使用环境变量或密钥管理服务。
- 操作日志记录规则创建、导出、删除和权限变更。
- 对敏感关键词、个人信息导出和批量下载设置权限控制。
- 设置数据保留周期，过期数据自动归档或删除。

## 9. 质量指标

建议从第一天就记录这些指标：

- 每个平台采集成功率。
- 每个规则每日新增内容数。
- 去重率。
- 平均采集延迟。
- 告警命中率。
- 人工标注的有效线索比例。
- 高分线索转化率。
- Connector 错误类型分布。

## 10. 第一个 MVP 建议

为了尽快形成闭环，建议第一版只做：

1. 选择 Reddit 或 X 作为第一个官方 API 数据源。
2. 支持关键词规则和社区/账号规则。
3. 定时采集并写入 PostgreSQL。
4. 实现基础去重和搜索。
5. 实现简单线索评分。
6. 每天自动发送摘要邮件或飞书消息。
7. Dashboard 只做规则列表、内容列表和任务状态。

完成 MVP 后，再决定是否接入闲鱼、小红书的合规数据来源。