Polymarket 台北天氣
怎麼結算？手機顯示 30 度，為什麼合約不一定算 30 度？

「台北」還不夠，先找到測站名稱

手機寫台北 30°C，預測市場卻把最高溫放在另一格，第一個該查的就是地點。合約標題為了好讀，只寫「台北」；真正決定結果的規則，會把測站與資料來源寫得更窄。

例如 2026 年 10 月 15 日的台北最高溫市場，指定的是 Taipei Songshan Airport Station，也就是台北松山機場測站。來源連結中的識別碼為 RCSS，採 Weather Underground 提供的當日紀錄。

所以，要判斷這張合約，不能只找任何一個名為「台北」的溫度。手機定位可能對應你所在的地點，其他氣象頁也可能顯示另一個測站或預報區域。即使相距不遠，只要規則指定的測點不同，就還沒完成同一組資料的比較。

我會先把測站名稱與來源頁固定下來，才看哪個溫度區間的機率較高。少了這一步，後面再仔細比較預報，仍可能一直在研究另一個地方。

打開正確網站，仍可能拿錯一個數字

這次合約最值得注意的規則，放在說明的第一段：以 Weather Underground 的 Daily Observations 表格為準。若它與 Day High & Low 摘要不同，優先採逐筆觀測表。

中文可以把兩者理解為「各時間點的觀測紀錄」和「當日高低溫摘要」。合約選的是前者。光截一張頁面上醒目的最高溫摘要，還不足以證明符合結算條件。

表格可左右滑動，或聚焦後使用方向鍵。

規則既然把資料欄位列得這麼明確，另一份氣象資料就算更細，也不能自動取代它。例如，外部測站報出 29.6°C，不代表可以自己四捨五入成 30°C，再宣布這張合約的 30 度選項成立。

這裡要分開兩個問題：哪一份資料更適合研究天氣，以及這份合約約定用哪一份資料結算。前者可以比較不同觀測與預報的品質；後者必須回到題目的指定來源。

手機上的 30 度，可能是預報，還不是觀測結果

再看手機畫面。現在氣溫、當日最高溫預報和體感溫度，常會一起出現，但各有用途。以 iPhone 為例，Apple 的資料來源說明指出，除另有說明外，10 天天氣預報由 Apple「天氣」提供。不能因為它也寫台北，就假設數值來自合約指定的觀測表。

以下用一組假設數字示範。同一天看到這四個數字，完全可能沒有任何一項算錯：

表格可左右滑動，或聚焦後使用方向鍵。

在觀測資料已齊備、且沒有觸發例外處理的這個假設裡，合約應核對的是最後一列。最高溫預報 30°C 可以落空；傍晚現在只有 27°C，也不會抹掉白天已記錄的 29°C。

至於體感溫度，中央氣象署的說明把氣溫、濕度與風速放進計算。它用來描述冷熱感受，不能直接填進這張合約的氣溫欄。假設表中的 32°C 只是區分指標的示例，並非由表內其他數字計算而來。

已經看到 29 度，不代表資料已經算完

最高溫看的是整天。中午已記錄到 29°C，只能說目前看到的最高值至少到過這裡；下午仍可能更高，資料也可能補登或修正。只看其中一筆紀錄，就下結論說全天最高恰好 29°C，跳過了剩下的時間。

這張合約還寫明資料截止方式：當指定來源公布隔日第一筆資料，或到觀測日隔天的美東時間 23:59，以較早發生者為準。一般溫度紀錄的修訂，考慮到隔日第一筆資料出現為止。

美東時間不能直接當成台灣時間；「10 月 15 日的最高溫」也不代表台灣一過午夜，所有資料處理與結算就必然完成。判讀期限時要連同條款使用的時區一起看。

另外有兩個例外，會直接改變結果的意義：

• 整天資料缺失：若直到觀測日隔天美東時間 23:59，來源仍沒有該觀測日的資料，條款指定結算到最低區間。本案例最低區間是「26°C 或以下」。這是缺資料的備援結果，不能據此宣稱松山機場那天真的不超過 26°C。
• 明顯錯誤的資料：若來源發生條款所述的技術、操作錯誤或未授權干預，市場可能保留最多七個日曆日等待來源修正。這是另訂的錯誤處理，不代表任何事後改值都會被接受。

因此，「現在機率已經非常接近 100%」和「已依規則完成結算」仍是兩個狀態。要判斷自己看到的是哪個階段，須查看市場狀態與資料紀錄，不能只看價格。

比對數字前，把這一列資料留完整

我會把核對紀錄寫成一行：「市場日期／指定測站／來源欄位／攝氏單位／觀測時間／看到資料的時間」。這幾個欄位齊全，才有辦法知道兩張截圖在不在比較同一件事。

接著沿 Daily Observations 表格查看該日全部紀錄，找出最高值，並確認資料截止與修訂條款。若只是研究接下來還會不會升溫，可以另外參考預報；但預報要留在預測那一側，不能當作已發生的最高溫。

這個案例最容易省錯的步驟，就是看到同一個網站便以為已經核對完成。條款連「哪一張表」都指定了，最後那一欄仍得讀到。