html
Windows 搜索一直时好时坏，而在繁忙的工作日，最不想碰上“失灵”的情况。当你确切知道要找什么时，搜索栏表现尚可，但如果你想找一个只依稀记得的文件，比如上周四编辑的那个，或者几周前名字里某个地方带“Xbox”的图片文件，那你就得使出浑身解数，靠天大的运气才能找到它。
出于好奇，我想看看能否通过构建一个工具来解决这个问题，这个工具能根据我用自然语言描述文件的方式来查找文件，于是我决定带着这个问题去找 Claude。我现在敢说，我用的就是最好用的文件浏览器，就因为它不会动不动就让我用 Bing 搜，也不用我费劲去记自己瞎起的文件名。
它解决了什么问题？
Windows 搜索的关键问题不在于它完全坏了。问题在于它半生不熟，就可用性而言，这可以说更糟。临时想找个文件，通常感觉就像非得记起确切的名字不可，或者它所在的文件夹，或者至少得记得里面某个特别的字眼。这本来应该是搜索工具帮用户省心的，结果倒好，它又把麻烦推回给用户了。
可用性先驱雅各布·尼尔森的第六条可用性启发式指出，用户应依赖辨认而非记忆，这完美地抓住了问题的关键。理想情况下，搜索界面应通过呈现相关信息来减轻记忆负担，而不是期望用户独立回想。我构建的（或者说构思的）基于Python的工具正是以这种方式运作，它就是灵光一闪想到的：“如果我能向一个具有更广泛文件系统访问权限的LLM描述我正在寻找的文件，它就能轻松找出来。”有了个大概框架后，我将这个想法交给了Claude。
就像给我电脑装了个搜索引擎
Haiku负责解析，SQL接着查
设计理念讲完之后，我来解释它是如何运作的。我可以让它扫描一个大文件夹，让它索引内容，然后用大白话描述文件。它会获取该描述，将其传递给Claude Haiku以提取意图，并在本地SQLite数据库里查一下，结果眨眼间就出来了。
Haiku 处理查询的方式，是它比普通关键词搜索更管用的一个原因。它不是去扫子字符串，而是把纯文本描述变成一个过滤器，然后从里面把文件类型、日期范围、大小限制和关键词单独拎出来，再拿这些参数去拼一条精准的 SQL 查询。
为了让你看看它好在哪，我在同一个建好索引的目录里跑了两次搜索。这个目录里有一个电子表格和一张出版计划表的图片。搜“publishing schedule”时，两个文件都会出来，跟想的一样；但搜“publishing schedule, saved as an image”时，就只蹦出那张图片。
对于不想用 API 密钥就想搞定这事儿的人来说，本地有个备用解析器，不连外部网络也能处理基本查询，应付大多数场景下的简单描述绰绰有余。我倒觉得带 Haiku 的版本更有意思，它能搞定同义词、换个说法，还有多条件查询，这些本地解析器都玩不转。
这玩意儿快得飞起，好用得很，而且才 30KB
就 820 行代码，却藏着能改变人生的玩意儿
我之前搞的这个工具，老版本有个毛病——太慢。给真实的 Windows 目录建个完整索引，慢到让人抓狂，反而帮倒忙。重写之后，这问题就彻底搞定了。
在一个有87,000个文件的目录里，第一次搜索大概2.6秒就能跑完，之后每次基本不超过0.2秒。这工具默认还会跳过Windows系统文件夹，比如Windows、Temp和回收站这些，这样一来，C盘上实际要扫的文件数就能少一大截。整个工具也就30KB左右，代码量才820行Python。就冲它在自然语言搜索上能把Windows Search甩出几条街，这点占用空间简直不值一提。
这个问题的解决办法，本来就不可能出自微软自己。
微软嘴上把AI和Copilot当成了操作系统的头等大事，可在处理用户天天碰到的那些使用麻烦上，却好像有个特别让人摸不着头脑的死角。用户为啥成批地卸载、到处找办法关掉AI服务？这背后是有原因的，多半跟它怎么落地部署脱不了干系。只要用点基本的用户体验常识，再配个轻量级语言模型，就能搞定几百万用户天天吐槽的痛点，关键就是把AI用在刀刃上。可偏偏微软，砸了这么多钱进去，到现在还没整明白。
热门跟贴