开发者 Andrew Pollack 在 GitHub 上传了一个叫 linkedin-feed-blocker 的开源 Chrome 插件,功能很简单:把 LinkedIn 首页的信息流整块隐藏掉,同时保留职位搜索、消息、通知这些"工具性"功能。触发这件事的是一条让他不适的招聘相关帖子——原作者在项目说明里贴了前后对比截图,态度直白:我只想找工作、聊招聘,不想被这种东西糊一脸。

这类"反 Feed"插件不新鲜,Facebook、Twitter 生态里早有 News Feed Eradicator 这类工具。但这次的时间点值得多看一眼:LinkedIn 官方在 2024 年 10 月才刚刚系统性引入"停留时长"作为排序信号,这款插件几乎是在同一个周期里,以代码的方式做出了反向动作。

精准拆除,不是全面封锁

这款插件的实现分两步。第一步用 CSS 规则隐藏 data-testid="mainFeed" 这个模块,连带藏起发帖框。第二步用 Chrome 的 declarativeNetRequest 机制拦截网络请求,但只拦截携带 sduiid=com.linkedin.sdui.pagers.feed.mainFeed 标识的请求,而不是笼统地封掉所有分页接口。

这个选择不是随手写的。LinkedIn 的分页机制被多个功能共用,如果规则写得粗放,职位列表、搜索结果这些同样靠分页加载的功能可能被误伤。作者选择精确打击一个具体的 pager 标识,换来的是"只删首页,不动别处"的干净效果。

两种拦截思路的差别 通用分页拦截 封锁所有分页请求 职位/搜索结果 可能一并失效 实现简单 误伤风险高 精准 mainFeed 拦截 只锁定 sduiid 标识 职位/搜索/消息 不受影响 需要读懂请求结构 误伤风险低

LinkedIn 想让人多停留,用户开始想办法逃开

LinkedIn 官方对排序系统的表述一直是"多阶段、多目标",不是简单的点赞数排名。2024 年 10 月的工程博客披露,系统新增了"停留时长"信号,用自适应模型去预测用户会看多久,极短的停留会被当成负面信号处理。官方说法是要追求"高价值时间",而不是单纯拉长使用时长。

问题在于,停留时长这个信号本身有歧义:一个人多停留几秒,可能是内容真的有用,也可能是看不懂、被冒犯、或者单纯手滑没划走。算法分不清这几种情况,"优化相关性"和"优化粘性"在技术上很难彻底切割开。

平台分不清你是喜欢还是反感,只知道你多停了几秒

同一时间段,Reddit 上关于 LinkedIn 的抱怨越积越多:2024 年 4 月的热帖描述首页被好友的点赞评论动态淹没,专业内容反而被挤到后面;2025 年用户反映反复刷到两周甚至更久之前的旧帖;也有人吐槽即便反复点"不感兴趣",广告和无关推广内容照样占满屏幕。越来越多讨论把 LinkedIn 形容成"迷你 Facebook"——专业社交的外壳下,塞的是个人化、说教式或纯互动向的内容。

  • 结论.这不是一个人的偏执,而是一场有社区基础的、针对同一套排序逻辑的持续不满。

谁会用这类插件,谁该多留个心眼

会用上这种工具的,基本是把 LinkedIn 当"求职工具"而非"社交产品"用的人——只想看职位、聊招聘,不想被首页的表演性内容占用时间。这批人的诉求很具体:少刷、少被打扰、功能照常用。

但 linkedin-feed-blocker 不是唯一选项。News Feed Eradicator 专门为屏蔽多平台信息流设计,uBlock Origin 配合自定义规则更成熟、权限透明度更高,Stylebot 靠纯 CSS 隐藏元素但界面一改版就容易失效。相比之下,这款新插件的权限范围更窄——只精确针对一个请求标识——逻辑也足够简单到可以逐行读懂。

  • 风险.小众单一用途扩展维护往往跟不上,仓库是否持续更新、所有权是否变化,都得用户自己盯着。

对创作者和广告主来说,如果这类"物理拆除信息流"的做法扩散开,直接影响的是内容曝光基础和信息流广告库存——这部分冲击目前还看不出规模,但方向是清楚的。接下来值得盯的,是 LinkedIn 会不会像 Twitter、Facebook 那样推出官方的"仅关注列表"或专注模式,把这场对抗从用户自己写代码,变成平台主动让步。