Tenten · Field Guide № 04
2026 年版
AI 預測市場 / Polymarket
閱讀時間 約 35 分鐘
A Trader's Field Guide to Prediction Markets

Polymarket 建構 AI 交易代理。 從環境設定到部署,涵蓋技術架構、提示工程與風險控管。

Polymarket 上 84.1% 的錢包處於虧損,頂端 1% 的帳號賺走逾八成利潤,其中絕大多數是自動化機器人。本指南說明完整的技術堆疊、決策邏輯與風險框架,協助開發者評估是否進場,以及如何建構可維護的代理系統。

84.1% 錢包
處於虧損
73.3% 市場
以 NO 結算
$9B+ 2024 累計
交易量
<100ms 機器人捕獲
73% 套利
01 Foundations / 基礎概念

Polymarket:預測市場的運作機制

預測市場把「未來事件的機率」轉換成可交易資產。以下先釐清核心術語,再說明它與一般賭博平台的結構差異。

Polymarket 是建構在 Polygon 區塊鏈上、以 USDC 結算的去中心化預測市場。每一個「市場」是一個是非題:「BTC 會在 2026 年 6 月前突破 15 萬美元嗎?」「川普會贏 2024 大選嗎?」「2026 年 6 月歐冠決賽誰會贏?」每一題產生兩個獨立的 ERC-1155 代幣,一個代表「Yes」結果,一個代表「No」結果。價格介於 0 到 1 美元之間,可解讀為市場對該事件發生機率的估計。

當你買入「Yes」代幣,本質上是付錢給願意在事件不發生時收下這筆錢的對手方。如果事件真的發生,每一張代幣的最終結算價是 $1,差額就是你的利潤。價格 $0.65 意味著市場認定 65% 的機率,你買進就是在賭實際機率 高於 65%。

交易者下注的對象是市場標出的機率是否偏離真實機率,而非事件本身的結果。混淆這兩者是散戶虧損最常見的原因。 — Lookonchain,分析 35 天虧 200 萬美元的交易者

三個必須記住的概念

Condition ID
市場識別碼
代表一個事件題目。從預言機與題目參數推導出的十六進位字串。
Token ID
結果代幣 ID
每個結果(Yes/No)獨立的 ID。下單交易用的是這個,不是 condition ID。
CTF
條件代幣框架
Conditional Token Framework。Gnosis 開發的智能合約系統,讓結果代幣可拆分組合。
CLOB
中央限價委託簿
Central Limit Order Book。和 Coinbase、Binance 類似的訂單簿撮合架構,不是 AMM。
⚠ 法律警語

Polymarket 的服務條款明確禁止美國公民及其他特定司法管轄區的居民使用平台(無論透過 UI、API 或任何代理工具)。在進場前,請先確認你所在地的合法性。本指南僅供教育用途,不構成法律或財務建議。

02 Reality Check / 現實檢視

進場前需要了解的市場現況數據

以下數字來自 Bloomberg、Dune Analytics 及多份學術論文的交叉驗證。在寫第一行程式碼前,請先消化這些資訊。

2025 年初至今,超過 10 萬個錢包在 Polymarket 上虧損達 $1,000 以上,幾乎是同期獲利 $1,000 以上錢包數量的兩倍。在獲利帳號中,利潤高度集中於行為類似自動化機器人的少數帳號。其餘帳號合計虧損約 1.31 億美元。

多倫多大學的 Charles Martineau 教授分析了 2022 年以來的資料,發現約 69% 的交易者在 Polymarket 上是虧損的,而頂端 1% 的帳號賺走了 75% 的利潤。這與散戶交易的一般研究結論一致。

族群結果解讀
頂端 0.51% 帳號累積利潤 > $1,000絕大多數是機器人或專業團隊
頂端 1% 帳號賺走 80%+ 的全平台利潤高度集中
進行 50+ 筆交易的帳號已贏過 77% 的使用者大多數人只是淺嚐
所有交易過的錢包84.1% 處於虧損2.5M 錢包鏈上分析
賺進 $100K+ 的帳號僅 0.033%機率比中樂透稍高
機器人的優勢在於下單速度,而非預測準確率。散戶即使猜對結果,也因入場延遲、成交價格不佳而產生虧損。 — Joshua Della Vedova 教授,San Diego 大學

