开工那十分钟，常常不是花在看内容上

早上坐到编辑器前，代码敲了两行，忽然想起：昨天到现在，AI 圈又发生了什么。于是切浏览器、刷时间线、翻几个收藏夹，再切回来，刚才那行代码要写什么已经忘了。

信息本身不缺。模型发布、工具更新、论文上榜、GitHub Trending、Reddit 上的争论、X 上一些人的观点、YouTube 的讲解，全都有人在做。问题是它们散在十几个入口，每换一个入口就要重新进入一次状态。对写代码的人来说，状态切换的代价往往比阅读本身更高。

一种比较省力的思路是：把“今天 AI 圈有什么”这件事搬回编程 Agent 的会话里。查询、过滤、摘要都在同一个窗口完成，不额外开页面，也不把注意力从编辑器里拔出来。下面按实际流程拆开说。

先把问题问对，再考虑用什么查

不少人第一次尝试就是在对话框里敲一句“今天 AI 圈有什么”，然后拿到一长串泛泛的标题，看完还是不知道该点哪个。问题通常不在工具，在问题本身太宽。

有经验的使用者会把提问当成一次过滤，至少带上三类限定中的一类：

• 时间范围：过去 12 小时、过去 24 小时、过去 3 天。范围越短，越适合开工前的快速扫读。
• 类目：大模型发布、AI 工具更新、论文、开源项目热度、社区讨论。
• 来源：只看 GitHub Trending 和 Hugging Face 论文榜，或者只看 Reddit 上某个方向的讨论。

组合起来的问法大致是“过去 24 小时，大模型发布和 AI 工具更新”，或者“过去 3 天 Reddit 上的 AI 讨论”。范围一收窄，返回的条目少而准，判断成本立刻降下来。

顺带提一句：提问时最好不要省略时间单位。说“过去 24 小时”比说“今天”更稳，因为“今天”依赖时区，而小时数是明确的。

做法一：在编程 Agent 里加一个查询入口

如果日常用的是 Claude Code、Codex 这类编程 Agent，可以接入一个 AI 资讯 Skill，让它具备按类目、来源、时间范围查询的能力。InBrief Agent Skill 是其中一种：仓库在 https://github.com/frankzch/ai-news-skill ，支持 Claude Code、Codex、OpenClaw、Antigravity，按仓库说明接入后，直接在会话里用自然语言提问即可，不需要额外的 API Key。

实际使用顺序大致是：

1. 按仓库说明完成接入，不同 Agent 的步骤略有差异。
2. 提问时带上时间范围和类目，别只问“有什么新闻”。
3. 拿到结果后做一次二次筛选，比如让它按重要性排序，或者只保留带来源链接的条目。
4. 真正重要的内容点回原文看。摘要负责筛，不负责替代原文。

这套流程的好处是查询动作本身不打断写代码的节奏。扫几条标题和摘要，值不值得展开一眼就能判断，然后继续写。

做法二：自建聚合源，把过滤规则握在自己手里

如果不满足于“别人替你筛”，而是想自己定义信息源和过滤规则，思路就变成搭一条采集加摘要的流水线。InBrief 的开源采集引擎属于这一类：https://github.com/frankzch/ai-news-brief ，MIT 协议。它从 RSS、Hacker News、Reddit、X、YouTube 字幕、GitHub Trending、Hugging Face 论文榜持续采集 AI 内容，用 LLM 做过滤、打分、去重，输出中英双语摘要；去重是 SimHash 加 pgvector 两级。规模上追踪 94 个信息源，其中包含 35 个 X 上的 AI 账号和 13 个 YouTube 频道。

自建的好处是可控，代价要提前算清楚：需要 PostgreSQL + pgvector 和 LLM API Key，采集与去重策略得自己维护，不是装完就一劳永逸。另外它是面向 AI 领域的，不覆盖其他行业的新闻。

不想自己写采集和摘要逻辑的话，n8n 上有 RSS + AI summarize 的工作流模板，Horizon 这类开源项目也是同一方向。选哪条路，取决于想把控制权拿到什么程度。

每天怎么用，才不会变成新的负担

把它固定成三段，比随时想起来就刷要省力：

• 早上开工前问一句“过去 24 小时 AI 圈有什么”，扫标题和摘要，挑一两件真正相关的。
• 中午或休息时限定来源，比如“只看 GitHub Trending 和 Hugging Face 论文榜”，盯工具和论文两个方向。
• 收尾时补社区视角，问“过去 3 天 Reddit 的 AI 讨论”，看有没有被忽略的不同意见。

如果每天要跟的线比较固定，这几句问法可以直接当模板重用，不用每次重新组织语言。核心不是看更多，而是让入口固定、信息量可控。

几个容易踩的坑

时区。“今天”覆盖的是哪个时区的内容，结果可能和预期差一截。跨时区的源尤其明显，问的时候直接把小时数说出来更稳。

摘要里的数字。LLM 摘要可能漏掉细节，也可能把参数、发布日期这类信息说得不准。涉及具体数值时点回原始链接确认一遍，成本很低。

单一来源的偏置。X 上的观点代表不了全部，Reddit 的讨论里噪音也不少。同一件事多看两个来源，比多看十条转述更有用。

评分只是排序工具。重要性评分能帮你决定先看哪条，但它替代不了判断，尤其是和手上项目直接相关的内容。

自建不是零成本。数据库、向量检索、API Key、去重策略，长期都要有人管。如果只是每天跟进一下，先别上自建。

别把所有信息都推到眼前。类目和时间范围的作用就是减量。铺得太开，很快就会回到“刷不完”的状态。

点回原文这一步别省。摘要给的是线索，不是结论。真正要引用、要写进方案里的内容，都值得打开原链接看一眼。

说到底

跟进 AI 动态这件事，难的不是信息获取，而是让它不侵占写代码的时间。把查询入口放进编程 Agent 的会话里，用类目、来源、时间范围控制返回量，需要原文时再点出去——这套动作跑顺之后，每天十分钟基本够用。真正的分水岭不是用了哪个工具，而是有没有把这件事固定成一条不打断工作的日常路径。

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

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

文章摘自：https://www.cnblogs.com/frankzch/p/23234575