策略回測到實單交易：量化系統上線前的風控檢查清單

回測報表上的年化報酬率、夏普值再漂亮，都只是「策略在歷史資料上表現得很好」，不是「策略在真實市場上能安全運作」。兩者中間隔著一長串工程與風控細節，任何一項沒做，實單上線就是拿真錢在測試系統穩不穩。

我們看過不少團隊的策略邏輯本身沒問題，回測數字也扎實，卻在上線後踩到跟策略優劣無關的坑——多半出在「回測環境」跟「真實交易環境」之間的落差沒被填平。這種落差平常不會顯現，只有在市場出現異常波動、或系統連續運行數週之後才會浮現，而那往往已經造成實質虧損。上線前，建議至少過一遍以下六個檢查項目。

01滑價與手續費是否計入回測？

很多初版回測只計算理想成交價，沒有考慮委託與成交之間的價格滑動、以及交易所與券商的手續費、稅費。高頻或薄利策略對這些成本特別敏感，一旦計入真實成本，原本亮眼的績效曲線可能大幅縮水，甚至由正轉負。建議至少用保守估計（例如高於歷史平均的滑價幅度）重跑一次回測，確認策略在扣除所有摩擦成本後仍然具有正期望值，而不是只看毛利潤。

02極端行情下有沒有斷路機制？

回測資料通常是「正常」的市場區間，但真實市場會出現閃崩、流動性枯竭、單日巨幅波動。系統需要有明確的最大虧損、最大部位、最大單日交易次數等停損式斷路機制，在超出預期的行情下自動停止下單，而不是靠人盯著螢幕手動介入。斷路機制觸發後應該預設進入「安全模式」（例如只允許平倉、不允許加碼），並且主動通知負責人，而不是靜默停止讓人以為系統還在正常運作。

03API 斷線或延遲時，系統怎麼反應？

網路中斷、交易所 API 逾時、行情資料延遲，這些狀況在實盤交易中遲早會發生。上線前要明確定義：連線中斷時未平倉部位如何處理、重新連線後是否會重複下單、資料延遲時策略是暫停還是繼續運作。沒有定義這些行為，等於把應變方式交給運氣。實務上建議搭配券商端的保護性停損單作為第二道防線，即使系統本身斷線，部位風險仍有基本的保護。

04部位上限與資金控管是否寫進系統？

單一標的曝險上限、總資金曝險上限、單日虧損上限，這些規則如果只存在風控文件裡、靠人工執行，遇到系統當機或連續下單異常時就會失守。這些限制應該是程式碼層級的硬性檢查——每一筆下單前都先檢查是否超過上限，超過就直接拒絕下單，而不是事後補救的規範。這一層檢查獨立於策略邏輯之外，即使策略本身出現異常訊號，也不會讓虧損無限擴大。

05有沒有即時監控與告警？

策略上線後不代表可以放著不管。部位異常、連續虧損超過門檻、系統延遲升高，這些狀況需要即時告警（簡訊、通知、儀表板），讓人在問題擴大前介入，而不是等到月底結算才發現異常已經持續了兩週。建議至少建立三層告警：系統健康度（是否正常連線與下單）、部位與虧損狀態、策略績效是否偏離回測預期，三者分開監控，才能快速定位問題出在哪一層。

06是否經過一段小額真倉測試期？

回測與模擬交易永遠無法完全複製真實市場的滑價、成交延遲與心理壓力。上線前用小額資金跑一段真倉測試，觀察實際成交與預期的落差，往往能在虧大錢之前發現回測階段沒看到的問題，例如委託單被部分成交、下單延遲導致的價格偏移，或是策略在特定時段流動性不足時的表現異常。這段測試期的長度，建議以涵蓋至少一個完整的市場週期為原則，而不是固定跑幾天就結束。

量化系統的風險，很少是策略邏輯本身的問題，更多來自這些「策略之外」的工程細節。把這份清單走過一遍，通常比再優化一次策略參數，更能決定這套系統能不能撐過第一次真正的極端行情。

常見問題