开源新闻雷达：按个人标准筛选技术资讯

Horizon 想接管的，是读新闻之前那串琐碎工作：到处找来源、筛掉低价值内容、合并重复报道，再补上背景和社区讨论，最后生成中英双语简报。它最有意思的设计，是把「什么值得读、该怎么讲」做成可配置的 profile。

对每天追 AI 动态、技术文章和开源项目的程序员，这比单纯生成摘要更贴近需求。不过，项目说明展示了完整流程，没有提供筛选准确率、运行成本或阅读效率的对照数据。功能是否齐全与简报是否好读，还需要分开判断。

同一套摘要规则，为什么不够用

新闻和工程文章，读者想拿走的东西不同。模型发布新闻需要解释影响，工程深挖则需要交代解决方案和可复用做法。如果全部套进「概括主要内容」的提示词，产物往往整齐，却未必有用。

Horizon 用 profile 承载一套可复用的编辑规则：哪些内容属于这个范围、按什么标准评分、最终写成什么样。输出可以侧重摘要、背景、解决方案或行动要点，通过 Markdown prompts 和 JSON block definitions 定义。原文表示，调整已有 profile 通常不需要改 Python。

这里要区分两层配置。profile 定义内容的处理方式；个人偏好，比如保留分数和是否合并同主题内容，放在 processing.profile_settings，而不是 profile 文件里。示例中，tech-news 使用 threshold: 7.0，并开启 topic_dedup: true。

它把「编辑标准」从一次性提示词变成了可以持续调整的配置。

来源与 profile 的关系也有三种：显式指定就直接使用；省略或设为 "auto"，由 AI 在全部可用 profiles 中匹配；设为 ["tech-news", "finance-news"]，则把匹配范围限制在这两个选项内。每条内容最终只进入一个 profile，不会天然生成多个角度的解读。

对范围清楚的订阅源，直接指定 profile 更容易检查结果；对混合主题的信息流，自动路由更灵活。但原文没有给出路由准确率，不能默认 AI 总能分对。

先筛选再补背景，才能控制简报的体积

Horizon 接入的来源包括 RSS、Hacker News、Reddit、Telegram、X、GitHub 和财经新闻。收集之后，先做分析、筛选与 profile 内去重，再为入选内容补充信息，最终按 profile 分组生成简报。

这个顺序有实际意义：没有通过筛选的内容，不必继续补背景、整理讨论。原文还支持通过网页搜索补充上下文，以及汇总社区评论。不过，它没有交代搜索如何挑选证据、遇到冲突信息怎样处理，不能把「有背景补充」直接等同于「完成事实核查」。

另一个容易被忽略的问题，是高频主题挤占版面。即使每条 AI 新闻都超过分数线，一天收到的简报也可能只剩 AI。Horizon 为此提供总条数和类别组配额：

{
  "digest": {
    "max_items": 20,
    "category_groups": {
      "ai": {
        "limit": 5,
        "categories": ["ai-news", "ai-tools", "machine-learning"]
      },
      "finance": {
        "limit": 5,
        "categories": ["finance", "business", "equities"]
      }
    },
    "default_group": "other",
    "default_group_limit": 3
  }
}

这里需要看清 categories：它来自来源配置，例如 sources.rss[].category。类别组负责分配版面，profile 负责决定内容如何处理，两者不是一回事。

这份配置将总量限制为 20 条，AI 和财经组各最多 5 条，默认组最多 3 条。配额在 profile 筛选之后、内容增强之前生效；省略 category_groups、max_items 和 default_group_limit，就不会应用这些平衡限制。它们是上限，不是必须填满的数量。

上手靠向导，运行仍要管依赖和状态

项目提供两种配置入口。运行 uv run horizon-wizard，向导会询问兴趣并生成 data/config.json；也可以复制 .env.example 与 data/config.example.json，手动填写来源和模型配置。

