Situation Monitor：開源 OSINT 儀表板，把全球事件收進同一面板

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

TL;DR

Situation Monitor 是一套把全球新聞、市場報價、地緣熱點與加密幣整合到同一個面板的 OSINT 儀表板，以 SvelteKit 2.0 加 Svelte 5 寫成純靜態前端，部署到 Vercel、Cloudflare Pages 或 GitHub Pages 都行。它在 GitHub 拿到 4,170 顆星但沒有 LICENSE 檔，main 分支從 2026 年 1 月 13 日以來沒再提交，沒有發布過任何 release。市場報價與經濟指標需要你自己申請 Finnhub 與 FRED API key，預設的 RSS 抓取會經過作者自己的 Cloudflare Worker。適合把全球脈動放第二螢幕追蹤的研究員、記者與跨市場工作者，不適合想要裝了就完整可用的人。

先說結論：這個工具的價值與邊界都在哪裡

把 Situation Monitor 直接想成「追新聞的儀表板」會低估它，想成「金融業的 Bloomberg 終端機替代品」又會高估它。它的真正定位是把分散在全球公開 API 與 RSS 的訊號，整合在同一個可自架的 Svelte 介面。資料來源是 GDELT、BBC、NPR、Guardian、NYT、CNBC、FT、White House、Federal Reserve、SEC、CSIS、Brookings、CoinGecko、Finnhub、FRED 這類公開渠道，不是某個付費資料庫。對於本來就在多個螢幕之間切換新聞 App、市場報價與地緣資訊的人，這個整合本身就值回票價；對於期待「裝完就有完整市場資料」的人，會發現預設狀態下市場面板是空的，需要自己申請 API key。

如果你想把這種資料聚合監控的思路換到預測市場上，Opinion Whale Tracker 是一份用 Python 把 CLOB 訂單簿聚合成巨鯨掛單監控的範例，可當骨架參考。

同樣把外部資料源排程抓進一個自己掌控介面的做法，DailyWallpaperHub 套用在每日壁紙歸檔上，用 GitHub Actions 自動收集 Bing 與 Unsplash 的精選壁紙。

下判決之前有四個邊界必須先講清楚。先看授權：授權狀態未定：GitHub 顯示 License 為 None，倉庫根目錄沒有 LICENSE 檔，法律上 public 不等於 licensed，不能直接當作開源自由取用。再看維護：專案停滯：4,170 顆星與 924 個 fork 看似熱門，但 main 分支從 2026 年 1 月 13 日之後就沒再提交過，到現在已經超過半年，沒有任何 release，19 個 open issue 也沒處理。更關鍵的是：CORS proxy 預設指向作者自己的 Cloudflare Worker，你不修改設定就部署的話，所有 RSS 抓取會經過作者的基礎設施。最後是 BYOK 邊界：市場與經濟指標的 API key 要自備，Finnhub 與 FRED 都要自己申請 key，而且 SvelteKit 的 VITE_ 前綴會把 key 打包進用戶端 bundle，任何人都能從前端抽出來。

把這四個邊界記在心裡，再往下看它的功能與機制，會比較知道這個工具到底適不適合自己架一套。

打開 demo 會看到什麼：六種預設配置與 24 個面板

Situation Monitor 的官方 demo 部署在 Vercel，第一次打開會跳出一個「Welcome to Situation Monitor」的設定視窗，要你從六種預設配置擇一啟用。這六種預設對應不同使用情境，也決定了一開始會載入哪些面板。

• News Junkie：聚焦突發新聞，涵蓋政治、科技與財經，7 個面板。
• Trader：市場導向，含股票、加密幣、原物料，9 個面板。
• Geopolitics Watcher：全球局勢與區域熱點，10 個面板。
• Intelligence Analyst：深度分析、模式偵測與敘事追蹤，7 個面板。
• Minimal：地圖、新聞、市場三個核心面板。
• Everything：全部 24 個面板一次開。

