【血祭 0206】你的量化模型正在重演 8 年前的悲劇？當年這群程式交易老手一夕賠光身家，只因忘了歷史上最昂貴的一堂課

2018 年 0206 選擇權大屠殺是台灣量化交易史上最慘痛的一頁。本文將透過技術視角拆解當年的流動性枯竭機制，並介紹如何利用現代開源框架（Backtrader, Lean）進行極端壓力測試，避免你的演算法在下一次黑天鵝中歸零。

2018 年 2 月 6 日：被遺忘的演算法喪鐘

對於許多台灣的老一輩交易員來說，2018 年 2 月 6 日（0206 選擇權大屠殺）是一個不願回首的日子。當天台指期（TX）開盤受美股重挫影響下跌，這本是正常的市場波動。然而，災難發生在選擇權市場（TXO）。

在短短幾分鐘內，流動性瞬間枯竭。不管是買權（Call）還是賣權（Put），許多深價外（Deep OTM）的合約價格被市價單（Market Order）瞬間掃到漲停板。你沒看錯，指數大跌，但買權卻漲停。這導致了毀滅性的骨牌效應：期貨商的風控系統偵測到帳戶權益數（Equity）暴跌（因為選擇權市值被錯誤地以漲停價計算），隨即觸發無差別的強制平倉（Forced Liquidation）。

這場屠殺的受害者，很多不是散戶，而是自以為避險完美的「選擇權賣方策略」老手。他們的模型假設市場永遠有流動性，假設 Bid-Ask Spread（買賣價差）會維持在幾點之內。

技術盲點：你的 Backtest 騙了你

大多數入門的量化交易者，在使用 Python 寫回測時，最容易犯的錯誤就是 Look-ahead Bias（預知未來偏誤）和 Liquidity Neglect（忽略流動性）。

如果你用簡單的 Close 價格進行回測：

# 錯誤的邏輯：假設你可以用收盤價成交
if signal == 1:
buy(price=data.close[0])

在 0206 這種極端行情中，Close 價格可能已經是漲停價，但中間的流動性是斷層的。你的模型會顯示「止損出場」，但在真實市場中，你根本成交不了，或者會成交在滑價（Slippage）極大的位置。

現代防禦術：用開源工具構建護城河

為了避免重蹈覆徹，我們必須在演算法中加入「流動性濾網」與「壓力測試」。

1. 選擇正確的框架

不要自己從頭刻回測引擎，除非你是造輪子的專家。推薦使用成熟的開源框架：

Backtrader (Python): 雖然更新較慢，但其架構對於自定義 Slippage 和 Order 執行邏輯非常靈活。你可以撰寫客製化的 Sizer 和 Broker 來模擬流動性枯竭。
LEAN (C#/Python, by QuantConnect): 這是目前地表最強的開源引擎之一。它內建了精細的 Tick-level 數據處理能力，並且有真實的 Spread 模型。
NautilusTrader (Python/Rust): 追求極致效能的新星，適合高頻與造市策略，特別強調事件驅動（Event-Driven）的正確性。

2. 實戰防禦邏輯（虛擬代碼）

在你的策略中，必須加入以下防禦層：

A. 動態滑價模型 (Dynamic Slippage Model) 不要設定固定的滑價（例如 1 點）。滑價應該是波動率（Volatility）與買賣價差（Spread）的函數。

# 概念邏輯
def get_slippage(volatility, spread):
if volatility > HIGH_VOL_THRESHOLD:
return spread * 5  # 在恐慌時假設滑價擴大 5 倍
return spread

B. 流動性斷路器 (Liquidity Circuit Breaker) 在下單前，檢查 Order Book 的深度（Depth）。如果最佳買賣價差過大，或者掛單量（Size）太少，拒絕交易或大幅縮小部位。

# 概念邏輯
current_spread = ask_price - bid_price
if current_spread > MAX_ALLOWED_SPREAD:
logger.warning("Spread too wide, cancelling entry.")
return  # 不進場

C. 極端情境壓力測試 (Stress Testing) 不要只跑 2020-2024 年的多頭數據。請刻意將 2018/02/06、2020/03/19（疫情熔斷）的數據納入回測，甚至手動製造「假數據」，將波動率放大 3 倍，看你的帳戶會不會爆倉（Margin Call）。