TrendRadar：把全網熱點變成可追蹤、可分析、可對話的 AI 情報管線

每天的資訊問題，通常不是「找不到新聞」，而是「新聞太多，卻沒有穩定的方法留下真正重要的訊號」。一個熱搜榜能告訴你現在什麼話題正在升溫，但它不會自動回答：這個話題是不是已經連續幾天出現？不同平台的討論是否指向同一個事件？我關心的關鍵字，哪些值得立刻看，哪些只是短暫噪音？

sansan0/TrendRadar 值得注意的地方，在於它沒有把自己定位成單純的新聞爬蟲或通知腳本，而是把「採集、篩選、儲存、報告、推送、AI 分析」組合成一條可以自架的情報管線。根據 2026 年 8 月 24 日的 GitHub 查核，專案約有 61,726 顆星、24,876 個 forks，最近一次推送更新為 2026 年 7 月 17 日；它仍然是活躍且具實作深度的開源專案。

這篇文章不把 TrendRadar 包裝成萬能的新聞真相機器，而是從工程角度拆解它真正解決的問題：如何把不穩定、分散、難以回看的熱門資訊，整理成可以排程執行、可以持久化、可以推播，最後也能被 AI 查詢的資料流程。

先看結論：TrendRadar 的核心不是「熱搜」，而是資料流

把 TrendRadar 想成五層會比較清楚：

來源層：從多個熱榜平台和 RSS/Atom feed 擷取內容。
規則層：用關鍵字分組、別名、正規表示式和條數限制，把「我想追蹤什麼」寫成可版本控制的設定。
狀態層：保存新聞與歷史資料，支援 SQLite，也能使用 S3 相容的遠端儲存；這是增量推送和歷史追蹤的基礎。
輸出層：產生 HTML 報告，並透過 Telegram、企業微信、飛書、Slack、Email、ntfy、Bark 等渠道通知。
理解層：使用 AI 做翻譯、興趣篩選與趨勢分析，或以 MCP 服務讓支援 MCP 的 AI 客戶端查詢本地累積資料。

這個分層很重要，因為它把「收集資料」和「呼叫模型」拆開。沒有 API Key 時，基本的熱榜、RSS、關鍵字匹配與 HTML 報告仍可以運作；啟用 AI 後，模型是加在既有資料流上的理解層，而不是整個系統唯一的入口。

從熱榜到報告：一次執行發生了什麼？

### 1. 先收集，而不是先問模型

TrendRadar 可以同時處理熱榜平台和 RSS。這兩類資料的特性不同：熱榜適合觀察短期熱度和排名，RSS 則適合追蹤固定來源的文章。專案將 RSS 內容納入相同的關鍵字分組與顯示流程，讓使用者不用為兩套資料源維護完全不同的閱讀介面。

這也帶來一個務實的設計：AI 分析不必直接連到網路搜尋。官方文件特別說明，MCP 的 AI 分析主要針對 output 目錄中已經累積的新聞資料。換句話說，系統的可追溯性取決於你是否先把資料穩定存下來，而不是單次提示詞寫得多漂亮。

### 2. 用設定檔描述關注範圍

最基本的關鍵字設定放在 config/frequency_words.txt，可以用群組組織關注主題，也支援別名、註解、條數限制與正規表示式。若你不想把關注範圍硬編碼成一長串詞，也可以在 config/custom/ai/ai_interests.txt 用日常語言描述興趣，例如「我想看 AI 和新能源的產業消息」，讓 AI 先抽取標籤，再為每則新聞評分。

這裡有一個值得借鑑的工程取捨：AI 智能篩選失效時，系統會回退到關鍵字匹配，避免整條通知流程因模型錯誤而中斷。AI 可以提高召回與排序品質，但核心的可用性不應依賴一次成功的模型呼叫。

### 3. 把「新增」和「熱門」分開

監控工具最容易造成的疲勞，是同一則新聞因為持續熱門而每天重複出現。TrendRadar 提供增量模式，讓使用者只關心新出現的匹配話題；同時也保留按熱度觀察的模式。這種模式分離讓同一份資料可以服務不同情境：高頻通知看新增，早晚簡報看整體趨勢，研究時再回看完整歷史。

AI 功能的三個層次

### AI 翻譯：降低跨語言資訊的閱讀成本

RSS 和熱榜來源可能混合不同語言。TrendRadar 的翻譯功能可以指定要翻譯的區域，並與 AI 分析共用模型配置。它的價值不是取代原文，而是把「先判斷這篇值不值得讀」的成本降低，尤其適合把海外 RSS 納入日常資訊流的使用者。

### AI 智能篩選：把自然語言興趣轉成排序訊號

傳統關鍵字很精準，但也很僵硬。只寫 LLM 可能漏掉沒有使用這個縮寫的相關新聞；把詞表寫得太寬，又會帶來大量噪音。AI 智能篩選讓使用者以自然語言描述關注方向，再為候選內容評分。實作上仍應保留關鍵字 fallback，並把 AI 評分視為排序和過濾訊號，而非事實判定器。

### AI 分析：從清單產生可讀的簡報

AI 分析會對推送內容做趨勢概述、關鍵字熱度、跨平台關聯和潛在影響評估；推送模式可以選擇只送原始內容、只送分析結果，或兩者都送。分析範圍也能獨立於推送範圍，例如推送只發新增消息，但 AI 分析當天的完整新聞，以免「避免打擾」和「看完整趨勢」互相牴觸。

