AnimeGarden 是什麼？動漫花園鏡像站，附開放 API 與 RSS 訂閱

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

打開 animes.garden，第一眼會以為是動漫花園換了張皮：字幕組的發布一條條排下來，有番劇名、字幕組名稱、檔案大小與發布時間。再往下看會發現它不止於此：首頁排出 2026 年 10 月新番的整週放送表，頁面頂端掛著資料介面的入口，整個網站的原始碼放在 GitHub 上公開，採 AGPL 授權，任何人都能下載檢視。

Pin

先把最常被問到的問題回答掉。它跟動漫花園是什麼關係：第三方鏡像站，非官方自營，而且實際整併的來源不只動漫花園一個。追番的人拿它能做什麼：好上手的進階搜尋、放送表、自訂 RSS 訂閱。合不合法的問題：站上索引的是磁力連結與資訊，檔案本身不放在它的伺服器；但被索引的內容多數是字幕組發布的版權動畫，這條線怎麼畫，後面有專段說明，不藏在免責聲明裡。

非官方鏡像，而且整併的不只動漫花園

AnimeGarden 的自我定位寫得很直白。專案在 GitHub 上的描述是「動漫花園鏡像站、動畫 BT 資源聚合站、動畫 BT 資源開放介面」，它自己產生的 RSS 通道描述也自稱「動漫花園資源網的第三方鏡像站」。開發者是 yjl9903（網路上常用暱稱 XLor），專案從 2023 年 4 月開始經營，至今仍在更新：2026 年 10 月 24 日釋出 v0.5.5，倉庫最後一次推送停在 2026 年 11 月 6 日，一週內的活動。

「鏡像」只說了一半。實際連上它的 MCP 服務問來源，回應裡自己寫明：資料聚合自動漫花園（dmhy）、蜜柑計畫（mikanani.me）、萌番組（bangumi.moe），外加發布源 ANi。首頁的資源連結也看得到證據，位址開頭分成 /detail/dmhy、/detail/mikan、/detail/moe 幾種並存。翻到原始碼這一層更清楚：爬蟲套件裡就是 dmhy、mikan、moe、ani 四個目錄，各自負責解析一個來源站。換句話說，搜一個 AnimeGarden，等於同時搜三個資源站的索引，這是它跟「單純備份動漫花園」最大的差別。

技術上它做的也不是「轉址備份」那種鏡像。爬蟲把來源站的資源解析進自己的 PostgreSQL 資料庫，網站與 API 查的都是自己的庫：查詢速度不隨來源站起舞，篩選與搜尋功能也因此能自己做，這是它敢開放 API 的前提。代價則是資料有落地延遲，來源站剛發布的資源要等爬蟲跑完才查得到，急著要最新一話的人有時直接去原站反而快。

規模有感覺得到的大小。首頁列出的字幕組共 47 個，從老字號的 VCB-Studio、SweetSub 到近年活躍的喵萌奶茶屋都在；資源分類有動畫、合集、音樂、日劇、RAW、漫畫、遊戲、特攝、其他九種。查詢介面回傳的資料是活的，清單裡最新的幾筆發布時間就落在查詢當下的同一天。

還有一個小但實用的發現：網路上流傳的舊網址 garden.onekuma.cn 還活著，只是現在會直接轉址到 animes.garden。看過去教學文的人別以為站掛了，同一個服務換了正式網域在跑。

追番的人實際的用法：搜尋、放送表與自訂 RSS

對一般追番的人，它最有價值的部分是搜尋與訂閱，兩件事都比原站省力。

