AI 交易機器人：從 Pine Script 到自動下單
你把想法講給 AI 聽，它丟回一段 Pine Script（一種專為交易圖表設計的腳本語言），貼進圖表一次就編譯過。這件事現在真的不難。 沒有人先跟你講的是：「程式碼能編譯過」跟「程式碼能自動下單」是兩道完全不同的關卡，Pine Script 有一長串規則在決定你落在哪一邊。 這篇文章不評論你用的是哪個 AI 工具好不好——我們沒做過這種測試，這篇也不會做。
這篇文章不是要教你寫 Pine（一種專為交易圖表設計的腳本語言），而是給你三件事：
- 哪個 alert 有資格送 webhook
- 為什麼你設的條件會重複觸發
- 怎麼設計才會安靜地壞掉
第 0 層——這個 alert 本身有沒有資格送 webhook？
這層過濾最簡單，但最常被忽略。你必須確認自己的 TradingView 方案支援 webhook，否則後面所有設計都是白搭。
| 方案 | Webhook | Active price alerts | Technical alerts |
|---|---|---|---|
| Free（免費） | 沒有 | 3 則 | 未列出 |
| Essential | 有 | 20 則 | 20 則 |
| Plus | 有 | 100 則 | 100 則 |
| Premium | 有 | 400 則 | 400 則 |
| Ultimate | 有 | 1,000 則 | 1,000 則 |
來源：TradingView 官方定價頁（查證日期 2026 年 10 月）
Free 方案沒有 webhook，這是明確寫出來的限制。如果你看到「免費就能跑自動交易」的教學，第一步就錯了。
webhook 是用來從圖表推送到你自架伺服器的一串 URL，讓你能接到當條件滿足時的訊號。也就是當圖表上的條件被滿足時，系統會把這個訊號傳送到你設定的網址。簡單說，就是圖表訊號的「通知管道」。
第 1 層——snapshot 機制讓你的 alert 沒有記憶
你設的 alert 會在每一根 K 棒上重新評估。這聽起來是好事——每根 K 棒都檢查一遍，確保條件滿足時就觸發。但問題是：這個 alert 本身沒有記憶。
這不是 bug，這是設計。但很多 AI 生成的策略沒有意識到這一點，寫出「上週金叉、這週死叉」之類依賴跨 bar 記憶的邏輯，結果每根 K 棒都在重頭開始。
如果你需要跨 K 棒保留狀態，必須用 var 關鍵字：
var 讓變數跨 bar 保留值
var int signalCount = 0 if crossover(sma(close, 14), sma(close, 28)) signalCount := signalCount + 1 alert("Golden cross #" + tostring(signalCount), alert.freq_once_per_bar)沒有 var 的話，signalCount 每根 K 棒都會從 0 開始算，永遠都是 1。
還有一個進階關鍵字 varip（variable intrabar persist），它不僅跨 bar 保留值，還會在「同一根 K 棒內」的多次價格更新中持續保留。這在即時交易場景很有用——但回測時不會重現這種行為，因為歷史資料沒有 tick 級的更新。
第 2 層——你拿到的是 indicator，還是 strategy？
很多「AI 交易機器人」給你的，就是單純的 indicator。indicator 只有兩種狀態：above/below、crossed up/down。它不會告訴你：「我剛剛才觸發過，別再通知我一次了。」
Pine Script 有兩種發送 alert 的方式：
| 函數 | 觸發頻率預設值 | 適合場景 |
|---|---|---|
| alert() | freq_once_per_bar | 需要動態訊息的自動化交易 |
| alertcondition() | 由使用者在 Alert 對話框選擇 | 簡單條件通知 |
| alert() + freq_once_per_bar_close | 每根 bar 收盤一次 | 避免未確認訊號重複觸發 |
來源：Pine Script Language Reference v6（查證日期 2026 年 10 月）
alert() 的預設頻率是 freq_once_per_bar——也就是說，同一根 K 棒內只要 alert() 被呼叫一次就會觸發。如果你把 alert() 放在 if 條件裡，而且這個條件在一個 bar 內可能被評估多次（例如用 calc_on_every_tick=true 的策略），它就可能觸發好幾次。
要更嚴格的防重複，可以用 freq_once_per_bar_close，讓 alert 只在 K 棒收盤時才發送一次。這能避免「未確認訊號」的問題——也就是在 K 棒還沒結束時，價格可能會來回晃動導致條件反覆滿足。
第 3 層——equity 的模擬陷阱
TradingView 會用 strategy.equity 來計算 webhook 送出的數量。strategy.equity 是 Pine 策略完全在 TradingView 伺服器上模擬出來的數字，等於 initial_capital + netprofit + openprofit。
數字情境：假設你的回測用 10 萬美元 initial_capital 跑，default_qty_type 設成 strategy.percent_of_equity、數值 10（即 10%）。你實際的交易所帳戶裡只有 2,000 美元。
當 alert 觸發、webhook 打到你的執行伺服器，實際會送出多少數量？
答案是：TradingView 會用「這根 K 棒當下的 strategy.equity」的 10% 去算這筆單的數量——而 strategy.equity = strategy.initial_capital + strategy.netprofit + strategy.openprofit，所有數值由 TradingView 伺服器計算與儲存。如果你的回測表現好，equity 變大，webhook 送出的訂單數量也會跟著變大——即使你的真實帳戶根本沒有那麼多錢。
第 4 層——webhook 延遲與丟失
TradingView 從未針對自己故障期間漏掉的 alert 公布任何 SLA。我們也沒有替 TVSBot 公布正常運行時間保證，因為我們自己也沒有可以拿出來的公開 SLA。
這意味著如果你的執行伺服器（TVSBot、自己的後端、或是任何 intermediary）在 3 秒內沒有回覆 HTTP 200，TradingView 就會放棄這次發送。它不會重試。
此外，TradingView 有頻率限制：如果三分鐘內觸發超過 15 次 alert，系統會自動暫停發送。這在回測時不會碰到（因為歷史 bar 的處理是批量的），但在即時交易時可能成為瓶頸。
設計能降低漏單的機率、縮小影響範圍，但沒辦法把可能性歸零。
第 5 層——交易所的斷線自動撤單，不是人人有份
交易所掛了，我的部位會自動被關掉嗎？沒有任何一份官方文件直接寫明會或不會。但我們查過 Binance、OKX、Bybit、Bitget 的斷線自動撤單機制，範圍都嚴格限定在撤銷掛單——沒有一份提到部位。
重點是：這些功能**都不是預設開啟的**。每一家都需要手動設定，而且有的還有客戶等級限制。
| 交易所 | 斷線撤單功能 | 預設開啟 | 備註 |
|---|---|---|---|
| Binance | 有（Kill-Switch） | 否 | 僅限期權/期貨做市商 |
| OKX | 有 | 否 | API 協議明確寫訂單仍有效 |
| Bybit | 有（DCP） | 否 | 僅限機構客戶（Ins） |
| Bitget | 有（Deadman Switch） | 否 | 需手動配置心跳 |
來源：各交易所官方文件比對（查證日期 2026 年 10 月）
唯一可以確定的是：四家交易所都不會在你斷線時自動平倉。如果你的部位已經成交，價格繼續往不利方向走，你可能會面臨超出預期的虧損。
- 3 秒：TradingView webhook 超時上限
- Free：無 webhook 權限的方案
- 10%：default_qty_type 預設比例
- 15 則／3 分鐘：alert 頻率上限
常見問題
AI 生成的 Pine Script 能直接自動下單嗎？
為什麼同一個條件會重複觸發？
TradingView webhook 延遲到底有多嚴重？
為什麼 indicator 的歷史訊號會變？
本文不構成任何投資建議。所有提及的數字均來自官方文件、公開訪談、鏈上資料 — 引用來源在文末 RelatedPosts 之後可索取。加密交易風險高，請評估自身風險承受能力。