我看了 #20 就知道问题在哪了
> 只能说这些功能一般人都用不到
> 我们平时从几千个说明书搜一个出来
可见楼主说的“一般人”就是指自己
而这个"几千个说明书"很明显是某种专业用途,并不是“一般人”。当然搜索个说明书也没多专业，勉强可以算是“一般人”，但是为什么就断言其他“一般人”就用不到了呢？
#38 提到“记不得哪篇文章里面提到了某个关键字”，这就是一个典型的场景。
再者，“文件名搜索”并不是所有搜索都应该做的基础功能。我拿苹果来实践一次 Whataboutism：
iPadOS 13.5.1，首屏两个应用 Photos 和 Overcast，下滑调出搜索，输入 “otos”，下面是 "SIRI SUGGESTED WEBSITES"，输入“cast”，下面是 iPadOS 内置的”PODCASTS“ App 搜索。俩 App 都没给我搜出来
要想用这种方式搜出 App 得多打几个字，比如”vercas“才能搜出”Overcast“，然后假设我打错了一个字，比如”iverc“，这时是搜不出来的，”iverca“可以。
你看一个设备，顶多装几百个 App，都能搜成这德行，怎么能指望“游戏机系统“做全盘的文件名搜索呢？
我这 Mac 的 Spotlight 就更别提了，用五次 crash 一次，也并不能保证文件名能搜到，甚至有的时候啥也搜不到。
为什么这些搜索做得这么烂？性能考虑仅仅是一方面。我个人认为根本在于它们都属于”面向傻逼的界面“，面向傻逼的界面试图让人远离机器，试图让用户感知到这个设备 /系统是“智能”的。
也就是说，面向傻逼的界面致力于做到“用户告诉我想要什么，然后我告诉用户用户想要的”——这根本就不是现在的科学能解决的问题，这是 AGI 才能解决的。
写不出 AGI，又不想使用地球现有的 76 亿 AGI 的前提下，这问题无解。所以面向傻逼的界面往往发布会上很厉害，很“智能”，实际使用的时候只会让人感觉“聪明的人都是类似的，笨的机器却各有各的笨法”。
面向傻逼的界面是没有前途的。
（其实就算有了 AGI 也好不到哪去，领导把事情布置下去，然后下面一般是往“讨领导高兴”的方向干，而不是真去干事）
我只打个“verc”，你从 76 亿 AGI 里面拉出来猜，有几个猜得出我要找的是 Overcast ？面向傻逼的界面致力于做到“用户告诉我想要什么，然后我告诉用户用户想要的”，人都猜不出你想要什么，怎么能指望面向傻逼的界面猜出来？
如何解决面向傻逼的界面的问题？
我个人并无什么高见，我的风格是如果解决不了问题，那就逃避问题（如果觉得“逃避”有些不合适的话，可以换个词，比如“绕过”）。也就是说我并不解决面向傻逼的界面的问题，我直接放弃“面向傻逼的界面”，我认为“面向傻逼的界面”这个需求存在根本性的错误。
乔布斯几十年前说，计算机是“bicycle of mind”。我很认同这句话，只是可能需要一些修改——几十年之后硬件和软件都爆炸式的发展，“自行车”用来形容功能机还可以，现代的计算设备早就发展成了三轮车、汽车、飞机甚至火箭了。就算是自行车也要学，其他工具的学习成本比自行车高得多。而“面向傻逼的界面”试图削平学习成本，这就相当于完全自动驾驶了。
做不到自动驾驶，又想开飞机，怎么办，学呗！也就是说，在“面向傻逼的界面”做不好的时候，做出妥协转而做“面向机器的界面”以及“面向‘有缘人’的界面”——不学佛法的人是无缘极乐世界的。
其实类似“全文搜索”，程序员还有"在代码库中搜索符号"的需求，针对这一需求，依次有： 普通全文搜索 => awk/ag/ripgrep 等编程语言、VCS 相关的全文搜索 => ctags 等符号索引工具 => 与编译器 /IDE 集成的查找引用 /查找定义功能多种方式，每一个层级都有其优缺点。但是程序员这一群体因其身份的特殊性，更善于使用不同的计算机工具，并且在使用工具时了解其功能定位甚至实现原理。对于不同的问题能选择合适的工具解决，所以这一套体系能跑起来。
其他人没这么幸运，只能在对“面向傻逼的界面”一次又一次的失望中像楼主一样“留下心理阴影”。
其实“文件”这个概念，不管是普通人的理解，还是所谓“UNIX 哲学”中的体现，都是在为效率拖后腿的。比如说，我这里有 100 个项目的源码，都是 git clone 下来的文件夹。电脑只知道有这些文件，并不能从文件结构中得出具体信息——比如这 100 个项目中有 10 个是编译器项目，10 个是各种操作系统源码，还有 10 个是各种论文的开源代码，并且用的语言各不相同。我现在可以分三个文件夹“compiler”“os”“papers”，问题来了，我把代码对应的论文找来了，我是给论文单独放在一个文件夹里面呢（丢失文章 <=> 代码库之间的对应关系），还是把论文和对应的代码放一块呢（文章分散到各地需要靠搜索聚合起来）？ linux 和 git 都是 Linus 写的，一个是操作系统，一个是 VCS，我是单独起一个“linus”文件夹放呢（但是我想找 OS 源码的时候就找不到 Linux 库了），还是把 linux 放在 os 文件夹里面，git 放 VCS 文件夹里面呢（丢失开发者信息）？ tikv 和 redis 都是数据库，我可以单独起一个“db”文件夹把他们俩放进去，但是恰好 tikv 和 redis 一个是 Rust 写的，一个是 C 写的，并且都是非常好的 Rust/C 项目。我现在想做一个“优秀的 Rust 代码库”和“优秀的 C 代码库”做参考，那就得把 tikv 从 db 文件夹里面挪出来？
可见“文件”本身的抽象能力就是非常不足的。建立在其上的大厦自然也就根基不稳。解决这个问题，最简单的给文件加入元数据——给 Redis 打个 tag 是 C 写的，并且是个数据库，是 antirez 写的。那么 antirez 还写过什么项目？ kilo 不错。antirez 住在意大利西西里，这和一般看到的 “XXXXX, CA” 不一样，interesting ... 这么下去就是个数据库了，“文件”也就没有存在的意义了。
而在搜索的时候，自然也会变成”项目名中包含‘nux’的所有操作系统项目”（看上去楼主想要的就是“朴素”的文件名查找，但是精确了许多——需要是一个软件项目，并且是个操作系统项目），“Star 数超过 31415 并且主要作者不在加州的开源软件”，“与编译器相关的所有书籍”。当然由于不是面向傻逼的界面，所以是以某种机器语言表示的。但是本质上就是把通用的搜索从“普通全文搜索”升级到了“与编译器 /IDE 集成的查找引用 /查找定义功能”而已。
@
tankb52 #32 关于这个，Raymond 还真写过一篇文章：
https://devblogs.microsoft.com/oldnewthing/20180521-00/?p=98795 Maintaining Notepad is not a full-time job, but it’s not an empty job either