FeedCraft 是什麼？開源自架的 RSS 中間件，把摘要源變全文

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

訂閱了 RSS，點開卻只有標題和兩行摘要

RSS 老用戶多半遇過這種狀況：訂了一個源，點開才發現只剩標題加兩行簡介，想讀全文得連回滿是廣告的網頁；英文長文源看得很慢，每篇都得靠翻譯工具一段一段啃；混著業配文的行銷源又吵得要命，真正想看的內容被業配淹沒。這些其實都不是閱讀器本身的問題，而是源送進來的時候就不夠乾淨。FeedCraft 想解的就是這一層，它是一套開源、自架的 RSS 中間件，架在你的 RSS 源和閱讀器之間，把缺全文、缺翻譯、缺摘要的源，重組成可直接讀的完整內容。

不過在動手之前，有三個問題值得先問清楚：它跟平常用的 RSS 閱讀器到底差在哪？一定要自己架嗎？跟很多人在用的 RSSHub 是同一類東西嗎？這篇就把這三題，連同自架的成本與限制一次講清楚。

它跟 RSS 閱讀器差在哪：是處理層，不是閱讀介面

最容易搞混的一點是：FeedCraft 不是拿來「讀」的。Reeder、Feedly 這類閱讀器，職責是把訂閱內容端上來給你看；FeedCraft 則是在源送進閱讀器之前，先做一輪清洗與重組，抓出全文、翻成你要的語言、產生摘要、過濾掉不要的。換句話說，你原來的閱讀器不用換，只要把訂閱地址改成 FeedCraft 處理後的新網址就行。

它走的是 Go 寫的輕量後端，以 Docker 部署，原作者 Colin 在 GitHub 上以 GPL-3.0 開源，repo 仍持續頻繁更新，並提供英文、簡體中文與繁體中文三語文件。它內建一個叫 AtomCraft 的處理模組，讓你像組積木一樣，為每個源設定要做哪些加工，翻譯用哪個模型、要不要抓全文、要不要擋業配文，都能分開調。

它實際在做的事：全文、翻譯、摘要、轉 RSS

FeedCraft 的核心能力圍繞著「把不夠好的源變好用」展開，幾個最實用的點包括：

• 全文提取：針對只給摘要的網站，自動抓回原文內容；遇到需要 JavaScript 才渲染的動態網頁，也能用模擬瀏覽器的方式硬抓（官方稱之為 Fulltext Plus），把本來殘缺的源補齊。
• AI 翻譯：可接 OpenAI、DeepSeek、Google Gemini，或本機的 Ollama。能選只翻標題快速掃視，或做原文一段、譯文一段的對照式沉浸翻譯，遇到有價值的長文再深入。
• AI 摘要與過濾：讓 AI 先在文章開頭產生一段 TL;DR，或下規則把含「業配」「Sponsored」等字眼的行銷內容直接從訂閱流剔除，讓資訊流安靜下來。
• 把沒有 RSS 的東西變成 RSS：內建產生器，能把網頁 HTML、JSON API 回應，甚至搜尋結果轉成訂閱源，補上那些「很想訂但沒有 RSS」的網站。

這幾項湊起來，它的定位其實很單純：一個放在源與閱讀器之間的處理層。你給它一堆參差不齊的源，它還你一組整理過、可讀性高的新源。AtomCraft 模組的好處是每個處理步驟都能單獨開關，你不需要對所有源都跑全套，只給真正困擾你的那幾個源加上對應的處理就好，避免無謂地消耗 API 額度與伺服器資源。

Pin

一個實際的訂閱整理流程

把這些功能串起來看，比較具體的使用樣貌是這樣：你把某個只給摘要的技術網誌接進 FeedCraft，設成自動抓全文；再把一個英文的產品更新網誌設成沉浸翻譯，AI 產生一段中文 TL;DR 放在開頭；另外幾個老是塞業配文的源，則用關鍵字規則直接過濾掉。每個源要套哪些處理、用哪個模型、翻譯要全譯還是只譯標題，都能在設定裡分開調，不會強迫所有源走同一套。處理完的新源網址，再丟回 Reeder 或 Feedly 訂閱。於是你打開閱讀器時，看到的已經是全文、翻好、摘要過、濾掉雜訊的內容，不必再逐篇點進網頁，也不必邊讀邊切翻譯工具。