原文的手动示例使用 provider: "openai"、model: "gpt-4"、api_key_env: "OPENAI_API_KEY"；Gemini 示例对应 "gemini"、"gemini-2.0-flash" 和 "GOOGLE_API_KEY"。这些是配置示例，没有附带模型效果比较。符合条件的 ChatGPT 订阅用户还可选择 openai-chatgpt，通过 Sign in with ChatGPT 使用订阅，具体资格条件原文没有展开。

密钥配置有个明确边界：api_key_env 填环境变量名，真实密钥放进 .env。data/config.json 的任意字符串值还支持 ${VAR_NAME}，可用于 ai.base_url、私有 RSS 地址、webhook 地址或自定义请求头模板。

安装以源码方式为主：git clone https://github.com/Thysrael/Horizon.git 后进入目录，执行 uv sync，也可用 pip install -e .。测试依赖需额外执行 uv sync --extra dev，因为 dev 当前是可选 extra。

可选财经来源 OpenBB 使用 uv sync --extra openbb。若依赖在本机没有 wheel，原文给出的处理方式是 uv pip install --only-binary=:all: openbb openbb-benzinga。全文提取工具 trafilatura 已包含在基础安装中；twitter extra 另需 Playwright 浏览器和系统包，当前 Dockerfile 没有安装它们。Docker 因而不能直接消除所有来源的依赖问题。

运行入口是 uv run horizon [OPTIONS]，或 docker compose run --rm horizon [OPTIONS]。--data-dir 改变摘要、订阅者及默认配置所在的状态目录，--config 只改变配置文件；报告默认写入 data/summaries/，指定数据目录后则写入 <data-dir>/summaries/。

如果希望 AI 助手协助安装、配置和执行，原文提供：

npx skills add Thysrael/Horizon --skill horizon -g

注意，这条命令要求 Node.js 22.20+。Horizon 自身仍有 Python 安装流程；这不是一个纯 Node 工具。完整流水线可通过 CLI 运行，也可让助手通过 MCP 调用各阶段。

项目声明已支持 Markdown、中英双语、GitHub Pages、邮件、webhook 和微信交付。每日 GitHub Actions 模板默认禁用，需要自行配置，并重命名为 daily-summary.yml 才启用。Discord 来源、GitHub releases 和 PyPI 发布仍列在计划中，不能把 pip install -e . 理解成已经支持从 PyPI 直接安装。

我的判断

我更认可它对内容规则的拆分，而不是「AI 新闻雷达」这个包装。来源、编辑标准、个人阈值和版面配额各自可调，出了问题更容易定位：是来源太杂、评分太松，还是某个主题占满了简报。

但可配置也有维护成本。threshold: 7.0 只是示例，没有校准数据；同主题去重是否误删不同观点、社区评论是否具有代表性，原文都没给评测。模型、提示词或来源一换，结果也需要重新抽查。

与 RSS 阅读器相比，它多承担了筛选和加工，也引入了模型判断的不确定性。与单次把文章交给聊天助手相比，它把持续收集、去重和交付串了起来，同时要求维护配置、依赖与运行状态。

原文证明了流程可以串起来，还没有证明它能稳定替读者选出更值得读的内容。

项目由维护者利用业余时间维护。文中没有成本、耗时、失败率或对照实验，关于节省注意力的收益，目前应按产品设计主张看待。

能拿来做什么

• 先接少量已有阅读习惯的 RSS 来源，并显式指定 tech-news 等 profile，逐条检查入选与落选内容，再决定是否扩大来源范围。
• 为技术新闻和工程深挖设置不同的输出要求：前者解释影响，后者提取解决方案与使用条件，避免所有内容只剩一段泛泛摘要。
• 同时关注多个领域时，设置 max_items 与类别组配额，并检查来源上的 category，让简报长度和主题占比符合自己的阅读时间。
• 接入每日自动任务前，先手动跑通采集、生成和目标交付渠道，确认状态目录与密钥配置，再启用 daily-summary.yml。