让 AI 自动帮你追全网资讯，最后会卡在哪里

如果你搭一个 AI，让它追某个领域的论文、发布、benchmark、观点和 changelog，它到底能替你走到哪一步？从 2026 年 1 月到 6 月，我持续试用了自己能接触到的一批资讯聚合、页面监控和自动简报工具。这个样本不覆盖市场上的全部产品，也不是严格的横向测评；它只是我在同一套技术资讯任务上的长期观察。结论是：AI 很擅长搬运和整理；但缺少用户目标、工作上下文与结果反馈时，它不能可靠替代最终判断。

这篇文章是《2026 AI 上半场观察以及下半场预测》专栏的第一篇。我想先把上半场真实发生的事讲清楚：信息自动化的爆发到底给了我们什么，又在哪里卡住了。然后再往下半场推演。

上半场：access 门槛被砍到了零

先说好消息，而且是真红利。

一年前，追一个快速演进的领域，最大的成本是 access：信源散落在 arXiv、GitHub Release、公司博客、邮件列表和社交平台。“去哪看"“看得过来"“跨语言看懂"各是一道门槛。

到 2026 上半场，在我的中文技术资讯样本里，采集、翻译、摘要和聚合已经能高度自动化。一条 RSS、一个 API 或网页快照进来，系统可以翻译、摘要、打标签、按主题归堆。它仍会漏抓、误译或丢上下文，但人工时间确实被压薄了。

瓶颈因此从"能不能拿到"移到两个指标：**noticing latency（变化发生到你注意到的延迟）**和 attention cost（消化它所需的注意力）。自动化能降低前者，却不会自动消除后者；追资讯远没有因此被解决。

这类产品长什么样：三条技术路线

在我 2026 年 1—6 月接触到的样本里，能力主要落在三类路线。它们不是穷尽式分类，一个产品也可能跨类；这只是便于分析失败模式的工程切面。

第一条：订阅流聚合（push）。 它接入 RSS、newsletter、webhook 和平台 API，再做翻译、摘要、归类。这一路成熟、便宜，但信源必须预先配置；未订阅的新团队和新渠道通常不会进入候选集。

第二条：变更监控（poll）。 它定时去抓某个页面、某个 Release、某个文档的快照，做 diff，有变化就报。这一路的价值在于覆盖那些没有 RSS 的信源——定价页、模型卡、API 文档、GitHub Release。它的问题是信噪比极差：一个页面改了个 CSS class、换了张配图、更新了版权年份，diff 都会告诉你"变了”。你必须再叠一层模型去判断"这次变更是否语义上重要”，而这一层的误判是这条路线的主要成本来源。

第三条：主动检索（agentic search）。 你给它一个问题或一个领域描述，它自己去搜、自己判断该看哪些、自己决定要不要再搜一轮。这是能力上限最高的一路——它是唯一有机会发现"你不知道自己不知道"的东西的路线。代价是它最贵、最慢、最不稳定：同样一个查询跑两次，返回的东西可能有相当比例不重合，因为搜索结果本身在变、模型的检索决策本身有随机性。

把这三条摆在一起看，能看出一个很有意思的结构：

我最终采用的是混合方案：push 打基本盘，poll 盯少数没有 RSS 的关键信源，agentic 定期补盲。这不是所有产品的唯一解；它只是当前样本中成本、延迟与召回率较平衡的组合。三类路线首先解决的仍是"东西怎样到你面前”，不直接回答"到了以后怎样行动"。

天花板：产出停在"一个更精致的收藏夹"

但你把这套流水线跑上一个月，会慢慢咂摸出不对劲。

问题不在于它做得不好，而在于它交付的是排整齐、翻译过、去过重的信息流。哪条重要，哪条值得今天动手，仍要结合自己的任务判断。若没有这一步，产出只是一个更及时的收藏夹。

摘要不等于降噪。把长文压成三句话，降的是字数；“对我是否重要"却取决于目标、项目上下文和过去反馈。系统拿不到这些信号时，只能估计通用重要性，无法稳定贴合个人任务。信息越来越便宜，处理信息的能力反而更贵。

一张图：自动化能吃下的和吃不下的

