我是 InBrief 的作者。先把这件事说清楚：它把散在很多地方、每天都在更新的 AI 内容收进同一个入口，按固定节奏整理成一份带摘要和重要性评分的列表。
它不替我读文章，也不生产观点。它做的是收口——把你本来要开十几个标签页去翻的东西，先翻一遍，排好序，再交给你。
为什么值得做：AI 信息的问题在"散"，不在"少"
这个判断不是拍脑袋来的。做过一段时间跟进之后你会发现，同一条进展往往有四个版本的现场。
以模型发布为例：官方博客给出的是事实和时间线；X 上有作者本人和从业者的即时解读，往往带着"哪一部分值得注意"的直觉；Hacker News 的评论区里通常会出现反例、复现失败和补充数据，这些恰恰是转述里最容易被省略的；再过一两天，Reddit 上有人贴实测，Hugging Face 论文榜上出现相关论文，GitHub Trending 上冒出配套工具。
这几面说的是同一件事，但要凑齐它们，你得在五六个 App 之间来回切换，而且切换成本最高的不是打开，是判断——哪条值得点开，哪条只是同一个公告的第七次转述。
中间层还会再加一层损耗。等你从别处看到二手整理时，事实已经被压缩过一轮，语境被削掉一半。所以我从一开始就没打算做"再一个来源"，而是做收口。
具体做法是：持续追踪 370 多个信息源，其中既有 OpenAI、Google DeepMind、Google Research、Microsoft AI、Nvidia、Apple 机器学习、Hugging Face 这类官方博客，也有科技媒体、X 上约 310 个 AI 从业者账号（Karpathy、Sam Altman、Simon Willison 都在追踪列表里）、13 个 YouTube 频道，以及 Hacker News、Reddit 的 AI 板块、Hugging Face 论文榜和 GitHub Trending。内容按固定节奏刷新，大约两小时一轮。
三类内容，在同一个列表里各占什么位置
一手来源：把官方更新的时间线并到一处
第一类最直接，就是各家的官方博客和官方账号。它们的共同点是：信息从源头出来，没有中间转述。
用法上可以把它当成一张会自己更新的"实验室动态表"。OpenAI 发了模型公告，Google DeepMind 更新了研究页，Nvidia 出了开发者工具，Apple 机器学习放了新论文——这些原本分散在不同站点、不同排版风格里的更新，会进入同一条流。每条前面有摘要和评分，你可以先扫一遍再决定细读哪条。
如果你恰好是那种"只想把几家官方博客的 RSS 收到一个列表里"的人，这件事本身并不复杂：收集 RSS、统一采集、再做摘要和排序。InBrief 的开源采集引擎就是把这套流程落成了可运行的形式，仓库在 https://github.com/frankzch/ai-news-brief ，MIT 协议。它不替你做解读，也不替代原文，只是把一手来源摆到同一个平面上。
社媒与社区：不刷 X，也能看到从业者在讨论什么
第二类是我个人用得最多的部分。
X 上那约 310 个账号，覆盖的是研究者、工程师、创业者。他们发的内容常常比官方公告更有信息量——哪一部分是真正的变化，哪一部分只是营销话术，往往在发布后几小时内就有人在时间线上说清楚。我不刷 X，但不想错过这些判断，所以把它们做成了摘要加评分的形式进入信息流。
这里要说清一个边界：你看到的是摘要，不是原帖。摘要的作用是筛选，点开原帖才能拿到完整语境和上下文。涉及需要引用或判断的场合，原帖仍然是唯一依据。
社区这边，Hacker News 的首页讨论连同评论区一起纳入，Reddit 则覆盖 r/OpenAI、r/MachineLearning、r/ClaudeAI 等 AI 板块的热帖。我特意把评论一起带上，是因为这两个地方的真正价值常常不在标题，而在评论区的反例、经验和不留情面的反驳。
代码与论文：热度和技术细节不落在列表外
第三类容易被忽略，但对做东西的人来说最实用：13 个 YouTube 频道的更新会以摘要形式出现，Hugging Face 论文榜和 GitHub Trending 也进同一条流。
这三样东西放在一起看有个好处——你能大致分辨出"大家嘴上在讨论什么"和"大家手上在做什么"。论文榜反映研究侧的新动向，Trending 反映工程侧的关注转移，两者有时同步，有时错开，错开的时候通常更有意思。
入口要有入口的样子：两级去重与双语摘要
一个聚合入口最常见的失败方式，是变成第二个噪音源。同一件事被十几个账号转发、被三家媒体改写，如果你的列表把它们全列出来，那这个入口就白做了。
所以 InBrief 在中间加了两道处理。一是 SimHash 加 pgvector 的两级去重，先把近似重复的内容压掉，减少同一件事反复刷屏；二是让 LLM 做过滤、打分和摘要，输出的摘要同时给中英两个版本。中文读者不必先读一遍英文再自己总结，这一步被提前做掉了。
我承认这里有取舍：打分是统一标准，不是为某一个人定制的。它不猜你的兴趣，只是把"这件事在当天有多重要"尽量排出一个顺序。个性化的东西交给你的眼睛——扫一遍列表，跳过不关心的，这个动作比调推荐参数快得多。
十分钟怎么走完，以及怎么用自然语言问它
如果每天只看十分钟，我自己的路径是这样的：先扫一遍评分靠前的条目，再按类目看一眼官方博客和社区讨论，最后挑一到两条点开原文细读。双语摘要的作用是省掉第一遍翻译和概括的时间，而不是替代阅读。
另外还有一个 Agent Skill，可以用自然语言按类目、来源、时间范围去问。比如"今天 OpenAI 官方博客有什么更新""过去 24 小时 Hacker News 上关于大模型的讨论有哪些"。仓库在 https://github.com/frankzch/ai-news-skill ，Claude Code / Codex / OpenClaw / Antigravity 里都能用。它的定位是帮你从已经聚合好的内容里快速定位，不是又一个阅读界面。
已知限制，以及哪些人不太适合
写到这里，该说不好听的部分了。
第一，它只做 AI。 其他行业的新闻不在覆盖范围内，也不会去覆盖。如果你要的是一份综合资讯早报，它不合适。
第二，自建有环境门槛。 核心采集引擎是开源的，但跑起来需要准备 PostgreSQL + pgvector 和 LLM API Key。如果你希望零配置、打开就用完全托管的服务，那 InBrief 当前的核心形态不一定对得上你。
第三，摘要和评分是辅助。 它们是筛选工具，不是事实来源。涉及关键判断时，仍然要点开原帖或官方博客核对——这一步没法省。
第四，节奏是大约两小时一轮，不是实时。 对需要秒级盯盘的人，它不够快，也不需要够快。
它和别的方案不是一回事，也不必是一回事
有人习惯用 RSS 阅读器，因为掌控感最强；有人喜欢 Newsletter，因为编辑视角本身就是价值；也有人就是直接刷 X，习惯之后效率也不低。这些方式我都不觉得有问题，不同人的信息习惯差别很大。
InBrief 的差异只在一点上：把 370 多个来源收进一个入口，做过滤、打分、去重，输出中英双语摘要，并且核心引擎是开源的。它适合的是那种想用固定入口、固定时间段，快速扫完一手动态和社区讨论的人。
如果你属于这类人，可以先从 GitHub 上那个采集引擎看起，判断它的采集逻辑和去重方式是不是你想要的。如果不是，也没关系——把信息源收窄、按固定频率看，这个原则本身和用哪个工具无关。
利益相关：作者参与 InBrief 项目。
创作说明：本文在资料整理与成文中使用了 AI 辅助（DeepSeek），经作者审阅后发布，作者对内容负责。