選了 Everything 之後會看到主介面：上方是橫幅標題「GLOBAL SITUATION MONITOR」與「Refreshing…」狀態列，中央是世界地圖（用 D3.js 渲染），上面標著各城市的事件熱點，顏色代表風險等級（紅色 High、黃色 Elevated、綠色 Low），可以看到 Caracas、Tehran、Moscow、Riyadh、Taipei、Delhi、Singapore、Nuuk 這類名稱。下方是並排的面板：POLITICS、WORLD LEADERS（含 19 位領袖名單）、VENEZUELA WATCH。地圖右下角有縮放與重置控制，右上角是圖例與 Settings 按鈕。

Pin

地圖本身就是 Situation Monitor 的核心隱喻：它的用意是讓你一次看到「同一段時間內全球哪些地方在發生什麼」，而不是逐則滑過新聞。對於習慣用文字訊息流追蹤事件的人，這個空間式的呈現會帶來不同的判讀方式。例如同時看到 Caracas 與 Tehran 同為紅色高風險，會促使你回頭查這兩個地方是否在同一週內發生了關聯事件。

技術架構：SvelteKit 靜態站加三層服務層

把 package.json 與 svelte.config.js 翻開看，技術堆疊很清楚：SvelteKit 2.0 加 Svelte 5（用新的 $state、$derived、$effect runes 反應式寫法），TypeScript 開 strict 模式，Tailwind CSS 處理樣式，D3.js 畫地圖，Vitest 與 Playwright 跑測試。部署端用的是 @sveltejs/adapter-static，這是純靜態輸出，整個專案編譯完是一堆 HTML、JS、CSS 與靜態資源，沒有 server runtime。

這個「純靜態」性質比外表看來更重要。對外介紹把它描述成「Vercel 邊緣部署」，但其實它可以是任何靜態主機：Vercel、Cloudflare Pages、GitHub Pages、Netlify、甚至本機用 npx serve build/ 跑都行。vercel.json 只有 96 bytes，幾乎沒有 Vercel 專屬設定。真正的部署邏輯寫在 GitHub Actions workflow 裡，預設會推到 GitHub Pages 的 https://hipcityreg.github.io/situation-monitor/，Vercel 上的 demo 只是另一個入口。

純前端的代價是所有資料抓取都在瀏覽器裡發生，沒有後端可做快取或代理。為了不讓每個使用者都打 30 個 RSS 來源被對方擋 CORS 或速率限制，原始碼在 src/lib/services/ 加了三層服務層：CacheManager 處理 per-service 快取（市場資料 1 分鐘、新聞 5 分鐘、天氣 10 分鐘），CircuitBreaker 避免連鎖失敗，RequestDeduplicator 防止並發重複請求。所有 HTTP 請求都經過 ServiceClient 整合這三層。資料刷新分三階段：Critical（0ms，新聞、市場、警示）、Secondary（2s 延遲，加密幣、原物料、情報）、Tertiary（4s 延遲，合約、鯨魚動向、裁員、polymarket），用循序錯開避免一次灌爆 API。

資料來源：30 個以上的 RSS 加四個公開 API

Situation Monitor 最有價值的部分其實是資料來源清單本身。把 src/lib/config/feeds.ts 打開，可以看到 RSS 來源分成六大類，全部是主流媒體與官方機構的公開 feed：

• Politics：BBC World、NPR News、Guardian World、NYT World。
• Tech：Hacker News、Ars Technica、The Verge、MIT Tech Review、ArXiv AI、OpenAI Blog。
• Finance：CNBC、MarketWatch、Yahoo Finance、BBC Business、FT。
• Government：White House、Federal Reserve、SEC Announcements、DoD News。
• AI：OpenAI Blog、ArXiv AI（與 Tech 重複）。
• Intelligence：CSIS、Brookings、CFR、Defense One。

