一个扩展只删除 LinkedIn 信息流：用户为什么不能自己关闭推荐
作者：周白｜OC 产品体验编辑
作者：周白｜OC 产品体验编辑
开发者 Andrew Pollack 发布了一个极简 LinkedIn Feed Blocker：隐藏 LinkedIn 首页动态和发帖框，阻止继续加载信息流，同时保留个人资料、职位搜索、消息、通知等功能。
一句话结论：这个扩展技术上几乎没有复杂度，它存在的原因才值得报道：用户需要 LinkedIn 的职业工具，却无法在产品里关闭平台最想让人停留的推荐流。
扩展用一条 CSS 规则隐藏带有 data-testid="mainFeed" 的主信息流，再用声明式网络规则拦截 mainFeed 分页请求。它特意不封锁通用分页端点，避免影响职位搜索和其他页面。用户需要以开发者模式加载本地扩展，没有商店安装和自动更新流程。
这不是把 LinkedIn 整站屏蔽掉。作者仍然想找工作、联系招聘者和查看个人资料，只是不想每次进入网站都面对混杂着职场表演、争议话题与算法推荐的首页。扩展实际上把一个复合产品拆回工具：账户、搜索和通信留下，注意力入口被移除。
为什么平台不提供这个开关
因为信息流同时承担广告库存、创作者分发、互动增长和用户回访。对用户来说，“只用招聘与消息”是一种合理模式；对平台来说，这意味着更少展示、更少行为数据和更短停留。两边目标并不一致。
很多产品会提供“少看此类内容”“取消关注”和通知设置，却不提供永久关闭推荐的总开关。细粒度选项让用户承担持续训练算法的工作，又保留了信息流本身。一个只有几条规则的扩展，反而给出了最清楚的退出机制。
极简扩展也有边界
Chrome 内容脚本可以按网址匹配向页面注入 CSS 或 JavaScript，因此很适合做这种局部改造。但扩展依赖 LinkedIn 当前的 DOM 属性与请求参数。平台改名、重构页面或换分页协议后，它可能无声失效。隐藏界面也不必然停止首屏数据请求，只有被明确拦截的后续请求不会发生。
本地加载还意味着用户需要自己审查源码、维护目录并在更新后重新加载。这个项目当前逻辑很小，便于检查；若将来加入遥测、远程脚本或更广泛站点权限，风险会完全不同。浏览器会把页面读取和修改能力交给扩展，安装任何“清理信息流”工具前都应查看权限范围。
用户控制不该依赖 DOM 补丁
平台完全可以把“职业工具模式”做成正式设置，让用户选择默认进入职位、消息或空白首页，并明确是否加载推荐内容。这样的模式不仅减少干扰，也能服务只在明确任务下使用 LinkedIn 的人。
但只要平台收入仍和停留、展示及互动高度相关，这类选择就不会自然出现。扩展的价值不只是清爽，而是把被产品捆绑的功能重新拆开：账户关系不必等于消费推荐流。
关键事实
- 扩展隐藏 LinkedIn
/feed页面主信息流和发帖框 - 它拦截主信息流的继续分页，但保留资料、职位、搜索、消息和通知
- 项目通过本地开发者模式安装，用户需要自行更新
- 实现依赖 LinkedIn 的页面属性与请求参数，站点改版可能导致失效
OC 判断
一个极小扩展解决的并不是技术难题，而是商业模式不愿提供的用户选择。推荐算法可以继续存在，但关闭它不该需要用户懂 CSS、网络规则和开发者模式。真正的产品控制权，是让人决定某个入口是否出现，而不只是教算法少推荐一点。
为什么重要
- 对用户：本地扩展能恢复专注，但安装前要检查权限与源码。
- 对开发者：针对具体 DOM 和请求的补丁应保持最小权限，并准备站点变更后的测试。
- 对平台：允许关闭推荐不会摧毁核心工具价值，反而能服务目标明确的低频用户。
评论
围绕这篇文章补充信息、提出问题或分享观察。