我把这条流水线画开，你就能一眼看清楚"降维打击"发生在哪几层，又在哪一层撞墙。

                外部世界（不断发生变化）
                        │
   ┌────────────────────┼────────────────────┐
   │  获取模式（三选一，通常混用）               │
   │  ① 订阅流 push   ② 变更轮询 poll  ③ 主动检索  │
   │     RSS/webhook     diff/快照      agentic  │
   └────────────────────┼────────────────────┘
                        ▼
        ┌─────────── 信息层（AI 主场）───────────┐
        │  采集 → 翻译 → 摘要 → 聚合 → 三级去重   │  ← 高度可自动化
        │  URL 规范化 → 内容指纹 → 向量近重       │
        └───────────────────┼───────────────────┘
                            ▼
        ╔═══════════ 结构性天花板 ═══════════╗
        ║      降噪(对你而言) + 判断           ║  ← 卡在这里
        ╚═══════════════════┼═══════════════╝
                            ▼
        ┌─────────── 知识层 / 行动层 ───────────┐
        │  读完 → 判断 → 决策 → 动手 → 反馈       │  ← 还给了你的眼睛
        └───────────────────────────────────────┘

上半段更适合自动化；越靠近不可逆行动，越需要明确的责任边界与人工复核。

顺带把"降噪"这层的工程细节说透一点，因为很多人误以为降噪就是"少给我看点”。真正的降噪工程核心是三级去重：

第一级：URL 归一候选 去跟踪参数、解析跳转，再结合 canonical 信号归并
第二级：内容指纹     SimHash / MinHash，正文级别判"同一篇稿的搬运"
第三级：向量近重     embedding 相似度，抓"同一件事的不同复述"

三级去重能把"十家媒体转同一条稿"压成一条，能力很扎实。这三级的分工值得说细一点，因为顺序错了会白花很多钱：

• 第一级（URL 归一候选）成本很低，但不能只靠删参数。 utm_* 等已确认不改变正文的跟踪参数可以移除，跳转可以解析；可内容参数不能盲删。AMP、移动版和镜像站是否同稿，还应结合重定向、站点声明的 rel="canonical" 与内容校验。Google 也明确把 canonical 视为搜索系统选出的代表 URL，站点声明只是信号而非绝对命令：Google Search Central：Canonicalization 。
• 第二级（内容指纹）很便宜，SimHash / MinHash 都是纯 CPU，正文级别判"同一篇稿被搬运"。它抓的是那种改了标题、加了段导语、正文一字没动的转载。
• 第三级（向量近重）增加 embedding、向量存储与相似度检索成本，用来抓"同一件事的不同复述"。它通常比字符串规则和本地指纹更贵，但差距取决于文本长度、模型价格、是否本地推理、索引规模与查询方式，不能笼统说必然高出若干数量级。

工程上通常先跑确定、便宜的规则，再给剩余文本做向量近重：这样能避免给明显重复项反复计算 embedding。但"通常"不等于硬规则；低流量系统可能更看重实现简单，高流量系统还要把缓存、批处理、召回率与误杀成本一起算。

下面的数字来自我对 2026 年上半年个人技术资讯管线普通工作日量级的估算，既非可复现的行业统计，也没有经过完整日志审计。信源数量、转载密度和我的当期项目都会改变结果；它只用来展示压缩发生在哪一层，不应外推到别的领域：

一天进来的原始条目            ~800 条
        │
        ├─ 第一级 URL 规范化   → 砍掉约三成          剩 ~560
        │  (同链接不同参数、镜像、AMP)
        ▼
        ├─ 第二级 内容指纹     → 再砍掉约四成        剩 ~340
        │  (转载、洗稿、标题党改写)
        ▼
        ├─ 第三级 向量近重     → 再砍掉约三成        剩 ~240
        │  (同一件事的不同复述)
        ▼
   去重后"每条都是新的"                          ~240 条
        │
        ╠══════ 自动化到此为止 ══════╣
        │
        ▼
   跟我当下真正在做的事有关的                    ~10 条
        │
        ▼
   看完之后真的改变了我某个动作的                 ~1 条

这个个人估算里，自动去重约把 800 压到 240；240→10→1 则依赖我当期在做什么。它揭示的不是一个固定压缩比，而是一条边界：去重去掉的是"重复"，不是"对我不重要"。后者需要目标、上下文和反馈。

为什么这道墙是结构性的

我一开始以为模型再强一点就能替我判断。半年后，我更愿意把它看成分层问题。信息层回答在哪、是什么、说了什么；知识层回答这对我意味着什么；行动层决定做什么、放弃什么。越往下，任务越依赖个人状态，错误代价也越具体。

目标、处境、风险偏好和历史反馈并非永远无法提供给模型，但它们常常没有被结构化记录。更准确的表述是：缺少这些信号时，AI 不能可靠替代最终判断。