除了 RSS，還接了四個 API：GDELT（Google 資助的全球事件追蹤資料庫，是專案內 news.ts 的核心來源）、CoinGecko（加密幣報價，免 key）、Finnhub（股票／ETF／原物料報價，需 BYO key）、FRED（聖路易斯 Fed 的總經指標，需 BYO key）。資料來源透明度這一條，Situation Monitor 給得很乾淨：所有來源都在 config 檔裡，沒有不可查的私有資料供應商。

這裡有個值得一提的 source-vs-code 校正：.env.example 只列了 VITE_FINNHUB_API_KEY，但實際的 src/lib/config/api.ts 還用了 VITE_FRED_API_KEY。也就是說，只照 .env.example 設定的話，FRED 經濟指標面板會抓不到資料。實際自架時兩個 key 都要申請。

Pin

那個沒被講清楚的 CORS proxy：你的 RSS 查詢預設經過作者的 Cloudflare Worker

純前端抓 RSS 會撞到瀏覽器的 same-origin policy，多數 RSS 來源不送 CORS header。Situation Monitor 的解法寫在 src/lib/config/api.ts 裡，預設的 CORS_PROXIES 是：

export const CORS_PROXIES = {
  primary: 'https://situation-monitor-proxy.seanthielen-e.workers.dev/?url=',
  fallback: 'https://corsproxy.io/?url='
} as const;

翻成白話文：你不修改設定就部署，所有 RSS 抓取會先經過作者的 Cloudflare Worker（situation-monitor-proxy.seanthielen-e.workers.dev），失敗才 fallback 到第三方 corsproxy.io。這意味著你開 demo、或自己架一份卻沒改 config 的話，每次刷新面板，RSS 查詢的 URL、頻率、來源 IP 都會經過作者 control 的 worker。作者有沒有記 log、記多少、保留多久，原始碼與對外文件都沒說。

這個設計本身是純前端 App 常見的折衷，類似 FeedCraft 的 RSS 中介層也在處理同一個問題，只是人家把 proxy 邏輯寫成你自己架的中介層，不是綁在作者基礎設施上。Situation Monitor 沒有給「自架 proxy」的範例，作者也沒在倉庫附 worker 原始碼。要避開這個依賴，你得自己 fork 一份、把 CORS_PROXIES 改成自己架的 proxy URL，或改成 serverless function 直抓。

對於把這個工具當研究面板、RSS 來源都是公開媒體的人，這個依賴或許可以接受；對於把 Situation Monitor 部署到公司內部、或追蹤較敏感的區域事件的人，這條 proxy 預設值就是個需要正視的隱私決策點。最低限度，自架之前先到 src/lib/config/api.ts 把這兩個 URL 換掉。

BYOK 的兩個 API key 與 VITE_ 前綴的副作用

要讓市場與總經面板真的有數字，需要兩個 API key：Finnhub（市場報價，免費 tier 每分鐘 60 次，到 finnhub.io 註冊）與 FRED（聖路易斯 Fed 的總經資料，免費 tier 無限請求，到 stlouisfed.org 註冊）。CoinGecko 與 GDELT 不需要 key。

這裡的關鍵 gotcha：SvelteKit 的環境變數用 VITE_ 前綴代表「會被打包進用戶端 bundle」。也就是說，你申請的 Finnhub 與 FRED key 會以明文形式嵌進編譯後的 JavaScript，任何打開你部署的網站、按 F12 看 source 的人都能抽出來。免費 tier 的 key 被抽走影響有限（頂多觸發速率限制），但這個性質要先理解：BYOK 在純前端 SvelteKit 專案裡，本質上不是「你的 key 留在本機」，而是「你的 key 跟著每個造訪者的瀏覽器一起發請求」。

