这篇整理一下现在的 ACG 和音乐管理方案。

这一类内容和 Movie & TV 不太一样。电影、剧集更适合做成统一的媒体库：文件、刮削、海报、字幕、播放入口都可以围绕 Emby 收束。但 ACG 会分散得多：动画有新番订阅和字幕，漫画有章节更新和多端阅读，小说有书源和阅读进度，游戏有安装包、平台和设备，音乐又横跨几个流媒体平台。

所以这里的核心目标不是把所有东西塞进一个工具里，而是按内容类型拆开处理：

  • 连载中的内容优先保证更新及时；
  • 已完结的内容优先保证归档稳定；
  • 需要长期保存的内容尽量回到 NAS 或网盘；
  • 成人向内容单独隔离，不和普通库混在一起；
  • 音乐按平台分工，保持歌单和收藏入口清楚。

这样整理之后，ACG 就不再是一堆散落在网盘、阅读器、下载目录和浏览器收藏夹里的东西，而是变成几条相对稳定的链路。

Anime

动画这部分基本按「已完结」和「未完结」分开。

已完结动画的重点是收藏质量。资源入口可以来自 Dmhy、PT 或其他归档来源，下载和转存之后先用 115 做远端保存，再通过 115desk 和 mpv 做播放验证。字幕这一步单独处理：如果内封、外挂字幕不完整，就用 U2、A 站字幕等来源补齐，再用 subrenamer 对齐文件名。

这条链路大致是：

发现资源
  -> 下载或转存
  -> 115 保存
  -> 115desk / mpv 播放检查
  -> subrenamer 处理字幕名
  -> Emby 入库

已完结内容不需要特别追求速度，更重要的是版本、字幕和命名稳定。动画最容易出现的问题是字幕文件和视频文件对不上，或者不同字幕组的季度、集数、OVA 命名不一致。前面处理干净，后面 Emby 扫描出来才不会变成一堆散集。

未完结动画则更看重自动化。现在主要用 ani-rss 订阅蜜柑，把新番更新尽量自动拉进来，再通过 openlist、115、115desk、mpv 和 subrenamer 做后续播放与整理。新番的特点是每周更新，手动找资源很快就会变成重复劳动，所以订阅和自动转存是主线。

未完结内容的流程更像这样：

蜜柑订阅
  -> ani-rss 监控
  -> openlist / 115 接入
  -> 115desk / mpv 播放
  -> subrenamer 修正字幕
  -> Emby 展示

原盘、动画电影和国漫单独看。它们不一定适合完全走新番订阅，更多时候要从网盘、HDlive、盘搜或 PT 里找合适版本。这里更像是补库：看到想收藏的版本，再手动确认画质、字幕、音轨和体积，最后再归档。

成人向动画不进普通库，直接放到 NAS 的独立库里。这里的重点不是自动化，而是边界清楚：单独目录、单独库、单独权限，不参与普通动画库的首页推荐和搜索。

Comic

漫画的核心是多端阅读。

现在 iOS 端主要用可达阅读器和 Tachimanga，Windows 端用 Rulia 和 Suwayomi，Mac 端则是可达阅读器加 Suwayomi。这样分配之后，每个设备都有合适的入口：手机和平板适合追更，电脑适合整理和补旧章节，NAS 和 WebDAV 负责把已完结内容沉淀下来。

已完结漫画的目标是归档。

这部分通常走 WebDAV 加可达阅读器。漫画下载或整理完成后放到 NAS，再通过 WebDAV 挂到阅读器里。旧章节可以从网盘、闲鱼、PT 或网站补齐，整理完之后统一同步到 NAS。这样做的好处是，漫画不依赖某一个在线站点，只要 NAS 还在，书库就能继续读。

已完结漫画比较适合按作品维度整理：

Comic/
  作品名/
    Vol.01.cbz
    Vol.02.cbz

或者按话数整理：

Comic/
  作品名/
    Chapter 001.cbz
    Chapter 002.cbz

关键是不要卷版、话版、扫图版混在一个目录里，否则后面同步到阅读器时很容易重复、跳章或者排序异常。

未完结漫画和成人向漫画更适合走在线订阅。Tachimanga 负责订阅站点，旧章节从网盘或闲鱼同步到 NAS，最新章节则直接看在线更新。这样既保留了旧章节，又不用每次更新都手动下载。

漫画这类内容不适合过度追求统一工具。它的更新源、汉化组、卷话命名、图片质量差异都很大，能做到「追更方便、完结可归档、不同内容分开」就已经够稳定。

Novel

小说的管理比漫画轻，但更依赖书源和阅读进度。

未完结小说现在主要用阅读服务器版订阅。连载小说的重点是更新提醒和阅读连续性，不太适合每次都手动找 TXT 或 EPUB。只要书源能稳定更新，阅读服务器版就可以作为主入口。