例如，同一天进来两条消息：主流框架发布大版本；一个小众库在 changelog 里改了默认超时。通用排序大概率抬高前者。但如果我正在排查超时，后者更有用。只要系统不知道我的当前任务，也没有从"读了、跳过、采取行动"中获得反馈，就没有可靠依据调换顺序。窗口再大，也装不下从未记录的上下文。

判断可以部分交给模型，但端到端可靠性必须单独测。下面的乘法只是悲观示意，不是对真实 agent 的经验定律：假设每一步相互独立，而且每一步成功都是最终成功的必要条件，单步成功率都为 p，那么整条串联系统的成功率才是 p^n：

单步 95%，串 5 步：  0.95^5 ≈ 77%     → 约每 4 次有 1 次歪
单步 95%，串 10 步： 0.95^10 ≈ 60%    → 约每 5 次有 2 次歪
单步 99%，串 10 步： 0.99^10 ≈ 90%    → 仍有 1/10 歪
单步 99%，串 50 步： 0.99^50 ≈ 61%    → 悲观假设下仍明显衰减

真实步骤往往相关，也可能有冗余、重试和纠错，所以不能把 0.95^n 当成实测成功率。它提醒我：单步 benchmark 不能代替端到端评估。METR 对多步软件与推理任务的原始研究也发现，人类完成任务所需时间越长，模型成功率总体越低；短于 4 分钟的任务接近 100%，超过约 4 小时的任务在其测试中低于 10%。这不证明简单乘法成立，却给"长链更难可靠完成"提供了实证依据：METR：Measuring AI Ability to Complete Long Software Tasks 。

工程上的办法是实测整条链，在关键节点保留来源、置信信号与可回滚状态；对高代价决策缩短链路，遇到不确定性时停下来问人。关于无人值守 agent 的信任问题，我在 信任工程那篇 里单独拆过。

因此更准确的边界是：信息层可高比例自动化；知识层需要把用户目标和反馈接进来；行动层是否保留人工批准，应按错误代价决定。部分判断可以交给 AI；缺少上下文、反馈和责任机制时，不应把最终判断默认外包。

一个诚实的 caveat

这不是说 AI 追资讯没用。它能显著缩短 noticing latency，并减少翻译、归类和重复阅读的成本。更合适的定位是情报前哨：让候选信息及时到达；至于哪些决定需要人工拍板，应由上下文完整度和错误代价决定，而不是用一个漂亮却无法验证的自动化百分比来回答。

那你今天该怎么搭：一份 checklist

讲了这么多边界，落到你手上应该变成动作。下面这些是我自己这半年反复调之后留下来的，你可以直接照着对。

先划清楚：哪些交给它，哪些留给你。

搭之前先回答四个问题。 我见过太多人（包括我自己）先兴冲冲搭系统，搭完才发现回答不了这几个问题：

1. 你追这个领域，是为了做什么具体决策？ 如果答不上来，那你不需要情报系统，你需要的是先想清楚要干嘛。为"保持关注"而追，是自动化最经典的浪费——它会让你极其高效地浪费时间。
2. 多久看一次就够？ 大部分领域，一天一次绰绰有余，很多领域一周一次都不损失什么。你把延迟从一天压到一分钟，压的往往不是延迟，是你的专注。 别用"实时"的架构去解决"每周"的问题。
3. 漏一条的代价是什么？ 如果答案是"没什么代价"（多数情况如此），那就别追求全，追求准。全和准在信息系统里是明确的取舍，不是既要又要。
4. 看完之后，你的输出去哪？ 没有出口的输入就是囤积。这一条最重要，下一节展开。

具体的工程动作，按性价比排序：

• 给每条加"为什么给你看"的一句话理由。 不是摘要，是理由——“因为你上周在关注 X”。这一句话的价值不在于它准（它经常不准），而在于它让你能一眼判断该不该读，把判断成本从"读完再说"压到"看一眼理由"。这是我改动里投入产出比最高的一项。
• 把便宜的过滤器排在贵的前面。 前面说过，不重复了。
• 保留原文链接和原文快照，永远。 摘要是有损压缩，你迟早会遇到需要回原文的时刻。信源本身还会消失、改稿、删帖。
• 给"待读"设硬上限。 比如每天最多 20 条，超了就必须挤掉。没有上限的队列不是队列，是垃圾场——它只会持续给你负罪感，不会给你信息。
• 让系统记录你的"读了/跳过/采取行动"。 这是你未来唯一可能拿来训练个性化的信号，而且它现在就有用：过一个月回看，你会发现某几个信源你从来没点开过。删掉它们。
• 每月强制砍一次信源。 信源列表只会单调增长，除非你定期动手。我的规则很粗暴：一个月内一条都没让我点开过的信源，删。

