分类还是打标签：构建不易崩塌的个人信息层级

无限嵌套与标签爆炸的双重困境

整理个人知识库或文件系统时，人们往往容易走入两个极端：一种是痴迷于构建精细的文件夹树状层级，建出“工作/2026/项目A/阶段一/会议/外部/初稿”这样深达七八层的目录，导致每次存取文件都要经历繁重的层级穿梭；另一种则是彻底放弃文件夹，试图用几十上百个标签来组织一切，最后因为同义标签泛滥（如“AI”、“人工智能”、“LLM”并存）而彻底失去检索控制。

这两种崩溃的根源，在于没有分清文件夹与标签在信息架构中的根本职责。文件夹代表排他性的“物理归宿”，用于限定范围与生命周期；标签代表非排他的“动态维度”，用于跨领域穿透与状态标记。唯有让二者各司其职，系统才能在数据增长中保持稳固。

文件夹法则：宽目录、浅层级与排他性归宿

文件夹的核心原则是“单选题”：任何一份文件在任意时刻只能存在于一个文件夹中。因此，文件夹分类必须极其粗放且边界清晰，层级尽量控制在两层以内。可以参考经典的 PARA 或类似结构，将顶层目录限制在 4~6 个（如：01_正在推进的项目、02_长期维护的领域、03_可复用的参考资料、04_已结束的历史归档）。

不要为偶发的小主题新建文件夹。当你犹豫一份文件该放进文件夹 A 还是文件夹 B 时，通常说明这两个文件夹划分得太细了。将它们合并为一个更宽泛的目录，检索时依靠现代文件系统的全文搜索往往比人工逐级翻找快得多。

• 知识库的文件夹层级是否严格控制在 2~3 层以内？
• 顶层分类是否少于 6 个且彼此不重叠？
• 保存文件时是否能在 3 秒内决定放入哪个目录？
• 标签总数是否控制在可一眼扫过的极少范围？

标签法则：极度克制，只用于状态与跨界连接

标签的最大陷阱是“描述内容是什么”。如果你有一份关于 Python 数据分析的笔记，在笔记正文里已经包含了 Python 和数据分析这些词汇，此时再打上“Python”“数据分析”两个标签其实是完全冗余的，全文检索即可覆盖。

标签真正无可替代的价值在于标记那些无法从正文中自动提取的“元信息”与“临时状态”。例如：“待核对”（状态维度）、“核心原则”（价值维度）、“对外演讲素材”（场景维度）。全库的活跃标签数量应严格限制在 10~15 个以内，只保留那些会定期被聚合查看的行动标签。

场景示例：搭建一套技术文档与票据资料库

设想你需要管理数百份学习笔记、工作草稿与电子发票。低效的设计是建立“学习/前端/React/hooks”与“财务/报销/2026/8月”这种深度目录，外加给每篇笔记打上五六个主题标签，随着时间推移系统很快无人维护。

稳健的设计是：文件夹仅设 3 个：Projects（当前项目）、Resources（参考库，按大领域分 4 个子目录）、Archive（历史归档）。所有发票放入 Resources/财务凭据，依靠文件名（如 2026-08-14_高铁票_Daniel.pdf）实现日期与主题自解释；笔记放入对应领域，仅对当下需要报销或修改的条目打上“待报销”或“待修改”状态标签。当报销完成后移除标签，资料自然沉淀在物理目录中，秩序井然。

避免系统老化的“防腐测试”

如何判断当前的分类标签体系是否健康？进行一次简单的压力测试：回看过去三个月中，你是否真正点击过某个标签来完成一次检索或行动？如果有某个标签创建了三个月从未被点击调用过，它就是纯粹的认知负担，应立即批量删除。

同样，如果在保存新内容时经常感到犹豫和焦虑，说明分类规则已经超出了你的日常心智承载力。此时最有效的操作不是重新设计一套更复杂的宇宙分类法，而是大刀阔斧地将小文件夹合并，重新恢复扁平化。

好架构的标志是“用最少规则运转最久”

一流的信息架构往往看起来甚至有些“粗糙”：几个简单的大文件夹、极少数几个状态标签，配合强大的搜索工具与规范的文件命名。它不会要求你在每次保存资料时都填写繁复的元数据，却能保证在一年后、三年后依然能毫不费力地找回所需。

把精力从折腾分类系统中抽离出来，投入到对内容的实际阅读、理解与产出中去。工具是用来服务思考的，而不是用来被供奉的。