搜尋支援一種口語化的進階語法，條件直接打在搜尋框裡，像「上伊那牡丹 +1080p fansub:喵萌奶茶屋」這樣一句，就同時過濾了作品、解析度與字幕組。這種條件在原始網站上通常要開好幾層篩選器慢慢點，這裡一句話打完。有個繁簡細節值得先知道：鍵名有英文與中文兩套（fansub、type、after，加上站方以簡體字示範的中文鍵名），用英文鍵名最穩；要配對的值同樣以來源站標題使用的字形為準，標題裡多數是簡體標記時，繁體關鍵字會撈不到。篩出來的結果還能再依字幕組、發布者、關鍵字縮小範圍。字幕組的挑選有實質意義：同一部番，不同字幕組的翻譯品質、字幕語言（簡體、繁體或雙語）、解析度與檔案大小差很多，先選定跟慣的組再看列表，比每次在混雜的列表裡撈快得多。以喵萌奶茶屋為例，同一部番通常同時有簡日雙語與簡繁日內封兩種版本在列表上，條件下對了才不會每次都撈到不要的那個。

篩出結果只是第一步，條件還能存成收藏，之後從收藏清單直接回訪，不必重打條件。收藏更進一步的玩法，是把多組條件合併成一條聚合訂閱，等於幫自己生一個「只放我想看的內容」的私人頻道。

放送表以週為單位排出本季每部新番的播出日，週一到週日每天一段，2026 年 10 月季的內容標記為放送中。點進作品能直接看該作品的資源列表，把「這季有什麼」與「最新的集數在哪」接在同一條動線上；對季初決定要追哪些番的人，這一頁比資源列表更適合當入口。

RSS 是它相對少見的強項。任何一組搜尋條件都能變成一條訂閱網址，格式是 api.animes.garden/feed.xml 加上參數，把番劇代碼、字幕組、關鍵字指定進去，之後新資源出現就會進你的閱讀器。實測帶 keyword=1080p 的訂閱網址，回傳的 RSS 內容正常。它的應用場景很具體：固定跟某部番的某個字幕組，就訂一條只含這個組的來源，新集數發布自動收到，不必每天手動查；追的番一多，就把每部各訂一條，閱讀器會按時間排好。習慣用 RSS 工具整合資訊的人，可以併進自己現有的流程，像先前介紹過的 FeedCraft RSS 轉接工具 就是同一類用法。

把這些功能放回對照，才看得出它的定位。動漫花園官網本身就有完整的分類列表與搜尋，蜜柑計畫也以介面乾淨著稱，各自早有忠實用戶。AnimeGarden 的差別在整併與開放：同一套搜尋語法同時涵蓋三個來源，任何條件都能直接變成 RSS 或 API 呼叫，資料離開網站也能用。已經習慣固定某一站的人，升級動機可能不強；會被它吸引的，通常是同時跨多個來源找資源、或想把動畫資訊接進自己工具鏈的人。

README 另外寫到它支援與 AutoBangumi、AnimeSpace 兩個追番自動化專案整合，讓下載追番整條流程自動跑。這段是作者宣稱；想走自動化路線的人把它當線索自己測，別當成保證。在裝置端追番的另一個選擇，可以看先前的 Kazumi 動畫收集器介紹，兩者剛好是服務端索引與用戶端播放的互補關係。

開發者那一側：開放 API、npm 套件與 MCP

這個專案真正與眾不同的地方，是它把資源索引當成一種公開服務在經營，而不只做給人看的網頁。

查詢介面完全開放，不需要申請金鑰。用一行指令就能驗證：向 api.animes.garden/resources 打請求，回傳 JSON 格式的資源清單，欄位有標題、字幕組、發布時間、檔案大小與磁力連結，分頁參數也正常作用，回應裡連服務端實際套用的篩選條件都會附上，方便除錯。站上提供互動式的 API 文件頁，連資源列表頁都會直接生成 cURL、JavaScript、Python 三種現成的請求範例讓你複製，等於把「怎麼接」的門檻降到貼上就能跑。

篩選參數的設計看得出有照開發者的需求想過：可以用 Bangumi 條目代碼鎖定作品，可以指定多個字幕組或發布者（任一符合即命中），可以要求標題必須包含哪些詞（例如同時要 1080p 與繁體字幕的標記）、排除哪些詞（例如排除 RAW），也能限定發布時間區間。對「自動化下載清單」這種應用，這組參數剛好夠用。倉庫的 examples 目錄還附了一份 API 測試檔，常見的查詢組合都有現成範例。

