開源樂透資料看板 Double-Color-Ball-AI，把開獎歷史變成多模型 AI 比較

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

Double-Color-Ball-AI 是一個以中國福利彩票「雙色球」開獎資料為素材的開源資料看板專案，用 Python 腳本爬取並清洗歷史開獎紀錄，再透過四個大型語言模型產生各自的選號策略，最後在前端用 Chart.js 圖表把開獎趨勢與模型輸出同台陳列。整個專案放在 GitHub 上以 MIT 授權釋出，任何人都能下載、修改、自架。

這個專案最初的分享文把它定位為「純粹的資料視覺化學習案例」，甚至註明「不具備任何預測功能」。然而對照 GitHub 倉庫的說明文字與實際程式碼，專案名稱與描述都明確標示為「AI 雙色球彩票預測」，內含完整的預測生成腳本與五種選號策略。對想研究資料工程鏈路與多模型結構化輸出比較的開發者來說，這個專案的技術骨架有清楚的參考價值；但彩券開獎本質上是隨機事件，任何統計模型都無法提高中獎機率，這一點在閱讀時務必放在心裡。本文把重點放在工程實作面，不討論選號建議。

從原始碼看專案的實際組成

來源分享文以「Python/Vue.js 資料視覺化看板」來描述這個專案，但實際 clone 倉庫後會發現技術堆疊完全不同。前端是純 HTML、CSS 與 JavaScript，沒有 Vue 框架，也沒有 package.json 或建置步驟；圖表用的是從 CDN 載入的 Chart.js 4.4.0，而非文章提到的 ECharts 或 Recharts。這個落差本身無傷大雅，但如果照著分享文的技術標籤去找對應的原始碼結構，會浪費不少時間。

Pin

專案的實際組成是三層：後端是 Python 腳本，負責從 500 彩票網爬取歷史開獎資料、清洗成 JSON，以及呼叫 AI 模型產生預測；資料層是幾個 JSON 檔案，存放 144 期歷史紀錄、模型預測結果與預測歷史；前端則是三個 JavaScript 檔案搭配 Chart.js，把資料渲染成互動式圖表與模型卡片。沒有資料庫，沒有後端伺服器，前端透過 fetch 直接讀取 JSON 檔案。

線上 demo 部署在 Vercel 上，打開後會看到當期（例如 2026 年 7 月 23 日第 26084 期）的預測發布頁面，包含四個 AI 模型的預測卡片、資料趨勢分析圖表，以及歷史資料回溯區。資料每期透過 GitHub Actions 自動更新，倉庫最近一次推送就在 2026 年 7 月 22 日，屬於活躍維護中的專案。

Pin

從原始網頁到結構化資料的工程鏈路

資料爬取的入口是 fetch_history/fetch_lottery_history.py，用 Python 的 requests 搭配 BeautifulSoup 從 500 彩票網的歷史開獎頁面抓資料。腳本會把 HTML 表格解析成結構化的 JSON，包含期號、紅球號碼陣列、藍球號碼與開獎日期，再合併去重後寫入 data/lottery_history.json。這個 JSON 目前累積了 144 期紀錄，並且帶有一個 next_draw 欄位標示下一期的期號與開獎時間。每期資料的欄位設計相當乾淨：period 存期號字串、red_balls 是六個號碼的陣列、blue_ball 是單一號碼、date 是開獎日期。這種扁平化的結構讓前端可以直接消費，不需要再做轉換。

這條鏈路對學習資料工程的人來說是很好的參考：從非結構化的網頁 HTML 出發，經過解析、清洗、正規化，最終產出可以直接被前端消費的 JSON。腳本還包含錯誤重試機制與帶時間戳的備份功能，這些都是實務上爬蟲腳本該有的設計。不過 500 彩票網的頁面結構若改版，爬蟲就需要跟著調整，這是所有依賴第三方網頁的資料管線共同的維護成本。

前端方面，data-loader.js 負責讀取三份 JSON 檔案，app.js 是主邏輯，components.js 則放 UI 元件的渲染函式。圖表全部用 Chart.js 繪製，包括開獎號碼的分布、頻次統計的柱狀圖，以及趨勢折線圖。對於想了解「如何把靜態 JSON 餵進 Chart.js 做互動式視覺化」的人，這部分的程式碼相當直接易讀。