這直接影響架構決策:跑在筆電上、透過 REST API 呼叫 Claude 進行機率推理的代理,無法在 sub-100ms 套利場景中競爭(該場景由連接 Chainstack 私有 RPC 的機器人主導)。有效的替代方向是選擇需要語意判斷、對延遲容忍度較高的市場類型。

哪些是「人類 + AI」還有勝算的角落?

03 System Architecture / 系統架構

三個 API、一條鏈、一把需要本地管理的私鑰

Polymarket 的功能分散在三個 API 端點上。了解各端點的職責分工,是排除開發期錯誤訊息的基礎。

API主機名稱用途需要驗證
CLOB APIclob.polymarket.com訂單簿、下單、撤單、部位L1(錢包)+ L2(HMAC)
Gamma APIgamma-api.polymarket.com市場 metadata:題目、token IDs、24h 成交量
Data APIdata-api.polymarket.com任意錢包的歷史部位、PnL(鏈上公開)

三個你會踩到的坑

坑一:把 Gamma 當訂單簿用。Gamma 的 outcomePrices 欄位是延遲快照,可能比 CLOB 真實訂單簿落後幾秒。要做價格敏感的決策,永遠讀 CLOB get_order_book(token_id)

坑二:混淆 condition ID 和 token ID。下單時要傳的是結果代幣的 token ID(YES 或 NO 各有一個),不是市場的 condition ID。買錯邊是非常昂貴的錯誤。

坑三:忘了 negRisk: true。多結果市場(例如「誰會贏 2024 大選」有 5 個候選人)使用 negative-risk 模型,所有結果共用一個 collateral pool。在這類市場下單,必須在 order options 設定 negRisk: true,否則交易所合約會拒絕你的單,丟出一個語意不明的錯誤。

簽章類型一覽(這會決定你怎麼初始化 client)

signature_type = 0
EOA / MetaMask
直接持有私鑰的錢包。包含硬體錢包。必須先手動 approve CTF 合約的 USDC 額度。
signature_type = 1
Email / Magic Link
透過 Polymarket UI 用信箱註冊的帳號。最常見。SDK 會自動處理 CTF approval。
signature_type = 2
Browser Wallet Proxy
透過 proxy 合約的瀏覽器錢包。較少見。
funder
資金錢包地址
「實際持有 USDC 的地址」。對 Magic / proxy 帳號來說,這跟 PRIVATE_KEY 對應的地址不同。

訂單類型總表

類型角色行為適用場景
GTCMaker限價單,留在簿上直到成交或撤銷做市、被動掛單收 rebate
GTDMaker限價單,到指定時間自動失效事件前掛單,避免遺忘
FOKTaker市價單,全部成交或全部取消事件驅動的快速進場
FAKTaker市價單,能成交多少就成交,剩下取消大單分批吃流動性
關鍵知識 — 沒有沙箱

Polymarket 在 Polygon mainnet (chain_id 137) 上運行。Amoy 測試網 (80002) 上的 CLOB 部署 並不穩定,且不會反映真實流動性。要測試你的下單邏輯,唯一務實的選擇是:用非常小的金額($1–$5)在 mainnet 上做。把這個成本當作學費。

04 Environment / 環境設定

環境設定:依賴項目與初始化

以下以 Python 為例(SDK 最為成熟)。TypeScript 或 Rust 的流程邏輯相同,替換 SDK 名稱即可。

你需要的東西清單

⚠ 私鑰安全

你的私鑰掌控所有資金。它不像 API key 可以撤銷。不要 commit 到 git、不要貼給 AI 助理、不要存在 Notion、不要寄信給自己。用 .env + python-dotenv,並把 .env 加進 .gitignore。更進一步:用 1Password CLI / AWS Secrets Manager 把它從本地檔案系統移除。