Pin

有些團隊會把它當成輕量的資訊監控層，例如把對手公司的官方部落格、版本發布備忘、技術論壇的特定看板收進來，用 AI 摘出每日重點；也有人把整理過的源丟進 Obsidian、Slack 或飛書，當團隊的情報來源。不過得提醒，它本質上還是個人開發者維護的開源專案，拿來做團隊級的情報中樞時，穩定度與支援要自己把關，有別於企業級的成熟服務。

跟 RSSHub 是競爭還是互補

很多人會把 FeedCraft 和 RSSHub 拿來比，但兩者做的其實是不同段。RSSHub 擅長「把沒有 RSS 的網站變出 RSS」，重點在產生訂閱源；FeedCraft 擅長「把已有的源做深度處理」，重點在改善內容品質。一個管生成、一個管處理，方向不同，所以兩者可以串著用，讓 RSSHub 先產出源，再交給 FeedCraft 做全文提取、翻譯與摘要。

和稍後讀工具（如 Pocket、Instapaper）相比，差別在自動化程度：稍後讀是你一篇一篇手動存，FeedCraft 是整個訂閱流自動跑完處理流程，不用逐篇處理。和把網頁存成可搜尋筆記的知識庫工具相比，FeedCraft 處理的是「即時進來的源」，不是「已經讀完想留存的內容」，位置也剛好錯開；真要拼，兩者可以串成「FeedCraft 先把源整理好，你讀完覺得值得的再丟進知識庫」這樣一條流程。

自架之前先看清的成本

FeedCraft 免費、開源，但「自架」這兩個字背後要扛的東西不少，幾個你一定要先估進去的成本與風險如下。

部署與維運。它用 Docker Compose 部署，你得會基本的 Docker 操作，還要有一台持續開機的伺服器或 VPS（還沒有適合自架的機器，可以先從〈主機推薦〉抓個方向）。架上去之後，更新、備份、監控都得自己來；自架服務的基本功也別省，把後台預設密碼換掉、確認管理介面與 API 端點沒有直接掛在公用網路上（放在反向代理後面或限定來源 IP 更穩當）。它提供 amd64 與 arm64 兩種架構的容器映像檔，所以不管你用的是一般 x86 VPS 還是 ARM 小主機，基本上都裝得起來，差別只在跑 Fulltext Plus 時能撥出多少記憶體。

LLM API 帳單。翻譯和摘要都會呼叫模型，如果你訂閱的源更新很頻繁、又開了全文翻譯，API 額度燒得很快。實務上建議搭配 DeepSeek V3、Gemini Flash 這類低成本模型，或乾脆接本機 Ollama 把模型費用壓到零，代價是機器規格要夠推得動模型。要特別留意的是，內容送往哪個模型是由你設定的 provider 決定：接 OpenAI 就走 OpenAI、接本機 Ollama 就不出網，所以資料流向的邊界在你手上，而不是 FeedCraft 幫你決定。換句話說，隱私要求高的場景，就連翻譯這一步也能完全留在自家機器，只是要接受本機模型的翻譯品質通常比不上頂級雲端模型這個取捨。

記憶體與抓取合規。Fulltext Plus 等於在容器裡多跑一個無頭瀏覽器去渲染動態網頁，記憶體佔用會跳一階，低配 VPS 跑起來會吃力，建議只在需要的源上啟用。也要先有心理準備：付費牆或登入牆後的內容、反爬機制嚴格的站點，或純 SPA 靠鑑權 API 載入內容的網站，它未必抓得到，遇到想訂卻抓不全的源，多半得個別排查或放棄。另外，全文提取本質上就是在抓目標網站的原文，記得遵守對方的 robots 協議、設合理的抓取頻率，別對來源站造成壓力，這也是自架者要自己扛的合規責任。