Finnhub 號稱免費 tier 每分鐘 60 次，但實際上 Situation Monitor 的 Critical 階段一次刷新就會打將近 10 個 quote 請求（4 個大盤 ETF 加上多個原物料與加密幣），多人同時使用同一個 key 很容易撞限制。如果你打算給團隊用，建議直接升 Finnhub 付費 tier 或自建市場資料的快取層。

「開源」這兩個字：原始碼公開不等於授權使用

Situation Monitor 在對外介紹裡一直被稱為「開源」，但實際查 GitHub 倉庫 hipcityreg/situation-monitor 的 License 欄位，顯示的是 None。根目錄也沒有 LICENSE 檔案（用 curl 抓 raw.githubusercontent.com/.../main/LICENSE 回 404）。GitHub 的預設規則是：沒有 LICENSE 檔的倉庫，法律上保留所有權利給作者，public 不等於 licensed，你不能直接當作開源自由取用、修改、再散布或商業使用。

這個區分在中文圈常被混淆。「原始碼公開」（source-available）與「開源」（open source）不是同一件事：前者只是「你看得見 code」，後者還包含一份具法律效力的授權條款（MIT、Apache-2.0、GPL 等）允許你使用、修改、再散布。Situation Monitor 目前是前者。要把它當作開源專案使用，至少得等作者補上 LICENSE 檔，或取得作者書面授權。

個人拿來自架、自己追蹤訊號，多數情境下沒人會管你；但若打算商業部署、改作、或包進自家產品，這個授權真空就是必須先處理的硬阻塞。如果是後者，建議直接聯繫作者（GitHub 倉庫的 issue 或 discussions）釐清授權意圖。

4,170 顆星的另一面：明星專案的停滯訊號

4,170 顆星、924 個 fork、19 個 open issues、0 個 release。把 GitHub API 撈出來的時間軸對齊來看，會看到一個耐人尋味的模式：倉庫建立於 2026 年 1 月 7 日，最後一次 commit 在 1 月 13 日，整個開發活動集中在 6 天內，之後 main 分支就凍結到現在。updated_at 雖然顯示 2026 年 7 月 24 日，但那是 GitHub metadata（stars、forks、wiki 編輯等）的更新，不是原始碼變動。要判斷一個專案是否還活著，看 main 分支最後 commit 比看 pushed_at 準。

這在開源專案裡不算罕見模式：一個專案在初期衝上 Hacker News、reddit、推特，幾天內湧入大量星，作者解掉最 immediate 的 bug（看 commit 訊息是 PR #17 修 Vercel redirect URL），然後熱情退燒、回歸主業、專案進入維護停滯。高星數不等於活躍維護，這個觀察也適用於其他號稱熱門的監控類工具，例如 Sniffnet 的 network 監控或 DeepSeek API 監控工具。

實際影響是：你今天 fork 一份部署，半年後想回頭跟上游 sync 新功能或修過的 bug，會發現上游沒有動，等於 fork 的瞬間就是 final 版本。對個人使用者影響有限（你拿到的是 1 月 13 日版的快照），但對團隊部署來說，要評估「上游不會再修 CVE、不會再加新資料來源」這個長期風險。

自架流程：四步把 Situation Monitor 部署成你自己的

部署流程本身不複雜，多數時間會花在決定要不要 fork、改 proxy URL、申請 API key 這幾個前置決策上。

申請 API key：先到 finnhub.io 與 stlouisfed.org 註冊兩個免費 key，不然 market 與 economic 面板會是空的。

決定是否 fork：如果要避開前面講的 CORS proxy 預設值，建議 fork 一份，改 src/lib/config/api.ts 把 CORS_PROXIES.primary 換成自己架的 proxy URL（或直接刪除讓它 fallback 到 corsproxy.io）。

git clone https://github.com/hipcityreg/situation-monitor.git
cd situation-monitor
cp .env.example .env
# 編輯 .env 填入 VITE_FINNHUB_API_KEY 與 VITE_FRED_API_KEY
npm install
npm run build