AI 信息碎又重复，InBrief 如何收拢？

我是 InBrief 的作者。写这篇文章不是要把它包装成万能工具，而是交代三件事：我为什么做它、我平时怎么用其中几类功能、以及它在哪些地方帮不上忙。AI 信息的问题，很多时候不是“信息太少”，而是同一条消息换了几层标题反复出现，原始出处被淹没，新闻、讨论、代码和论文散在不同页面里。

我为什么想要一个固定入口

做 InBrief 之前，我的日常大概是：早上在 X 看到一张模型发布截图；中午在群里看到同一件事的几种说法；下午打开 Hacker News，发现首页正在讨论它，评论区补充的论文出处比新闻本身更有用；晚上两封 newsletter 又有大半重合。一天下来看了很多，真正记住的没几条。

这里有三个具体麻烦。第一是重复：一条足够大的消息会被很多账号改标题重发，分辨“是不是同一件事”比读它更花时间。第二是转述失真：官方博客里一句带限定条件的话，传到第三手可能变成确定结论。第三是碎片：新闻在新闻站，观点在 X，深度讨论在 HN 和 Reddit，代码在 GitHub，论文在 Hugging Face；要么放弃几块，要么不停切标签页。

我想要的是一个固定入口：不必记住所有来源，也不必每次重新判断“这条和刚才那条是不是同一件事”。InBrief 的形态就是一个按时间排列的列表，每 2 小时更新一轮，采集 RSS、Hacker News、Reddit、X、YouTube 字幕、GitHub Trending 和 Hugging Face 论文榜，目前追踪 370 多个信息源，其中约 310 个是 X 上的 AI 从业者账号，另有 13 个 YouTube 频道。内容经过 LLM 过滤、打分和去重，输出中英双语摘要。

大厂官方博客：先看原文，再看解读

这是我做 InBrief 最原始的动机。它会追踪 OpenAI、Google DeepMind、Google Research、Microsoft AI、Nvidia、Apple 机器学习、Hugging Face 等官方博客，也会收录 TechCrunch AI、The Verge 这类科技媒体。官方更新和媒体报道混在同一个列表里，顺序不会反：先看到官方那条，再看媒体怎么解释。

我自己的用法是，涉及模型和能力发布、API 与定价变更、论文与基准结果、公司层面的战略调整，尽量回到官方原文校准事实；产品体验类和行业八卦类，看媒体解读更省时间。一手来源和二手转述的差别不只在速度，更在适用范围、发布时间和限制条件有没有被保留。固定入口的好处是，不用记住多个博客地址，也不用维护一堆 RSS，打开同一个列表就能完成“先官方、后解读”的顺序。

社媒和社区：不刷时间线，也能看到关键发言与评论

X 的信息密度高，但刷起来时间不可控。InBrief 追踪 X 上约 310 位 AI 从业者，包括 Karpathy、Sam Altman、Simon Willison 这类经常输出判断的人。我的用法是不打开 X，直接在列表里看他们发言的摘要；需要细节时再点回原帖。这样解决的是“想关注这些人的观点，但不想被时间线吞掉”。

Hacker News 我会连评论区一起看。HN 的价值很大一部分在评论里：有人补论文出处，有人指出基准测试的问题，有人直接贴实现。只看标题等于只看目录。Reddit 覆盖 r/OpenAI、r/MachineLearning、r/ClaudeAI 等 11 个 AI 相关板块的热帖，其中研究讨论和本地部署、开源模型实操的帖子，往往比新闻评论区更有信息量。

新闻告诉你“发生了什么”，讨论告诉你“这意味着什么、哪里可能有问题”。我每天会先扫新闻列表，再单独花两三分钟看社区那一栏。有时候当天最值得记的一条，不是新闻，而是某条 HN 讨论里的一句话。

摘要和重要性评分：先判断值不值得点开

每条内容都会生成摘要和重要性评分。我的使用顺序是：先看评分高的几条，读完摘要，判断这件事跟我有没有关系；没关系就跳过，有关系再点原文。评分低但标题眼熟的，多半是已经被重复报道过的事件，扫一眼摘要确认没有新增信息就划过去。

这一步的效果不是“看得更多”，而是“点开得更少”。以前我会因为标题好奇点进十几条，读完发现八条是同一件事的不同版本；现在大部分判断在列表层完成，十分钟能覆盖的量反而更多。摘要也能救回一些原本会被错过的内容，比如一条外文来源、标题平平的官方更新，摘要里写清楚它改了什么，我才知道值得点进去看细节。

去重是列表能不能看的另一个关键。引擎用 SimHash 加 pgvector 做两级去重，同一件事被不同媒体改写标题重发时，不会把列表刷满。这个机制本身不复杂，但直接决定了你打开列表时看到的是“信息流”还是“重复流”。

用 Agent Skill 查具体问题，用开源引擎自己跑

日常浏览之外，如果想查某条具体新闻或某个话题，可以用 Agent Skill 按类目、来源、时间范围做自然语言查询。它可以在 Claude Code、Codex、OpenClaw、Antigravity 里使用。采集引擎是开源的，MIT 协议，仓库地址是 https://github.com/frankzch/ai-news-brief ；Agent Skill 的仓库是 https://github.com/frankzch/ai-news-skill 。自建采集引擎需要 PostgreSQL + pgvector 和 LLM API Key，这是技术门槛，不是打开网页就能完成的事。

它和别的方案怎么分工

简短说几句，不带褒贬。Newsletter 适合固定时间读一封邮件，节奏感强，但交互和回溯不如列表方便；RSS 阅读器控制力最强，源完全自己定，代价是要自己维护源列表和去重规则；纯新闻站更新快、编辑视角明显，但偏媒体叙事，官方原文和社区讨论要另外找。InBrief 的定位是“聚合 + 打分 + 去重”的固定入口，把几类信息放进一个列表，不替代深度阅读，也不替代你自己去读论文原文。

适合谁，不适合谁

适合每天要跟 AI 进展但时间有限的程序员；需要追踪大模型和 AI 工具动态的产品经理；想拿一手信息而不是转述的从业者；以及想建立固定信息流、而不是被推送牵着走的人。

不适合只关心综合新闻、不聚焦 AI 的人，因为它面向 AI 领域，不覆盖其他行业新闻；也不适合不想做任何技术准备、又要完全自建的人，因为自建采集引擎需要 PostgreSQL + pgvector 和 LLM API Key。它也不适合当唯一信息源——它负责聚合和筛选，深度内容还是要回到原文、论文和长文讨论里读。

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

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