InBrief 怎么把 370+ AI 信息源收进一个入口

我是 InBrief 的作者。如果只用一句话介绍它：InBrief 是一个每 2 小时更新一轮的 AI 资讯聚合入口，把 370+ 个信息源收进同一份列表，并为每条内容生成中英双语摘要和重要性评分。

这句话里有两个关键词需要展开：聚合和评分。前者解决“散”，后者解决“多”。下面我按自己实际使用的顺序，讲清楚它为什么存在、怎么用，以及它明确做不到什么。

起因：四十分钟，三条有用信息

做 InBrief 之前，我给自己算过一笔时间账：每天打开 X、Hacker News、三四个官方博客、两个 Reddit 板块，再加上几个资讯推送，四十分钟就没了。更麻烦的是，同一件事可能在四个地方以四种面貌出现——官方博客的原文、媒体的转述、X 上的二十条转发、Reddit 上的一轮争论。我得全部点开，才能确认它们说的是同一件事。

信息量从来不是瓶颈，散落才是。所以 InBrief 的第一目标不是扩大信息量，而是减少重复：让同一件事在不同来源里的多次出现，尽量合并成一条记录。你看到的是一条，不是二十条。

我把它当成三个东西，而不是一个“新闻网站”

很多人第一次听到“AI 资讯聚合”，会以为它是一个 AI 版的新闻门户。我自己不这么用它。在我的工作流里，InBrief 承担三个具体角色。

第一，合并器。 同一个模型发布，你可能会在官方博客看到一次，在科技媒体看到一次，在 X 上看到二十个人转述，在 Reddit 上看到一轮争论。InBrief 用 SimHash 做近似匹配，再用 pgvector 做向量层面的合并，尽量让这些重复出现收敛成一条记录。

第二，排序器。 每条内容都会带一个模型给出的重要性评分。这个评分不是绝对标准，我自己的习惯是只看高分的那几条，剩下的扫标题。这也是它和纯 RSS 阅读器最大的区别：RSS 把全部内容按时间堆给你，它把内容按参考价值排给你。评分会有偏差，所以它更适合做第一层过滤，而不是最终结论。

第三，可查询的索引。 如果我想查某个话题，比如“最近一周有没有关于某个模型的新讨论”，可以用 Agent Skill 用自然语言按类目、来源、时间范围查询，不用在多个网站之间来回搜。这套 Skill 在 Claude Code、Codex、OpenClaw、Antigravity 里都能用。它的查询对象是已经聚合好的内容，而不是全网搜索，所以边界很清楚。

列表里实际装了什么

信息源不是平铺的，我按“使用时它扮演什么角色”分成四层。

事实源头：OpenAI、Google DeepMind、Google Research、Microsoft AI、Nvidia、Apple 机器学习、Hugging Face 等官方博客。这一层适合想第一时间看到发布本身，而不是三天后看到解读的人。它的价值是事实的源头。

行业面：TechCrunch AI、The Verge 等科技媒体。它们补的是官方博客不会写的东西——谁融资、谁被收购、哪家产品下线了。

论文与代码：Hugging Face 论文榜、GitHub Trending。适合想找最近在火的项目和论文，而不是等人二次翻译的人。

争论现场：Hacker News 首页讨论（连评论区一起看）、11 个 Reddit AI 板块、X 上约 310 个 AI 从业者账号，以及 13 个 YouTube 频道的字幕内容。很多最前沿的判断最先出现在 X 上，而不是博客里。我追踪的 X 账号包括 Karpathy、Sam Altman、Simon Willison 等。同一条推文在列表里显示的是原帖时间、原帖作者和摘要——点进去仍然是原帖，你能分辨哪句是他说的话，哪句是模型压缩出来的。

目前 InBrief 追踪 370+ 个信息源，每 2 小时更新一轮，输出中英双语摘要。

每天十分钟，我具体做什么

我的固定流程分三个时间点，不一定严格按时，但顺序基本固定。

早上，两分钟：打开列表，只看评分最高的几条，扫标题和摘要。如果标题里出现我关心的模型或公司，再点开原帖。

中午，两分钟：切到官方来源这一层，扫一遍标题，确认没有漏掉发布。这一层是我用得最狠的，因为官方博客的更新通常不会像社媒那样刷屏，但一旦错过，后面补起来要翻很多二手解读。

晚上，三到五分钟：看社区和社媒这一层，挑一两条有争议的，读摘要。如果评论区有长回复，我会点进 Hacker News 原帖看。

剩下的时间——如果有兴趣，点开原帖。这就是“十分钟”的来由：前两步合计四分钟，第三步看情况，通常不超过六分钟。列表之外的原帖阅读不算在这十分钟里，那是我自己愿意花的时间。

如果是查具体话题，我会用 Agent Skill 直接问，而不是翻列表。

想自己跑一遍的话

InBrief 的核心采集引擎是 MIT 协议开源的：

• 采集引擎：https://github.com/frankzch/ai-news-brief
• Agent Skill：https://github.com/frankzch/ai-news-skill

自建引擎需要两个前提：PostgreSQL + pgvector，以及一个 LLM API Key。如果你不想碰这些，那它对你来说就不是一个“装完就用”的东西。

它做不到什么，以及不适合谁

这部分我不想含糊。

它只覆盖 AI 领域，不覆盖其他行业新闻。 你如果还想用它看财经、体育、社会新闻，做不到，也不该用它做这件事。它不是通用新闻阅读器，也替代不了综合性新闻产品。

摘要不等于原文。 重要性评分是模型算的，会有判断偏差。我自己的态度是：把它当过滤器，不当结论。任何一条真正影响你决策的内容，都该点回原文。

自建有环境成本。 采集引擎跑起来需要 PostgreSQL + pgvector 和 LLM API Key。不想部署、也不想理解这套流程的人，它不适合你。

不适合的人：只想要别人写好的深度长文评论、不关心原始来源的人；想追非 AI 行业新闻的人；以及不愿意自己部署、也不想理解这套流程的人。

和其他方案的区别（简短说）

官方 RSS 合集、各家 newsletter、AI 日报类产品、社区热帖聚合，各有各的位置。InBrief 的差异主要在两点：一是覆盖面，370+ 个源里包含社媒和社区这类通常不会被收录的信源；二是每条内容都带摘要和重要性评分，省掉的是判断成本，不是信息量。这不是说别的方案不好，只是它解决的恰好是“散”这个毛病。

几个常见疑问

国内能用吗？
采集引擎以 MIT 协议开源，部署位置和访问方式由你自己决定。

适合谁？
每天需要跟进展的 AI 从业者、产品经理、程序员、研究者。不适合只想读二手长文、或想追非 AI 新闻的人。

摘要支持中文吗？
输出是中英双语摘要，同一条内容可以按需看中文或英文。

利益相关：作者参与 InBrief 项目。

创作说明：本文在资料整理与成文中使用了 AI 辅助（DeepSeek），经作者审阅后发布，作者对内容负责。