四個 AI 模型的結構化輸出比較設計

這個專案在技術上最值得參考的部分，是多模型結構化輸出的比較框架。generate_ai_prediction.py 會讀取歷史開獎 JSON，套用一份寫在 doc/prompt.md 裡的 prompt 模板，然後依序呼叫四個 AI 模型，要求每個模型產生五組不同策略的選號結果，全部以嚴格的 JSON 格式回傳。這本質上是一場「同一份 prompt、同一份資料、不同模型」的結構化輸出對照實驗。

prompt 模板設計了五種策略：熱號追隨者挑最近 30 期高頻號碼、冷號逆向者挑低頻號碼、平衡策略師在奇偶比與大小比之間做多維度平衡、週期理論家找短期頻率上穿長期頻率的號碼、綜合決策者融合前四種策略。每組結果都包含紅球六碼、藍球一碼與策略說明，並且要求模型只回傳純 JSON。模板裡還嵌入了規則約束，例如紅球必須從 01 到 33 選六個且按大小排序、藍球從 01 到 16 選一個，這些約束確保不同模型的輸出格式一致，可以做逐欄對比。這份模板對於想研究「如何讓 LLM 穩定輸出結構化資料」的人，是一份現成的參考實作，generate_ai_prediction.py 裡還有 JSON 驗證邏輯，會檢查欄位完整性、號碼數量與排序是否正確，驗證失敗就跳過該模型繼續執行下一個。

不過這裡有一個必須指出的誠實問題：模型名稱的標示與實際呼叫的 API 不一致。從 generate_ai_prediction.py 第 20 至 25 行的 MODELS 設定可以看到，看板上顯示為「GPT-5」的模型，實際呼叫的 API ID 是 gpt-4o；顯示為「Claude 4.5」的，實際是 claude-3-5-sonnet-20241022；顯示為「DeepSeek R1」的，實際是 deepseek-chat。只有 Gemini 的標示大致符合。這意味著看板上呈現的「模型比較」，名稱被抬升了一個世代，讀者在解讀比較結果時需要留意這個落差。

另外，AI 呼叫走的是 BYOK（自備金鑰）模式。專案的 .env.example 預設指向 aihubmix.com 這個第三方 API 聚合服務，使用者必須自己申請 API 金鑰才能啟用預測功能。換句話說，你要產生自己的預測，就必須把歷史開獎資料連同 prompt 一起送到第三方伺服器處理。這和自然語言查資料的 AI 工具一樣，都是資料在本地、AI 處理在雲端的架構，差別在於這裡的資料是彩票開獎紀錄而非業務資料。

統計特徵工程的學習參考

專案內建的幾種策略，背後對應的都是統計學裡經典的特徵工程手法。頻次分析計算特定區間內每個號碼的出現次數，均值回歸觀察低頻號碼在長週期下是否往均值靠攏，離散度計算則衡量奇偶與大小分布的平衡性。這些計算邏輯散布在 prompt 模板與前端 JavaScript 裡，對於想了解「如何把統計概念寫成可執行程式碼」的人，可以當成閱讀教材。

但必須再三強調：這些手法套用在彩券資料上，並不具備任何預測效力。雙色球的開獎是獨立隨機事件，每一期每個號碼出現的機率都是相同的，歷史頻次、冷熱週期都不影響下一期的結果。專案作者在 AI 預測指南裡也寫了「本腳本僅供學習交流使用，不構成任何投資建議」，這句話應該認真對待。如果你對量化分析的工程實作有興趣，可以參考自架量化工作台的專案，那裡的統計手法應用在金融資料上才有實質意義。

限制與誠實考量

這個專案有幾個需要誠實標示的限制。最根本的是預測效力：彩券開獎是純隨機事件，任何基於歷史資料的統計策略都無法提高中獎機率。專案的核心價值在於資料工程與 AI 輸出比較的技術骨架，而非預測結果本身。如果你是為了「用 AI 預測彩券號碼」而來，這個工具幫不了你。