專案初始化

# 建立專案
mkdir polymarket-agent && cd polymarket-agent
python3 -m venv .venv
source .venv/bin/activate

# 安裝套件
pip install py-clob-client-v2 python-dotenv requests anthropic

# 建立 .env 檔案
cat > .env <<EOF
POLYMARKET_PRIVATE_KEY=0x...
POLYMARKET_FUNDER_ADDRESS=0x...
POLYMARKET_SIGNATURE_TYPE=1
ANTHROPIC_API_KEY=sk-ant-...
EOF

# 別忘了
echo ".env" >> .gitignore
echo "__pycache__/" >> .gitignore
echo "*.db" >> .gitignore

第一次握手:確認你能跟 CLOB 講話

import os
from dotenv import load_dotenv
from py_clob_client_v2 import ClobClient, ApiCreds

load_dotenv()

# Level 0:無驗證,只是 ping
client = ClobClient(host="https://clob.polymarket.com", chain_id=137)
print(client.get_ok(), client.get_server_time())

# Level 1:用私鑰,第一次會 derive API credentials
auth_client = ClobClient(
    host="https://clob.polymarket.com",
    chain_id=137,
    key=os.environ["POLYMARKET_PRIVATE_KEY"],
    signature_type=int(os.environ["POLYMARKET_SIGNATURE_TYPE"]),
    funder=os.environ["POLYMARKET_FUNDER_ADDRESS"],
)
creds = auth_client.create_or_derive_api_key()

# Level 2:完整驗證,可以下單
auth_client.set_api_creds(creds)
print("API credentials derived. You can now place orders.")

執行後應看到 ok 及伺服器時間。若出錯,最常見原因是 signature_type 設定不正確。Magic 帳號設為 1,MetaMask 設為 0。

05 First Trade / 第一筆交易

從查詢市場到送出第一筆委託

每一個 token ID 後面都是真實資金。建議先以 $1–$5 的小單跑通完整流程,確認路徑正確後再討論策略。

步驟 1 — 用 Gamma 找市場

import requests, json

GAMMA = "https://gamma-api.polymarket.com"

resp = requests.get(f"{GAMMA}/markets", params={
    "closed": False,
    "active": True,
    "limit": 20,
    "order": "volume24hr",
    "ascending": False,
})
markets = resp.json()

for m in markets[:5]:
    print(m["question"])
    print(f"  24h vol: ${m.get('volume24hr', 0):,.0f}")
    print(f"  prices: {m.get('outcomePrices')}")
    print(f"  token_ids: {m.get('clobTokenIds')}")

步驟 2 — 讀真實訂單簿(不要相信 Gamma 的價格)

target = markets[1]
yes_token_id = json.loads(target["clobTokenIds"])[0]

book = auth_client.get_order_book(yes_token_id)
best_bid = float(book.bids[0].price) if book.bids else None
best_ask = float(book.asks[0].price) if book.asks else None
spread = (best_ask - best_bid) if (best_bid and best_ask) else None

print(f"Best bid: {best_bid} | Best ask: {best_ask} | Spread: {spread}")

步驟 3 — 掛一張小小的 maker 限價單

from py_clob_client_v2 import (
    OrderArgs, OrderType, PartialCreateOrderOptions, Side
)

# 在 best_ask 之下 2 cent 掛買單。如果有人 cross 到我們,就成交。
# 否則就被動等著,賺 maker rebate。
my_price = round(best_ask - 0.02, 2)
my_size = 5.0  # 5 股,$0.XX 一股,總金額很小

resp = auth_client.create_and_post_order(
    order_args=OrderArgs(
        token_id=yes_token_id,
        price=my_price,
        side=Side.BUY,
        size=my_size,
    ),
    options=PartialCreateOrderOptions(tick_size="0.01"),
    order_type=OrderType.GTC,
)

print(f"Order ID: {resp['orderID']}")
print(f"Status: {resp['status']}")

跑通了,你已經把一張單放上 Polymarket 的訂單簿。接下來的所有 AI 邏輯,最終都會走到這個 create_and_post_order 呼叫。

