指標重繪（repainting）：訊號消失、訂單卻已經送出去

策略在 K 棒中途觸發了 alert，webhook（也就是把訊號自動 POST 到你伺服器的那條通道）送到你的執行端，訂單成交。等你晚一點回頭看那根 K 棒，剛剛觸發的訊號在圖表上根本沒出現——這就是 repainting（指標重繪）在自動下單裡最典型的樣子：條件在收盤前成立、收盤後又不成立，但單子已經送出去了。

沒有人先跟你講的是：這不是你的腳本壞了。這是 Pine Script（也就是 TradingView 圖表上寫策略的那個腳本語言）對 close、high 這些即時值的定義——只要 K 棒還沒收盤，它們就會隨每個 tick 變動。這種行為有個專有名詞叫 repainting，中文常翻成「指標重繪」，而它是自動下單最容易安靜壞掉的地方。

這篇不評論「哪些策略比較會 repaint」——那要看你自己的邏輯。這篇只做三件事：把 repainting 的機制講清楚、列出你能在 Pine 端擋掉的方法、以及說明為什麼你的 webhook 執行端不是這個問題的正確解藥層。

「觸發了、又消失了」到底是哪一步在騙你？

TradingView 官方對 repainting 的說法很直白，大意是：腳本在歷史 K 棒上的計算結果，跟即時 K 棒上的計算或繪圖結果不一致。這個描述涵蓋了兩件不同的事——一種是圖表上的線畫得跟收盤後不一樣（視覺上的重繪），一種是即時計算的中間值跟收盤後不同（會影響觸發判斷）。真正會讓自動下單出事的，是後者。

Pine 的執行模型是逐棒（bar-by-bar）：歷史 K 棒每根只算一次，用的是最終確定的 OHLC；即時 K 棒卻是每個 tick 都會重新算一遍，用的是那個 tick 當下的資料。同一段程式碼在歷史與即時兩個階段吃到的輸入不一樣，輸出當然可以不一樣。

條件式讀到的 close 在即時 K 棒上就是「這一 tick 的最新價」，不是「這根 K 棒的收盤價」。你的 if close > sma_line 可能在某個 tick 成立，alert 觸發、webhook 送出去；下一個 tick 價格回落，條件變回不成立。K 棒真的收盤時，close 已經是別的數字，圖表上你連當時觸發過的痕跡都看不見。

為什麼手動看盤幾乎無感、自動下單卻真的送了單

如果你只是坐在電腦前看 K 棒，這件事只會讓你偶爾覺得「線圖看起來怪怪的」——你不會拿它做決策，因為你的動作在你點下滑鼠那一刻才發生。中間有再多次條件成立、又不成立，都不會實際發生任何事。

自動下單完全相反。alert 觸發的當下就是動作發生的時間點，webhook 已經打到執行端、訂單已經送出去。就算 K 棒收盤時條件不再成立，那筆訂單也收不回來——你只能在事後看到帳戶多了一筆你回頭看根本看不出理由的成交。

這件事的殺傷力是「看似安靜、實際上有訂單被送出去」的組合。它不會噴錯、不會在對話框上跳警告，甚至你去看 alert 歷史都會看到訊息確實送過。它會安靜地壞掉。

三種常見的 repainting 來源，各有各的解法

三種來源可以同時出現在同一支腳本裡，也可以一個都沒有——沒辦法一句話說「你這支腳本會不會 repaint」。判斷方式是把腳本貼給 AI 或自己走一輪，把每個讀到 OHLCV 或 request.security() 的地方對照上表逐條過。

Pine 端能做的就這兩件事

不管你走的是哪種來源，能在腳本層面擋掉重繪的動作其實只有兩個。都不做不會編譯失敗，做了也不會有一句話跳出來告訴你「這樣就對了」——TradingView 官方在講這件事時也明說是有代價的取捨：等收盤確認能避免重繪，但也會讓訊號晚幾秒到一整根 K 棒才觸發，兩者不可兼得。

一：alert Frequency 改成 Once per bar close

建 alert 的視窗裡有一個 Frequency 下拉選單，官方 Help Center「Differences between alert frequencies」列了四個選項：Once only、Once per bar、Once per bar close、Once per minute or every time。跟自動下單策略最相關的是中間那兩個，差別如下：

這個下拉選單是你自己在瀏覽器裡點的，不需要動程式碼。沒選到 Once per bar close 的話，下面那件事白做——因為條件式再乾淨，Once per bar 仍然會在 tick 中途觸發。（另外兩個選項 Once only 一輩子只觸發一次、Once per minute or every time 只要條件成立就每分鐘送一次，兩者跟連續運作的自動下單策略都不合，不在這篇的討論範圍。）

二：條件式用 barstate.isconfirmed 包住

只改 Frequency 還不夠。你的策略可能有多個 alert condition，或用 alert() 函式而不是 alertcondition()——這時候要在 Pine 裡自己判定「這根 K 棒是不是真的收盤了」。判定的變數就是 barstate.isconfirmed：它在歷史 K 棒上永遠為 true，在即時 K 棒上只有最後一個 tick 才是 true。

