我电脑里现在有大概四万个文件。这个数字不小，但我找任何东西的平均时间在十秒以内。这不是因为我有一套精妙的分类体系——恰恰相反，是因为我放弃了分类体系。
我试过的方法论，以及它为什么在我这里失败
三年前我认真实践过一套流行的四层目录法：把所有东西按「项目 / 领域 / 资源 / 归档」分开。我读了很多介绍文章，画了图，花了一个周末重排了整个硬盘。
它失败了。失败点非常具体，我记得清清楚楚：
我在写一份关于团队协作流程的文档。这份文档是为了某个具体项目写的（所以是「项目」），但它也是我长期关注的领域（所以是「领域」），同时它引用了三篇我收藏的文章（那些是「资源」）。我在那儿站了两分钟，决定不了它该放哪。
然后我做了一件很有代表性的事：我把它放到了桌面上。
接下来三个月，桌面上堆了六十多个这样的「决定不了放哪」的文件。一个分类体系的真实使用率，取决于它最模糊的那个边界有多模糊，而不是它最清晰的部分有多清晰。
现在的做法：四个顶层目录
我现在的整个用户目录下只有四个我自己建的文件夹：
inbox—— 所有新东西的落脚点。下载也直接指向这里。work—— 当前在做的事，一个事一个目录。archive—— 按年份分的封存区。ref—— 长期参考的东西，比如证件扫描件、模板、字体。
关键是 work 下面只有一层。一个项目一个目录，不许有子分类。如果一个项目内部复杂到需要子目录，那是那个项目自己的事，我不管。
目前 work 下面有九个目录。我的软上限是十二个，超了就说明我该封存一些了。
命名比目录重要得多
这是我这些年最大的转变。以前我把精力花在「放哪」，现在花在「叫什么」。
规则一：日期前缀
所有会产生多个版本的文件，都用 YYMMDD- 开头。比如 240718-协作流程草稿.md。
好处是天然按时间排序，而且我一眼能看出新旧。这条规则替我彻底消灭了 最终版、最终版2、真的最终版 这个古老的问题——因为日期不会撒谎。
规则二：名字里写清楚是什么，不靠目录提供上下文
我不再依赖「这个文件在哪个目录下所以它是关于什么的」。我要求文件名单独拿出来也能看懂。所以我的文件名会长，比如 240903-支付回调超时排查记录.md，而不是 排查.md。
这条的道理是：文件会移动，目录会重组，但文件名会跟着它一辈子。而且长文件名对搜索极其友好。
规则三：不用空格，不用特殊符号
纯粹是命令行的考虑。用连字符和下划线。我为此在三年前批量重命名过一次，花了半小时，之后再也没有为转义头疼过。
inbox 的规矩
这是整套东西的核心。所有新文件先进 inbox，不做任何判断。这一步是零摩擦的，因为判断被推迟了。
每周五下午我会花五到十分钟清 inbox。规则是默认删除：一个文件如果我不能在五秒内说出未来会用它做什么，就删。
实际比例大概是：七成删掉、两成移进某个 work 目录、一成进 ref。
我知道有人会问：删错了怎么办？删错过，大概一年三四次。三四次里有两三次是能重新下载的，另外一两次我损失了十几分钟。这个代价我认，因为它换来的是 inbox 永远不会变成第二个坟场。
归档：按年封存，不整理
项目做完了，整个目录原样扔进 archive/2025/，不整理、不精简、不重命名。
我以前会在归档时做一次「清理」，删掉中间产物、整理结构。后来放弃了，原因有两个：一是这个清理动作耗时且无聊，导致我拖着不归档；二是我发现自己回头翻归档时，要找的往往正是那些中间产物——某个当时的草稿、某个我改了三遍的配置。
归档的目的不是整洁，是把东西从视野里拿走，同时保证能找回来。 硬盘很便宜，我的注意力不便宜。
搜索优先，结构次之
说到底我这套东西的前提是：我主要靠全文搜索找东西，目录结构只是在搜索失效时的兜底。
所以我做了两件配套的事：一是尽量用纯文本格式，因为它可以被全文检索；二是给必须用二进制格式的东西（比如扫描件）配一个同名的 txt 说明文件，写几个关键词。第二件事有点土，但对我很有效。
代价
诚实地说三条：
- 这套东西不适合协作。我的命名习惯和扁平结构在多人共享的空间里会被同事讨厌，那种场合我老老实实按团队的规范来。
- 它依赖我的搜索工具。换到一台没有配好搜索的机器上，我的效率会明显下降。这是一个我接受的耦合。
- 它看起来不整齐。我的 work 目录截图出来不好看，没有那种漂亮的树状结构。我曾经很在意这个，现在不了——整齐是给别人看的，好用是给自己的。
如果只让我留一条建议：不要在「放哪」上花时间，把那些时间挪去起一个足够长、足够具体的文件名。三年前我要是懂这一条，能省下几十个小时。