JavaScript 與 TypeScript 的開發者有現成的封裝套件 @animegarden/client（npm 上 2026 年 10 月更新的 0.5.5 版），把請求與篩選包成函式，文件裡的篩選欄位對照表寫得清楚；部落格站長則有現成的嵌入程式碼，一個 iframe 標籤就能把某部番的資源列表放進自己的頁面，樣式跟著主站走。

更貼近現在趨勢的是 AI 代理的整合。它提供標準的 MCP 服務端點（api.animes.garden/mcp），實測連線初始化正常，服務自述提供兩個工具：資源搜尋與單一資源詳情，回傳的欄位一樣含磁力連結與詮釋資料。對使用者更具體的講法是：在 Claude Code 或 Codex 這類代理工具裝好它的官方外掛（倉庫提供現成指令），之後直接用一句「幫我查某部番第一話的資源」讓代理代查；DeepSeek Harness 這個用戶端也有對應外掛，2026 年 11 月初剛更新過。把資源站的檢索能力做成代理可呼叫的服務，這條路是 2025 到 2026 年間長出來的新用法，在傳統資源站上並不多見，也是我認為這個專案最值得觀察的實驗。

不想裝外掛的人有更輕的路：MCP 端點走 HTTP 協定、不必申請金鑰，任何支援這種連線方式的用戶端都能直接掛上；官方文件也提供把檢索能力包成 skill 的安裝指令，一樣是免帳號免金鑰的做法。門檻低是雙面刃：整合方便，但也代表任何掛上它的代理都能查資源索引，家裡有小孩或共用電腦的人，要不要讓代理工具碰這類內容，值得先想一下。

授權方面，整個專案採 AGPL-3.0，是正規的自由軟體授權，程式碼完整可審；附帶的義務是，若拿它改作自架服務對外提供，修改後的原始碼也要以同授權公開，商用整合前要先想清楚這點。想自己架一套的人，倉庫附有 docker-compose 設定檔（含 PostgreSQL 與 Redis 兩個相依服務），不過官方文件主要為開發貢獻者而寫，自架要自己摸。

索引層不等於內容層：版權這條線怎麼畫

談這個站繞不開版權問題，值得把事實攤開來講，而不是一句「請支持正版」帶過。

先講可以驗證的部分。AnimeGarden 索引的標的是磁力連結與發布資訊，這點在原始碼裡看得到：爬蟲解析來源站後，用專門的函式庫把種子資訊轉成磁力連結格式存進資料庫，站方伺服器上放的是索引；影片檔不在那裡。它對來源站的關係是讀取與整理，沒有自己上傳任何內容。

但索引層的乾淨不等於內容層的合法。被索引的資源，從標題型態看，多數是版權動畫的字幕組發布版本：番劇名、集數、解析度、字幕語言的組合，加上字幕組前綴，這是長年存在的非授權重製生態的典型格式。動畫的著作權屬於製作委員會與授權方，字幕組的翻譯與發布未經授權，這在多數司法管轄區都是事實，台灣也不例外。動漫花園本身經營這個生態多年，AnimeGarden 站在它上游再包一層索引，內容的授權狀態不會因為多包一層開源程式碼而改變。

把行為拆開看會更清楚。搜尋、訂閱 RSS、呼叫 API，碰到的都只是發布情報：哪部番、第幾話、哪個字幕組、多大容量，這部分的本質跟看節目表相近。下載內容是另一件事，重製權的問題從按下磁力連結那一刻才開始；而把檔案持續分享給其他人（做種上傳），在多數司法管轄區的風險又比單純下載更高。台灣的著作權法對重製與散布各有規範，實際責任要看行為態樣，這裡只給一般性的提醒，不是法律意見，真有疑慮請查證法條或問專業人士。對想完全避開風險的人，只把它當情報層用（查更新、訂 RSS），正版管道看正片，是最乾淨的用法。

站方在這件事上的立場，README 與首頁都看不出來，未見授權聲明或內容政策頁面。另外要注意內容組成：資源流裡全年齡動畫與成人向標題混在一起，站上沒有分級開關或過濾器，首頁打開就會看到全部，家長要留意這點。

