每天打开浏览器第一件事是刷一遍各个技术社区、公众号、知识星球里的人工智能相关更新。刷完感觉掌握了不少动态实际上真正有用的可能只有两三条剩下的大半是在重复、炒作和标题党。更尴尬的是我的收藏夹里存了超过三百篇“先存再看”的文章真正回看的不到5%。后来我实在受不了这种状态花几个晚上写了一个浏览器插件把“我主动去刷”变成“情报自己送上门”并且坚持本地优先——所有过滤、去重、排序都在浏览器里完成不上传任何阅读行为数据。这篇就把完整思路、实现链路和踩过的坑整理出来。我姑且把这个项目叫做“情报闸门”。它解决的就是标题里那句话每天被中文 AI 资讯淹没但真正该看的没几篇。这篇会讲清楚我为什么没有做成手机 App而是选浏览器插件插件里是怎么设计采集、清洗、过滤、去重这条链路的以及最关键的——怎样让资讯“自己来找你”而不是又变成一个需要你主动打开的信息流。内容偏技术但我会把每一步的取舍逻辑讲明白不是单纯贴代码。1. 信息过载的解药不是“订阅更多”而是“设一道闸门”1.1 我的真实困境收藏夹吃灰信息流刷不完做技术相关工作的朋友应该都有同感人工智能这个领域的信息量已经大到不正常了。每天新模型、新论文、新开源项目、新政策解读、新的行业八卦分布在公众号、视频号、各种星球、各个社区的讨论帖里。早几年我靠 RSS 就能覆盖大部分信息源现在很多中文内容根本不提供 RSS只能靠平台算法推给我。算法推什么我看什么结果就是平台觉得我爱看 AI于是推更多同质化的东西真正有价值的那几条反而被淹没了。我试过把信息来源分成“必读”和“选读”两组也试过每天晚上固定一小时集中处理还试过只在周末看一次。结果都一样要么错过关键动态要么再次陷入几小时的刷屏。直到某次我翻自己的收藏夹发现里面躺着二十几篇文章竟然都是同一个事件的不同解读角度我才意识到问题不在我懒而在没有一个机制帮我做第一层筛选。1.2 为什么选浏览器插件而不是手机 App这个问题的答案最初是出于“偷懒”我每天在工作时打开的大部分页面都在浏览器里阅读行为也集中在浏览器里。如果做一个手机 App我需要额外处理推送权限、前台后台切换、跨设备同步还要忍受各种系统限制。而浏览器插件可以在我看网页的时候顺带完成采集和提醒零切换成本。更深层的原因是浏览器插件在权限上更“透明”它只能在我授予的域名范围内读取数据所有数据都可以留在本地存储里。我不需要为了“同步”而把阅读记录发到某台服务器上。对一个本身就是为了缓解信息焦虑的工具来说如果还要担心隐私那等于增加新的焦虑。所以“本地优先”这个设计原则从一开始就定了抓回来的原文可以临时缓存但我的阅读行为、过滤规则、收藏标记一律只存在自己的浏览器里。1.3 拆开标题里的三个关键词“本地优先”不只是情怀它直接决定了插件架构。这意味着我不依赖云端去重、云端摘要、云端画像所有计算都在浏览器本地完成。好处是响应快、离线可用、没有服务费代价是代码要自己扛下不少脏活后面会详细说。“中文 AI 情报”则限定了输入范围。中文内容的抓取和解析比英文麻烦不少因为中文没有天然空格分词很多 HTML 页面排版也不规范。针对这个领域我需要额外准备一些中文特有的过滤词和命名实体规则比如模型名、框架名、会议名这类专有名词。“自己来找你”是整个项目最核心的产品逻辑。它不代表做一个新窗口让人去刷而是利用浏览器自身的通知机制在每天固定几个时间点把真正值得看的内容推送到我面前。理想状态下我一天只需要被打扰两三次每次看两分钟就能跟上进度。2. 插件架构数据不出浏览器情报照样每天新鲜2.1 浏览器扩展的骨架和后台任务设计在开始写代码之前先想清楚一件事插件靠什么在后台定时运行。主流浏览器插件的后台机制现在都转向 Service Worker事件驱动用完即停。这意味着不能在后台放一个永不停歇的 while 循环去轮询信息源必须借助系统提供的定时器接口。我用的定时策略很简单注册一个最小间隔的周期任务每 30 分钟触发一次。每次触发时检查两个东西——距离上次抓取是否超过我设定的间隔以及当前是否处于我设置的不打扰时间段。插件本体用 Manifest V3核心配置长这样{ manifest_version: 3, name: 情报闸门, permissions: [ alarms, notifications, storage, unlimitedStorage ], host_permissions: [ https://*.example-news-1.com/*, https://*.example-news-2.org/* ], background: { service_worker: bg.js }, action: { default_popup: popup.html } }注意host_permissions这块很有讲究。最初我把权限写成all_urls能抓到任何网页但浏览器会提示“此扩展可读取您访问的所有网站的数据”吓退了不少潜在用户。后来我改成只授予固定的几个资讯源域名插件面板里也写明“仅在以下站点读取内容”心理负担小很多审核风险也低。这算是一个容易被忽略的产品决策技术上越自由产品上越要克制。2.2 IndexedDB 为什么比 localStorage 更适合做情报池抓回来的文章数据我存在 IndexedDB 里而不是更常用的 localStorage。原因很实际localStorage 的空间上限通常在 5MB 到 10MB 之间字符串操作虽然方便但存几十篇文章的标题、链接、摘要、正文快照就快到头了。IndexedDB 虽然 API 啰嗦但它支持对象存储、索引查询、事务容量也宽裕得多。数据模型我精简成三张表sources订阅源配置包括名称、主页地址、抓取 URL、类型、权重、是否启用。items抓取到的文章包括标题、链接、摘要、正文快照、发布时间、来源 ID、状态未读/已读/收藏/忽略。rules过滤规则包括关键词、类型白名单/黑名单、匹配位置、生效时间。每次后台任务跑完我会把新抓到的文章写入items然后立刻执行过滤和去重。这里有一个性能技巧不要每抓一条就写一条、处理一条而是先全部抓回来放进一个数组统一去重过滤后再一次性写入。IndexedDB 的事务机制很适合这种批量写入速度比逐条写快很多。// 批量写入新文章 async function saveItems(newItems) { const db await openDb(); const tx db.transaction(items, readwrite); const store tx.objectStore(items); for (const item of newItems) { store.put(item); } await tx.done; }2.3 定时任务的触发策略条件触发代替粗暴轮询直接每 30 分钟全量抓取一遍所有源是最粗暴也最容易出问题的做法。很多资讯源并不需要那么频繁地刷新有些技术博客一周才更新一次频繁请求不仅浪费资源还可能触发源站的反爬限制。我的做法是给每个源配置不同的抓取频率和优先级。比如重要的一手信源每 30 分钟查一次普通社区源每 6 小时查一次长文博客每天查一次。定时器触发后先读sources表找到“当前时间距离上次抓取已超过该源频率”的源只对这部分源发起请求。这样整体请求量降下来了也不会漏掉重点源。另外要考虑浏览器对后台 Service Worker 的节流策略。长时间不打开浏览器、或者标签页被休眠时定时器可能不准。所以我在插件面板里加了一个状态提示显示“上次抓取时间”和“下次预计时间”让我能直观判断后台任务是不是被系统卡住了。3. 情报管线的四个环节采集、清洗、过滤、去重3.1 采集不只用 RSS还要兼容 HTML 结构解析很多人提到资讯聚合第一反应是 RSS。但中文 AI 领域的情况是相当一部分优质内容只有网页版没有 RSS 输出有些虽然有 RSS但只给摘要不给全文。所以我的采集层做了三种适配。第一种是标准 RSS/Atom解析 XML取标题、链接、发布时间、描述。第二种是针对“有列表页但没 RSS”的站点通过定时抓取列表页 HTML用 CSS 选择器提取文章链接再逐个进详情页提取正文。第三种是兜底方案针对提供 JSON API 的站点直接拉 JSON。这里有个现实问题每种源都要单独写解析规则。我维护了一个sources表里面存了selectors字段记录标题、正文、发布时间对应的 CSS 选择器。源站改版是家常便饭所以解析结果里如果发现“标题为空”或“正文长度小于预期”我会自动标记该源为“异常”停止抓取并在面板里提示而不是反复报错。// 抓取单个 HTML 源的示例 async function fetchHtmlSource(source) { const res await fetch(source.feedUrl, { credentials: omit }); const html await res.text(); const doc new DOMParser().parseFromString(html, text/html); const nodes doc.querySelectorAll(source.selectors.listItem); // 解析每个列表项返回最小化字段 }3.2 清洗与正文提取把长篇大论压成三行要点抓下来的 HTML 里通常充满广告、导航、页脚脚本直接存下来会占用大量空间也不好处理。我的清洗流程分两步先用正则和 DOM 操作去掉常见的噪声节点比如包含script、style、advertisement、recommend等特征的节点再用行文密度算法找出正文块。所谓行文密度算法其实很简单把 HTML 转成纯文本后按段落切分统计每个段落的字数、标点密度、链接密度。正文段落通常字数多、标点密度高、链接密度低而导航和侧边栏通常字数少、链接密度高。得分最高的连续几个段落就是正文主体。对于摘要我没有用外部 AI 接口而是坚持本地规则取正文前几句 包含关键信息的那几句比如包含数字、百分比、模型名、发布时间词汇的句子拼成三行以内的摘要。这个方案不完美但好处是零成本、零隐私风险、不依赖网络。如果你追求摘要质量也可以在插件里预留一个“对接本地模型服务”的配置项把正文快照发给本机跑摘要再把结果存回来——依然符合本地优先的原则。3.3 过滤规则关键词、来源权重、热度阈值过滤是整个闸门的核心。我把规则分成两层硬过滤和软过滤。硬过滤是黑名单逻辑。某些词出现在标题里直接丢弃比如“震惊”“重磅”“必看”“彻底炸锅”这些标题党高频词某些词出现在正文里且比例过高也降低文章优先级比如通篇都是“赋能”“抓手”“闭环”这类空话。这部分规则我内置了一批也允许在面板里增删。软过滤是加权打分逻辑。文章的初始分来自来源权重比如一手信源权重高转载源权重低再从标题和正文里匹配白名单关键词命中“大模型”“多模态”“智能体”“开源”这类专业词就加分。热度的判断则用时间衰减发布时间越近基础分越高如果有多个独立来源都在报道同一个话题该话题下的文章集体加分。最终只有总分超过阈值的文章才会进入推送列表。阈值是可调的太敏感的时候调高一点错过信息的时候就调低一点。这个“可调”非常关键因为信息密度的感知因人而异没有哪个固定阈值适合所有人。3.4 相似去重标题不一样不代表内容不一样中文 AI 领域的同质化报道特别严重。一个事件出来十几个公众号从不同角度写标题完全不同内容却有七八成相似。只看标题去重肯定不行必须对内容做相似度判断。我用了 SimHash 的简化思路没有引入复杂的向量模型。做法是对摘要文本做分词给每个词分配一个哈希值按词的权重累计得到一个二进制指纹两篇文章的指纹相差的二进制位数小于某个阈值就判定为相似保留得分高的那篇其余标记为“重复”并折叠起来。SimHash 对短文本的效果一般但摘要这种长度的文本够用了。实测下来大部分“换皮转载”都能被识别出来。有一个注意点中文分词要先做一遍否则直接用整句算哈希效果很差。我用的方案是不依赖外部分词库而是维护一个领域词表 通用二元组切分兼顾速度和准确率。4. 让“自己来找你”的主动推送机制4.1 浏览器通知的打开策略别一上线就轰炸技术上讲浏览器通知接口很简单chrome.notifications.create({ type: basic, iconUrl: /icon.png, title: 每日 AI 情报简报, message: 今天有 5 条值得看3 条来自一手信源。 });但“推送”这个动作如果做得太频繁就成了新的信息骚扰。我给自己定的原则是每天最多推送三次——早上 9 点、下午 5 点、晚上 10 点。每次只推送一张汇总卡片列出这段时间内通过过滤的前五条文章标题不再逐条弹通知。还有一个细节浏览器通知会占用系统通知栏打开浏览器时尤其烦人。所以我在通知逻辑里判断如果当前浏览器处于活跃状态就只在插件角标上显示数字不弹系统通知。只有浏览器在后台运行时才真正弹一次通知。这样白天工作的时候浏览器开着情报会静默积累在角标里通勤路上再次打开浏览器时才收到一天一次的汇总推送。4.2 每日简报把二十条变成五个值得看的点推送只是入口真正提高效率的是简报本身。我的简报不是简单列出今天抓到的所有文章而是按话题聚类。比如今天有五条在讲某个模型发布就归成一个话题显示一张卡片里面包含该话题的核心事实以及“不同来源的差异点”这个我额外提取的字段。这个聚类怎么做的其实还是用 3.4 节的相似度指纹。相似的文章聚成一簇之后簇的数量就是话题数量簇内得分最高的文章作为主稿其余作为补充视角。这样简报页面上通常只有三到五个卡片每张卡片扫一眼就够不再需要逐条点开。我还在简报末尾加了一行“今天忽略了 X 条低分内容”这是有意为之。看到这行字你会意识到闸门确实在干活而不是漏掉了信息。这个反馈对信任感很重要建议做类似工具的人保留。4.3 popup 面板与阅读队列零碎时间也能高效消化点击工具栏图标弹出的面板我设计成“阅读队列 快速操作”的组合。队列显示今天通过过滤、但还没看的文章按话题聚类排列每条后面有三个按钮已读、收藏、忽略。这里有一个我一开始没想到的经验真正让我坚持用下去的功能不是推送而是“忽略”。因为我可以在面板里把不感兴趣的话题一键忽略插件会把这个话题下的所有文章以及未来三天内的相似内容都过滤掉。忽略得越多情报越准。这种“负反馈”机制比单纯调阈值更符合实际操作习惯每点一次忽略都在帮闸门学习我的口味。面板不需要复杂。复杂的面板会变成第二个信息流那就违背初衷了。我做面板时时刻提醒自己页面上的元素每多一个用户做决策的成本就高一分。5. 实测运行中遇到的意外与调整5.1 后台任务被浏览器节流情报迟到怎么办插件上线跑了一周我就发现一个问题经常到了下午五点简报还没来。查了半天发现浏览器对 Service Worker 的定时任务有限制最短周期是一分钟但只要标签页长时间不活跃后台任务的实际触发时间会大幅度延后。尤其是在合上笔记本再打开时积压的任务会在同一时刻全部触发造成一次性的多次请求风暴。我的解决办法是分两层一是把重要来源的抓取频率提高到最短间隔保证大部分文章能在发布后半小时内入库二是再额外监听浏览器windows.onCreated事件每次打开新窗口时立即补跑一次抓取任务相当于“开机即更新”。这样就算后台定时器被延迟只要用户重新打开浏览器情报也能马上补上来。5.2 中文分词与关键词匹配的坑最初我在过滤里直接用了includes判断关键词是否出现在标题里效果很不理想。问题出在中文没有空格比如我设了黑名单词“重磅”一篇标题是“又一项重磅研究发布”的文章会被正确过滤但另一篇标题是“重量级研究发布”的漏网之鱼就躲过去了因为字符串里根本没有“重磅”这两个连续字符。解决思路是给关键词匹配加了一层模糊化把关键词拆成语素组合同时匹配“词”和“词的近义表达”。我还收集了一批常用的标题党句式比如“彻底改变”“不容错过”“最全整理”直接用正则匹配。这部分没有标准答案就是需要在实际使用中持续补充规则库。所以我的插件设置页里专门留了一个“导入/导出规则”的按钮方便我把积累的规则复制到新环境。5.3 源站改版导致的解析失效与容错降级运行到第二个月有个常看的资讯站改版了。列表页结构完全变更我的选择器全部失效抓回来的items表里多了几十条空标题垃圾数据。好在采集层有“异常源自动停用”机制问题没有扩大。我加了一个更稳妥的容错策略解析结果里如果连续出现五条数据都不满足“标题长度大于 5 个字 正文长度大于 200 字”的条件就把该源标记为疑似异常停止抓取并发送一条提示通知。同时保留上一轮抓取的有效数据作为缓存即使源站短暂不可用简报也不会变成空白。这套降级策略让我省心很多至少不会再被反复请求失败刷屏。5.4 设置界面不必复杂但“可调阈值”一定要有最初我把过滤阈值写死成代码里的常量结果发现不同时期的信息偏好完全不同行业发布会密集期需要降低阈值捕获更多动态平静期则需要提高阈值避免把边角料也推送过来。后来我把阈值、推送次数、安静时段、来源权重全部做成面板设置项。设置项虽多但我刻意把它们分组第一组是“什么内容值得看”第二组是“什么时候可以打扰我”第三组是“数据存在哪里”。分组名字用大白话不搞“高级设置”这种让人不想点开的标签。做这类工具我最大的体会是用户需要的不是更多参数而是参数背后的控制感。6. 一些可以直接抄走的配置和排错思路6.1 我最终使用的配置清单如果你也想搭一个类似的本地优先情报聚合插件可以直接借鉴这套初始配置配置项我的设置说明抓取间隔重要源 30 分钟普通源 6 小时长文源 24 小时控制请求量与时效性的平衡黑名单词震惊、重磅、必看、彻底炸锅、不容错过剔除标题党白名单词大模型、智能体、多模态、开源、推理、Agent、数据集给专业内容加权软过滤阈值初始 60按周调整一次过敏感时提高错过信息时降低推送次数每天 3 次早上、下午、晚上各一次安静时段22:00 到 08:00不打扰休息这套配置跑下来每天进入阅读队列的文章数量稳定在 10 到 15 篇其中真正会点开阅读的大概 4 到 6 篇阅读率比之前刷信息流高了好几倍。6.2 常见问题排查表现象可能原因处理方式长时间没有新情报后台定时器被节流打开一下插件面板触发补抓推送弹个不停通知策略未开启合并改为每天三次汇总通知全部文章都是同一话题相似去重失效检查是否有源被标记为异常某源连续空标题源站改版自动停用手动更新选择器面板打开卡顿IndexedDB 记录过多定期清理超过 30 天的旧记录还有一个比自己摸索更快的方法先从一个信息源开始跑通全流程再加上第二个、第三个源。我最初只挂了三个源跑了两天才逐步扩展到十几个。增量推进的好处是一旦出现解析问题你能很快定位是哪个源出的问题不会在几十个源的大泥潭里捞线索。6.3 后续可以扩展的方向这个插件目前对我个人已经够用但如果你准备在它的基础上做更多事有三个方向值得考虑。第一个方向是增加“跨设备同步”的能力对敏感数据做端到端加密后用自己信任的同步通道在几台设备间共享已读状态和规则配置。第二个方向是引入更智能的话题聚类不局限于相似度指纹而是用本地 embedding 模型把摘要转成向量再做聚类效果会更好。第三个方向是把“忽略”行为的数据沉淀下来做成一份个人兴趣演变报告每个月回看一次了解自己近期关注点变化。我在实际使用中发现最有价值的不是抓取工具本身而是“设闸门”这个思维转变。过去我总怕错过所以什么都想订阅现在我知道真正重要的事情不会因为我看得少就消失反而会因为筛选得准而更清楚。这个插件让我从“被动刷屏”回到了“按需获取”一天省下的一两个小时拿去读一本厚书都够了。