已完结小说则放回山丘阅读和 NAS 书库。来源可以是已有书库、书香门第、Z-Library、安娜的档案，或者网盘、闲鱼、贴吧等地方补齐。整理时更关注格式和命名：同一本书尽量只保留一个主版本，番外、精校版、实体书版可以在文件名里标清。

我的习惯是把已完结小说当作真正的书库来处理：

Novel/
  作者名/
    书名.epub
    书名 番外.epub

这样后面不管换阅读器，还是迁移 NAS，都比较容易。

成人向小说单独放一个入口，主要走网站阅读或独立归档。和动画、漫画一样，这部分不和普通小说库混在一起。内容类型一旦混库，后面搜索、推荐和同步都会变得很麻烦。

Game

游戏这部分不太像媒体库，更像一个来源和安装包管理问题。

正版平台还是主入口。SteamTools 负责补齐入库体验，Steam 本身负责启动、更新、云存档和手柄支持。能走平台的游戏优先走平台，因为后续维护成本最低。

网盘和论坛入口主要用来补充非平台内容。这里更关注文件是否完整、版本是否清楚、DLC 是否齐全、安装路径是否好迁移。和影视不同，游戏归档不能只看文件名，还要关心运行环境、补丁、存档和启动方式。

BT 入口适合体积大、版本固定的游戏包。下载完成之后不要急着散放在下载目录里，最好按平台和类型归档：

Games/
  PC/
    游戏名/
      installer/
      patches/
      saves-backup/
  Switch/
    游戏名/

Switch 单独处理。它和 PC 游戏的安装、补丁、存档、设备环境都不同，混在同一个目录里只会增加整理成本。

游戏管理的目标不是像 Emby 那样展示得漂亮，而是以后想重装、迁移、补丁或找存档时能找得到。尤其是大型游戏，重新下载一次成本很高，所以目录结构和版本说明比封面海报更重要。

Music

音乐这部分先不做本地大一统，而是按平台分工。

YouTube Music 适合找动画、游戏、现场、翻唱和一些平台曲库不完整的内容。很多 ACG 相关音乐并不是正规专辑形态，或者只有视频、Live、剪辑版、上传版，这时 YouTube Music 反而更容易找到。

网易云更适合中文环境下的收藏、评论和部分国内曲库。它不一定是最完整的音乐库，但对中文歌、ACG 歌单、用户整理歌单来说仍然很方便。

Spotify 更偏向发现和跨设备播放。它的推荐、歌单、客户端体验比较稳定，适合日常听歌和探索相似风格。

Apple Music 则更适合作为高质量收藏入口。无损、资料库、专辑管理和 Apple 设备之间的体验都比较完整，适合把真正想长期听的专辑收进去。

这几个平台不需要强行统一。更实际的做法是给它们分工：

YouTube Music：找稀有曲、Live、翻唱和视频源
网易云：中文环境、评论和用户歌单
Spotify：日常推荐和跨设备播放
Apple Music：高质量收藏和长期专辑库

音乐管理最怕的是每个平台都收藏一点，最后自己也不知道哪边才是主库。现在的思路是：发现可以分散，长期收藏尽量收束。听到喜欢的歌可以先在任何平台标记，但真正想长期保留的专辑或歌单，最后要回到一个主入口里。

内容隔离和长期维护

把这些内容拆开之后，整个系统大概变成几条线：

  • Anime 走订阅、字幕、115、Emby；
  • Comic 走阅读器、WebDAV、Suwayomi、Tachimanga；
  • Novel 走阅读服务器、山丘阅读和 NAS 书库；
  • Game 走平台、网盘、BT 和独立归档；
  • Music 走 YouTube Music、网易云、Spotify、Apple Music 分工；
  • 成人向内容单独目录、单独入口、单独权限。

这里最重要的不是某一个工具，而是边界。

动画和影视可以进 Emby，漫画和小说更适合阅读器，游戏要按平台和安装包管理，音乐则优先交给流媒体平台。每类内容都有自己的最佳入口，硬塞进同一个系统只会增加维护成本。

现在这套方案已经基本覆盖日常需求：新内容有订阅，旧内容能归档，多端阅读和播放都有入口，特殊内容也不会污染普通库。后续如果继续优化，重点应该是减少重复整理，比如统一命名规则、定期检查 NAS 目录、给游戏安装包补版本说明，以及把真正重要的音乐收藏慢慢收束到一个主库里。

ACG 内容太分散，想一次整理到完美很难。但只要把「追更、归档、阅读、播放、隔离」这几个动作分清楚，后面就会轻松很多。它不再是一堆临时入口，而是一套可以长期维护的个人内容系统。