反模式清单，这几条我全都亲自踩过：

• ❌ 追求覆盖率。 “我要追全"这个念头，是把一个判断问题伪装成一个工程问题。你追得越全，需要判断的量越大，最后崩溃得越快。
• ❌ 实时推送。 推送是把 noticing latency 优化到极致的手段，代价是把你的注意力切成碎片。你为了早知道两小时，付出了一整天的深度工作。 除非你的角色真的靠"早两小时知道"吃饭（极少数人是），否则批量、定时、一次性看完。
• ❌ 让模型直接给"重要性打分"然后按分排序。 它排的是通用重要性，不是对你的重要性，前面已经论证过。你会得到一个排序精美、但头部全是你不需要的东西的列表——而且因为它看起来很专业，你会更倾向于相信它，这比没有排序更糟。
• ❌ 让 agent 全自动写日报然后你只读日报。 复合误差 + 你彻底失去了跟原文的接触。跑三个月，你会发现自己对这个领域的直觉在退化——你读的一直是模型的二手理解，不是这个领域本身。
• ❌ 把系统本身当成产出。 我见过（也当过）太多人，把大量时间花在把流水线搭得更漂亮上，而不是花在用它产出的东西上。流水线跑得再顺，它也不是你的作品。 一个粗糙但你天天用的系统，胜过一个精致但你在维护它的系统。

下半场预测

上半场我们见证了信息自动化的爆发。基于这半年的观察，我对下半场下三个判断。

第一，信息层会继续标准化。 采集、翻译、摘要、聚合与去重的实现成本可能继续下降，单纯用信源数、延迟和语言数形成差异会越来越难。这里的"水电"是趋势判断，不是说成本已经为零；摘要与向量近重仍受调用量、模型、索引和运维方式影响。成本如何改变 Agent 规模，我在 开源模型成本坍塌那篇 里另有测算；产品竞争的分层则见 红海蓝海那篇 。

第二，差异会移到闭环质量。 重点不是追得最全，而是怎样把"知道"接到可验证的判断，再接到行动与反馈。我在 超级个体的情报系统 里拆过这条私人管线。

闭环也可以由系统主动触发：agent 从"你提示它"变成 它反过来提示你 。这能减少"记得去看"的负担，却会引入打扰风险，仍需用反馈校准。

第三，值得增加"判断命中率”。 覆盖率和延迟分别回答追得全不全、知道得快不快；判断命中率追问：基于这些信息做出的可验证判断，事后对了几成。

把这三个维度摆一起，差别就很刺眼了：

而且这一维今天就能测，不需要等任何新技术。它的门槛不是工程，是诚实——你得愿意把自己的判断写下来，然后接受它被打脸。最土的做法就够用了：每次你因为某条信息做出一个判断（“这个方向值得投入"“这个技术是噱头"“这个坑我得绕开”），就用一句话把它和当天日期记下来，附上触发它的那条信息。三个月后翻回来，逐条打勾或打叉。

第一次做这件事，几乎所有人都会被结果打击到——我第一次翻回去看的时候，发现自己有相当一部分判断根本没法评判，因为当时写得太模糊（“这个方向有意思”，什么叫有意思？）。光是被迫把判断写成一句事后能验证的话，就已经是这套练习一大半的价值了。 剩下的价值在于：几轮之后你会开始看出模式——比如你在某类问题上系统性地过于乐观，比如某个信源的东西你信了十次错了七次。

这是最本质、也最反直觉的一维——它衡量的是这些信息最终有没有让你做对事，而非系统给了你多少信息。谁先把这一维接进闭环，谁就领先了不止一个身位。

一句话收束下半场：信息层会变成免费的水电，值钱的全部迁移到判断层和行动层。

结尾：它替你知道，替不了你想

回到开头那个问题：让 AI 全自动帮你追一个领域的全网资讯，它到底能走到哪一步？

答案是：它能替你走完"知道"的全程，然后在"想明白"的门口，把接力棒交还给你。 这不是它的失败，这是分工——上半场我们已经把"知道"这件事彻底外包给了机器，这是了不起的进步；但也正因为"知道"变得如此廉价，“想明白"才第一次变得如此昂贵、如此稀缺。

信息不值钱，值钱的是处理信息的能力。当全世界的信息都能以近乎为零的成本躺到你面前，你和别人的差距，一分一毫都落在你怎么处理它上。 上半场，AI 替我们赢下了信息的战争；下半场，真正的战场是判断——而那一仗，暂时还得你自己去打。