//@version=6
        strategy("safe-cross", overlay=true)

        fast = ta.sma(close, 9)
        slow = ta.sma(close, 21)

        // ❌ 不安全的寫法：任何一個 tick 成立就進場
        // if ta.crossover(fast, slow)
        //     strategy.entry("L", strategy.long)

        // ✅ 安全的寫法：只在 K 棒收盤確認後判斷
        if ta.crossover(fast, slow) and barstate.isconfirmed
            strategy.entry("L", strategy.long)

不確定哪些地方要包，可以把腳本貼給 AI 並照順序問這四題：

這是一支 Pine Script v6 策略，我要拿它接 webhook 自動下單。
        先不要改寫，回答我：

        1. 這支腳本裡，有哪些條件可能「K 棒中途成立、收盤時又不成立」？逐行列出來。

        2. 有沒有用到 request.security() 讀更高週期資料？
           如果有，是不是同時用了 [1] 與 lookahead = barmerge.lookahead_on？
           （兩者互相依賴，只加其中一個對非重繪 HTF 讀取而言不夠）

        3. 有沒有其他地方用到 barmerge.lookahead_on？
           如果有，是不是也搭配 [1] 抵銷？

        4. 如果我把 alert 的 Frequency 設成 Once per bar close，
           這支腳本的哪些行為會改變、哪些不會？

        四題都回答完，再給我修正版。

        [把你的腳本貼在這裡]

先答再改的目的是看 AI 是不是真的搞懂，還是只是在重複你剛剛講過的話。第 1 題要求「逐行列出」，回答如果是「大致上沒有問題」這種模糊句子，就代表它沒讀進去——這時候讓它動手改，通常會把可能有問題的整段直接刪掉。

已經送出去了，webhook 端能不能救回來？

短答：不太行。長答：可以做兩層 mitigations，但兩層都補不回一個「條件本來就不該成立」的 alert。

第一層是最直覺的：webhook 端做 dedup，同一根 K 棒收到兩則就當一則。這在「同一個 alert 因為接收端回 5xx 觸發 TradingView 重送」的情境確實有用；但 repainting 送出的訊號 payload 可能不完全一樣——因為 strategy.equity、strategy.position_size 這些值也會隨 tick 變動，算出來的 qty 可能就差幾位。這件事我們自己踩過。

舉例來說，TVSBot 執行端有一個 60 秒視窗的 dedup，指紋是 user_id | strategy | symbol | action | qty 的 SHA-256 前 32 字元；同一個指紋 60 秒內第二次來會直接 skip 不下單。這對「TradingView 重試同一則」有用，對「同一根 K 棒但 qty 因 equity 浮動」就攔不住——後者兩則的 qty 不一樣，指紋不同，兩則都會執行。這是機制推論，不是官方承諾——別的執行端如果不把 qty 放進指紋，行為會不一樣。

第二層是事後的 replay／audit：把每一筆收到的 payload、當下的判斷、送出去的訂單完整存下來，讓你能倒回去看「這一筆到底是不是真的該送」。這一層對 repainting 一樣沒有預防效果——它讓你能重建現場，但不能幫你把訂單收回來。

所以「解 repainting」的正確層級一定是 Pine 端：Frequency ＋ barstate.isconfirmed。執行端能做的事是讓真的送錯的訊號至少可查、可重放——但那不是同一個問題。

上線前的五項自檢

• alert 的 Frequency 設成 Once per bar close（不是 Once per bar，也不是 Once only 或 Once per minute or every time）。這一步不需要動程式碼，最省事。
• 條件式裡任何讀到 close／high／low／open 的地方，都用 barstate.isconfirmed 包住。
• 用到 request.security() 讀更高週期時，同時在 expression 加 [1] 並帶 lookahead = barmerge.lookahead_on——兩者互相依賴，缺一都會破功。
• 整支腳本沒有其他 barmerge.lookahead_on——如果有，確認它搭配 [1] 抵銷未來偏移，不要拿它讓回測看起來漂亮。
• 你的執行端會保留每一筆收到的 payload 原文與處理紀錄，方便事後對照 TradingView 端的觸發時間——不是自動去重，是替自己留一份可查的證據。

五項都做完，還是可能出現「一根 K 棒送兩單」的情況。那通常不是 repainting，而是這根 K 棒真的產生了多筆訂單事件（進場單加上停損停利各自送一則），或是接收端回了 5xx 觸發 TradingView 自動重送。這幾種跟重繪的機制不同，處理方式也不同，見 Alert 沒有記憶那篇的除錯決策樹。

誠實的一段：60 秒 dedup 不是重繪的解藥

任何自動化交易架構都攔不下 100% 的重繪假訂單——包括我們自己。TVSBot 的 60 秒 dedup 是替「TradingView 5xx 重送」設計的，不是替 repainting 設計的；我們沒有辦法在收到訊號的當下判斷「這個 close 值撐不撐得到收盤」——那件事只有 Pine 執行環境自己知道，webhook 打過來時 K 棒的最終 OHLC 還沒定案。設計能降低重複下單的機率、縮小影響範圍，但攔不掉本來就不該送的那一則。

任何人拿自家的 webhook 中介層講出相反的話，那句話背後大概是沒有東西可以佐證的——它需要事先預知未來的收盤價，這件事沒有人做得到。

常見問題