我是 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经作者审阅后发布作者对内容负责。