EA日誌設計｜讓事故事後可以重現

結論：沒有日誌的EA，出了事故也無法驗證

先說結論。EA的日誌至少應該各輸出一行「判斷所用的數值」「沒有進場的原因」「成交的結果」這3種記錄。有了這3項，事後就能重現非預期的交易，以及「什麼都沒發生」的狀況。反過來說，沒有這些記錄，無論是出現虧損，還是交易數一直是0筆，都無法分辨原因是EA的邏輯、行情，還是券商端。

我們自己開發EA時，既有被日誌救了一命的時候，也有因為日誌不足、最後不明原因收場的時候。本文從使用者的角度，整理什麼才是「好的日誌」。

為什麼需要3種日誌

EA的一次判斷，大致是「計算數值 → 判定條件 → 下單 → 成交」的流程。要在事後找出是哪個階段與預期不同，就需要每個階段的記錄。

判斷值：不留下數字，就無法與「碰巧」區分

只輸出「出現買入訊號」的日誌，幫助很有限。因為不知道當時指標數值與閾值差了多少，就無法判斷是勉強達到條件，還是明確達到條件。此外，用哪一根K線(已確定K線的時間)做判斷，也一定要記錄下來。

跳過原因：最容易被省略，卻最重要的日誌

多數EA只在「進場」時才輸出日誌。但運用期間最常見的詢問是「完全不進場」。如果日誌裡有放棄的原因，就能確認那是符合規格的正常放棄，還是設定錯誤或伺服器時間偏差所造成的。

我們的MEGAMAX DONCHIAN在Exness模擬帳戶的前向測試中，截至2026年11月11日交易為0筆。放棄進場的原因我們目前也還無法確認，在此不做臆測。不過遇到這種情況時，有沒有跳過原因的日誌，確認所需的功夫會大不相同。交易0筆並不代表績效差，但在讀過日誌之前，也無法斷定這就是「正常的放棄」。

成交：記錄發生在EA之外的事

訂單是被拒絕，還是成交了但滑價很大，這與EA的邏輯是不同層面的問題。只要留下回傳碼與成交價格，就能把EA的問題與券商、網路線路的問題分開思考。

一行該輸出什麼：寫法範例

我們把一次判斷濃縮成一行，並採用事後容易搜尋的固定格式。

[EVAL] bar=2026.11.10 14:00 sig=BUY val=1.234 th=1.200 spread=18 -> ENTRY
[SKIP] bar=2026.11.10 15:00 reason=SPREAD spread=45 max=30
[FILL] ticket=123456 req=152.340 fill=152.346 slip=6 ret=10009

撰寫時的重點如下：

• 開頭加上種類標籤(EVAL / SKIP / FILL)，方便用grep或搜尋抓出來
• K線時間寫「判斷所用的已確定K線」的時間(前提是伺服器時間)
• 原因不寫成句子，而是用固定代碼(SPREAD、TIME、POSITION 等)
• 不要每個tick都輸出，只在做出判斷的瞬間輸出

如果每個tick都輸出，日誌會在短時間內變得龐大，不但佔用磁碟，關鍵的那一行也會被淹沒。基本原則是「K線確定時輸出一次」。

使用者端的檢查步驟

使用EA的人，依照以下順序檢查，可以更快找到原因。

1. 在MT5的「專家」分頁，確認EA是否有輸出自己的日誌
2. 找出非預期交易發生時間點的EVAL行，查看判斷值與閾值
3. 沒有進場的期間，查看SKIP行，統計哪種原因最多
4. 在FILL行確認要求價格與成交價格的差距，以及回傳碼
5. 將「操作歷史」分頁(券商端的記錄)與時間對照

設定的檢視請參考EA設定方法，建置24小時穩定運作的環境則可參考VPS資訊。

限制與注意事項

日誌並非萬能。我們老實說明如下。

• 沒寫進日誌的事就無從得知。 開發者沒有預想到的狀況，本來就不會被記錄。
• 日誌不一定正確。 如果輸出日誌的程式碼本身有bug，就會記錄下錯誤的數值。
• 看不出行情判斷的好壞。 日誌能告訴你的是「是否照規格運作」，而不是依該規格能否獲利。
• 輸出過多也會釀成問題。 大量日誌會佔用容量，閱讀的人也更容易漏看。
• 回測與模擬帳戶、真實帳戶的日誌意義不同。 測試器無法像實際環境那樣重現滑價與拒單，因此比較成交日誌時，請以環境不同為前提。

總結

• 日誌各輸出一行「判斷值」「跳過原因」「成交」這3種
• 最容易被省略的是放棄進場原因的日誌，在調查「不動作」的原因時最有用
• 事先決定好標籤與原因代碼，事後就能搜尋並統計
• 輸出以每根已確定K線一次為準，不要每個tick都輸出
• 日誌只能告訴你「是否照規格運作」，能否獲利需要另外的驗證

其他MT5運用的實用知識，整理在EA・MT5知識庫。