文件结构其实很难承担大规模资料管理。
资料少的时候，建立几个文件夹就够了。电影放进电影，小说放进小说，音乐放进音乐，再认真一点，还可以在文件名里加上年份、作者、类型和版本。只要格式足够整齐，看上去就像是已经完成了管理。
但数量一多，这套结构几乎一定会失控。
一部作品可能同时属于某个作者、某个系列、某种题材和某个年代；它可能来自百度云，也可能来自 115 或爬虫；可能有原始版、精校版和重新排版版；还可能关联封面、评论、评分、阅读进度和其他人的推荐。文件夹只能让它出现在一个位置，现实中的关系却远远不止一种。
在文件名里不断追加标签，也只是把问题推迟。标签越来越长，命名规则不断变化，重复文件无法判断，移动目录还会破坏旧索引。最后我们得到的不是资料库，而是一片勉强知道里面有什么、却越来越不敢整理的文件森林。
这就是所谓的“仓鼠症”。它很难真正治好，因为问题不只是舍不得删除，而是网络一直在产生值得保存、可能消失、以后也许会用到的内容。
真正需要改变的，不一定是收集本身，而是管理资料的方式。
从网络回到本地
个人资料库的第一步，是把散落在网络上的内容重新归档到本地。
不同渠道适合获取不同的东西。115 更适合承接体积较大的影视资源和种子资源；百度云更常见的是资料、分享作品、精校小说、音乐和各种整理包。它们解决的是已经有人整理、已经有人分享的部分。
剩下的大量内容，仍然要依靠爬虫。
Python 可以请求网页、解析内容、下载文件，也可以完成后续的数据清洗。但爬虫从来不只是“发一个请求，然后保存”。网站会有频率限制、登录状态、接口签名、动态渲染和反自动化机制。普通请求无法完成时，就会进入无头浏览器、页面自动化、模拟交互和人机验证处理这一层。
当然，能抓取不等于可以无边界地抓取。公开范围、个人使用、版权、隐私和网站规则，仍然决定了一套工具应该在哪里停下来。
爬虫和反爬总是一起出现。早期许多小说网站的基本逻辑就是从其他来源抓取内容，清洗后入库，再通过网页提供检索与阅读。当爬虫越来越多，反爬也就成为网站基础设施的一部分。这不是偶然的攻防，而是数据只要能产生价值，就一定会围绕获取权形成边界。
因此，爬虫脚本本身也需要保存。网页会改版，接口会失效，但脚本中沉淀的字段理解、页面结构和处理规则仍然有价值。清洗脚本同样如此：修正章节、统一编码、整理段落、重命名文件、提取元数据、生成封面，这些看似只是一次性的脏活，实际上都是资料库的生产工具。
一套资料库保存的不应该只有最终文件，还应该保存它们是怎么被获取、怎么被清洗，又经过了哪些处理。文件是结果，脚本和规则是生产结果的能力。
下载只是开始，清洗才产生价值
从网络拿到的数据通常不能直接使用。
标题可能有广告，作者可能有多个别名，日期格式不统一，同一个作品可能重复下载，图片和正文可能无法对应，文件名里还混着网站名称、群号和推广信息。更麻烦的是，两个文件看起来不同，实际上可能只是压缩方式、清晰度或排版版本不同。
于是下载之后，真正耗费时间的工作才开始：
- 判断相似性和重复项；
- 统一标题、作者、日期、编号与格式；
- 把本地文件和网络来源对应起来；
- 提取人物、系列、题材、标签和封面；
- 标记原始版、清洗版、精校版和派生版本；
- 保留无法确定的原始信息，等待以后重新处理。
这部分工作很脏，却是整个系统里价值密度最高的部分。
未经清洗、又可以重复获取的通用数据，通常不值钱。网络上到处都是文本、图片和视频，真正稀缺的是经过筛选、去重、校正、关联和持续维护的数据。一个下载目录只有占用空间的成本；一个清洗完成、随时可以搜索和复用的数据集，才开始成为资产。
数据库不是仓库，而是文件的语义层
数据库天然适合管理关系。
但这并不意味着要把几十 GB 的电影、音乐和图片全部塞进数据库。对个人本地系统来说，更简单可靠的方式通常是：文件系统继续保存实体文件，数据库保存路径、元数据和关系。
换句话说，硬盘是仓库，数据库是目录、索引和说明书。
数据库可以知道某个文件对应哪部作品，作品关联哪些人物、系列和标签，封面来自哪里，本地是否存在，有没有看过，看到哪里，是否收藏，以及它在某个榜单中排第几。文件即使仍然散落在不同硬盘上，只要路径和身份关系稳定，就可以在同一个界面里被找到。
大型公司可以使用对象存储、分布式数据库、内容分发网络和多级缓存。它们能够获得更好的扩展性和访问速度，但也引入了复杂的存储桶、权限、迁移和一致性问题。个人本地系统没有必要照搬这套方案。
本地更需要的是一套特殊但稳定的规则：原始文件尽量保持可直接读取；目录允许按大类、来源或磁盘容量组织，但不要试图表达所有分类；数据库记录文件身份与位置；封面、缩略图、转码文件、全文索引和向量索引都视为可以重新生成的派生数据。这样即使数据库暂时不可用，文件也没有被锁死在系统里；即使文件移动了，也只需要重新扫描和修复映射。
原始数据、清洗后的数据和展示数据也最好分开。原始数据尽量只增加，不直接修改；清洗层负责统一格式、去重、匹配和补充信息；展示层再根据网页、手机、电视或其他设备的需要，生成封面、缩略图和转码文件。
清洗规则会变化，脚本也会出错。保留原始数据，意味着以后仍然可以用新的规则重新处理。派生数据则应该允许随时删除和重建，而不是和唯一的原始文件混在一起。
我做的 FanHao，本质上就是这套思路的一个实验。
它扫描本地磁盘上的作品、影视、套图、小说、短视频和音乐，再通过网页和手机端展示。核心数据库把作品、本地文件、人物、系列、厂商、图片和外部来源关联起来；小说、短视频、音乐和图库分别使用适合自身结构的 SQLite 数据库；收藏、观看历史、播放进度和手动封面等用户状态则独立保存。
这里最重要的不是用了几个数据库，而是本地文件第一次获得了文件夹之外的关系，也开始拥有稳定的身份。
一部作品不再只是 D:\某个目录\某个文件.mp4。它可以同时属于某个人物、某个系列、某个榜单和某个收藏夹；可以拥有网络元数据、本地封面、评分、播放记录与外部页面；网页和安卓端看到的是同一套数据，而不是两份重新整理的文件列表。
只要身份还在，文件换了硬盘、移动了目录，甚至重新下载了另一个版本，都可以重新建立关系，而不是从头整理。
数据库不是为了替代文件，而是给文件增加语义。
资料不应该只有一种分类
如果只按媒介类型划分，个人资料大致可以分成几类。
文字类包括小说、PDF、严肃文学、资料、网页正文、抓取的评论，以及微信等聊天记录。聊天记录看上去只是对话，实际上还包含人物关系、时间、事件和大量个人语境，是非常特殊的长期数据。
图片类包括下载的图集、AI 生成的图包、作品封面、地图、截图和扫描件。它们既可能独立存在，也可能只是小说、音乐、人物或影视作品的附属资产。
声音类包括音乐、有声书、录音和其他音频。音乐内部又可以继续关联歌手、专辑、流派、歌词、版本、播放次数和收藏状态。
视频类最复杂。抖音、B 站、YouTube 等平台上的短视频应该和长视频分开，它们的获取方式、浏览方式、元数据和保存价值都不同。长视频中又有电影、电视剧、短剧、动漫和 AI 作品。VR 视频、3D 视频是特殊分支，需要额外记录视角、格式和播放设备。医疗 3D 数据、建模文件虽然也和三维内容有关，但已经更接近专业资料或工程资产，不能只当普通视频处理。
成人内容、动漫等更适合作为题材和内容域，而不是底层存储类型。否则同一部作品到底应该进入“视频”“动漫”还是“成人内容”，很快又会回到文件夹只能选择一个位置的问题。
游戏则更特殊。Steam 出现以后，大部分仍在正常发行的游戏可以交给平台管理，联网下载通常比个人归档更可靠。真正值得重点保存的，是已经停止运营、从商店消失的作品，Flash 游戏，难以再次获得的小众游戏，以及它们依赖的运行环境、补丁和说明。游戏保存的不是一个媒体文件，而是一套能够再次运行的环境。
工具和软件也是如此。安装包只是其中一部分，版本、依赖、许可证、配置、使用说明和配套脚本往往同样重要。
所以，媒介类型只能回答“它是什么”。一个真正可用的资料库还要回答更多问题：
- 它从哪里来；
- 讲什么主题；
- 处在原始、已清洗还是已校验状态；
- 是否涉及隐私或访问权限；
- 是否可以重新下载；
- 为什么值得长期保存。
文件夹适合保存物理位置，标签和关系才适合表达这些维度。
点赞、评论和收藏，本质上都在给数据打标
资料进入数据库以后，就可以不断追加新的关系。
评论是文字标注，点赞是偏好标注，收藏是价值标注，播放进度是行为标注，关注是人物关系标注，转发则同时包含兴趣和社交传播。单独看，每次操作都很轻；聚合起来，它们就会把优秀的作品从海量内容里筛选出来，于是可以形成排行、推荐和趋势。
这也是我理解字节跳动价值的一种方式。
平台不只是拥有大量视频，更重要的是无数用户一直在替它处理数据。每一次停留、划走、点赞、评论、收藏和转发，都在为内容增加新的标签。用户一边消费数据，一边又生产训练推荐系统所需要的数据。看上去是在刷视频，实际上也在参与一条巨大的数据清洗和标注流水线。
微信的逻辑又不完全相同。微信更接近身份、关系和通信基础设施，比内容平台更底层，因此拥有更牢固的位置，也承受更多公共性和社会关系上的约束。有些内容平台能做、敢做的事情，基础设施型平台未必适合做。
同样，在我看来，阿里的核心也不只是购物页面，腾讯的核心也不只是游戏产品。购物和游戏是表层业务，下面分别连接着交易、支付、物流、账号、关系、分发和云服务。真正形成壁垒的，往往不是某一个页面，而是页面下面那套长期积累的数据与基础设施。
这也解释了为什么今天的手机软件越来越相似。大家都想做购物、短视频、小贷和 AI，并不只是缺乏想象力，而是手机能够承载的基础对象已经非常稳定：文字、图片、声音、视频、关系、交易和位置。产品的差异不再主要来自页面上还能放什么，而来自它能获得什么数据、如何处理这些数据，又能用处理结果驱动什么新的行为。
AI 也没有创造一种全新的基础数据。它更像是加入了一个更强的处理层：理解原有数据，重新组合原有数据，再以更低的成本生成新的数据。
一套资料库的完整流水线
如果把具体内容全部拿掉，所有资料系统最后都可以抽象成几件事：
- 产生数据；
- 获取数据；
- 处理和清洗数据；
- 保存数据；
- 展示数据；
- 导出和迁移数据。
处理数据嵌在产生和保存之间。展示与导出落在存储系统之外，却决定了前面的工作有没有意义。
只保存而无法检索，等于没有保存；只能在某一个软件里查看而无法导出，则只是把资料从一个平台搬进了另一个平台。真正属于个人的数据，应该能够被搜索、关联、备份、迁移，并在需要时以网页、手机、文件或接口的形式重新使用。
AI 改变的是个人定制系统的成本
过去，个人并不是完全做不了资料库。Calibre、Kodi、Jellyfin、NAS 和各种爬虫工具早已存在，也一直有人自己写脚本、建网站和整理数据库。
真正的问题是，这件事需要跨越太多技术领域：写爬虫、设计数据库、清洗数据、开发后端、制作网页和手机端，还要长期维护不断失效的脚本。大型公司可以把工作分给不同的人；对个人来说，任何一个环节都可能让项目停下来。
AI 改变的不是这件事是否可能，而是个人定制系统的实现和维护成本。
它可以帮助个人写抓取和清洗脚本，分析陌生格式，设计数据库表，生成管理页面，修复批处理任务，再把同一套系统接到网页和手机端。许多过去因为工作量太大而停留在想法里的事情，现在可以先做出一个能运行的版本，再一轮一轮补全。
多端同步也不一定意味着把全部原始文件上传到云端。更合理的方式可以是：大文件留在本地，数据库和必要状态进行备份，局域网内直接访问，需要时再开放受控的远程入口。手机是浏览器和控制器，电脑或 NAS 才是资料真正落地的地方。
AI 不能替代人的判断。什么值得保留，什么应该删除，哪些数据可以抓取，哪些信息涉及隐私，两个相似文件是不是同一作品，这些仍然需要长期形成的标准。但 AI 可以把判断之后的大量重复劳动变成脚本，并把脚本继续沉淀成工具。
这使个人资料库不再只是大型机构才能完成的工程，而成为一个人也可以持续迭代的系统。
从占用空间到形成记忆
仓鼠症也许无法解决，也未必一定要解决。
真正的问题不是保存得太多，而是保存之后再也找不到，不知道为什么保存，也无法从这些内容中产生新的关系。未经整理的文件只是在占用硬盘；经过清洗、关联和标注的数据，才可能形成个人的记忆、审美、知识和判断。
严格来说，并不是所有原始数据都不值钱。已经消失的网站、不可重复采集的记录、历史版本和私人资料，本身就很珍贵。
但对那些随处可见、可以重复下载的内容来说，单纯保存一个文件，价值通常非常有限。
对于可以重复获取的内容，数据本身不值钱。
清洗之后的数据，非常值钱。
而对个人来说，它的价值不一定表现为出售或商业化。它可能只是让我多年以后仍然能找到一部消失的作品，重新打开一本小说，回顾一段聊天，知道自己当时喜欢什么、相信什么，又是如何一步一步走到现在。
从网络归档回本地，只是第一步。
最终要做的，是让散落的文件重新获得关系，让保存下来的数据真正成为自己的东西。