模型標示也值得留意。如前一段所述，看板上的模型名稱被抬升了一個世代，這會誤導讀者對各模型能力的判斷。如果你要拿這個專案來做模型比較的參考，務必回到原始碼確認實際呼叫的 API ID，而不是相信看板上顯示的名稱。這種顯示名稱與底層呼叫不一致的做法，在以展示為目的的專案裡不算罕見，但放在標榜「模型比較」的脈絡下就顯得矛盾。

資料流向是另一個需要理解的面向。啟用 AI 預測功能需要把自己的 API 金鑰設到環境變數，歷史開獎資料連同 prompt 會經由 aihubmix.com 送往模型供應商。雖然彩券開獎資料本身不涉及隱私，但這提醒我們：任何 BYOK 工具都存在「資料在本地、處理在雲端」的邊界，使用前應確認你信任那個 API 聚合服務的資料政策。aihubmix 屬於第三方 AI API 聚合服務，本身不是模型供應商，而是把多個模型的 API 統一包裝成一個端點，這意味著你的請求會經過多一層轉發。

資料來源的依賴性同樣值得考慮。爬蟲腳本依賴 500 彩票網的頁面結構，對方一旦改版，整條資料管線就會斷裂。這不是這個專案獨有的問題，而是所有網頁爬蟲方案共同的維護成本。不過專案有 GitHub Actions 自動排程，能在結構不變的前提下持續更新資料，加上 MIT 授權允許自行修改爬蟲目標，這一點算是設計得比較完整。若你想把同樣的骨架套用到其他公開資料集，只需替換爬蟲目標與欄位定義，前端圖表邏輯基本可以沿用到任何時間序列資料的視覺化。

適合誰，不適合誰

這個專案適合正在學習資料工程全鏈路的開發者：你想看一個從網頁爬取、資料清洗、JSON 正規化到前端視覺化的完整範例，而且規模夠小（整個專案不到三十個檔案），可以在一個下午讀完。它也適合想研究多模型結構化輸出比較的人：prompt 模板如何設計、如何驗證回傳的 JSON、如何把不同模型的輸出排版在同一個介面上，這些都能在原始碼裡找到答案。如果你最近在比較不同 AI 訂閱方案的結構化輸出能力，這個專案的對照框架可以借鑑。

不適合的人也很清楚：如果你是為了買彩券而想找「AI 選號工具」，這個專案對你沒有實用價值。彩券開獎是隨機事件，再精密的統計模型也改變不了每個號碼出現的機率。同樣地，如果你期待一個開箱即用的資料視覺化產品，這個專案更接近一份學習用的範例程式碼，需要自己讀原始碼才能從中獲益。

授權與專案狀態

專案以 MIT 授權釋出，LICENSE 檔案完整，版權標示為 2026 年 sinyu。MIT 是最寬鬆的開源授權之一，允許商業使用、修改與再散布，只需保留版權聲明。截至 2026 年 7 月，倉庫累積了 143 個星標，主要語言是 JavaScript，沒有正式的 release 標記，但程式碼透過 GitHub Actions 每期自動更新資料。Issue 追蹤區有兩個開放中的功能請求，都是希望增加其他彩種的支援（大樂透、福彩 3D），顯示社群有一定的延伸需求。

常見問題

這個工具能幫我中獎嗎？不能。雙色球開獎是獨立隨機事件，每一期每個號碼的出現機率都相同，歷史資料與統計模型都無法改變這個事實。專案的價值在於資料工程與 AI 比較的技術骨架，不在於預測結果。

看板上的「GPT-5」和「Claude 4.5」是真的嗎？不是。原始碼顯示「GPT-5」實際呼叫的是 gpt-4o，「Claude 4.5」實際是 claude-3-5-sonnet，「DeepSeek R1」實際是 deepseek-chat。模型名稱被抬升了一個世代，做比較時應以原始碼的 API ID 為準。

能在台灣使用嗎？專案針對的是中國福利彩票雙色球，台灣並沒有這個彩種。技術骨架可以參考，但如果你要套用到台灣彩券，需要自行替換爬蟲目標與資料結構。此外，台灣對彩券的相關法規與中國不同，使用前請自行確認。

需要付費嗎？專案本身免費且開源，但 AI 預測功能需要自備 API 金鑰（走 aihubmix.com 或其他 OpenAI 相容端點），呼叫模型會產生費用。歷史開獎資料量不大，每次預測的 token 消耗有限，但長期累積仍需留意帳單。