第一次用脚本搜索工具，脚本是搜索因为同事在群里扔了一句“谁有批量重命名文件的那个脚本”，然后五分钟没人回复。工具我翻了翻自己的脚本收藏夹，发现之前至少存过三个版本，搜索但一个也找不到。工具那一刻我意识到，脚本问题不是搜索没有脚本，而是工具脚本散落在无数个文件夹、聊天记录和浏览器书签里，脚本跟丢了没区别。搜索
脚本搜索工具要解决的工具，就是脚本这个“跟丢了”的问题。它跟普通文件搜索不一样。搜索普通搜索找的工具是文件名，脚本搜索得看内容——你记得某个脚本里有一行 `os.rename`，或者一个 `for file in` 循环，但文件名可能是 `test1.py`、`新建文本文档.py`、`最终版真的不改了.py`。人脑记不住这些，工具得帮你记住。
它到底在搜什么
我目前用的工具叫 sift，命令行下的，配置很简单，指定几个目录，它自动建索引。索引的不是文件名，是脚本的全文内容，外加语言类型、修改时间、文件大小。搜的时候可以按关键词、按正则、按语言过滤。比如我想找“所有包含 `requests.get` 的 Python 脚本”，一条命令就出来了。
有人会问，那用 grep 不就行了？grep -r "requests.get" ~/scripts 也能搜。区别在于速度。脚本多了之后，grep 每次都要遍历所有文件，几百个脚本还能忍，几千个就明显卡了。脚本搜索工具建了倒排索引，搜关键词是毫秒级响应。另外 grep 不会帮你区分语言，搜出来的结果里可能混着日志文件、配置文件、甚至二进制文件。脚本搜索工具会先按类型过滤，结果干净得多。
一个具体的使用场景
上周我要处理一批 CSV 文件，需要把每个文件里的日期列从 `MM/DD/YYYY` 改成 `YYYY-MM-DD`。我记得半年前写过一个类似的脚本，但记不清放在哪个项目目录里了。打开脚本搜索工具，输入 `csv` 和 `date`，两秒后列出七个结果。其中一个叫 `fix_dates.py`，打开一看，逻辑几乎完全匹配，只需要改一下列名。整个过程不到一分钟。如果没有这个工具，我可能得花二十分钟重新写一个，或者更糟——从头调试。
这种“我记得写过但找不到”的情况太常见了。写脚本的人往往不擅长整理文件，或者说，整理文件的成本比重新写一个还高。脚本搜索工具把整理这件事自动化了，你只管写，它负责记住。
不是所有脚本都值得索引
我试过把整个 home 目录加进去，结果索引了十几万个文件，大部分是 node_modules 里的 JS 和缓存文件。搜索变慢了，结果也杂。后来我改成只索引几个固定目录：~/scripts、~/projects/tools、~/dotfiles/bin。数量控制在两千个以内，搜索体验最好。
另一个坑是版本问题。同一个脚本可能存了五六个版本，`v1.py`、`v2.py`、`v2_fixed.py`、`v2_fixed_真的fixed.py`。搜索工具会把它们全列出来，你得自己判断哪个是最新的。有些工具支持按修改时间排序，或者标记“常用脚本”，能缓解这个问题，但没法根治。根本办法还是养成习惯：确定最终版之后，把中间版本删掉或者移到一个 `archive` 目录里，不让它们进索引。
值不值得折腾
如果你手头只有十几个脚本，文件夹结构清晰，那确实没必要。但如果你写脚本超过一年，存了上百个文件，又经常需要复用旧代码，那花半小时配置一个搜索工具，后面能省下大量翻找的时间。我自己的感受是，它降低了我复用代码的心理门槛——以前想到“找一下之前那个脚本”就觉得麻烦，干脆重写；现在搜一下就有，更愿意先搜再写。
工具本身不复杂，核心就是索引加搜索。但用起来之后，你会发现自己写脚本的习惯也在变：命名更随意了，因为知道反正能搜到；反而更愿意写小工具了，因为复用成本降低了。这算是意外收获。