在台灣許多使用 MultiCharts、Python 或券商 API 進行程式交易的開發者，日常研究往往處於高度混亂的狀態：桌面散落著各種暫存文字檔，回測報表隨手存成一張張好看的截圖，程式碼被覆寫得面目全非。
看到績效曲線平滑向上便迫不及待想要上線實盤；一旦實際上陣遭遇連續虧損，回頭想找出問題，卻早已忘記當初到底套用了哪一段歷史資料、手續費與滑價是否設定過於理想、又或者究竟測試了幾百種參數組合才拼湊出這條看似完美的權益曲線。
沒有客觀的研發留痕，交易回測就只是單純的數字遊戲與嚴重的『過度最佳化（Curve-fitting）』。本文為你梳理一套輕量、模組化且立即可套用的 8 步驟交易研究日誌範本，助你建立嚴謹扎實的研發體系。
一份具備可稽核性（Auditable）的交易研究日誌（Trading Research Notebook），必須在撰寫程式碼之前與完成測試之後，忠實留下完整的思考軌跡。它涵蓋 8 項核心欄位：(1) 具體研究問題、(2) 經濟學直覺假說、(3) 資料集來源與版本、(4) 摩擦成本與成交假設、(5) 測試參數與總試驗次數、(6) 樣本內與樣本外對照結果、(7) 策略已知失效極限、(8) 下一步待檢驗方向。這套工作流程能有效阻絕後視鏡偏差帶來的過擬合陷阱。
| 模組名稱 | 欄位填寫目的 | 實務填寫範例 |
|---|---|---|
| 1. 核心研究問題 | 本次回測具體想驗證哪一個明確的市場規律？ | 『台指期日 K 線突破 20 日高點後，後續波段是否具備統計上的順勢超額報酬？』 |
| 2. 經濟學假說 | 為何這項超額報酬在真實交易市場中能夠持續存在？ | 『大型法人機構建立避險部位需要數日演算法分批吃單，造成趨勢初期存在價格反應不足。』 |
| 3. 資料集與區間 | 詳實標註測試所用的資料源代碼、日期與清洗規格 | 『2015-2024 年台指近月連續月日 K 線，券商歷史 API 2026-09-01 匯出版本，剔除除權息點數異常。』 |
| 4. 交易摩擦假設 | 實務執行時納入了哪些真實成本？ | 『單邊期貨手續費 50 元、期交稅十萬分之二、每口強制設定 1 點進出滑價摩擦。』 |
| 5. 測試參數與分母 | 如實記載測試過的參數範圍與被淘汰的組合總數 | 『突破均線採 20 日；此前嘗試 5 日、10 日、60 日共 3 組因回撤過大遭到淘汰。』 |
| 6. 樣本內外驗證 | 策略在完全未參與最佳化的全新時段表現如何？ | 『樣本內夏普值 1.38 (2015-2020)；樣本外夏普值 1.08 (2021-2024)，最大連續虧損 18 萬元。』 |
| 7. 策略已知侷限 | 這個交易模型在何種極端行情下必定會慘遭滑鐵盧？ | 『在無量長達數月的狹幅區間盤整中容易遭遇多空反覆停損；未考量國際地緣政治跳空風險。』 |
| 8. 下一階段實驗 | 下一步具體要做什麼證偽試驗以改善盲點？ | 『加入真實波動幅度（ATR）作為濾網，測試是否能在波動度收縮時主動降低開倉頻率。』 |
- 動手寫程式前先擬定假說：若看著已經跑出來的漂亮走勢圖才來替指標找藉口，那只是純粹的圖表看圖說故事與過度擬合。假說必須先於數據產生。
- 誠實記錄試錯分母總數：不加校正地測試數十甚至上百種參數組合，會極大地拉高數據窺探與過度擬合風險。完整記錄被推翻的測試次數，才能誠實檢驗最終結果的統計顯著性。
- 嚴格鎖定歷史資料版本：切勿在經常被動態覆寫的活體資料庫上進行多次回測，必須固定測試當日的靜態歷史資料快照。
- 維持輕量化與實用性：日誌必須能在 5 至 10 分鐘內記錄完畢。若把記錄流程搞得像寫學術論文，長期下來勢必無法持之以恆。
常見問題
主觀波段交易者沒有寫程式，也能使用這份範本嗎？
非常適合。主觀交易者在手動覆盤均線或型態時，往往更容易受到確認偏誤影響。用這套範本預先定義買賣規則與歷史樣本，能徹底排除只挑獲利案例看的盲點。
如何防止自己刻意隱瞞失敗的回測試驗？
在心理建設上，失敗的回測與成功的策略同等珍貴。將失敗的參數與原因如實列為『負面資料庫』，能有效防止自己在半年後忘記教訓並重複踩雷。
研究日誌推薦使用什麼軟體管理？
建議使用純文字 Markdown 格式，與交易程式碼一併納入 Git 版本控制；若偏好圖形介面，Obsidian 或 Notion 也是維持個人研究日誌的絕佳工具。