06 Anatomy / 代理解剖

AI Agent 的五層架構拆解

將 Claude 直接接到 CLOB API 是一個腳本,不是代理。代理需要五個可獨立替換的功能層。

多個公開 Polymarket bot 的事後分析指向同一個結論:「導致虧損的原因通常不是推理能力不足,而是缺乏 event log。」以下架構表是這些案例收斂出的最小可行設計。

分層職責技術選擇
1. 資料層每 5–15 分鐘快照 50–200 個目標市場:題目、價差、深度、成交量、外部新聞CLOB + Gamma API + 新聞 API(Tavily、Brave Search、Exa)
2. 篩選層從幾百個市場篩到一張十幾個候選清單,淘汰流動性、價差、措辭可疑的純 Python 規則,不需要 LLM
3. 推理層對每一個候選市場產出:估計機率、信心、推理鏈、新聞依據Claude Opus 4.7(精度)或 Sonnet 4.6(速度成本平衡)
4. 決策層用 Kelly Criterion / Edge 閾值決定要不要下單、下多大純 Python,含風險上限、相關性檢查
5. 執行層下單、撤單、追蹤部位、處理失敗重試py-clob-client-v2
記憶層記錄每一個決策(含 prompt、回應、執行結果、後續結算)SQLite / Postgres + Chroma(向量檢索新聞)
「Production discipline usually matters more than squeezing a bit more model accuracy.」
升級模型版本的效益有限。完善日誌系統的效益更為顯著。 — 多份 2026 Polymarket bot 後驗報告的共同結論

關鍵原則:分離「找機會」和「下單」

常見錯誤是把整個流程串成一個函式:get_markets → ask_claude → place_order。這會產生兩個問題:

正確的做法:讓推理層只輸出結構化的「機率估計 + 推理」,把「要不要下單」交給一個獨立、純規則、可重現的決策函式。這樣你能用同一份 LLM 輸出在不同的決策參數下重跑歷史,找出最適合的閾值。

07 Prompt Engineering / 提示工程

針對預測市場機率估計的 Prompt 設計

依研究文獻,verbalized probability + chain-of-thought + 顯式偏誤提示 是提升 LLM 機率校準(calibration)效果的三個主要手段。以下設計來自 2026 年多個公開 Polymarket agent 框架的收斂結果。

以下作為骨架使用。理解每一段設計的目的,才能針對具體策略進行調整。

SYSTEM PROMPT — Polymarket Market Analyst Production
你是一個冷靜的、機率敏感的預測市場分析師。你的工作不是預測「會不會發生」,而是估計一個事件的真實機率,然後與市場價格比較。 ## 角色與限制 - 你看到的是一個 Polymarket 二元市場。 - 你必須輸出 0.00 到 1.00 之間的機率估計,精確到小數點後 2 位。 - 不要拒絕回答。不確定就坦白寫「low confidence」並把區間放寬。 - 市場價格是分析的起點,不是真實機率。你的任務是評估它是否偏離。 ## 思考步驟(在輸出 JSON 之前,先逐項寫出) 1. 基準率(base rate):類似事件歷史上發生的頻率? 2. 當前訊號:列出最多 5 個支持「會發生」的證據、最多 5 個反對的。 3. 時間衰減:剩餘時間夠不夠讓條件成立? 4. 措辭風險:題目有沒有模糊處?結算規則會不會出乎意料? 5. 偏誤檢查:你是不是被最近的新聞 anchor 過頭? 6. 最終機率:綜合以上,給一個數字 + 90% 信賴區間。 ## 必須輸出的 JSON 格式 { "reasoning": "<step-by-step 中文推理,至少 3 段>", "supporting": ["..."], "opposing": ["..."], "base_rate": <0.0-1.0>, "estimated_probability": <0.0-1.0>, "confidence_interval_90": [<low>, <high>], "confidence_level": "high" | "medium" | "low", "key_risks": ["最多 3 個會讓你估錯的因素"], "wording_concerns": "<有無題目語意問題>" } 只輸出 JSON,不要前後說明文字。
USER PROMPT — 每次決策時動態組合 Per-call
## MARKET Question: {market.question} Description: {market.description} Resolution criteria: {market.resolutionSource} Resolution date: {market.endDate} Current YES price: {best_ask} Current NO price: {1 - best_bid} 24h volume: ${market.volume24hr} Spread: {spread} ## CONTEXT (retrieved from news + RAG) {retrieved_news_snippets} ## TODAY {today_iso_date} 請依照 system prompt 的步驟,輸出機率估計 JSON。

