這篇文章在講什麼

這篇文章是「台灣股票自動化研究平台」從原型跨越到 MVP (Minimum Viable Product) 的實戰總結。我們不僅成功串接了從「全市場初篩」到「策略優化建議」的完整數據閉環，更針對台灣 Open Data 的特殊性建立了強大的防禦性資料鏈。這是一份關於如何建構具備「自我進化能力」的量化研究系統的技術指南。

新手先記住這 5 件事

1. 分層資料獲取策略 (Tiered Sourcing)：初篩層 (Screening) 必須使用 Bulk 資料源 (TWSE OpenAPI) 以避開頻率限制；深度研究層 (Research) 則針對 Top 標的精準調用進階 API (FinMind)。這能兼顧廣度與深度，同時節省 API 成本。
2. 研究留痕的一致性 (Run-Level Traceability)：系統必須確保同一個 runId 貫穿全鏈路。若研究紀錄與成效回填、績效分析斷裂，系統會產生「資料幻覺」，導致優化建議毫無意義。
3. 績效評估的語義重構 (Semantic Success)：在量化研究中，成功不代表只有上漲。BUY 漲了是正確，但 BLOCK (風險攔截) 或 SELL 動作後續股價下跌，代表成功規避雷區，應同樣視為正確判定。
4. 論點狀態的自動生成 (Auto-Thesis)：系統不應只產出動作，必須為每個決策附帶「初始投資論點」。透過特徵分數自動建立 active, weakened, broken 狀態，讓後續的績效分析能精確追蹤論點的生命週期。
5. 數據純淨化與防禦邏輯：嚴格處理 TWSE 的千分位逗號解析與 Header 偽裝，並針對 FinMind 實作「空參數過濾」與「節假日自動偏移 (Offset Retry)」。確保報表中只有 N/A 而沒有 NaN% 污染。

白話版整理

1. 徹底治癒「平行世界」：資料鏈的接骨手術

在開發初期，我們發現 run-candidates 執行完後，run-history 卻查不到資料，或是查到舊資料。這是因為強制研究模式跳過了持久化層。我們進行了「接骨手術」：不論研究路徑為何，第一步必須建立 UUID 並持久化 research_runs 與 results。現在，系統的每個組件都鎖定同一個任務 ID，實現了真正的全鏈路追蹤。

2. 台灣 Open Data 的資料防禦術

對接 TWSE (證交所) 是最痛苦的環節：

• 偽裝與轉導：沒帶 User-Agent 會收到 302 或 HTML 錯誤。我們實作了 Header 偽裝與 Follow Redirect 邏輯。
• 逗號陷阱：1,234.50 被解析為 NaN。我們在正規化層加入了全局清洗，徹底根除數值污染。
• 上櫃盲區：TWSE 不包含上櫃股票 (OTC)。我們實作了「來源調度器」，當 TWSE 缺值時自動導向 FinMind 補強。

3. 解決 CLI 懸掛：讓 Node.js 優雅結束

在執行 MVP 腳本時，指令常在輸出報表後卡住。這是因為資料庫與快取的連線池 (Connection Pool) 尚未關閉。我們在所有核心指令末端加入了 process.exit(0)，並將執行環境升級為 tsx。這不僅解決了 DEP0180 棄用警告，更讓整個 MVP 測試流程變得流暢無比。

4. 從數據分析到策略進化：洞察引擎

目前的 ResearchInsightsService 已經能產出具有溫度的建議。它不只是顯示數字，而是會告訴你：「risk.block_rule 命中率極低 (0%)，建議降權」。此外，我們修正了 BLOCK 的勝率定義，現在當系統成功攔截一檔「後來真的跌了」的股票時，系統會給予規則加分，這才是真正的量化洞察。

5. Redis 與 PostgreSQL 的雙劍合璧

我們將快取層由 In-Memory 全面切換為 Redis，這讓不同指令間能共享 API 回傳資料，大幅降低了 400 錯誤的發生率。環境設定已完全鎖定在 .env 檔案中，實現了一鍵啟動 (PostgreSQL/Redis 模式) 的懶人體驗。

Hashtags

[#fintech](#fintech) [#量化交易](#量化交易) [#台股研究](#台股研究) [#NodeJS](#NodeJS) [#Postgresql](#Postgresql) [#Redis](#Redis) [#資料科學](#資料科學) [#MVP測試](#MVP測試) [#技術筆記](#技術筆記) [#新手向](#新手向)