屏蔽搜索引擎AI摘要的开源项目：Nobody Asked for AI 安装与使用指南

让 AI 闭嘴的“反向工具”出现了一个能屏蔽搜索引擎 AI 摘要的项目到底怎么用如果你最近上网搜索时经常被页面顶部的 AI 生成摘要打扰或者你只是单纯不想让 AI 替你总结内容、不想让 AI 回答“你以为你想问的问题”那今天这个项目值得关注。这次我们看的是一个偏“技术态度”的开源项目项目名叫Nobody Asked for AI。它解决的不是“如何把 AI 用得更好”而是“如何不被 AI 强制使用”。核心目标很直接把 Google 搜索、Bing 搜索等页面里的AI Overview / AI 摘要 / Copilot 回答从网页里隐藏掉让搜索结果回到传统、纯粹、自己动手点链接的状态。项目的核心特点可以提前列出一个浏览器扩展 / 用户脚本类项目注入前端代码隐藏 AI 摘要区块。主要针对 Google Search、Bing、YouTube 等页面中的 AI 生成内容。不涉及模型部署、不占显卡、不需要 API Key。本质是 CSS / JavaScript 选择器过滤 定时器清理。适合反感 AI 摘要、偏好原始搜索结果、或需要做内容对比测试的开发者。部署成本极低属于“前端脚本优化”类实践和本地大模型部署是完全两个方向。这篇文章会带你做几件事先把这个项目放在 AI 工具链里的定位讲清楚再给出本地安装、浏览器扩展配置、用户脚本加载三种使用方式然后提供一套功能验证流程告诉你如何判断 AI 摘要是否真的被移除最后补充常见问题和工程化使用建议。适合的读者有三类一是对 AI 生成信息疲劳、想回归搜索结果原貌的普通用户二是做 SEO 或内容竞品分析需要观察真实自然搜索结果排名的从业者三是想学习“前端如何用脚本定向隐藏页面 AI 区块”的开发者。1. 核心能力速览先把这个项目的能力边界列出来后面再展开具体步骤。能力项说明项目类型开源浏览器脚本 / 扩展类工具偏向用户端页面优化主要功能隐藏 Google、Bing 等搜索引擎结果页中的 AI 摘要、AI 回答区块硬件要求无特殊要求任何能跑浏览器的电脑都行启动方式浏览器扩展加载 / 用户脚本管理器注入 / 自定义书签代码是否依赖模型不依赖无本地模型、无 API 调用是否支持批量任务不适用主要作用于浏览器前端 DOM是否支持 API无独立服务端 API技术实现基于 CSS 选择器隐藏 DOM 观察者清理风险点搜索引擎页面改版可能导致选择器失效需要更新配置从功能定位上看它不是“生成式 AI 工具”而是“对抗式 AI 工具”。它不创造内容只负责清理页面里你不想看到的 AI 内容区块。必须强调一点这个项目只能处理“前端页面已经被渲染出来的 AI 摘要”。如果搜索引擎在服务端已经修改返回结果结构脚本需要同步更新选择器才能继续生效。任何页面隐藏类脚本都有这个通病不算项目缺陷是技术边界。2. 适用场景与使用边界2.1 适合谁用第一类是用搜索引擎获取信息但对 AI Overview 不信任的人。AI 摘要的本质是模型根据抓取内容二次生成存在内容失真、断章取义、甚至直接给错信息的可能。如果你搜索医学、法律、历史等需要精确来源的信息隐藏 AI 摘要能减少干扰。第二类是 SEO 和内容运营人员。做关键词排名监测时AI 摘要的存在会挤压自然搜索结果的展示位置。隐藏 AI 摘要后你能看到更接近“传统搜索体验”的排名结构方便判断自然流量入口到底长什么样。第三类是前端开发者。项目本身就是一个“用 MutationObserver 监听 DOM 变化 自动清理指定元素”的极好样例适合学习如何对抗动态渲染页面。2.2 不适合什么场景这个项目不适合所有人。如果你本来就依赖 Google AI Overview 快速获取答案或者你觉得 Bing Copilot 的总结很好用没必要装这个脚本。它只是一个“移除按钮”不是“搜索增强工具”。另外它无法解决“搜索引擎已经用 AI 改版”的问题。有些搜索结果页可能把 AI 摘要直接并入核心搜索结果的 DOM 结构导致隐藏后出现布局塌陷。遇到这种情况需要手动调整选择器普通用户会有门槛。2.3 合规与安全边界这里需要明确两个问题。第一项目本身不涉及破解、不被允许的数据抓取、绕过登录或窃取隐私。它的作用范围是你自己浏览器内的页面展示属于用户端个性化设置同“广告屏蔽”类扩展的性质类似。第二如果你用这个脚本做 SEO 数据采集、批量排名监测请遵守目标网站的 robots 协议和用户协议控制请求频率不要用于大规模爬取。脚本只是改变前端显示不改变你的访问行为是否合规。在隐私方面项目不需要注册、不需要联网鉴权本地脚本只操作 DOM。但如果你是从第三方网站下载的“整合版”扩展需要警惕脚本里是否夹带数据上报代码。建议优先从官方 GitHub 仓库获取文件或者自己审查代码后再安装。3. 环境准备与前置条件这个项目的环境要求非常简单比任何一个 AI 模型部署都轻松。3.1 系统与浏览器支持 Windows、macOS、Linux 下的主流 Chromium 内核浏览器例如 Chrome、Edge、Brave、Vivaldi以及 Firefox。Safari 也能通过用户脚本方式使用但代码兼容性需要自己测试。不需要安装 Python、Node.js、CUDA不需要下载 PyTorch更不需要一块好显卡。整个项目就是一个 JavaScript / CSS 脚本浏览器本身就是运行环境。3.2 准备工作建议准备以下东西一个 GitHub 账号如果你要从仓库拉取最新代码。任意一款浏览器扩展管理面板Chrome 直接访问chrome://extensions即可。如果选择用户脚本方式先装一个 Tampermonkey 或 Violentmonkey 扩展。一个文本编辑器用于修改选择器配置例如 VS Code 或 Notepad。3.3 检查浏览器开发者工具因为要观察 DOM 元素是否被正确移除建议你先熟悉浏览器开发者工具的基本操作。按 F12 打开开发者工具切换到 Elements 面板用左上角的选择器按钮点击页面里的 AI 摘要区块确认它的 HTML 结构。这一步很关键。后面无论用哪种方式安装最终都要靠选择器定位隐藏目标。不同地区、不同账号、不同语言环境下的搜索结果页 DOM 结构可能不一致开发者工具的检查能力是你排查问题的主要手段。整个环境的准备时间应该在 5 分钟以内不存在磁盘空间问题也不需要担心端口冲突。4. 安装部署与启动方式这个项目有两种主流使用方式做成浏览器扩展或做成用户脚本。下面分别说明。4.1 方式一作为“已解压的扩展程序”加载适合希望独立开关、不依赖第三方脚本管理器的用户。第一步从 GitHub 仓库下载项目代码。在仓库主页点击 Code 按钮选择 Download ZIP然后解压到本地目录或者使用 git 命令克隆。git clone https://github.com/nobody-asked-for-ai/nobody-asked-for-ai.git注意如果仓库地址发生变化以你实际搜索到的官方仓库为准不要从不可信渠道下载压缩包。第二步打开浏览器扩展管理页面。Chrome 输入chrome://extensionsEdge 输入edge://extensions。打开右上角的“开发者模式”开关。第三步点击“加载已解压的扩展程序”选择刚才解压的项目目录。加载成功后扩展列表中会出现该项目图标。第四步点击扩展图标确认开关处于开启状态。然后访问 Google 或 Bing 搜索一个热门关键词观察页面顶部是否还显示 AI 摘要。这种方式启动速度最快无需额外构建步骤适合直接使用。4.2 方式二作为用户脚本加载适合希望精细控制脚本运行时机、站点匹配规则、自动更新的用户。第一步先安装 Tampermonkey 浏览器扩展。安装完成后浏览器工具栏会出现 Tampermonkey 图标。第二步打开 Tampermonkey 管理面板点击“添加新脚本”。把项目提供的用户脚本代码粘贴进去保存。第三步检查脚本头部的match或include规则。这一步非常重要。一般在脚本开头会有一段这样的配置// match https://www.google.com/* // match https://www.bing.com/* // match https://www.youtube.com/*如果你的访问地区域名不同例如使用了 google.com.hk、google.co.jp 等需要补充对应匹配规则。第四步保存后刷新搜索引擎页面。Tampermonkey 会自动在当前域名下注入脚本开始移除 AI 摘要区块。用户脚本方式的优点是可以随时编辑脚本内容、查看日志、调整选择器灵活性比扩展方式更高。4.3 方式三手动执行代码临时测试如果你不想安装任何扩展只是想验证一下脚本在当前页面是否有效可以直接在浏览器控制台粘贴核心逻辑。但这里不推荐直接照抄一段未知的完整脚本而是建议理解它的核心原理。这类脚本的逻辑通常包含两部分第一部分是定义要隐藏的选择器列表。Google 的 AI Overview 区块、Bing 的 Copilot 区块在不同时期有不同 class 和 id通常是一组字符串数组。const selectors [ div[data-attridrelatedquestion], div.weather-main-container, div[aria-labelAI Overview] ];第二部分是移除函数和监听器。页面是动态渲染的AI 摘要区块可能在主页面加载完成后才插入所以需要配合 MutationObserver 监听 DOM 变化。function removeAIBlocks() { selectors.forEach(selector { document.querySelectorAll(selector).forEach(el el.remove()); }); } const observer new MutationObserver(() { removeAIBlocks(); }); observer.observe(document.body, { childList: true, subtree: true });手动执行的问题在于如果选择器写错脚本无法生效而且每次刷新页面后都要重新执行。它只适合临时测试和调试不适合长期使用。5. 功能测试与效果验证装完之后需要一套验证流程来判断是不是真的生效了。不要只凭“感觉页面干净了”就下结论。5.1 测试环境建议准备三组搜索结果页普通关键词例如“what is machine learning”问题型关键词例如“how to cook pasta”YouTube 视频搜索页或者带知识面板的搜索页这三类页面最容易触发引擎的 AI 摘要功能。5.2 功能测试步骤打开搜索引擎输入关键词等待页面完全加载。滚动页面到顶部观察是否存在一个独立于自然搜索结果、带 AI 标签的摘要区域。如果此时脚本已生效该区域应该被移除。再切换到开发者工具 Elements 面板全局搜索 AI Overview 相关的关键词。如果能搜到大量 DOM 节点说明区块还在如果搜不到说明脚本已经把对应节点移除。这里说一个经验Google 的 AI Overview 通常被包裹在一个带>import time from playwright.sync_api import sync_playwright with sync_playwright() as p: browser p.chromium.launch(headlessFalse) page browser.new_page() # 访问搜索引擎 page.goto(https://www.google.com/search?qmachinelearning) # 等待页面加载 time.sleep(3) # 手动注入脚本代码或通过 add_script_tag 添加脚本 page.add_script_tag(path./remove-ai.js) # 等待脚本执行 time.sleep(2) # 截图用于效果观察 page.screenshot(path./result.png) browser.close()这段代码不是项目提供的工具只用于说明“如何在自动化浏览器里验证前端脚本效果”。如果你的实际目标是批量监测搜索排名请自行控制抓取频率避免给目标站点造成压力。7. 资源占用与性能观察这个项目不会像大模型部署那样占用大量显存但也不是完全没有资源开销。7.1 内存与 CPU 占用脚本运行时会创建一个 MutationObserver 监听整个页面的 DOM 变化。在普通搜索结果页上这个监听器的开销很低几乎可以忽略。但如果页面非常复杂频繁触发 DOM 变化脚本会反复执行查询和移除操作可能造成短暂卡顿。更稳妥的做法是限制监听范围不监听整个document.body而是只监听搜索结果容器。这样能明显减少无效回调。const targetNode document.querySelector(#search); if (targetNode) { const observer new MutationObserver(removeAIBlocks); observer.observe(targetNode, { childList: true, subtree: true }); }这种写法的好处是搜索容器之外的 DOM 变化不会触发脚本性能更可控。7.2 对搜索引擎访问速度的影响脚本只做 DOM 移除不拦截网络请求、不修改响应头、不延迟页面加载所以对访问速度的影响几乎可以忽略。如果你觉得页面变慢了优先排查扩展数量和其他插件而不是这个脚本。7.3 页面布局问题隐藏 AI 摘要后部分页面可能出现留白因为原始布局是给 AI 区块预留了位置的。如果追求更完整体验可以额外写一段调整容器 margin 的样式把自然搜索结果上移。不过这个属于锦上添花不影响核心功能。8. 常见问题与排查方法问题现象可能原因排查方式解决方案安装扩展后没有效果选择器过时页面结构变化开发者工具检查 AI 摘要区块对比项目脚本里的选择器手动更新选择器并重新加载扩展页面闪烁后摘要消失脚本在 AI 区块插入后才执行这是 MutationObserver 正常表现无需处理部分搜索引擎生效部分不生效不同站点的 DOM 结构不同检查项目脚本是否包含对应站点规则在用户脚本中补充对应站点选择器脚本引发页面卡顿监听范围过大或页面 DOM 频繁更新打开任务管理器观察页面 CPU 占用缩小 MutationObserver 监听范围Tampermonkey 不注入脚本match 规则不匹配当前网址查看 Tampermonkey 脚本运行状态修改 match 规则覆盖完整域名扩展图标灰色不可用扩展未开启或权限不足打开扩展管理页检查权限重新加载扩展并开启开关更新脚本后反而失效搜索引擎改变了 AI 区块的渲染方式查看新版本更新日志和代码 diff回退旧版本或等待项目更新无法找到官方仓库项目名相似或镜像站点混乱使用 GitHub 搜索准确项目名只从可信来源下载9. 最佳实践与使用建议9.1 先小范围验证不要全站“一刀切”第一次使用时建议把脚本匹配范围限定在 Google 的搜索页验证选择器有效后再扩展到其他站点。直接全站启用容易遇到兼容性问题排查起来也麻烦。9.2 建立选择器维护清单搜索引擎每个月都可能调整页面结构。建议你把项目用到的选择器单独整理成一个文档记录下生效日期、适用站点、选择器内容。改版后能用最少的成本定位问题。9.3 区分“隐藏”和“退出”这个项目只是在前端隐藏 AI 摘要不代表搜索引擎不再收集你的行为数据。如果你更在意隐私应该单独配置搜索引擎的隐私设置而不是依赖一个脚本。9.4 关注项目更新节奏开源项目可能停止维护。如果项目长期未更新说明选择器很可能已经失效。这时你可以自己维护一个私有副本修改选择器后继续使用。这也是学习前端开发的一种方式。9.5 涉及版权素材和商用场景时要注意虽然此工具本身用于去除页面中的 AI 内容但在使用搜索引擎结果时仍需注意搜索结果中的图片、文字、视频缩略图等素材版权。如果你将搜索结果用于商业报告、竞品分析、内容二次创作需要确认素材授权范围不能因为隐藏了 AI 摘要就把整个页面内容当作可自由使用。10. 总结与下一步这个项目最值得尝试的点在于它用极低的成本解决了一个非常具体的痛点搜索引擎越来越喜欢替你做总结而你想要一个干净的搜索结果页。它不依赖 GPU不依赖模型文件不用 API Key安装门槛比大多数 AI 工具都低。建议你先从用户脚本方式开始装好 Tampermonkey加载项目去搜索页测试效果。如果遇到不生效就打开开发者工具检查 AI 摘要区块的 DOM 结构把新选择器更新进脚本。整个过程应该不超过 30 分钟。最容易踩的坑有两个一是搜索引擎改版导致选择器失效二是不同地区搜索结果 DOM 结构不同导致脚本只对部分账号生效。遇到这类问题不要盲目重装先看开发者工具里的实际 DOM再调整选择器。后续你可以继续扩展的方向包括把脚本迁移到自己的浏览器扩展项目里、增加站点白名单、把选择器配置可视化甚至结合自动化浏览器做定期搜索页改版监测。如果你也对“AI 生成信息的取舍”这个话题感兴趣建议收藏这篇文章下次搜索引擎页面出现 AI 摘要时照着步骤操作一遍就知道有没有必要了。Nobody Asked for AI 项目实用笔记安装、验证与排错上一篇文章里我们把“Nobody Asked for AI”的定位、安装方式和简单测试流程讲完了。这篇继续补充一些实际使用中更容易踩到的细节以及如果你想把这个项目纳入日常工具链应该怎么维护它。部分朋友看完第一篇可能会有一个感觉这东西原理也太简单了就是隐藏几个 DOM 节点讲这么多是不是有点小题大做但你实际用两天就会发现真正的问题从来不是“选择器怎么写”而是“搜索引擎改版之后你还能不能第一时间跟上”。下面这些内容就是围绕“长期使用”展开的。1. 搜索页 AI 区块的常见特征不同搜索引擎的 AI 摘要区块在 DOM 结构上差异很大但有一些通用特征可以辅助定位。首先AI 摘要区块通常是一个独立的容器周围有明显的语义化标记例如带有rolecomplementary、aria-label属性或者是单独的aside区块。其次它们大多被安排在搜索结果的顶部在自然结果之前。最后区块内部往往包含一个模型标识或“AI”Logo 标签这些在 DOM 中会以独立的标签节点呈现。如果你要自己维护选择器建议优先选择容器最外层、带有语义化属性的节点然后是固定的 id 或 data 属性最后才考虑 class 名。因为 class 名在改版中最容易变化而语义化属性相对稳定。2. 建议维护一个“选择器配置”文件不要把选择器全写在脚本里然后每次改版都翻源码。更务实的做法是单独建一个配置对象集中管理不同站点的选择器。const CONFIG { google: { enabled: true, selectors: [ div[data-attridwa_iframe], div[aria-labelAI Overview] ], container: #search }, bing: { enabled: true, selectors: [ .b_copilot, [data-idcopilot-answer] ], container: #b_content }, youtube: { enabled: false, selectors: [], container: ytd-search } };这样每次改版只需要调整这个配置对象。如果你用的是 Tampermonkey配置可以在脚本开头单独定义方便编辑。3. 如果你只想要“视觉上隐藏”CSS 可能比 JS 更稳“移除节点”和“隐藏节点”在技术上是两件事。移除节点会对页面布局产生整体影响可能导致其他模块重新排版隐藏节点则保留空间但不显示内容。/* 使用 CSS 隐藏 */ div[aria-labelAI Overview] { display: none !important; }CSS 方案的优势是性能更好、不需要监听 DOM 变化。劣势是如果选择器失效就完全静默失败不易察觉。JS 方案更灵活可以在移除后输出日志方便调试。如果你追求稳定体验建议选择“同时使用”的策略先通过 CSS 隐藏已知选择器再通过 MutationObserver 清理动态插入的新节点。4. 如何跟进项目更新开源项目不维护的情况非常常见。建议你关注 GitHub 仓库的 star 数量和最近一次 commit 时间。如果半年以上没有更新基本可以判断项目已经停更你需要自己维护选择器。自己维护的选择器可以发到自己的仓库里作为 fork 版本后续不需要依赖原项目。这个过程其实不复杂核心就是对比搜索引擎改版前后的 DOM 差异然后更新配置。下面是一个简单的手动维护流程发现不生效时先打开开发者工具定位 AI 摘要区块。记录该区块最外层容器的属性。更新本地脚本配置增加新选择器。保留旧选择器不要删除。因为搜索引擎通常是灰度发布不同账号看到的结构可能不同。刷新页面验证效果。5. 自动化环境中的使用思路如果你有批量检查搜索排名的需求可以把这个脚本接入 Playwright 自动化流程。这时候需要注意一点Playwright 启动的浏览器是一个全新的上下文没有安装任何扩展脚本需要手动注入。你可以把脚本代码保存为一个独立的.js文件在每次页面加载后通过add_script_tag注入。需要注意页面可能要在完全加载后再注入脚本否则会错过 AI 区块插入的时机。更稳的做法是把 MutationObserver 的启动逻辑写进脚本内部保证无论何时注入只要后续有新 AI 区块出现都能被捕获。from playwright.sync_api import sync_playwright with sync_playwright() as p: browser p.chromium.launch() page browser.new_page() page.goto(https://www.google.com/search?qhello) page.wait_for_load_state(domcontentloaded) page.add_script_tag(path./remove-ai.js) page.wait_for_timeout(3000) page.screenshot(path./clean.png) browser.close()这段逻辑适合做“隐藏 AI 摘要后的搜索结果截图”或“简单排名快照”。做批量时建议控制请求间隔不要并发一次跑太多关键词避免给搜索服务器带来压力。6. 对内容创作者和开发者的额外提醒如果你是技术博主或内容生产者使用这类工具时要注意隐藏 AI 摘要的目的应该是“减少干扰、回归一手信息”而不是“假装 AI 不存在”。模型生成内容的版权归属、引用规范、信息披露要求在不同平台和地区存在差异。如果你在文章中引用搜索引擎结果、图片预览或站点摘要应遵循相关平台的引用规则和版权要求。同样如果你在别人的网站、软件或服务里使用这个脚本或类似技术也应评估是否违反该服务的使用协议。总体原则是个人学习、测试、无障碍优化用途较为稳妥大规模数据采集、商业化内容再利用前务必阅读目标平台的服务条款。7. 最后说一个实际体验把这类脚本放进日常浏览器之后最明显的变化不是“搜索结果变干净了”而是你重新回到“自己判断哪些链接值得点”的状态。AI 摘要替你做了筛选但也替你省略了上下文。对于想深度了解信息的人原始搜索结果的标题、描述、域名、时间戳依然是最有价值的信息源。如果你只是想快速知道一个简单答案AI 摘要确实方便。但如果你想了解一个陌生领域建议关闭 AI 摘要从自然搜索结果的第一页开始看起。你会发现自己的信息筛选能力比想象中更重要。这套“选择器维护 自动化注入 效果验证”的方法同样适用于其他类似需求。以后如果有新的“页面区块清理”需求不用再等现成工具自己就能改脚本搞定。