為什麼這樣寫?三個關鍵設計決策

1. 強制 JSON 輸出 + 顯式 schema。這讓你能在後處理階段直接 json.loads(),並把每一個推理步驟存進資料庫。沒有 schema,你就得用正則表達式硬解,這條路通往災難。

2. 強制信賴區間 + 信心等級。Anthropic 與多份學術研究都指出:當 LLM 同時被要求解釋自己的不確定性,它的點估計會變得更校準。直接問「機率多少?」比起問「機率多少,以及你的 90% 信賴區間是?」,後者的 Brier score 平均好 12–18%。

3. 顯式 base rate 步驟。Tetlock 在《Superforecasting》裡反覆強調的核心:好的預測者永遠從「歷史上類似事件的頻率」開始。沒有 base rate 步驟,LLM 容易被最近新聞 anchor 過頭。

進階:用「swarm of personas」

PolySwarm(arXiv 2604.03888)這類研究框架的做法:用 50 個不同 persona 的 LLM 同時評估同一個市場(「保守的金融記者」、「賽局論者」、「政治評論員」、「市場做市商」),再用 confidence-weighted Bayesian aggregation 融合各自的機率估計。對單一 LLM 偏誤有顯著修正效果,代價是 50 倍的 API 成本。

實務折衷:跑 5 個 persona 即可拿到 70% 的好處。Anthropic 的 prompt caching 可以讓共用 system prompt 那段不用每次重算,總成本還可接受。

08 Strategies / 策略

五種已有公開驗證記錄的交易策略

以下策略已有公開實作與回測記錄。建議先透徹理解現有策略,再考慮開發原創方法。

策略 A — Endgame Sweep(終局清掃)

當一個市場接近結算、結果幾乎確定(例如比賽進入第 90 分鐘且 5 比 0 領先),市場價格會逼近 $0.99。但很多小散戶會因為害怕「萬一」或想趕快了結,掛單在 $0.997、$0.998 賣出。有耐心的買家可以把這些單吃光,幾天後拿到 $1.00 結算,賺 0.2–0.5% 的無風險(在合理估計下)利潤。

實作要點:

策略 B — Logical Arbitrage(邏輯套利)

相關市場之間的數學關係有時會出現破綻。例如「川普贏」的價格低於「共和黨贏」的價格,在數學上不成立(除非存在非川普的共和黨候選人)。同時做空高估方、做多低估方,即可鎖定價差。

另一個常見組合:「Trump wins AZ」 + 「Trump wins NV」 + ... 的加總應該約等於「Trump wins 270+」。差異就是套利空間。

策略 C — Latency Arbitrage(延遲套利)

對加密相關市場(「BTC 月底前破 X 美元」),CEX 上的 BTC 現貨價格通常領先 Polymarket 上的隱含機率幾秒鐘到幾分鐘。建一個 log-normal 定價模型,把 BTC 即時價格轉換成預測市場的隱含機率,價差出現時下單

缺點:這個賽道已經非常擁擠。sub-100ms 機器人吃掉了 73% 的套利利潤。你需要私有 RPC(Chainstack、QuickNode)才有勝算。不適合剛入門。

策略 D — Copy Trading Whales(鯨魚跟單)

因為 Polymarket 所有交易都鏈上公開,你可以挑出歷史 PnL 高的錢包,每當他們開新倉,你跟一小部分。工具像 PolyTrack、Stand.trade、Polymarket Analytics 都提供 whale alerts。