授權與成熟度。FeedCraft 是 GPL-3.0，開源但屬 copyleft，拿來商用或做衍生作品要留意授權繼承的義務。它是個人開發者 Colin 維護的專案，規模落在數百顆星、持續更新中，但還不是大團隊或企業級成熟產品，遇到邊角問題多半得靠社群或自己排查。

適合誰，誰先再等等

如果你是 RSS 重度使用者，早已經有自己的閱讀器，長期被「摘要源」「英文源」「業配文源」折騰，而且你有一台能跑 Docker 的伺服器、也願意花一個下午把它架起來調規則，FeedCraft 幾乎是為這個情境設計的，又是開源免費，很值得裝來試。對已經在用 RSSHub 的人來說，它補上的正好是 RSSHub 沒做的深度處理這段，兩者搭起來能把整個訂閱鏈路從「取得源」做到「整理成可讀內容」。

但有幾種情況我會建議先緩緩。如果你只是偶爾看看 RSS、沒有固定的閱讀器習慣，為了它特別去架一台伺服器，投入與產出不太划算，先把閱讀器本身用好可能更實際。如果你不想碰 Docker 與伺服器維運，那自架中間件的門檻對你偏高，市面上的雲端閱讀服務雖然少了這層加工，但省去所有維運負擔。如果你對「內容被送去外部 LLM」很在意，就得確定自己願意設成本機 Ollama，否則翻譯與摘要預設會走雲端模型，這條隱私邊界要自己評估能不能接受。

想再深入：源處理之外的兩條路

把訂閱源整理好之後，如果你也想順手管理其他自架服務，〈AList 這類開源的聚合管理工具〉是另一個常被擺在一起的自架方案，走的是檔案與雲端聚合的路線。若你感興趣的是「把看到的內容收進可搜尋的知識庫」這個方向，〈MindPocket 這款 AI 書籤工具〉把網頁存成可 AI 檢索的筆記，和 FeedCraft 的源處理剛好是一前一後的互補。

常見問題

FeedCraft 是 RSS 閱讀器嗎？

不是。它是架在 RSS 源與閱讀器之間的中間件，負責做全文提取、翻譯、摘要與過濾。你原本的閱讀器不用換，只要把訂閱網址改成 FeedCraft 處理後的新網址。

一定要自己架嗎？

它是自架工具，用 Docker Compose 部署，需要一台持續開機的伺服器或 VPS，以及基本的 Docker 操作能力。官方文件有提供繁體中文版與部署教學，但維運、更新與安全設定得自己來。

它跟 RSSHub 衝突嗎？

不衝突，兩者可以串著用。RSSHub 負責把沒有 RSS 的網站變成訂閱源，FeedCraft 負責把已有的源做深度處理。常見做法是讓 RSSHub 先產源，再交給 FeedCraft 做全文、翻譯與摘要。

翻譯和摘要會不會很燒錢？

取決於源的更新頻率和你開的處理項目。全文翻譯頻繁更新的源會快速消耗 API 額度。建議搭配 DeepSeek V3、Gemini Flash 等低成本模型，或接本機 Ollama 把費用壓到零（代價是機器規格要夠推得動模型）。內容送往哪個模型，由你設定的 provider 決定。

它的授權是什麼？

GPL-3.0，開源且免費，但屬 copyleft 授權，拿來做衍生作品或商業用途時，需留意授權繼承的義務。詳細以 repo 的 LICENSE 檔為準。

會不會很吃伺服器資源？

看你有沒有開 Fulltext Plus。一般全文提取與翻譯的負擔不大，入門級 VPS 多半夠用；但一旦開了模擬瀏覽器去抓動態網頁，容器會明顯吃記憶體，低配機器容易吃力。如果還接了本機 Ollama 跑翻譯，那就要預留模型本身的記憶體需求，通常得準備資源較充足的機器。

如果你正好受夠了只有摘要的訂閱源、也願意花時間自架，FeedCraft 不妨架來試，從幾個最痛的源開始調規則，跑順了再擴大。它不會取代你手上的閱讀器，而是默默在後面把源先整理好，讓你打開閱讀器的那一刻，看到的東西就值得讀。