要注意的是，摘要不是證據。模型輸出的情緒傾向、影響評估和跨平台關聯，都應回到原始標題、來源 URL 和時間線核對。TrendRadar 提供的是一個分析入口，不是替編輯省略查證步驟的捷徑。

MCP 讓新聞資料變成可對話的工作區

TrendRadar 的另一個亮點是獨立的 MCP Server。它不是把一個聊天視窗硬塞進爬蟲，而是讓新聞推送服務和 AI 分析服務分開部署：wantcat/trendradar 負責定時抓取、產生報告與通知；wantcat/trendradar-mcp 提供 MCP 協定介面，讓 AI 客戶端查詢與分析既有資料。

這個邊界帶來三個好處：

部署可以拆分：只想要推送時，不需要啟動 MCP；需要對話分析時，再加上 MCP 服務。
資料範圍更清楚：AI 查詢的是本地已累積資料，而不是讓模型任意宣稱自己看過即時網路。
客戶端選擇更自由：官方文件提供 Cherry Studio、Claude Desktop、Cursor、Cline、Continue 等 MCP 客戶端設定方式，服務可用 HTTP 端點接入。

以 Docker 為例，MCP 服務的 HTTP 端點預設是 http://localhost:3333/mcp，官方建議先限制在本機監聽；如果要遠端存取，必須自行補上反向代理與認證。這不是部署細節而已：新聞資料可能包含尚未公開的研究方向、公司情報或個人偏好，MCP 端點暴露到公網前，應先把身份驗證、網路範圍和資料保留策略想清楚。

三種部署路徑，對應三種維運取捨

### Docker：適合長期運作和完整歷史

官方把 Docker 列為推薦路徑。它可以讓新聞推送服務與可選的 MCP 服務以 Compose 管理，資料和設定透過 volume 保留，適合 NAS、家用伺服器或雲端主機。若要使用完整的增量推送、歷史追蹤和本地報告，這通常是最直觀的選擇。

設定上，功能行為放在 config/config.yaml，關鍵字放在 config/frequency_words.txt，敏感資訊如 API Key 和 webhook URL 則放在 docker/.env。環境變數會覆蓋 YAML 設定，因此可以在不改動版本控制檔案的前提下切換部署環境。

### GitHub Actions：低維運，但要處理持久化

GitHub Actions 不需要常駐伺服器，適合固定週期產生報告。不過 Actions runner 是短命環境，每次工作結束後本地檔案不會自然保留；若需要增量推送和歷史追蹤，就要配置 S3 相容遠端儲存，例如 Cloudflare R2。這條路徑的成本不是 CPU，而是 Secrets、雲端儲存和排程的正確配置。

### 本地 Python：適合開發、除錯和客製化

官方文件提供以 uv 管理依賴的本地執行方式。這對想研究資料源、修改篩選邏輯或加入自訂通知渠道的開發者最友善，但也代表你要自行處理 Python 環境、排程、程序監控和資料備份。

一個可實際落地的配置策略

如果要把 TrendRadar 用在 AI Chain 或工程團隊的技術情報，我會採用下面的順序：

先只開一個資訊源和一個通知渠道，確認能產生 HTML 報告並收到第一則訊息。
把關鍵字分成少量主題群組，例如模型、開發工具、基礎設施；不要一開始就把整個領域的詞都貼進去。
先用關鍵字模式建立基線，觀察一到兩天的誤報和漏報，再加入 AI 智能篩選。
將推送和分析分時段：即時或高頻時段只推送新增項目；早晚時段再生成完整分析簡報。
需要對話式回顧時才開 MCP，並先在 127.0.0.1 驗證，不要直接暴露到公網。
為資料保留設定期限，因為新聞資料會持續累積；歷史越完整，查詢越有價值，但敏感資料的保存風險也越高。

這個順序的核心，是先驗證資料流，再增加模型和整合。若第一步的來源、排程或儲存不穩，加入更昂貴的模型只會讓問題更難定位。

它適合誰？又不適合誰？

TrendRadar 適合需要長期追蹤主題、又不想每天手動打開十幾個網站的人：開源專案維護者可以監控依賴與競品，研究者可以把 RSS 和熱榜放進同一份時間線，團隊則能把重點摘要送到既有通訊渠道。它也很適合想探索「MCP 不只是工具呼叫，而是資料工作區入口」的開發者。

它不適合需要保證新聞完整性、即時交易級延遲或正式媒體編輯驗證的情境。來源平台的 API、頁面結構和可用性可能改變；AI 摘要也可能誤讀上下文。正式流程仍需要來源白名單、錯誤監控、人工抽查和權限控管。

最後的判斷：把注意力管理做成可維運系統

TrendRadar 最值得學習的不是「一次接了多少通知平台」，而是它把個人資訊焦慮轉成幾個可工程化的問題：資料從哪裡來？如何去重和分組？哪些內容只需要通知，哪些值得分析？歷史資料放在哪裡？AI 能查到什麼，不能查到什麼？

當這些邊界被寫進設定檔、儲存層和服務架構後，AI 才不會只是每天替你生成一段看似聰明的摘要，而是成為一條可追蹤、可回看、可調整的情報管線。對想建立個人或團隊 AI 工作台的人來說，這比單純增加一個聊天入口更接近真正能長期使用的產品形態。

查證來源

GitHub Repository：sansan0/TrendRadar
官方快速開始文件：選擇適合你的部署方式
官方 AI 分析文件：AI 分析
本文的星數、forks 與最近更新時間：GitHub Repository API，查核日期 2026-08-24