最后更新：2026 年 3 月 · 源码：info-pipeline
实时情报推送
一个 Python 管道，从 7 个平台拉取 AI 和技术内容，应用关键词过滤和相关性评分，去重后生成统一的 JSON/Markdown 报告供下游智能体使用。
是什么
info-pipeline 将来自 7 个异构平台的 AI 和技术内容聚合为单一的已评分、已去重的信息流。每个平台都有一个专用采集器，将其输出规范化为通用模式。过滤/评分阶段应用全局关键词匹配和相关性评分（0-100），然后写入报告。输出为机器可读的 JSON 以及人类可读的 Markdown 报告。
为什么
跟踪 AI 发展需要同时监控许多异构来源：GitHub 的新仓库、Hacker News 和 Reddit 的社区讨论、YouTube 的研究解释、Product Hunt 的新工具、Twitter/X 的早期信号，以及英语来源遗漏的中文平台内容。跨 7 个平台手动执行这些操作既耗时又不一致。
现有的聚合器（RSS 阅读器、Feedly 等）生成人类可读的信息流，但不是机器可读的结构化数据。AI 研究智能体需要一个已评分、已去重、已规范化的信息流来查询和推理——而不是一个待阅读链接列表。此管道以专为智能体使用设计的格式提供该信息流。
架构
管道有四个阶段：
[采集器 — 并行运行]
→ GitHub Trending、Hacker News、Reddit、YouTube、
Product Hunt、X/Twitter、中文平台（通过 MCP）
→ 每个都规范化为统一模式
[过滤 / 评分]
→ 对全局关键词列表进行关键词匹配
→ 相关性评分 0-100（关键词密度 + 平台信号）
→ 通过 URL，然后通过标题相似度去重
[报告生成]
→ 统一 JSON（所有条目）
→ Markdown 报告（前 N 个条目） 数据来源：
| 平台 | 语言 | 备注 |
|---|---|---|
| GitHub Trending | EN | 按过去 N 天的 star/fork 过滤主题的仓库 |
| Hacker News | EN | 热门故事，按最低分数过滤 |
| EN | 多个 AI 子版块——不需要 API 密钥 | |
| YouTube | EN | 通过 Data API v3 配置频道播放列表 |
| Product Hunt | EN | 通过 GraphQL API 获取每日新产品 |
| X / Twitter | EN | 关键词搜索——需要 Basic API 层级（低频） |
| 中文平台 | ZH | 知乎、36kr、掘金、少数派、InfoQ、Bilibili 通过 trends-hub MCP |
代码结构：
| 组件 | 职责 |
|---|---|
| collectors/base.py | BaseCollector，包含通用的获取、重试和速率限制逻辑 |
| collectors/*.py | 每个平台一个文件——每个都继承自 BaseCollector |
| collectors/__init__.py | ALL_COLLECTORS 注册表——注册所有启用的采集器 |
| filters/scorer.py | 关键词过滤、相关性评分（0-100）、去重 |
| main.py | 入口点——协调采集器运行和报告生成 |
所有来源的每个条目共享相同的 JSON 模式：
{
"title": "文章 / 项目标题",
"url": "https://...",
"source": "github",
"score": 85,
"published_at": "2026-02-18T10:00:00Z",
"summary": "简短描述或摘录",
"tags": ["llm", "open-source"]
} 关键设计决策
统一输出模式——在源头规范化
每个采集器的工作是在离开采集器之前将其平台的输出规范化为通用模式。评分器和报告生成器只处理通用模式——它们没有平台特定的逻辑。这使得添加新来源只需实现一个具有单一 fetch() 方法的新类。
配置驱动，而非代码驱动
关键词、平台参数和来源选择都存储在 YAML 配置文件中。调整信息流不需要更改代码。当快速迭代要关注的主题或调整平台特定的阈值（如最低 HN 分数）时，这很重要。
缺少 API 密钥时优雅降级
没有配置 API 密钥的采集器会带警告跳过——而不是报错。管道仍然从已配置的来源生成输出。这意味着管道可以部分运行（例如只有 GitHub + HN），而不需要所有七个 API 凭据都存在。
中文平台使用 MCP——避免直接爬取
中文科技平台（知乎、36kr、掘金）有复杂的反爬虫措施，也没有官方的英文 API。trends-hub MCP 服务单独处理这些来源；管道将其作为工具调用，而不是实现需要持续维护的平台特定爬虫。
如何自行构建
1. 首先定义统一模式
在编写任何采集器之前，定义所有采集器必须生成的输出模式。最少有用的字段是：title、url、source、score、published_at、summary。之后添加字段需要更新每个采集器。
2. 实现带重试和速率限制逻辑的 BaseCollector
速率限制和错误重试是每个平台采集器都需要的。将它们放在基类中。每个具体采集器只需要实现如何获取其平台的数据以及如何将其映射到通用模式——而不是如何处理 HTTP 错误或速率限制。
3. 保持评分简单——关键词密度 + 平台权重
基于关键词匹配数量（按文本长度归一化）加上平台特定参与信号（GitHub star、HN 分数、Reddit 点赞数）的 0-100 分已经足够。不要添加基于 LLM 的评分——对于大多数用例来说，它增加了延迟和成本，但质量提升不成比例。
4. 先通过 URL 去重，再通过标题相似度去重
同一个故事经常出现在多个平台上。URL 去重捕获完全重复的内容。标题相似度（简单的词重叠就足够了）捕获同一文章以略有不同的 URL 或标题跨平台链接的情况。
5. Twitter API 速率限制是真实约束
Basic Twitter/X API 层级有严格的每月请求限制。保持 max_results 较低（每次运行 10-15 个），并且运行采集器的频率低于其他采集器。构建采集器时要能优雅地失败，并且在触达速率限制时不阻塞整个管道运行。
常见问题
可以只启用部分来源运行吗？
可以。没有配置 API 密钥的来源会带警告跳过，而不是导致整个运行失败。你也可以直接运行特定采集器。Reddit 和 Hacker News 不需要 API 密钥，开箱即用。
相关性评分是如何工作的？
评分器检查配置的全局关键词中有多少出现在标题和摘要中。不匹配任何关键词的条目会被过滤掉；匹配会将分数提升至 100。原始平台参与指标（star 数、HN 分数、点赞数）也会影响评分。
中文平台的 trends-hub MCP 是什么？
中文平台采集器调用 trends-hub 服务（一个独立的开源项目）的 MCP 工具来获取知乎热榜、36kr、掘金等内容。该服务必须在本地运行，中文平台来源才能工作。
Authors: Qiushi Wu & Orange 🍊