开发者用1个脚本把谷歌搜索砍掉50%，代价是硬盘多了8个G

一位开发者用1.5个月时间，把自己对谷歌搜索的依赖砍了一半。他没换搜索引擎，没装插件，而是写了个工具把过去看过的网页全存进了本地硬盘。

从"再搜一次"到"我明明看过"

谷歌搜索的界面越来越像商场一楼的中庭。赞助结果、购物推荐、推广内容堆在顶部，真正想找的链接往往要滑到半屏以下。有机结果被SEO农场霸占，个人博客和小众资源被埋到第二三页。

AI摘要的加入让情况更微妙。技术查询需要精确，但自动生成的总结常丢关键细节，甚至给出简化到错误的答案。你在谷歌和真实信源之间，又多了一层过滤。

但这位开发者（原文未署名，以下称作者）的核心痛点比这更私人：他发现自己频繁搜索的，是上周读过却忘了收藏的文档页面，是昨天评论过却想不起项目名的GitHub issue，是公司内部无法被谷歌索引的私有仓库。

他在用谷歌当外接大脑，每次查询都被记录，而谷歌根本爬不到他真正需要找回的半数内容。

搜索的两种面孔

作者区分了搜索行为的本质差异。发现式搜索（Discovery Search）是探索未知信息——这类确实需要公共引擎。但记忆式搜索（Memory Search）是找回已知信息，只是忘了存在哪。

后者占了他日常查询的大头。每次"那个命令行参数是什么来着"的搜索，背后都是一次本可避免的中断：切换上下文、打开浏览器、忍受广告、在结果页里重新识别之前点过的链接。

他的解决方案叫Hister，一个自托管的网页历史索引工具。核心逻辑粗暴直接：本地运行爬虫，把访问过的页面全文索引进数据库，后续用关键词秒级检索。数据不出本机，自然也就没有追踪问题。

技术栈选得务实。Chromium扩展负责抓取页面内容，SQLite存元数据，Meilisearch做全文检索，Tauri打包成跨平台桌面应用。作者提到索引了约8GB的浏览历史，换来的是毫秒级的本地查询响应。

50%这个数字怎么来的

作者没给具体统计方法，只说是基于使用习惯的观察估算。减少的搜索量对应两类场景：一是成功用本地索引替代了"我之前看过这个"型查询；二是养成了主动归档的习惯，遇到可能复用的页面直接标记入库。

代价也实在。8GB硬盘空间在2024年不算夸张，但索引维护、定期清理重复内容、处理动态渲染的SPA页面，都是持续消耗。作者坦承工具目前"足够好用但远不完美"，比如对视频内容、PDF附件的支持仍有限。

更隐蔽的成本是认知负荷。用谷歌时你信任它的排序算法，用Hister时你得自己决定什么值得索引、怎么打标签、何时清理过期内容。这像从点外卖改为自己种菜——控制权多了，琐事也多了。

但作者认为这交易划算。省下的不只是搜索时间，还有每次查询时被广告和AI摘要分散的注意力，以及那种"我知道我见过但找不到"的烦躁感。

一个被忽略的老问题

Hister的思路并不新鲜。浏览器历史、Pocket、Notion Web Clipper、甚至简单的本地书签+全文搜索，都在解决同类需求。作者的特殊之处在于把这件事做到了接近谷歌搜索的体验速度，且完全本地化。

这指向一个被算法推荐时代掩盖的事实：我们消费的信息中，有价值复访的比例远高于直觉估计。社交媒体的时间线、搜索引擎的结果页、信息流的无尽滚动，都在训练我们"看完即走"的习惯，仿佛所有内容都是一次性纸巾。

但知识工作的本质是累积。那个上周看过的Kubernetes排错指南，三个月后会以另一种错误形式再次出现。把网络阅读变成可检索的个人档案，本质上是在对抗平台的遗忘机制。

作者在文末留下了一个未回答的问题：如果更多人开始本地索引而非依赖公共搜索，谷歌的广告商业模式会受到多大冲击？

他没给出数字。但1.5个月、50%、8GB这三个数，已经够一个产品经理算笔账了。