写在前面
很多人在把 MoviePilot 跑起来之后，真正卡住的往往不是“搜不到资源”，而是下面这些更细碎、也更折腾人的问题：
- 为什么电影整理后会通知，电视剧却没通知
- 为什么已经下载完成了，但文件没有自动整理进媒体库
- 手动加到下载器里的种子，到底会不会被 MoviePilot 接管
- 目录明明都配了，为什么总是落到不想要的那个目录
如果你也在这些地方来回试错，这篇文章就是给你准备的。
上一篇文章我已经把订阅识别流程和规则执行顺序拆开讲过了，这一篇不再重复“规则怎么匹配”，而是把目录配置、通知逻辑、整理流程和 Webhook 触发机制一次讲清楚。
先说结论
如果你只想先拿结论，可以先记住这几条：
- MoviePilot 的通知不是一个总开关，而是全局通知开关 + 目录通知开关两层同时生效。
- 目录配置里如果有多个目录都能匹配，会优先命中排在前面的目录。
- 想让下载完成后自动整理，目录的“自动整理”方式必须配对，尤其是“下载器监控”。
- qBittorrent 的 Webhook 只是“加速触发整理”，不是唯一机制；即使不配 Webhook，定时任务也会兜底。
- 手动加到下载器里的种子，也有机会被自动整理，只要它最终落在 MoviePilot 正在监控的目录里。
目录配置：先决定文件会落到哪里
MoviePilot 在订阅时如果不手动指定目录，会按照目录规则自动匹配。
你可以把这个过程理解成：系统先看“这是电影还是电视剧”，再看“更具体属于哪一类”，最后再决定应该送进哪个目录。
常见的匹配维度通常包括：
- 媒体类型：电影 / 电视剧
- 媒体类别：国产剧、欧美剧、综艺、动画电影这类细分
- 存储类型：本地还是网络存储
- 同盘优先：源文件和目标目录尽量在同一块盘上
这里最容易忽略的，是目录顺序本身就是规则的一部分。
为什么目录顺序会影响结果
如果有多个目录都满足条件，MoviePilot 往往会优先使用配置顺序里更靠前的那个。
所以一个常见的错误写法是：
| |
这会导致“TV（全部）”把后面的具体分类提前拦走，结果国产剧、欧美剧这些目录几乎没有机会生效。
更合理的顺序应该是：
| |
一句话总结就是：具体分类在前，全部分类在后。
目录怎么配更省心
如果你想精细管理，可以给电影、电视剧都配完整分类；如果你更在意稳定和省事，反而建议简化。
一个比较实用的思路是：
- 电影保留一个“全部”兜底目录
- 电视剧只拆最常用的几个分类
- 其他都交给一个 TV 总目录兜底
这样做的好处是：
- 目录不会配得太复杂
- 错误匹配时更容易排查
- 后期维护成本更低
通知系统：为什么有时有通知，有时没有
MoviePilot 的通知逻辑，最容易让人误解的地方在于：它不是只看一个总开关。
如果只盯着 Telegram、企业微信这种通知渠道，很容易把问题看偏。真正决定“有没有通知”的，通常还是站内这两层配置有没有同时满足。
第一层：全局通知类型
在系统通知设置里，你会看到这类总开关：
- 资源下载
- 整理入库
- 订阅
- 媒体服务器
这些开关决定“这个类型的通知要不要发”。
第二层：目录自己的通知开关
目录配置里通常还有一个“通知”选项。
它决定的是：整理进这个目录的内容，要不要发通知。
这就是为什么很多人会遇到一个经典现象：
- 电影目录有通知
- 电视剧目录没通知
并不是 MoviePilot 天生对电影和电视剧区别对待，而是电视剧对应的目录很可能没有勾选“通知”。
排查顺序
如果你遇到“某些内容通知正常，某些内容完全没通知”，优先按下面顺序查：
- 全局“整理入库”通知有没有开
- 目标目录的“通知”有没有开
- 文件最后到底落进了哪个目录
这第三点很关键，因为如果目录匹配顺序出了问题，文件可能根本没有进入你以为的那个目录，自然也就不会按你预期发送通知。
自动整理与 Webhook：到底是谁在推动文件入库
从使用体验上看，很多人会把“下载完成”和“自动整理”看成一件事，但实际上它们是两步：
- 下载器把文件下载完
- MoviePilot 再去识别和整理它
第二步能不能发生，取决于你的目录监控方式有没有配对。
如果你经常遇到“资源已经下完了，但媒体库里就是没出现”，这一节基本就是排查重点。
最常见也最推荐的方式：下载器监控
如果你的资源主要来自 qBittorrent、Transmission 这类下载器，最常见的做法就是给目录配置“下载器监控”。
它的核心思想很简单：
- 下载器先把文件下载到“资源目录”
- MoviePilot 定期扫描这些目录
- 确认下载完成后，再把文件整理到“媒体库目录”
一个典型配置可以理解成这样：
| |
只要“资源目录”和“监控方式”配对了，整理流程通常就能跑起来。
为什么有时下载完了却一直不整理
这种情况大多数不是“MoviePilot 不会整理”，而是它判断下来，这个文件不在它要监控的目录里。
也就是说，最常见的问题不在下载器，而在目录配置本身：
- 资源目录填错了
- 配的是目录监控，但实际走的是下载器监控思路
- 文件实际下载到了另一个分类目录
所以如果你发现“任务完成了，但没整理”，先别急着怀疑识别逻辑，先确认：
- 下载器实际保存路径
- MoviePilot 配置的资源目录
- 自动整理方式
这三者是不是同一套。
很多教程会教你在 qBittorrent 里配置完成任务后的 Webhook，这当然是有价值的，但它更准确的定位应该是：
让整理从“几分钟后”变成“几秒后”。
如果你已经把目录和监控方式配对好了，Webhook 带来的主要变化其实不是“能不能整理”，而是“整理发生得有多快”。
不配 Webhook 会怎样
不配也不代表完全不能整理。
因为 MoviePilot 通常还有定时任务在兜底，它会周期性地扫描下载器中已完成但尚未整理的任务。
区别只是：
- 配了 Webhook：种子完成后几乎立刻就触发整理
- 不配 Webhook：等下一轮定时任务来扫
所以如果你是重视实时性的人，Webhook 很值得配；但如果你只是想先把流程跑通，哪怕晚几分钟再整理，也不一定非配不可。
qBittorrent 怎么理解最简单
你可以把 qBittorrent 里的这个外部程序看成一个“提醒器”：
| |
它本身并不直接决定某个文件能不能整理，它只是把“开始检查”的时机提前了。
手动添加种子：会不会被接管
这是另一个很常见的问题。
比如你在 PT 站里看到了一个很满意的种子，直接手动丢进 qBittorrent，而不是从 MoviePilot 的订阅流程里发起下载。
这种情况下，MoviePilot 还有没有机会自动整理？
先说结论：有机会，而且很常见。
关键条件不是“这个任务是不是 MoviePilot 发起的”，而是：
- 文件最终有没有进入它正在监控的资源目录
- MoviePilot 能不能识别出媒体信息
如果这两个条件成立，手动种子同样可能被整理。
为什么有时手动种子也能识别
因为对于 MoviePilot 来说，识别媒体信息并不总是依赖“下载历史记录”。
当没有现成的订阅上下文时，它仍然可能根据：
- 文件名
- 种子名称
- 目录结构
去尝试识别媒体信息。
这也是为什么你会看到一种现象：
- 某些手动种子能顺利整理
- 某些手动种子完全识别不出来
区别往往不在“是不是手动添加”，而在于名称够不够规范、信息够不够完整。
搜索关键词和自定义识别词：什么时候值得用
如果你已经读过订阅流程那篇文章，应该知道 MoviePilot 在识别和搜索时很依赖标题质量。
所以这一篇里我只给一个更偏实战的建议：
默认情况下，先不要过度依赖自定义识别词
因为很多问题根本不在“识别词不够多”，而在于：
- 目录配置顺序不合理
- 通知没开
- 监控方式没配对
- 资源目录不对
这些问题如果没先解决，你再怎么补识别词，也只是把排查复杂度继续往上抬。
更稳的顺序通常是：
- 先把目录和通知链路跑通
- 再去处理识别词、关键词和特殊规则
如果你想进一步理解“为什么资源明明搜到了却被过滤”，建议接着看上一篇：
另外，很多“为什么这条资源不匹配”的问题，最后其实又会回到资源名称本身。如果你对资源标题里的 BluRay、WEB-DL、Remux、H265、Atmos 这些概念还不够熟，推荐再看这一篇：
最后给一套排查顺序
如果你的订阅、通知或整理流程出了问题，建议按这个顺序排：
第一步：先看目录
- 目录顺序对不对
- 兜底目录有没有放最后
- 资源目录和媒体库目录是不是填对了
第二步：再看通知
- 全局通知类型有没有开
- 目标目录的通知有没有开
第三步：再看整理方式
- 是下载器监控还是目录监控
- 实际文件路径是不是落在监控目录下
第四步：最后再看识别和规则
- 文件名是不是规范
- 识别词有没有必要补
- 订阅规则是不是把资源提前过滤掉了
按这个顺序排，通常比一上来就改一堆关键词和规则更有效。
总结
MoviePilot 的订阅与通知问题，很多时候不是“系统坏了”，而是几个看起来独立的小配置其实串成了一条链：
- 目录匹配决定文件去哪里
- 监控方式决定会不会整理
- 通知开关决定有没有提醒
- 文件名和识别逻辑决定能不能顺利入库
一旦你把这条链想清楚，很多之前看起来很玄学的问题，其实都能落回到很具体的配置点上。
简单记住一句话：
先把目录、监控和通知链路跑通，再去折腾识别词和高级规则。