3.7 KiB
3.7 KiB
name, title, description, triggers, capabilities, sessions
| name | title | description | triggers | capabilities | sessions | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| patrol | 巡检 | 检查站点、下载器、媒体服务器、存储和待处理事项是否正常，一段话说清哪些正常、哪些要处理。用户问「是否正常」「检查一下」「巡检」「体检」时用。 |
|
|
|
适用意图
- 「检查站点、下载器和媒体服务器是否正常」「巡检一下」「系统有没有问题」。
- 定时巡检（待处理巡检、下载诊断、订阅与站点周报）的目标里带「巡检」时也用它。
步骤
- 先看系统提示里的「当前环境」：哪些接入了、哪些没接入。没接入的直接记一句「还没接入」，不再去查。
- 下载器和媒体服务器：调用 downloader.list，看每个的连通状态、最近在线时间、进行中 / 失败任务数。
- 站点：调用 site.list，看每个站点上次检查结果和登录状态。关心做种时再用 site.user_data（做种数、上传量）。
- 下载器有失败任务时：download.list 只列失败 / 无进展的，记下名称和原因；不逐个 download.inspect，除非用户问原因。
- 待处理与订阅：decision.list 看未关闭事项；用户问到订阅时再 subscription.list。
- 用户明确要实时检测某个站点，才调用 site.health_check；站点登录失效时 site.refresh_login。两者都需要批准。
需要批准
- site.health_check（实时检测站点）、site.refresh_login（重新登录）。没有授权时会被拒绝：汇报里写一句「没做：实时检测「站点名」，需要你批准」，界面会给批准按钮。
- 需要批准的检查（如检测站点）不要只在汇报里写「需要你批准」：先实际调用一次，让审批卡 /「批准并重试」按钮出现在界面上，再在汇报里写一句「没做：…，需要你批准」。同一个检查只调用一次，被拒绝后不要重复调用。
- 其余都是只读，不需要批准。
汇报模板
一段话，最多 8 行，按「下载器 → 媒体服务器 → 站点 → 订阅 / 待处理」的顺序，异常的放最前面：
下载器 qBittorrent 正常，24 个在做种、没有在下载的；媒体服务器还没接入。站点憨憨上次检查正常（昨天 16:12），实时检测需要你批准。订阅 5 条都已取消，没有待处理事项。
有异常时：
下载器 qBittorrent 连不上（2 小时前最后在线），3 个下载停在 40% 左右。站点憨憨登录已失效，需要重新登录。媒体服务器 Jellyfin 正常；待处理 2 条，都是没识别出作品。
- 时间写相对时间，大小写 GB；对象用名字，不写 ID、adapter、英文状态。
- 巡检会话（定时）只读，最后可以补一句本次建议，不超过 2 条。
不要做
- 不要因为 site.list 里没有下载器就说「没有下载器」：下载器只看 downloader.list 和「当前环境」。
- 不要把站点的上传量、做种体积当作下载器健康的证据，也不要写「无证据不等于故障」这类解释。
- 不要向用户要下载任务 ID 或种子 hash：要看哪个下载就先 download.list。
- 不要列 ID、adapter、原始字节数的表格。