SuggestArr：把觀看紀錄接到 Seer 的自動點片流程
Effortlessly request recommended movies, TV shows and anime to Jellyseer/Overseer based on your recently watched content on Jellyfin, Plex or Emby—let SuggestArr handle it all automatically, keeping your library fresh with new and exciting content!
秒懂
- 它是什麼？
- SuggestArr 讀取 Jellyfin、Plex、Emby 的近期觀看紀錄，透過 TMDb 找相似作品，再把請求送進 Jellyseerr 或 Overseerr。它的價值不在推薦演算法，而在於把整條流程自動化，並補上審核、暫停與清理這幾道人工煞車。
- 適合誰用？
- 如果你已經有 Jellyseerr 或 Overseerr，而且希望媒體庫能依使用者實際觀看行為自動長出候選片單，SuggestArr 值得先以 Docker 在單一使用者上試跑，並把全域的 Approve requests before sending them to Seer 打開，確認 Requests 頁面的待審清單符合預期後再開放給其他帳號。若你沒有 Seer 這一層、或希望由自己完全掌控推薦邏輯，它就不是合適的工具。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫在最近一天內有新的提交。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它解決的是「片單不會自己長大」這件事
自架媒體伺服器的人常遇到同一個停滯：媒體庫建好之後，新內容的來源就只剩自己記得去搜。Jellyseerr 或 Overseerr 解決了請求與審核，但沒有人負責產生候選清單。SuggestArr 補的正是這一段。它從 Jellyfin、Plex 或 Emby 取出近期觀看紀錄當作種子，用 TMDb API 搜尋相似作品，再把結果轉成 Seer 的請求。目標使用者是已經跑起整套自架串流 stack、且願意讓程式代替自己決定要看什麼的人。README 的定位寫得很直接：讓 SuggestArr 全自動處理，保持媒體庫有新鮮內容。這個定位本身也說明了它的邊界，使用者愈在意「每一部片都是我親自挑的」，這個工具能帶來的價值就愈低。
資料流：從觀看紀錄到 Seer 請求的四段路
整條鏈路可以拆成四段。第一段是取樣，SuggestArr 連上你選定的媒體伺服器，抓取近期觀看內容。第二段是擴散，把這些片名送到 TMDb 找相似標題。第三段是過濾，README 列出幾種過濾方式：可排除已經在你所在國家串流平台上架的內容，可跳過在 Trakt 上已完整觀看的項目，也可依媒體伺服器帳號過濾請求，或讓管理員限制一般使用者只能看到與自己 Plex、Jellyfin、Emby 帳號連結的請求。第四段才是送出，把通過過濾的候選轉成 Seer 請求。這裡有個容易被忽略的設計：新任務預設會遵循全域的 Approve requests before sending them to Seer 設定，而該設定在 Advanced 底下、預設停用。也就是說，預設狀態下建議會直接流向 Seer。每個任務可以繼承這個設定，也可以覆寫成一律先審核或一律自動送出。被攔下的結果會出現在 Requests 頁面，由任務擁有者或管理員決定送出、拒絕，或加入全域黑名單。
AI 推薦與 AI 搜尋目前標示為 beta
除了 TMDb 的相似度路徑，SuggestArr 另有一條 LLM 路徑。README 說明它支援任何 OpenAI 相容的 LLM，列出的例子包括 OpenAI、Ollama、Gemini 與 LiteLLM，用來依觀看歷史產生個人化建議，並附上每個推薦的理由。另一項 AI Search 則讓使用者用自然語言描述想看的內容，由模型對照觀看歷史找出符合的標題，再一鍵送到 Seer。兩項功能在文件中都標為 beta。這個標記值得認真對待：LLM 路徑的輸出品質取決於你接的模型與提示設計，而這部分在提供的材料裡沒有更細的說明。相對地，TMDb 相似度路徑的行為比較可預期，因為它依賴的是既有的關聯資料，而不是生成。若你打算把 SuggestArr 放進無人看管的排程，TMDb 路徑會是比較容易推理的選擇。
Docker 部署與實際會用到的設定鍵
README 提供的是 Docker Compose 路徑。映像檔為 ciuse99/suggestarr:latest，GitHub Container Registry 上另有 ghcr.io/giuseppe99barchetta/suggestarr:latest。容器名稱在範例中寫作 SuggestArr，重啟策略為 always，對外埠與容器內埠都取自 SUGGESTARR_PORT，預設 5000。需要掛載的只有一個路徑：./config_files 對應到容器內的 /app/config/config_files，設定與狀態都落在這裡，備份時盯住這個目錄即可。環境變數只有兩個，且都是選用的：LOG_LEVEL 預設 info，README 說明它只在需要深入排查時才需要調整；SUGGESTARR_PORT 用來改埠。啟動指令是 docker-compose up。容器起來後，網頁介面在 http://localhost:5000，或你自訂的埠。設定流程在介面內完成：選媒體服務、填 API 金鑰與網址、設定 cron 排程。README 提到設定階段會自動驗證 API 金鑰與網址，這對首次導入有實際幫助，因為 TMDb 金鑰與伺服器位址是最常見的兩個出錯點。若要使用特定 Seer 使用者送出請求，需在介面勾選使用者選擇選項、從下拉選單挑人、輸入該使用者密碼；README 註明目前僅支援本地 Seer 使用者。
Trakt 是選配，且分成管理員與使用者兩層設定
Trakt 整合的設計分權限。管理員只需在 Services 到 Trakt 底下填入共用的 Client ID 與 Client Secret 並儲存，這些是整個實例共用的應用憑證。每個使用者則自行到 Profile 到 Trakt Account 點 Link Trakt，連結自己的帳號。README 明確指出 Trakt 是選配，沒有它，媒體伺服器的觀看歷史照樣能運作。接上之後多出兩件事：近期 Trakt 觀看紀錄可以當作推薦種子，以及已完整觀看的 Trakt 項目會進入 skip-watched 集合。介面上另有一個可收合的 Recent Trakt Preview 面板，展開時顯示最近從 Trakt 抓到的項目。這個分層是合理的，因為 OAuth 應用憑證屬於維運層級，而觀看歷史屬於個人資料，兩者混在一起會讓權限難以交代。
三道暫停機制暴露了真正的風險
SuggestArr 有幾個功能不是為了多送請求，而是為了少送。Pending-Request Job Pause 會在 Seer 仍有請求等待核准或拒絕時，跳過排程或手動任務。Unwatched-Suggestion Pause 會在使用者於指定天數內沒有觀看任何 SuggestArr 請求時，暫停排程的推薦任務，手動執行則不受影響。全域的 Request Workflow 設定還能在建議等待審核期間暫停任務，並自動拒絕擱置超過設定天數的建議，這項暫停行為可依任務覆寫。把這三道機制放在一起看，可以推論出這個專案面對的主要失效模式：自動化會持續產生請求，而請求堆積在使用者沒有真正觀看的內容上。對共用伺服器而言，這意味著儲存空間與 Seer 審核佇列會被慢慢填滿。這些開關的存在本身就是對這個風險的承認。相對地，Cleanup Automation 走得更遠，README 說它會在使用者從未於 Plex、Jellyfin 或 Emby 收藏時，修剪 SuggestArr 產生的舊請求與檔案。這是最需要謹慎的一項，因為它會刪除檔案，而提供的材料沒有描述它的判定細節。
什麼情況下不該用，以及可以考慮的另一條路
SuggestArr 的架構有一個硬性前提：Seer 必須存在。它不自己下載、不自己管理媒體庫，只負責產生請求。如果你沒有 Jellyseerr 或 Overseerr，這個工具對你沒有用處。另一個不適用的場景是推薦品質要求很高的使用者：TMDb 相似度本質上是關聯式推薦，會反覆產出同類型作品，若你的觀看紀錄集中在少數類型，建議清單會往同一個方向收斂。想要不同取徑的人，可以考慮以 Trakt 的推薦清單或自建腳本搭配 TMDb API 自行組裝流程。差別在於控制權與維護成本：自建腳本能完全掌握推薦邏輯與過濾條件，但審核介面、排程管理、即時日誌、使用者層級的請求可見性、以及前述三道暫停機制都要自己寫。SuggestArr 把這些都放進一個網頁介面，代價是推薦邏輯本身不容易替換。這是一個明確的取捨，不是誰比較好的問題。
維護成本與授權的實際含意
從版本節奏看，v2.14.0 在 2026-09-08 發布，v2.13.0 在 2026-08-24，v2.12.0 在 2026-08-05，大約兩到三週一個版次。這個頻率意味著功能仍在演進，也意味著你需要偶爾重新檢視設定語意是否有變，例如審核流程這類牽涉預設行為的調整。升級路徑本身單純：映像檔換標籤後重啟容器，狀態留在掛載的 config_files 目錄裡。風險在於設定結構若在新版改變，舊設定可能無法直接沿用，而提供的材料沒有說明是否有遷移機制，這一點在正式環境升級前值得先確認。授權為 MIT，屬於寬鬆授權，一般自架使用與修改分發的限制較少；但這不是法律意見，若你要把 SuggestArr 包進對外提供的服務，授權條款與其中涉及的第三方 API（TMDb、Trakt、LLM 供應商）各自的服務條款都需要自行確認。README 另列出 PostgreSQL 與 MySQL 作為 SQLite 之外的選項，理由是擴展性與效能，對多使用者實例而言這是值得提前規劃的一項。
編輯結論
如果你已經有 Jellyseerr 或 Overseerr，而且希望媒體庫能依使用者實際觀看行為自動長出候選片單，SuggestArr 值得先以 Docker 在單一使用者上試跑，並把全域的 Approve requests before sending them to Seer 打開，確認 Requests 頁面的待審清單符合預期後再開放給其他帳號。若你沒有 Seer 這一層、或希望由自己完全掌控推薦邏輯，它就不是合適的工具。導入前先確認三件事：TMDb API Key 與媒體伺服器連線是否通過設定的前置驗證、Seer 端使用的是否為本地帳號（README 明言目前僅支援本地 Seer 使用者）、以及 cleanup automation 的實際行為範圍，因為該功能會依使用者在 Plex、Jellyfin、Emby 是否收藏來修剪 SuggestArr 產生的請求與檔案。
社群筆記