缺點:頂尖鯨魚(例如 Fredi9999 / Theo)會用多個錢包混淆軌跡,你可能在跟錯人。而且當鯨魚自己也在用機器人時,等你的腳本看到鏈上事件,價格已經被另一群跟單機器人推高了。

策略 E — Nothing Ever Happens(NO 基準策略)

因為 Polymarket 上 73.3% 的市場最終以 NO 結算,理論上盲買所有 NO 應有正期望值。Sterling Crispin 的開源 bot 測試了這個假設,結果仍虧損,原因是 NO 的開盤價已把這個基準率定價進去了。

此策略的教學意義在於:迫使開發者明確定義一個簡單盲策略需要什麼條件才能獲利。Crispin 後來的修正版本是「只買 $0.65 以下的 NO」,在統計上具備正期望的可能性。

總結 — 該選哪一個?

新手:先從 Endgame Sweep + Copy Trading 起步,這兩個對速度要求最低,最適合驗證你的整套基礎建設。中階:加入 Logical Arbitrage,因為它在數學上明確、可被回測。Latency Arb 除非你有顯著基礎建設優勢,否則不要碰。

09 Risk Management / 風險管理

風險控管:kill switch 與部位限制

Lookonchain 分析的案例:35 天虧損 200 萬美元的交易者勝率為 51%,預測能力並非問題所在。根本原因是單筆部位過大,且缺乏自動停損機制。

四個你必須寫進程式的硬限制

1 — Quarter Kelly
下注大小
用 Kelly Criterion 算出理論最佳倉位,然後只下其 1/4。這是學術研究與業內共識的甜蜜點,能在保留複利效果的同時大幅降低破產風險。
2 — Per-trade cap
單筆上限
無論 Kelly 算出多少,單筆永遠不超過總資金的 5%。新手期建議 1–2%。
3 — Daily loss limit
當日停損
當日虧損達到總資金 10%,自動停止下新單。睡一晚再說。連續壞日子是策略失效的早期信號。
4 — Correlation guard
相關性控管
同時開多個相關市場(例如多個「川普贏 X 州」),把總曝險加總,超過上限就拒絕新單。

Kill Switch — 一個檔案就能殺死整個 agent

import os, sys, time

KILL_FILE = "/tmp/polymarket_agent.kill"
DAILY_LOSS_LIMIT = 0.10  # 10% of bankroll

def should_continue(state):
    # 1. 檔案 kill switch(人類緊急停止)
    if os.path.exists(KILL_FILE):
        print("Kill file detected. Shutting down.")
        return False
    
    # 2. 當日虧損
    today_pnl_pct = state.today_pnl / state.starting_balance
    if today_pnl_pct < -DAILY_LOSS_LIMIT:
        print(f"Daily loss limit hit: {today_pnl_pct:.1%}. Halting.")
        return False
    
    # 3. API 連線健康度
    if state.consecutive_api_errors > 5:
        print("Too many API errors. Halting.")
        return False
    
    return True

# 在主迴圈裡每次決策前呼叫
while True:
    if not should_continue(agent_state):
        sys.exit(0)
    run_decision_cycle()
    time.sleep(60)

代理在運行中必然遇到異常狀況。此時需要的不是更複雜的程式邏輯,而是一個執行 touch /tmp/polymarket_agent.kill 即可讓系統優雅停止的機制。

10 Community / 社群智慧

社群回饋:r/polymarket 高品質建議彙整

r/polymarket(5 萬會員)、X 上的預測市場討論及 Crypto Twitter 是官方文件之外的重要資訊來源,但也包含大量未經驗證的說法。以下為過濾後的實用建議。

社群普遍的真實建議(過濾後)

r/polymarket · 高讚回答合集

把你打算下的金額切成 10 份,先用第一份跑通整個流程兩個月。如果兩個月後你還有興趣、還有 PnL 在正確方向,再考慮放更多進去。

— 為什麼有用:絕大多數失敗的 agent 是在第二、第三週崩潰的(API 改動、邏輯邊界 case、心態失衡),不是在第一天。

