HK Odds Pick — 港彩賠率 AI 預測 SEO 實戰
即時賠率 + AI 因子模型 + SportsEvent schema 三位一體。公開架構決策、多 LLM fallback、env 衛生機制。
RedClaw 為 HK Odds Pick（hkoddspick.com）建構一套「即時賠率 ingestion → AI 因子模型 → 時效性 SEO 內容」的端到端架構。差異化在於：(1) 完整 SportsEvent schema 標記每場賽事，讓 Google 把賠率視為結構化資料而非一般文章；(2) AI 因子模型 fallback 鏈（Gemini → Claude → DeepSeek）解決 LLM API 限額與成本；(3) env var 衛生機制（防止 trailing newline 讓 LLM 靜默失敗）；(4) 時效性內容自動化，每場賽事 24 小時內產出分析。本頁公開技術選型與踩過的工程化坑。
HK Odds Pick（hkoddspick.com）是什麼？
HK Odds Pick 是 RedClaw 服務的香港賽馬賠率 AI 預測平台，對應域名 hkoddspick.com。RedClaw 負責 SEO 架構（含 SportsEvent / Article / FAQ schema）、AI 因子預測模型工程（多 LLM fallback 鏈）、時效性內容 pipeline 與基礎設施維護。本頁公開技術選型細節與可被驗證的工程化做法，可作為類似 sportsbook / 賠率產品 SEO 的參考。
產品基本資料
系統指標（截至 2026-05-24）
架構與技術指標公開；流量與營收數據受 NDA 保護。
RedClaw 為 HK Odds Pick（hkoddspick.com）部署 3 層 LLM fallback 鏈（Gemini → Claude → DeepSeek），單一 API 失敗時自動切換，搭配 env 衛生機制（防止 trailing newline 讓 LLM 靜默回空），確保 AI 因子分析的可用性與一致性。 (來源: RedClaw, 2026-05-24)
為什麼這套架構會贏：三根支柱
一般 sportsbook 站把每場賽事寫成文章 + 表格。我們把每場賽事標 SportsEvent + Event status + competitor + offerCount + lowPrice / highPrice，讓 Google 把整場賽事當「實體」處理。長尾查詢「[馬名] 賠率」「[騎師] 勝率」直接命中富結果。
Gemini 2.5 Flash 預設啟 thinking tokens 會吃光 maxOutputTokens 把 JSON 截斷；Claude 偶爾 rate limit；DeepSeek 便宜但中文穩定度差。我們用 fallback 鏈：Gemini（含 thinkingConfig: { thinkingBudget: 0 } 關掉 thinking）→ Claude → DeepSeek，任一失敗自動切。每次切換寫進 syncLogs 可追蹤。
Vercel 環境變數最常見的災難是「值尾端帶 \n」— Google 會拒收 GEMINI_API_KEY、aiFactors 靜默回空，每次 debug 30 分鐘起跳。我們寫了 sanitize-env.ts 在 build 時掃所有 env，trailing \n\r\s 直接 fail。這是跨專案的工程化護欄。
這證明了什麼（對未來客戶）
HK Odds Pick（hkoddspick.com）是一個活著的 sportsbook / 賠率產品 SEO 範本 — 可被直接訪問與引用。
- 1能在競爭最激烈的香港賽馬 SEO 取得空間
香港賽馬 SEO 玩家很多，傳統 Article + 表格的做法早被洗到第 3 頁。HK Odds Pick 走 SportsEvent + Knowledge Graph 路線，把每場賽事變成 Google 識別的「實體」，長尾查詢（特定馬名、騎師、場次）能切進富結果。這是「結構勝過內容」的範例。
- 2能交付 AI 因子產品 — 不只「用 ChatGPT 寫文章」
6 個獨立預測因子 prompt + 3 層 LLM fallback + thinkingConfig 控制 + syncLogs 可觀測 + env sanitization。這是工程，不是「AI 廣告」。每個技術決策都有原因（為什麼 Gemini 不能用預設、為什麼 Claude 不能單獨用、為什麼 DeepSeek 只能做 fallback），可在 FAQ 第 2 題完整復現。
- 3能用「跨專案工程護欄」防止重複踩同一個坑
env 衛生機制（sanitize-env.ts）、Vercel pre-deploy checks、Firestore SA key 結尾驗證、Gemini thinkingBudget=0 預設設定 — 這些工程護欄不是只給 HK Odds Pick，是同步寫進 RedClaw 跨專案知識庫，所有客戶都受益。一個坑踩過一次，全公司不會再踩第二次。
常見問題
為什麼 sportsbook 站要用 SportsEvent schema 而不是 Article？▾
Article 是「人類撰寫的文章」。SportsEvent 是「真實發生的賽事實體」。後者讓 Google 把賠率視為 dynamic facts（含 startDate、competitor、odds value），可進入 Google 賽事 carousel、Knowledge Panel 與 AI Overview 的賽事問答。Article 永遠進不了那些位置。HK Odds Pick 每場賽事頁都標完整 SportsEvent，這是它能在競爭激烈的香港賽馬 SEO 取得空間的關鍵。
為什麼用 3 層 LLM fallback 而不是直接挑最好的一個？▾
三個現實：(1) Gemini 2.5 Flash 預設啟 thinking tokens 會把 JSON 截斷，要 thinkingConfig: { thinkingBudget: 0 } 關掉，且偶爾整個 region rate limit；(2) Claude 配額有上限，賽事日尖峰會撞牆；(3) DeepSeek 便宜但中文穩定度差，做 fallback 不做主力。賽馬內容是時效性產品，AI 寫不出來 = 那場賽事就無內容。fallback 鏈確保「永遠有東西出來」，這比「永遠用最頂尖模型」重要。
env 尾端 \n 為什麼是災難級的 bug？▾
剪貼簿、CI/CD、某些 shell 都可能讓 env 值尾端帶 \n。後果分三層：(1) Google API 直接回「key not valid」— 還算容易發現；(2) LLM API 收下但回空字串 — 這個最爛，aiFactors / reasoning 靜默回空，前端不會報錯；(3) Firestore SA key JSON 結尾帶 \n 整段解析失敗。每次 debug 30 分鐘起跳。我們的 sanitize-env.ts 在 build 時掃，發現就 fail build，根本不讓上線。
怎麼驗證 HK Odds Pick 案例的真實性？▾
四個方式：(1) 直接訪問 hkoddspick.com 看活的賠率頁；(2) view-source 看 SportsEvent JSON-LD schema；(3) Google Rich Results Test 跑任一賽事頁，看 SportsEvent 是否綠燈；(4) NDA 後我們開放部署 repo、LLM pipeline 程式碼與 syncLogs 範例給技術窗口。
這套架構可以複製到其他賽事類產品嗎？▾
可以。SportsEvent schema 適用於足球、籃球、棒球、F1、電競等所有 sportsbook 垂直；多 LLM fallback 跟 env 衛生是與 vertical 無關的工程護欄。新客戶差異只在：(1) 賠率資料來源 API；(2) 預測因子定義；(3) 在地化 schema（聯賽名、競賽地點）。已經有架構模板，2-3 週可上線新 vertical。
AI 因子模型用了什麼 6 個因子？▾
賽馬常用 6 因子：(1) 即時賠率走勢（莊家信號）；(2) 場地適性（軟地/草地/沙地）；(3) 騎師近期成績；(4) 馬匹當前狀態（體重變化、近 5 場名次）；(5) 血統與配種；(6) 天氣與道濕度。每個因子由獨立 prompt 產生短評，LLM 整合成完整分析。權重可在前端依產品需求調整。