Weekly Trading Review 2026 W13

過完寒假，進入三月，就像去年過完暑假的九月，是充滿張力的一個月。

這個月最大的轉折，是一開始先評估 XQ 做回測，但試了一個禮拜後果斷放棄，改用 Claude Code + backtesting.py 開啟了另一片天。完成的項目數量是以前很難想像的，所以想在月底前提早做一次回顧。

為什麼要建這套系統？

在這之前，我的回測方式是人工一筆一筆看圖——這樣做有一個根本性的問題：後見之明很容易滲入。看著 K 線圖，你會不自覺地「知道」後面發生了什麼，判斷就會被污染。你以為自己在驗證策略，其實只是在確認自己想相信的事。

建構這套系統的核心目標，就是把現有的策略邏輯完整地寫成程式，讓電腦跑歷史資料，徹底排除人工判讀的主觀性。一旦系統建起來，之後要測試新的想法，成本就變得很低——寫一個假設，跑一次回測，結果馬上出來，不再需要坐在那裡一根一根看 K 棒。

📊 這個月，數字說話

26 天，從零到 3 個可實盤的策略。這個月的密度，是過去幾個月加起來都比不上的。

🛠 八個開發階段，一路演進

Phase 1：ETL 資料管線（Day 1）

從期交所下載 tick 級原始資料，建立完整的 ETL pipeline，從原始資料一路處理到可回測的連續合約格式。用 DuckDB 儲存多年歷史資料，設計成冪等性——每個步驟都可以獨立重跑。

一天內完成，從零到可用資料。

Phase 2：第一個策略 — 開盤突破（Day 1–3）

以開盤區間突破為核心邏輯，搭配 Backtesting.py 框架做回測，加入趨勢濾網與進場時間限制，產出第一份策略績效報告。

Phase 3：策略迭代與優化（Day 3–10）

密集開發期，某一天光是 commits 就有 28 個。加入各種濾網條件、分析週內效應，並建立 TradingView 指標供實盤觀察。

Phase 4：預估振幅體系成形（Day 8–14）

Phase 5：均值回歸策略（Day 14–20）

Phase 6：選擇權策略（Day 16–20）

Phase 7：假設驅動研究體系（Day 20–26）

這個階段是流程上的質變——從隨機實驗，轉型為系統化研究。

建立了「提出假設 → 探索分佈 → 回測驗證 → 歸檔結論」的標準工作流，設計兩階段的驗證框架：先做分佈探索，通過門檻才進入回測。靈感來自 scientific method，目的是避免 overfitting 和 data snooping。後期的假設全部走這套標準化的流程。

Phase 8：策略精煉與實盤對齊（Day 22–26）

針對實盤與回測的落差進行修正，把觀察到的系統性偏差一一找出來修掉，也把一個在回測中效果不錯的反轉概念，精煉成第三個上線策略。

🔑 幾個技術上的關鍵決策

1. DuckDB as single source of truth — tick 級資料到連續合約，全在 SQL 內完成，簡單、快、可重現。
2. 假設驅動研究流程 — 在看數據之前先提出假設，這是避免 data snooping 最實際的做法。
3. Python 回測 ↔ TradingView 指標雙軌 — 回測驗證邏輯，TradingView 做實盤視覺化，兩者同步開發。

💡 這個月學到最重要的三件事

第一，排除後見之明，才能真正知道策略值不值得信任。 以前人工回測一筆一筆看，其實是在自我感覺良好。現在換成程式跑，數字沒有情緒，結果是什麼就是什麼。有些本來覺得「感覺不錯」的想法，跑完之後直接被淘汰——這才是真正的驗證。

第二，系統建起來之後，測試新想法的成本變得極低。 這是這個月最大的複利效應。基礎設施花了時間打好，之後每個新假設從提出到有回測結果，可能只需要幾個小時。接下來幾個月能做的事，會比這個月更多。

第三，工具要先驗證，才能作為決策依據。 週五的虧損來自一個程式 bug，行為本身是對的，但工具出了問題。這讓我意識到：「遵守紀律」是好的，但遵守一個還沒驗證完的工具，並不等於紀律——那只是把責任外包給程式。新工具上線前，必須先在覆盤模式下跑夠多的案例，確認沒問題再用。

三月總結

三月的月結用一句話說：過程建立的月份，不是績效的月份。

月初幾天拿了一波大獲利，後兩週陸續還了一部分回去。這也讓我認清了一件事實：策略在某些市場環境是武器，在另一些環境是消耗。這正是回測系統存在的意義——繼續累積資料，搞清楚策略在什麼條件下有優勢，什麼條件下該休息。

基礎設施已經建好了。接下來，就是繼續用。