Hacker News · Polymarket bot 討論串

不要試圖在你還沒有 paper trade log 之前就上線。最少跑兩週只 log 不下單。當你看到自己的「假設我做了 X」會虧錢,你會慶幸沒上線。

— 為什麼有用:你會發現自己對策略的描述跟它在真實資料上的行為差很多。這是免費的學費。

X / Twitter · 多位前 Polymarket 鯨魚發言

不要把 Polymarket 當成 sportsbook。你不是在賭「Liverpool 會贏」,你是在賭「Liverpool 贏的真實機率 > 66%」。如果你買在 0.66 然後它真的贏了,那只是擲硬幣擲對一次而已。

— 為什麼有用:這個觀念差別會直接決定你的單該不該下、要下多大。是 Polymarket 散戶虧錢最大的根源。

r/MachineLearning · LLM forecasting 討論

LLM 在「找出兩個來源的資訊衝突」這件事上比人類好。在「估計未經明確比較的單一機率」這件事上比人類差。設計 prompt 時善用這個非對稱性,讓模型做比較分析,而非直接生成機率。

— 應用:這直接支持前文 prompt 設計的做法,即強制 LLM 先列出 supporting / opposing 證據,再輸出機率估計。

r/algotrading · Polymarket 專題

如果你已經能在傳統市場(股票、期貨)寫出穩定獲利的 bot,預測市場會稍微簡單一點,因為流動性結構更乾淨。如果你連傳統市場都做不好,Polymarket 不會是你的救贖。

— 為什麼有用:殘酷但真實。把這當作期望值校準。

社群一致警告:別碰這些

Reddit 上品質較高的分析多半出現在重大事件結束後數日。事件期間的熱門貼文情緒成分高,應視為噪音處理。 — PolyTrack Reddit Guide 2026
11 Legal / 法律與倫理

執行前必須確認的法律與合規事項

技術可行性與法律合規性是兩個獨立問題。本節列出需要向法律顧問確認的具體事項,不構成法律意見。

12 Roadmap / 路線圖

從環境設定到部署的六週里程碑

以下是壓縮版時程表,每週有明確的可交付物。第四週的「paper trade」階段是最常被跳過的步驟,也是最能避免資金損失的環節。

Week 1 · 基礎建設

環境設定 + 第一筆手動單

建立 Polymarket 帳號、入 $20 USDC、安裝 SDK、跑通 hello world、手動掛一張 $1 的 GTC 單再撤掉。確認整條鏈路都能動。

Week 2 · 資料管線

建立市場快照與篩選器

每 15 分鐘抓取 50 個高成交量市場的訂單簿、價差、深度。存進 SQLite。寫出篩選邏輯:流動性、價差、措辭。先別下單。

Week 3 · 推理層

接 Claude,產出機率估計

實作第七章的 prompt。對每一個篩選後的市場呼叫 LLM,記錄完整的 input、output、token 用量。每天 cost 控制在 $1–$3。

Week 4 · Paper Trading

跑完整決策迴圈,但不下真單

把 LLM 的機率估計 + Kelly 計算 + 風險規則接起來。決策層輸出「假設交易」並記錄。模擬至少 200 筆假設交易,計算理論 PnL、Brier score、calibration。

Week 5 · 上線(極小單)

放第一筆真錢進去

從 Week 4 的勝率最高策略開始,單筆 $1–$5。跑一週,每天人工 review 每一個決策。會看到 LLM 輸出的偏誤、API edge cases、結算延遲。修。

Week 6 · 風險加固

Kill switch + 監控 + 警報

實作前面提到的四個硬限制、Slack 或 email 警報、每日 PnL 報告。確認你能在 30 秒內讓 agent 停下來。完成後,才考慮放大倉位。

時程預期

六週是下限,不是目標。依公開案例,第一個版本能穩定獲利的開發者平均需要 3–6 個月才能從 paper trade 過渡到具備統計意義的正 PnL。將期望值設定在這個尺度,有助於做出更理性的資源分配決策。