我为什么做 InBrief：把 AI 一手信源收进一个入口

如果你每天要同时盯几家官方博客、GitHub Trending、X 和 Hacker News，这篇文章讲的是我为什么做了 InBrief、它在我这里怎么用，以及它做不到什么。写给同样在 AI 领域跟进展的人，不写给想找综合资讯的人。

我原来的麻烦是入口太多，不是信息太少

有一段时间，我的浏览器常驻六七个标签页：RSS 阅读器里塞着十几家官方博客，GitHub Trending 手动刷，Hugging Face 论文榜单独开一个，X 列表挂在后台，Hacker News 和几个 Reddit 板块想起来才点开。内容其实不缺，缺的是一个能按顺序看完的地方。结果常常是刷了不少，真正记住的只有推送来的那两三条。

这里面有一种不太容易察觉的损耗。同一家公司发布模型，你在转述里读到它，会误以为这是刚发生的事情，实际上可能已经过去两三天；原文里写明的适用范围、接口变化、基准测试条件，被压缩成一句结论；标题为了好看被改过，读完还是得回原文确认一遍。我不想把时间花在"找一个能确认的地方"上，于是干脆把入口往前挪。

InBrief 是什么

InBrief 是我参与的一个 AI 资讯聚合项目。它从 RSS、Hacker News、Reddit、X（Twitter）、YouTube 字幕、GitHub Trending、Hugging Face 论文榜持续采集，用 LLM 过滤、打分、去重，输出中英双语摘要。目前追踪 370+ 个信息源，每 2 小时更新一次。采集引擎是开源的（MIT），核心逻辑可以检查，也可以自己部署。

我不打算把它做成什么都收的新闻站。它的目标很窄：把"源头发布 → 摘要 → 判断值不值得点开原文"这段路缩短。

第一层：官方发布和仓库更新，先看源头

这一层是我自己用得比较多的。直接追踪的官方博客包括 OpenAI、Google DeepMind、Google Research、Microsoft AI、Nvidia、Apple 机器学习、Hugging Face，媒体侧收录了 TechCrunch AI、The Verge 等。再加上 GitHub Trending 和 Hugging Face 论文榜，源头大致三类：实验室和公司的官方发布、代码与模型仓库的动态、论文与榜单。

为什么值得单独看？举个我印象比较深的例子：某次接口调整，官方文档里写清楚了哪些字段废弃、迁移要改哪里、什么时候生效；等它出现在时间线上，往往只剩"某某 API 有更新"一句话。反过来，模型版本的发布公告里通常带着可用地区、上下文长度、限制条件，这些细节直接决定你能不能当天用上。

仓库也是同样道理。README 里的一句"已知问题"，往往比任何解读都直接。

用法很简单：把官方博客、GitHub、Hugging Face 的新增条目当成每天第一眼看的部分，按时间扫标题，只点跟手上工作有关的那几条。如果你想完全掌控信源，可以用开源引擎自建，按自己的清单增减源，仓库在 github.com/frankzch/ai-news-brief（MIT）。顺带说明：我列出的官方博客清单里没有 Anthropic，这个缺口自建时可以自己补上。

第二层：过滤、打分和去重，先把重复的挡掉

真正让人累的不是信息少，而是三件事反复发生：一条消息被十几个源同时推送；标题写得比内容狠，点进去发现是旧闻；刷了半小时，说不出今天到底发生了什么。

InBrief 在这一层的做法是：一个入口聚合 370+ 个 AI 信息源、每 2 小时更新，新闻、社媒讨论、YouTube、论文、GitHub 都在同一处；每条内容配摘要和重要性评分；去重用 SimHash + pgvector 两级完成，尽量让同一事件不重复占位。

用法上，先按评分扫一遍摘要，只在少数几条上花时间点原文，其余知道"发生过"就够了。这里得说清楚：评分是排序辅助，它衡量的是这条内容在全局的重要性，不代表对你的项目重要。

第三层：社区是第二意见

新闻回答"发生了什么"，社区回答"这东西到底行不行"。这一层覆盖：X 上约 310 位 AI 从业者账号，包括 Karpathy、Sam Altman、Simon Willison；Hacker News 首页讨论，连评论区一起收录；r/OpenAI、r/MachineLearning、r/ClaudeAI 等 11 个 Reddit AI 板块；另外还有 13 个 YouTube 频道。

评论区值得看，原因很实际：正文给结论，评论区里有反例、有复现失败的记录、有"我们内部试过，问题是……"这类一手经验。HN 上尤其明显，同一篇论文底下常有人贴实现细节，或者指出基准测试的设置问题。

用法上我建议汇总式而不是浸泡式：先扫 X 和 Reddit 的摘要条目，挑一两条进评论区；HN 单独看一眼首页标题，有争议的再展开。Reddit 这边 r/LocalLLaMA 不在目前列出的板块名单里，自建可以补。

第四层：用自然语言回溯

除了刷当天，还有一个场景是回溯。项目里有个 Agent Skill（github.com/frankzch/ai-news-skill，Claude Code / Codex / OpenClaw / Antigravity 可用），可以用自然语言按类目、来源、时间范围查询，比如问"上个月 Hugging Face 论文榜里有哪些跟推理优化相关的条目"。要写周报、或者做技术选型调研时，这比翻时间线省事。

我自己每天的十分钟

分两轮。第一轮五分钟左右：先看官方发布和仓库的新增，再扫评分较高的摘要，记下两三个待读；第二轮五分钟：挑一条进评论区，或者用 Agent Skill 查一个具体问题。重点不是把列表清空，而是每天结束时能说出"这两三件事值得回头细读"。

已知限制，以及谁不适合用

• 只面向 AI 领域，不覆盖其他行业新闻。要综合资讯，它不合适。
• 自建引擎有门槛：需要 PostgreSQL + pgvector 和 LLM API Key，属于要动手的范畴。不想折腾就用现成的聚合列表。
• 聚合替代不了读原文。摘要只负责排序，关键结论仍需回源头核对。
• 评分是辅助判断，不是结论。
• 不适合需要全覆盖时政财经的人；也不适合完全不打算自己筛、只想被喂结论的人。
• 输出是中英双语摘要，中文读者可以直接读中文；具体访问情况取决于你的网络环境，这一点我不做保证。

和其他方案的关系

邮件日报的节奏是每天一封、慢慢读一篇长整理；RSS 阅读器把信源清单的控制权交给你，代价是列表要自己维护；只跟一家公司的官方博客，适合关注面很窄的人；社区客户端适合愿意泡在讨论里的人。InBrief 做的事情很窄：把官方博客、代码与模型仓库、媒体、社区讨论放进同一个列表，减少切换次数。它不替代深度阅读，也不替代你自己那份信源清单。

如果你也在用多个入口拼 AI 信息，可以先去仓库看看引擎怎么采集、怎么去重，再决定要不要自己部署。用不上也正常，至少知道这条路能走到哪一步。

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

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