給想守住界線的人一個實際的用法框架：把 AnimeGarden 當「播出與發布情報站」用，查某部番更新到第幾話、哪個字幕組有出、什麼時候放送，這部分完全在索引層；至於按下磁力連結之後的事，每個司法管轄區對私人下載與分享的規範不同，後果自負這四個字在這裡是認真的。處理磁力連結的工具可以看先前的 imFile BT 磁力下載器介紹，工具選擇的邏輯同樣適用。

單人維運與簡中介面的代價

把吸引力講完，接著講會影響你去留的限制。

最結構性的風險在維運。這是一個人維護的專案：yjl9903 同時養著 AnimeGarden 與同一生態的 AnimeSpace（自動追番工具）、anipar（資源標題解析器）、bgmx（Bangumi 客戶端）等專案，倉庫累積約 1,400 顆星，發布節奏穩定，但公車指數是名副其實的一，維護者的人生變化會直接決定服務壽命。開源授權保證了程式碼不會消失，不保證這個網域上的服務永遠有人顧。專案的正面訊號也要公平講：三年半的歷史、持續的版本釋出、Telegram 上有開發者群組與推送頻道，這不是棄坑邊緣的專案，只是結構上先天單點。

Pin

資料的命脈繫在來源站手上。鏡像與聚合的資料都來自 dmhy、蜜柑、萌番組這些上游，來源站改版、加防爬機制或整個收掉，鏡像就跟著失效，而它與來源站之間沒有任何官方合作關係，上游隨時可以單方面讓它難做。爬蟲能不能持續追上來源站的改版，是這類專案最常見的死因；倉庫裡 28 個開啟項目目前多為功能規劃與相依套件更新，還沒有堆出這類維修債，算是健康訊號。

介面語言是另一道門檻：整站只有簡體中文，沒有繁體介面，原始碼裡也看不出多語言計畫的跡象。台灣使用者要自己適應簡體中文介面的用詞差異，看久了不難，但第一次上手會愣一下。

內容面再補一個角落：分級過濾的缺席前面講過了，搜尋預設不排除成人向內容是它的另一側，訂閱 RSS 時關鍵字下得不夠精確，推送進來的內容組成可能比預期雜。

誰會用到它，誰該直接關掉

它適合的人有明確輪廓。固定追多部番、在乎字幕組與版本選擇的人，進階搜尋加 RSS 訂閱的組合省下的時間立刻有感；想用程式或 AI 代理處理動畫資訊的開發者，開放 API 與 MCP 是這個生態裡少見的乾淨介面；經營動畫相關網站的人，嵌入程式碼與 API 可以直接拿來做功能。追番情資與 Bangumi 條目資料的整合應用，可以參考像 PickACG Bangumi 標籤搜尋 這類工具的思路。

畫一個具體的樣貌：某個人每週固定追幾部番，把每部各訂一條指定字幕組的 RSS，週末打開閱讀器掃一眼有沒有新集數或特別篇；臨時想查某部冷門番出過哪些版本，再用一句進階搜尋語法拉出全部結果。情報在這一層流動，要不要下載、去哪下載是另外的決定。這種用法等於把它當季刊目錄在訂，多數時間根本不必打開網站本體，界線也跟著乾淨。

反過來，把內容合法性當第一優先的人應該跳過它，它的核心價值建立在授權狀態有爭議的內容索引上，這個前提不會因為介面好用而改變；需要繁體中文介面、需要內容分級、或不想碰灰色地帶的人，同樣不必勉強。合法的正版追番管道（動畫平台的付費訂閱）是另一條路，與這個工具之間的取捨，最終落在價值判斷；技術面它做得夠完整。

第一步很簡單：打開 animes.garden，用一句進階搜尋語法查自己正在追的番，感受一下篩選的準確度；覺得有用，再把那組條件變成 RSS 訂閱放進閱讀器。開發者可以直接打 API 文件頁，從現成的請求範例開始。至於下載那一端要不要用、怎麼用，這個決定留給你，後果也歸你。