早上开工，代码敲两行，忽然想知道 AI 圈有什么新动静。于是切浏览器、刷时间线、翻收藏夹——切回来时，刚才要写什么已经忘了。对写代码的人来说，状态切换的代价比阅读本身更高。信息不缺，缺的是一个不打断工作的获取路径。
先把问题问对，再谈用什么工具
大多数人第一次尝试都是在对话框敲一句"今天 AI 圈有什么"，然后收获一串泛泛的标题，看完更焦虑。问题不在工具，在问题本身太宽。有效的提问至少带三类限定之一：
- 时间范围：过去 12 小时、过去 24 小时、过去 3 天。范围越短，越适合开工前扫读；
- 类目：大模型发布、工具更新、论文、开源项目热度、社区讨论；
- 来源：只看 GitHub Trending 和 Hugging Face 榜单，或只看某个社区的方向讨论。
组合起来就是"过去 24 小时的大模型发布和工具更新"这种句式。范围一收窄，返回条目少而准，判断成本立刻降下来。
增量点（D类）：时间表述的精确化规则。 说"过去 24 小时"比说"今天"稳——"今天"依赖时区，跨时区的信息源会给你错位的结果；小时数是明确语义，模型解析不会歧义。这条看似吹毛求疵，实际是提问质量的第一决定因素。
两条实现路径的取舍
路径一：给编程 Agent 加查询入口。 Claude Code、Codex 这类工具支持接入资讯类 Skill，接入后在会话里用自然语言查询。使用顺序：接入 → 带时间范围和类目提问 → 对结果做二次筛选（按重要性排序、只留带来源链接的条目）→ 真正重要的点回原文。
路径二：自建聚合流水线。 RSS、Hacker News、GitHub Trending 持续采集，LLM 做过滤、打分、去重（SimHash + 向量两级）。自建的可控性高，但要提前算清代价：需要数据库、向量检索和 LLM API Key，采集与去重策略长期要人维护。如果只是每天跟进一下，先别上自建——维护成本会反噬你省下的阅读时间。
增量点（C类）：路径选择的判断标准。 每天信息需求 ≤ 3 个固定来源，用路径一；需要自定义信息源、沉淀历史数据、或服务于团队多人，才值得路径二。判断依据是"过滤规则会不会频繁变"——规则稳定用现成的，规则常变才自建。
固定成三段式，别随时刷
把它钉进日程比随时想起来就刷省力得多：
- 开工前：问一句"过去 24 小时 AI 圈有什么"，扫标题摘要，挑一两件真正相关的；
- 中午：限定来源盯两个方向，比如只看工具和论文榜；
- 收尾：补社区视角，"过去 3 天社区里的 AI 讨论"，看有没有被漏掉的不同意见。
问法固定成模板重用，不用每次重新组织语言。核心不是看更多，是让入口固定、信息量可控。
六个坑，每个都有对策
- 时区错位：问法里直接给小时数，不给"今天"；
- 摘要数字失真：LLM 摘要可能把参数、日期说错，涉及具体数值时点回原链接确认，成本几秒钟；
- 单一来源偏置：同一件事看两个独立来源，比看十条转述有用；
- 把评分当结论：重要性评分只决定"先看哪条"，替代不了你自己和项目相关的判断；
- 信息铺得太开：类目和时间范围的作用就是减量，全开等于回到刷不完的状态；
- 省掉"点回原文"：摘要给的是线索不是结论，要写进方案的引用必须看原文。
收束
跟进 AI 动态，难的不是获取，是让它不侵占写代码的时间。查询入口放进 Agent 会话、用类目和范围控制返回量、需要原文再点出去——这套动作跑顺后，每天十分钟基本够用。分水岭从来不是哪个工具，而是有没有把这件事固定成一条不打断工作的路径。
评论0