每天都在被 AI 资讯淹没这种感觉我太熟了。从去年开始我关注的中文 AI 领域的公众号、知识星球、论坛帖子加起来得有几十个每天早上打开手机光是未读的“重磅”“震惊”“突发”就够我刷半小时。更夸张的是等我把这些文章刷完往往发现真正有价值的信息就那么两三条剩下的全是包装过的重复内容或者公关稿。后来我实在受不了这种被动接收的模式干脆动手做了一款本地优先的浏览器插件让我关注的 AI 情报自己去“找”我而不是我每天像一个没有感情的转发机器一样在信息的垃圾场里翻找金子。这篇文章就把整个项目的来龙去脉、设计思路、踩过的坑、以及最终的落地实现全部一次性讲清楚。不管你是被信息焦虑困扰的普通读者还是想自己动手做点工具的开发者应该都能从中拿到不少可以直接用的东西。1. 这个插件到底解决了什么问题先说痛点。中文 AI 资讯领域有个很特别的现象信息密度极高但噪声更大。今天这家公司发布了新模型明天那家机构放出了评测报告后天又有人开始炒作某个新概念。你要是完全跟风很容易被带着跑你要是不看又怕漏掉真正重要的技术拐点和行业信号。我最初试过好几个方案。订阅 newsletter很多高质量的中文内容根本不在邮件里用 RSS越来越多的平台砍掉了源地址靠社交媒体算法那更是个吞时间的黑洞刷二十分钟连自己最初想看什么都忘了。于是我换了个思路既然信息源分散在各个网页、各个平台那我为什么不直接在浏览器这个环节上做文章毕竟我日常获取内容的入口最终都会落到浏览器的页面上。所以这个插件定下来的核心定位就是三个词本地优先、主动聚合、低打扰。本地优先意味着你的浏览数据、订阅配置、筛选规则全部存储在浏览器本地不走云端服务器我作为开发者都看不到你的数据。主动聚合是指插件会在后台按你设定的节奏抓取你指定的信息源然后生成一份“情报摘要”。低打扰是说它不会像某些助手一样动不动就弹窗刷存在感而是等你主动打开新标签页的时候才告诉你“你关注的这几个源今天更新了这些内容”。用一句话概括它不是一个更花哨的阅读器而是一个帮你把信息获取成本降下来的过滤器和提醒器。2. 整体方案设计从信息源到最终呈现要过几道关信息处理流程是这次设计里最核心的部分整体可以拆成四个阶段。第一阶段是信息源管理。我先预设了一批质量相对稳定的中文 AI 信息来源包括几家头部科技媒体的官网、几个圈内认可度较高的个人博客、以及一些文档更新频繁的官方发布页面。你在设置界面可以勾选或取消也可以手动添加自己的源。这里有个细节我保留了一个“自定义选择器”的输入框方便你为某个特定页面配置内容抓取规则。第二阶段是内容抓取。插件在后台通过 fetch 请求去拉取目标页面的 HTML然后解析出标题、摘要、链接、发布时间。这一步碰到的阻力不小后面我会专门说怎么应对各种反爬策略和页面结构差异。第三阶段是兴趣过滤。这是整个插件和普通 RSS 阅读器拉开差距的地方。不只是按关键词匹配我加入了“信号积分”机制。比如标题里出现“发布”“开源”“融资”“论文”这类强信号词权重加高出现“教程”“思考”“观点”这类弱信号词权重降低。同时可以叠加自定义关键词的黑白名单。当一篇文章的信号积分超过阈值它才会进入最后的待推送队列。第四阶段是摘要与展示。插件在本地调用一个抽取算法从正文里提取关键句子生成一段 150 字左右的摘要。配合原文链接、热度标记和状态标签在一块独立的面板里呈现。你每打开一个新标签页面板自动更新一次。这里我刻意没有引入后端服务。所有抓取和解析都在浏览器扩展的 service worker 和 content script 里完成。好处很明显部署成本低你不需要维护服务器隐私性好配置和数据都在本地轻量几十 KB 的扩展就能跑起来。代价也有跨域限制更严、无法很轻松地做大规模并发抓取、规则的更新得靠插件版本迭代来推。对于个人使用场景这个取舍是值得的。3. 技术栈选型与关键依赖的取舍插件基于 Manifest V3 规范开发。这个选择是必须的Chrome 已经在逐步淘汰 V2新上架的扩展从审核逻辑上就更倾向 V3。在 V3 里后台逻辑被定义为 service worker它是事件驱动、可被随时回收唤醒的生命周期比 V2 的常驻后台页要碎片化得多。一开始我还担心这个限制会影响定时抓取任务实测下来发现只要设计好唤醒和注册机制问题不大。技术栈上我没有引入前端框架就是原生 JavaScript 加少量工具函数。整个项目的代码量大概在两千行左右分成了 background.js、content.js、options.js 和 popup.js 四个主模块。数据存储用 chrome.storage.local比 localStorage 更适合扩展场景支持存对象、容量也大一些而且能配合 chrome.storage.sync 做配置跨设备同步。解析 HTML 的时候我用的是 DOMParser没有挂第三方解析库。很多人会下意识地在扩展里引入 Cheerio但浏览器的原生 API 足够处理绝大多数情况引入额外依赖反而会拉大打包体积增加权限审查成本。摘要生成我同样没有调 AI 接口而是用“词频-逆文档频率”的思路提取关键句。这样做省了 API key也保证了离线可用。唯一让我犹豫过的工具是跨域请求的代理服务。真实抓取过程中会遇到 CORS 限制尤其是从扩展的 background 去请求一个不相关的站点时。我一开始尝试用 Extension 的 host_permissions 直接申请目标域名权限发现不少站点还是会在服务端校验 Origin返回 403。后来我换成了通过 content script 在页面上下文里发请求利用同源策略绕过去。代价是页面必须打开着才能触发所以我设计了一套“后台预唤醒加页面静止抓取”的机制后面详细说。4. 核心细节拆解配置项、抓取策略和信号积分算法这部分是重头戏也是踩坑最多的地方。先看配置项。在 options 页面里我把配置分为三类信息源配置、抓取配置、展示配置。信息源配置是一串 JSON 格式的订阅列表每一项包含 id、名称、主页地址、抓取 URL 模板、内容选择器、标题选择器、链接选择器和时间选择器。可能你会觉得这么写配置有点复杂但好处是灵活。针对不同的网站结构可以做出差异化的适配。为了让非技术用户也能用我写了一个可视化的“测试抓取”按钮填完选择器之后可以直接预览抓取效果不用盲猜。抓取配置里最重要的两个参数是抓取频率和并发上限。抓取频率我默认设为 60 分钟一次太频繁容易触发对方网站的限流太低又会漏掉当日热点。并发上限默认 3就是同时最多跑三个源的抓取任务避免浏览器被一堆请求拖垮。这里有一个小细节值得养成习惯所有请求都尽量带上合适的 User-Agent 和 Accept 头有些站点没有这些头部会直接返回空结果。展示配置相对简单主要是摘要长度、面板位置、以及未读标记的样式。再说信号积分算法这是过滤环节的灵魂。我给每条被抓取到的文章算一个 score公式是基础分 baseScore 为 20 分每条强信号词加 25 分每条弱信号词减 10 分自定义白名单词每条加 30 分黑名单词每条直接置为 0 分。强信号词你可以在预设列表里看到比如“发布”“开源”“测评”“融资”“报告”“重磅”“突破”。弱信号词包括“教程”“复盘”“观点”“思考”“杂谈”“周报”。自定义词则由你在配置界面添加实现完全贴合个人关注点的过滤。举一个实际例子。某条标题是“某开源模型发布新版本性能全面超越上一代”里面有“开源”和“发布”两个强信号词基础分 20 加 50总分 70超过我设定的默认阈值 50会进入摘要区。“某某团队发布季度复盘一些个人思考”里既有强信号词“发布”又有弱信号词“复盘”和“思考”得分是 20 加 25 减 20等于 25低于阈值直接被过滤掉。阈值也可以在配置里调灵敏型用户设 30 就行保守型可以调到 80。这里面包含一个很常见的误区不是过滤得越狠越好而是要在召回率和精准率之间做平衡。调太低你会看到一堆无关内容调太高可能漏掉真正重要的信息。我自己最后用的是 55同时把“重大发布”这类自定义词加进白名单双重保险。5. 从零实现完整抓取链路的过程实录这一节我按真实开发顺序把当初一步步跑通抓取链路的过程复盘一遍。这部分代码思路可以直接复用很多细节都属于那种“没踩过坑绝对意识不到”的类型。我的第一个版本抓取逻辑很简单在 service worker 里直接 fetch 目标页面然后用 DOMParser 解析。测试下来正常返回的页面基本都能解析成功但很快我就遇到了第一道坎部分站点开启 Cloudflare 防护或者做了 JavaScript 渲染依赖直接拿到的 HTML 内容非常有限列表区域的标题都是空的。如何处理一种是依赖站点提供 JSON 数据接口很多现代 Web 站点都会在 window 里注入一份嵌入了文章列表的 JSON 数据解析这份数据要省力得多。另一种是改用 content script 方式在页面已经加载完毕后再去提取 DOM。我采用了双模策略。extension 优先尝试 fetch 解析如果发现解析结果为空再降级为 content script 模式。content script 模式这里我不展开讲协议细节核心做法是让插件在后台探测到某个源需要脚本渲染就自动打开那个页面等渲染完成后从 DOM 里抽取数据再把数据通过消息通道回传给 service worker。实测下来这种方式能覆盖大约九成场景。第二个坎是有不少站点加入了防盗链和 Referer 校验。直接 fetch 时如果 Referer 是空的或者来自 chrome-extension:// 开头请求很可能被拒。解决方法是在请求头里带上目标站点自身的首页地址作为 Referer。这个操作不会涉及到任何可疑手段只是模拟一个浏览器内正常点击链接时应该带上的信息来源。第三个坎是关于编码的。有些老牌网站还在用 GBK 编码fetch 回来的文本默认按 UTF-8 解析就会出现乱码。解决方案是读取 response 的 arrayBuffer然后用 TextDecoder 来指定编码解析。我一开始扔掉了这一层结果好多源的内容抓出来都是“锟斤拷”级别的乱码排查了大半天才定位到问题。第四个坎是去重。同一个源在不同入口页里可能反复出现同样的文章或者不同源之间会互相转载同一篇内容。我的去重策略是取标题分词之后的前五个词加上文章链接的域名算一个哈希指纹。如果指纹相同就认为是重复内容。虽然朴素但实测效果不错。收藏夹里有个功能可以看到“重复来源”的列表一眼就知道哪些站点是转发大户。接下来是摘要生成。我的做法把正文分段后按段落长度过滤掉太短的碎片然后计算每个段落中出现在标题里的关键词的密度。密度最高的前三段作为候选再各自截取前 150 字去重拼接成摘要。整个过程不依赖第三方接口全是纯本地运算。跑得很快单篇文章大概几毫秒。6. 呈现层的设计如何让情报面板不打扰又实用抓回来、过滤完、生成好摘要的信息最后要通过一个合适的界面呈现。我选择的载体是新标签页替换页。每当你新建一个标签页就能看到当天的情报面板按“高信号”“中信号”“全部更新”三个分组展示。这个设计的出发点很简单新标签页是浏览器里最高频的被动触发场景不需要用户去主动点开扩展图标。频率太高或太低都不行只有当你主动要开始一次新的浏览任务时它才出现一下。就像前台把当日快报放在你桌上而不是每次路过都追着你念一段。面板的视觉风格我做了很多轮调整。最初版本的信息密度太高列表里塞了完整摘要、发布时间、来源域名、积分值、标签看起来就像一个调试工具毫无使用欲望。后来我改了设计原则一屏只展示七个最重要的信息卡片每条卡片默认只显示标题、来源和一句话摘要完整摘要需要点击展开。积分值不直接显示而是映射为一个三档热度条避免用户还要去理解一个数字。这里有一个交互细节值得单独拿出来说。卡片上的“标记已读”按钮我不想让它变成一个孤立的操作于是改成了滑动删除左滑卡片标记已读右滑卡片加入稍后读列表。这个交互是受到了邮件应用的启发实测下来比单纯点按钮要自然得多。标记已读之后该条记录就沉入历史档案不再出现在当天面板里。面板底部还有四个快捷入口“刷新全部”“只看高信号”“历史归档”“设置”。“只看高信号”是我自己最常用的功能配合信号积分机制能快速切换到一种“只关注重大动态”的模式。如果你今天的状态不适合摄入太多信息这个按钮就是你的安静模式。7. 隐私安全与性能优化的实际考量本地优先这四个字在架构层面是怎么落实的我梳理了几个关键点。所有数据都存放在 chrome.storage.local包括订阅配置、抓取结果、历史归档。插件没有自己的服务器也不会把任何抓取到的数据上传到任何地方。唯一的网络请求是对你订阅源页面发起的抓取请求以及抓取那些页面时携带的静态资源请求。你在隐私设置里可以看到一份完整的请求日志记录每次请求发生的时间、目标地址和请求类型。我不做任何形式的用户行为追踪。安装插件后不会有标识符生成不会通过页面注入收集浏览历史也不会在后台做遥测统计。你如果打开扩展的权限说明会看到它只申请了 tabs 和 storage 两个权限。这里额外说明一下我没有申请类似“读取全部浏览历史”的权限那对于一个情报聚合工具来说完全没必要。性能方面最大的风险是后台抓取任务对浏览器续航的影响。我在设计时做了一组限制抓取窗口集中在当日的几个整点附近避免后台进程在随机时间点上频繁唤醒 CPU每次请求之间加入随机 300 到 800 毫秒的延迟而不是用固定间隔这个随机化不仅是为了躲避限流也是为了减小并发瞬间的电量冲击所有抓取结果写入本地存储之前都会做字段裁剪去掉无用的样式类名、内联脚本和图片原始数据只保留纯文本和必要属性。我还加了一个轻量级的缓存策略针对更新频率低的源抓取间隔动态拉长到 2 到 4 小时针对资讯密集型的源则维持 30 分钟一次的频率。这个动态调节的依据是这个源最近十次抓取结果的平均增量变化率。如果一个源每次都只有 1 到 2 篇新文章就没必要让浏览器高频空转。8. 常见问题与排查技巧实录开发和使用过程中我遇到了不少问题有些凭直觉就能想到有些则折磨了我好几天。这里挑几个有代表性的写出来按“问题表现、排查过程、最终方案”三个部分来说方便你直接对照。第一个问题是某些订阅源一直抓取不到内容但手动在浏览器里打开页面是正常的。排查过程是先看扩展的 console 日志确认抓取请求是否真的发出去了再查看返回状态码和响应内容发现返回的是 403。这说明请求被服务端拒绝了。原因是扩展的请求头里缺少一些关键字段或者携带的 Referer 不符合站点预期。最终方案是在请求头部显式写入目标站点首页作为 Referer并带上常规浏览器的 User-Agent 和 Accept-Language 头。这个问题修改后立刻解决。第二个问题是抓取到的内容里 HTML 标签残留很多摘要里会出现成片的样式字符串。排查过程是我发现解析时直接用 innerHTML 取文本把一批带有样式的节点也一并拿了进来。最终方案是在提取文本时先遍历 DOM过滤掉 script、style、noscript 这类标签再用 textContent 拼接同时用正则把多余的连续空白字符压缩成一个空格。这里踩过的坑是直接用正则去处理 HTML会越写越乱千万不要图省事。第三个问题是面板加载时偶发白屏。排查过程是我的新标签页面板用了 document.write 来写入界面脚本在某些加载时序下脚本执行时机太早导致 DOM 还没准备好。最终方案是把页面结构改成静态的 HTML 模板脚本放在文件末尾等待 DOMContentLoaded 事件触发后再初始化。第四个问题是部分站点反爬逻辑会在短时间内连续请求后弹出验证码导致后续全部失败。排查过程是验证码出现的频率和请求频率有明显的相关性。最终方案是加入抓取频率冷却机制单个源一旦在三次请求中检测到异常响应就暂停该源 30 分钟同时把并发上限降到 2。相对于抓取时效性稳定性和不被封禁显然更重要。第五个问题是历史归档数据逐渐膨胀本地存储容量报警。排查过程是我查了 chrome.storage.local 的配额发现虽然比 localStorage 大不少但也不是无限。最终方案是给归档记录加了一个 90 天的自动清理周期超过期限的数据会被异步清除。为了避免误删清理之前会生成一份可导出的 JSON 备份文件。下面整理成一份速查表遇到类似问题的时候可以直接对照。问题表现常见原因直接方案部分源一直抓取失败缺少 Referer 或 UA 头请求头补全常规字段抓取内容乱码页面使用 GBK 编码用 TextDecoder 指定编码内容里带 HTML 标签提取逻辑未过滤标签过滤 script/style 后再拼接面板偶发白屏脚本执行时序不对静态模板加事件监听连续请求后出现验证码请求频率过高冷却机制加降并发本地存储空间不足归档数据未清理90 天自动清理加导出备份9. 从每日泛读到定向追踪的升级路径插件跑到这个版本基本满足了我的原始诉求每天打开新标签页如果当天有值得看的 AI 动态面板会告诉我如果没有就安安静静地显示一句“今日无高信号情报”。在实际使用了两周之后我发现自己的阅读习惯起了变化。以前是早上被动刷一遍各个信息流看到什么是什么。现在变成了主动在面板里挑两三条真正有价值的深度文章剩下的时间用来做更重要的事。这种从“泛读”到“精读”的转变在我看来是这个工具最大的价值。后来我还做了一个小扩展针对特定型号或者特定公司的动态单独建立一个跟踪主题。比如你最近在关注某个开源模型的迭代周期就可以新建一个主题只订阅那些标题或摘要里同时包含模型名和发布类关键字的文章。一旦有新文章命中面板顶部会出现一条主题横幅点进去可以看到该主题的时间线。这个功能本质上是信号积分机制的一个结构化应用。我也考虑过接入 RSS 的标准化解析让通用性更高。实现上并不难就是在 content script 之外再加一条基于 XML 解析的通道。但维护成本会比现在高不少因为不同 RSS 源的字段风格差异还挺大。暂时把它放在待办清单里等真正有需求再说。如果你也想做一个类似的东西我的建议是先不要追求功能大而全。把最核心的“抓取、过滤、展示”三条链路跑通比什么都重要。后续再根据你的实际使用习惯逐步加入新功能。很多功能不加之前你觉得很需要加了之后才发现一年也用不到几次。少做无用功是这类个人工具最值钱的理念。10. 实际使用三周之后的个人体会距离插件跑通第一版到现在已经过去了大约三周。期间我调整了四次信号词的列表把最初预设的二十多个词删到了十五个左右。删掉的那几个大多是描述性词汇用处不大反而容易把一些旧闻重新带回来。留下来的词则全部是强行动词比如发布、开源、融资、关闭、退役。好的信号词应该是对“事件已经发生”最直接的描述。我每天早上看完情报面板的时间从以前刷手机的半个多小时缩短到了现在的十五分钟以内。这个时间节省核心是过滤器在帮你做决策而不是让你在信息流里自己挣扎。还有一个我自己很喜欢的细节是“午夜快报”功能。我设定了每天晚上十一点生成一份当天的信息汇总直接存在本地。第二天早上打开面板时会先看到这份快报再看到昨晚新增的内容。这样就不会出现“早上只看到重庆发布完的内容却没看到深夜发布的另一个公告”这类信息空档。如果你打算自己动手做最后分享一个小技巧扩展的调试期一定要用真实场景的数据来测别只用一两个你熟悉的站点头跑。我就是因为在开发阶段只测了三个优质源结果上线后发现各种反爬和页面结构兼容问题接二连三地冒出来。每加一个新源都像一次小型的逆向工程但每适配一个源插件对你个人的信息生态匹配度就高一分。这种一点点把工具打磨成自己专属形态的过程本身就是这个项目最有意思的部分。