北京
找一份几周前保存的文件，翻遍硬盘也找不到。Finder 的搜索在你知道文件名时还算好用，但当你只记得"这文件是讲什么的"，它基本帮不上忙。
有人换了个思路：不整理文件，而是让 Claude Code 给每个重要文件夹写一份 README。结果第一次测试，找同一个文件的时间从 260 秒降到 9 秒，降幅 96.5%。
做法并不复杂。README.md 本来是 GitHub 开源项目里常见的说明文档，用来交代项目包含什么、怎么运作。这套逻辑被搬到了个人电脑上：不是写一份包罗万象的大清单，而是搭一套层级结构。
主 README 像目录，指向各个重要文件夹里的子 README，子 README 再说明该文件夹里装了什么。关键要求是，这些文档不能只列文件名，而要描述文件实际讲的是什么，写进日常会用来搜索的关键词，还要说明分散在不同位置的文件之间是什么关系。
Claude 从主目录开始，先判断哪些文件夹值得深入，然后并行开了三个代理，分别查看桌面、下载目录，以及主目录下的项目和文档。翻查过程比预想的更费劲——课程作业、文章截图、代码项目、多年攒下的杂七杂八，还翻出了一些相当混乱的关联。
比如一些数据库管理的 SQL 文件，被放在一个叫 COAL 的文件夹里，而 COAL 其实是一门汇编语言课程的名字。这类命名，正是让文件搜索变成噩梦的根源。
探索完成后，Claude 先给出方案，说明哪些文件夹值得单独配 README、哪些由主索引覆盖。最终产出 7 份 README 和 1 份 CLAUDE.md。主 README 放在主目录作为入口，其余分别覆盖桌面、下载、文档、汇编语言课程作业，以及几个格外混乱的子目录。
CLAUDE.md 的作用不同。它不描述文件，而是告诉 Claude Code 怎么找文件：先看主 README，顺着链接进入更窄的索引，给出答案前先核实文件真实存在。这样后续会话就不必每次全盘搜索。
Claude 还对这套结构做了校验，最初发现 4 处引用问题，修复后报告全部 309 个链接和文件名引用均可正确解析。整个过程没有移动或重命名任何原有文件。
测试设计得比较克制。两个独立的 Claude Code 会话，跑同一个模型，都加上 --safe-mode 参数，禁用 CLAUDE.md、技能、钩子、插件等自定义项，避免刚写好的指令同时影响两边。第一组明确要求从主 README 出发、顺着子目录 README 走、最后核实文件；第二组则要求完全忽略 README，用常规文件系统搜索工具。
题目是一个大学时写的汇编程序，功能是显示带取款和存款选项的 ATM 菜单。文件名毫无描述性，就叫 labtask4.asm，埋在一个 DOS 文件夹里。除非事先知道位置，否则只能靠翻文件、比对内容来判断。
带 README 的那组用了 9 秒：查主 README，跳到 DOS 文件夹的 README，定位到具体文件，核实内容确实是那个 ATM 菜单，全程只用了两条 shell 命令。
不带 README 的那组，先在主目录里搜汇编文件，光这一步就花了近三分钟，中途还检查了一个不相关的汇编程序，等搜索加核实全部完成，已经过去 4 分 20 秒。两边找到的是同一个文件。
其余测试的差距没有这么夸张，但方向一致。八次测试里，用 README 的会话七次更快，一次打平。把显示耗时加总，带索引的搜索共 79 秒，不带索引共 382 秒，整体约减少 79%。第一次测试异常慢，占了差值的一大部分。
更让实验者意外的不是速度，而是搜索量本身少了。Claude 不再反复扫描目录、猜测命名含糊的文件里装了什么，而是先读一段简短描述，缩小范围，直接去核实相关文件。
遗留问题也很明确：这套系统怎么长期维护。再过一段时间，又会攒下几百个文件、更多命名离谱的文件夹，部分 README 迟早过时。实验者本人的整理习惯也没变好，桌面几周后大概还会恢复成灾难现场。但至少现在，找到想要的东西的概率高了不少。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
