370个信源还不够？他做了个去重优先的AI资讯流

做AI资讯聚合的人常被问一个问题：信源不够多吗？InBrief作者给出的答案是否定的。他把自己日常的阅读流程拆开看，问题从来不是"AI新闻不够多"，而是同一条新闻被反复包装。

他描述的旧日常是这样的：早餐前在X上刷到某模型发布的截图；午饭前团队Slack里已经出现同一发布的三篇改写；下午看Hacker News讨论帖，评论区引用的原始出处比文章本身更扎实；晚上两份newsletter，内容重叠约一半。

他把这种体验归为三种失效模式：

• 变体式重复：足够大的新闻会被所有人换标题重发，判断两条是否在讲同一件事，比读完任何一条都费时间。
• 传话失真：官方博客里带三个限定条件的说法，传到第三手就变成一句没有范围、没有日期、没有前提的断言。
• 碎片化：公告在公司博客，观点在X，深度讨论在HN和Reddit，代码在GitHub，论文在Hugging Face。要么漏掉几个平台，要么一整天在切标签页。

他要的不是更多信源，而是一个按固定节奏打开、并且已经替他判断过"B是不是A的复述"的地方。

管线里真正重要的两个决定

InBrief是一个按时间排序、每两小时刷新的列表，抓取RSS、Hacker News、Reddit、X、YouTube转录、GitHub Trending和Hugging Face论文榜，目前覆盖370+信源，其中包括X上约310位AI从业者（Karpathy、Sam Altman、Simon Willison等）和13个YouTube频道。条目经LLM过滤、打分、去重，输出中英双语摘要。

两个工程细节比其余部分更关键：

• 两段式去重：先用SimHash，再用pgvector。SimHash低成本抓近似相同的文本，向量阶段抓"用完全不同的措辞讲同一件事"。单用任何一个都不够，因为换标题重发的帖子，有时是字符级复制，有时是彻底重写。
• 打分发生在阅读之前：每条都有重要性评分，这是几百条列表还能看下去的前提。

双语输出听起来像功能清单里的一项，实际是分诊工具：当信源用的语言他读起来不轻松时，摘要先告诉他原文值不值得打开。

如果只能为一个设计决定辩护，他选去重阶段。它不体面，但它决定你打开的是一个信息流，还是同一份公告重复五遍的墙。

一手在前，评论在后

这是最初动手的动机。列表同时追踪官方博客（OpenAI、Google DeepMind、Google Research、Microsoft AI、Nvidia、Apple Machine Learning、Hugging Face）和TechCrunch AI、The Verge这类媒体，官方帖与报道混在同一列表里，顺序不倒置：先看到一手条目，再看到它被如何解读。

他的经验法则：模型与能力发布、API与定价变动、论文与基准结果、公司级战略，回一手信源核对事实，因为报道往往最先丢掉范围和限定条件；上手体验和行业八卦，读报道更划算。

一手与二手的差距主要不在速度，而在范围、发布日期和前提条件能否在传递中存活。把两者放在同一列表，意味着不必维护十几个博客书签和一堆RSS来保住"官方在前、分析在后"的顺序。

评论区就是内容

在Hacker News他读的是讨论串而不是标题。HN的价值很大一部分在回复里：有人贴出文章正在概括的那篇论文，有人指出基准被污染，有人给出可运行的实现。只看标题等于只读目录。

Reddit覆盖11个AI相关子版块，包括r/OpenAI、r/MachineLearning和r/ClaudeAI。研究类讨论串和本地部署、开放模型类讨论串，常常比新闻文章下面的评论区更有信息量。

新闻告诉你发生了什么，讨论告诉你它意味着什么、可能错在哪。他的顺序是先扫新闻栏，再在社区栏花两三分钟。有些日子值得记住的是HN某条回复里的一句话，而不是任何标题。

先看分，再点开

工作流是：读高分条目，读摘要，判断是否相关，再决定跳过还是打开原文。低分且标题眼熟的条目，通常是已被反复覆盖的事件，扫一眼摘要确认没有新东西就过。

效果不是读得更多，而是打开的标签页更少。以前出于好奇点十几个标题，发现其中八个是同一个故事的不同版本；现在大部分判断在列表层完成，十分钟能覆盖的范围比过去大。摘要还捞回了一些本来会漏掉的东西：一个非英语信源，或一条标题平淡、但摘要说清了到底改了什么官方更新。

想提问而不只是扫的时候

浏览解决"有什么新东西"。要问"这段时间里谁就这个话题说过什么"，有一个Agent Skill，按类别、信源和时间范围接受自然语言查询，可运行在Claude Code、Codex、OpenClaw和Antigravity里。

采集引擎以MIT协议开源，Agent Skill单独一个仓库。自托管是实打实的活：需要带pgvector的PostgreSQL和一个LLM API密钥，这是技术门槛，不是填个注册表。只想读的话，这一节可以跳过。

和newsletter、RSS、新闻站的分工

他不评价其他工具，只谈分工：

• Newsletter适合固定时间的邮件习惯，节奏强，但互动和回头翻找较弱。
• RSS阅读器控制力最强，因为每个信源都由你挑，代价是信源列表和去重规则也得你自己维护。
• 新闻站更新快、有编辑视角，但叙事优先，一手信源和社区讨论在别处。
• InBrief是固定入口后面的聚合、打分、去重。它不替代深读，更不替代自己读论文。

适合谁，不适合谁

合理的选择：需要跟进AI进展但时间有限的开发者；追踪模型与工具变化的产品人；宁愿要一手信源也不要"摘要的摘要"的人；想建立固定信息节奏、而不是被通知牵着走的人。

不合适的选择：泛新闻读者，覆盖范围只限AI；想要零技术配置又要完整自托管的人，PostgreSQL加pgvector加LLM API密钥就是入场价；寻找唯一真相来源的人，它只做聚合和过滤，深度仍在原文、论文和长讨论串里。

给同样在做这类工具的人，他留的一句话是：去重是产品功能，不是实现细节。打分模型吸引注意力，但去重阶段决定有没有人第二次打开这个列表。

文末披露：作者参与InBrief项目；本文写作过程中使用了DeepSeek辅助研究与起草，内容经作者审阅并负责。