針對溫度結算市場的氣象建模管線。
Polymarket 上有一類市場以城市單日最高溫作為結算依據。PolyWeather 針對這類市場,把分散的氣象觀測與多家數值預報整合成單一決策管線:資料彙整、模型融合、機率校準,再把結果推送到終端機與 Telegram。專案以 Python 為主(56.2%),搭配 TypeScript 前端(37.4%),採 GNU AGPL-3.0 授權,目前版本 v1.8.1(2026-06-07)。
核心方法是 Dynamic Error Balancing(DEB):依各模型近期誤差動態加權,融合多個最高溫預測,再以高斯校準(Gaussian calibration)把點預測轉成機率分桶與每小時共識路徑。資料來源涵蓋多個官方氣象網路——土耳其 MGM、中國 CMA/NMC、日本 JMA AMeDAS、韓國 AMOS 跑道感測器、香港 HKO、台灣 CWA——並整合 TAF(機場定時天氣預報)輔助機場側的時間判斷。
系統監測 51 座城市,橫跨 EMEA、APAC、美洲與南亞。後端與交易機器人以 Docker 部署,前端為 Next.js 儀表板,透過 SSE 即時更新圖表與結算倒數;Telegram 機器人提供雙語的機場與跑道警示。付款採多鏈處理(Polygon USDC、以太坊主網),並提供會員、排行榜、回饋分流與點數的營運後台。
觀測彙整
多模型預報
DEB 融合
高斯校準
機率分桶
終端 / Telegram
Production weather-intelligence stack for temperature settlement markets on Polymarket. 面向 Polymarket 溫度結算市場的生產級氣象情報系統。
用 Docker 啟動後端, 前端本機開發。
PolyWeather 分為兩部分:後端服務與交易機器人以 Docker Compose 啟動;前端儀表板可在本機獨立開發。下列指令取自官方 README。
# 建置映像並在背景啟動後端服務與交易機器人
docker compose up -d --build前端儀表板(本機開發)
前端是獨立的 Next.js 應用,透過 SSE 取得後端的即時溫度路徑與結算倒數。在 frontend/ 目錄安裝依賴並啟動開發伺服器:
cd frontend
npm ci
npm run dev九個子系統, 從資料到結算。
PolyWeather 由數個職責分明的子系統串成一條管線:資料層彙整觀測與預報,模型層以 DEB 融合並校準,輸出層把機率與共識路徑推送到終端機、Telegram 與營運後台。下表列出主要子系統與其角色。
資料層 · 01
data ingestion
觀測與預報彙整
彙整 51 座城市的即時觀測與多家數值預報,涵蓋 EMEA、APAC、美洲與南亞。
模型 · 02
DEB
動態誤差平衡
依各模型近期誤差動態加權,融合多個最高溫預測為單一共識值。
校準 · 03
Gaussian calibration
機率分桶
以高斯校準把點預測轉為機率分桶,並產生每小時的共識路徑。
官方網路 · 04
official feeds
氣象機構串接
串接 MGM、CMA/NMC、JMA AMeDAS、AMOS、HKO、CWA 等官方氣象網路。
機場側 · 05
TAF
跑道時間判斷
整合 TAF 機場定時天氣預報,輔助機場側與結算時間的判斷。
終端 · 06
realtime terminal
SSE 即時圖表
以 SSE 推送即時圖表更新,疊加結算倒數(settlement runway)。
通知 · 07
Telegram bot
雙語警示
雙語機場與跑道警示;指令含 /top、/id、/diag、/help。
金流 · 08
payments
多鏈結算
多鏈付款處理,支援 Polygon USDC 與以太坊主網。
營運 · 09
ops dashboard
會員與排行榜
會員、排行榜、回饋分流與點數獎勵的營運後台。
想查什麼,看哪個介面
| 你想看什麼 | 對應介面 / 端點 |
|---|---|
| 即時溫度路徑與結算倒數 | Web 終端機(SSE 即時更新) |
| 結算前的機場 / 跑道警示 | Telegram 機器人(雙語推播) |
| 服務存活、系統狀態與指標 | /healthz · /api/system/status · /metrics |
| 會員、排行榜、點數與回饋 | 營運後台 Dashboard |
這套系統的幾個關鍵設計。
以下要點整理自官方 README 與 /docs,說明 PolyWeather 在資料、模型與輸出層的設計取捨。內容皆可在專案文件查證,不含外部社群評論。
要點 01 · 不依賴單一預報
Dynamic Error Balancing 依各模型近期誤差動態調整權重後再融合。融合與校準分離,讓最終的機率輸出可被追溯與檢視。
來源 · 官方 README
要點 02 · 輸出機率,而非單一溫度
系統輸出機率分桶與每小時共識路徑,而非一個點預測。這對應 Polymarket 溫度市場以區間結算的結構。
來源 · 官方 README
要點 03 · 以官方氣象網路為資料底層
資料層串接 MGM、CMA/NMC、JMA AMeDAS、AMOS、HKO、CWA 等官方來源,並以 TAF 補機場側的定時預報。
來源 · 官方 README
要點 04 · 讀訊號前先確認管線狀態
部署後先打 /healthz、/api/system/status、/metrics 三個端點,確認服務與資料新鮮度,再觀察終端機與 Telegram 輸出。
來源 · 官方 README
要點 05 · 中英雙語文件與警示
/docs 提供中英雙語文件;Telegram 的機場與跑道警示亦為雙語,便於跨時區團隊協作。
來源 · 官方 docs
要點 06 · 金流與訂閱分離
付款走多鏈(Polygon USDC、以太坊主網),鏈上邏輯位於 contracts 目錄。專案另提供 Pro 訂閱(29.9 USDC / 30 天)。
來源 · 官方 README
從部署到讀出第一個結算訊號。
以下走一遍實際流程:用 Docker 啟動後端與交易機器人,確認服務健康,啟動前端終端機,並透過 Telegram 取得結算前的警示。指令均取自官方文件;輸出以說明取代具體數值,避免臆測實際回傳內容。
> docker compose up -d --build
> curl http://127.0.0.1:8000/healthz
ok: 200 OK · 服務存活
> curl http://127.0.0.1:8000/api/system/status
> curl http://127.0.0.1:8000/metrics
> cd frontend && npm ci && npm run dev
$ You › /diag
$ You › /top
hl: 結算前的機場 / 跑道警示會主動推播到此對話。
以高斯校準,把多模型預測 轉成機率分桶與每小時的共識路徑。
這段流程說明了什麼
價值不在單一預測,而在可重複的管線:資料彙整、DEB 融合、高斯校準、推播,每一步都有對應的服務與端點可檢視。健康檢查與指標端點讓你在讀訊號前,先確認資料是新鮮的。
輸出設計對齊市場結構。Polymarket 的溫度市場以區間結算,因此 機率分桶 比點預測更直接對應下注決策;每小時的共識路徑則讓你看到結算倒數內,預測如何收斂。
上線前, 先看清楚這些邊界。
把 PolyWeather 接進你的流程。
PolyWeather 的程式碼與文件公開,可自行佈署、擴充資料來源,或調整融合與校準。以下是幾條延伸方向。
進階玩法地圖
**1. 接更多城市與來源。**資料層以官方氣象網路為主。若你關注的市場不在 51 座監測城市內,可在 src/ 與 config/ 擴充對應的觀測與預報來源。
**2. 把指標接進監控。**以 /metrics 的 Prometheus 指標接 Grafana,監看資料新鮮度、模型誤差與排程狀態。
**3. 自訂融合與校準。**DEB 與高斯校準的參數可依市場調整;先用歷史結算回測,再上線。
**4. 客製 Telegram 警示。**調整 /diag、/top 等指令與警示門檻,讓推播對齊你的結算時程。
5. 檢視鏈上金流。contracts/ 目錄含鏈上付款邏輯;自架金流前,先在測試網驗證。
最該讀的三份延伸閱讀
Production weather-intelligence stack for temperature settlement markets on Polymarket.