Claude Code 用 TradingView MCP 接上圖表之後，離自動交易還差哪一段

你已經看過那批錄影：Claude Code 打開了 TradingView 圖表、把 Pine Script 貼進去一次編譯過、 順手替你新增一個 alert，全程你只打了一段話。事情看起來就差最後一步—— 把觸發後的訂單真的送出去。沒有人先跟你講的是：那最後一步不是 MCP 的下一個 tool 沒寫，是 TradingView MCP 這一整層設計上就沒有這個位子。

這篇不評論你用的是哪個 MCP server——目前 GitHub 上至少三個叫得出名字的 tradingview-mcp， 我們沒做過對照測試，這篇也不會做。也不談哪個 AI 模型比較會寫 Pine。 這篇只做一件事：把「Claude Code 透過 MCP 能碰到 TradingView 的哪些東西」跟 「離全自動下單真正還差的那幾段」切開，並且指出這個切口是 MCP 這層協定自己畫的。

TradingView MCP 現在能替 Claude Code 做的三大類事

先分類。目前檯面上三個活躍度較高的 tradingview-mcp 專案定位其實完全不同， 混在一起講會誤判 MCP 這一層的能耐。這張表是給你比對用的，不用背—— 重點是三個 repo 走的是三條不同路線。

三個 repo 各自的 README 全部都把下單這件事挑明講不做。 tradesdontlie 有一節叫 「What This Tool Does Not Do」， 逐字列了 「Execute real trades (chart interaction only)」。 atilaahmettaner 的 README 寫 「It does not execute trades, manage money, or guarantee any result.」 lev-corrupted 沒有下單類型的工具，README 也沒對外承諾這件事。

落差一：MCP 這層設計本來就沒有「下單」這個位子

讓 Claude 直接下單這件事被卡住不是因為 tool 還沒寫，是 MCP 這一層的位子放不下它。 Model Context Protocol 官方規格對 tool 這個概念寫的原文是：

一句話：MCP 讓「模型」直接叫工具。但同一頁 spec 還有另一段：

這兩句組起來是決定性的：任何會產生現實後果的 tool——下單、轉帳、把錢動出去—— 按 MCP 官方的建議都應該經過人工確認。tradesdontlie 選擇不提供下單這個 tool， 是符合那句 SHOULD 的最保守解讀：既然不能保證每次呼叫都會經過人工同意，那就不做。

這件事對你怎麼用 Claude Code 的影響是：如果你想全自動下單， 你要放的不是「一個下單 MCP」，是一段跟 MCP 平行、獨立的執行端—— 那段程式碼的觸發訊號來自 TradingView alert，不來自 Claude 的下一輪 tool call。 這是這篇後面每一節都會回到的骨架。

落差二：能寫 Pine Script，但不管執行端怎麼吃

說 Claude Code 現在能寫 Pine Script 這件事沒有錯——tradesdontlie 的pine_smart_compile 工具鏈（pine_set_source →pine_smart_compile → pine_get_errors →pine_get_console → pine_save）就是為了這個。 lev-corrupted 那組甚至內建 v3 → v6 版本轉換與 sandbox。

但在 TradingView 內編譯過跟上線之後執行端會拿到什麼是兩件事。Alert 觸發時 TradingView 送出的 payload 內容、部位大小、qty_type， 都是你在 Pine 裡的宣告與 alert 訊息模板決定的——MCP 幫你寫的 Pine 或幫你改的 alert message， 如果沒有把執行端要的欄位補齊，執行端會 500 或安靜地壞掉。

這條之前站上已經有文章拆得比這裡細。AI 生的 Pine 從編譯到下單有幾道獨立的關卡，這篇按順序講；部位大小是 TradingView 端算的、不是你交易所帳戶算的，這個坑在這篇裡整篇拆；Alert 沒有跨執行的記憶造成的重複下單，在這篇。上面三條落差，MCP 都不會替你處理。

所以你該做什麼？讓 Claude Code 寫 Pine 的時候，把執行端要收的 JSON schema 也貼進 prompt，逼它把 alert message 直接寫死成合法 JSON——這件事任何 MCP 都不會替你做， MCP 只負責讓它更快看到程式碼在 TradingView 裡編譯成不成。

落差三：能建 alert，但那個 alert 之後怎麼被吃是另一層

tradesdontlie 有 alert_create、alert_list、alert_delete 三個 tool——Claude 可以看到現有 alert 清單、可以新增、可以刪除。 這對「多個策略同時養、一次調整」是實用的能力。但 alert 建起來之後： webhook URL 打不打得到、payload 過不過交易所 API 的驗證、那筆訊號重不重複、 交易所斷線時有沒有備援管道——這幾件事全部在 alert 被觸發之後才發生。

MCP 這一層看不到這些後續。除非你把觸發回饋接回 Claude 當一輪新 context， 但那已經是你自己的 orchestration，不是 MCP 給的能力。 站上另一篇的五層除錯流程圖完整走過這些關卡；MCP 幫你把 alert 建起來只是走進第 0 層而已。

落差四：跨系統的狀態一致性沒有人負責

舉一個具體場景：你叫 Claude 用 tradesdontlie 那個 MCP 把某支策略的 alert 全部關掉。 它照做了、chart 上看不到 alert 了。同一時間你的執行端從別的來源 （例如另一個帳戶的 API）還收不收得到訊號？——沒有人保證這兩邊一致。 tradesdontlie 只碰你這台電腦上的 TradingView Desktop UI， 不碰你帳號的伺服器端 alert 佇列，也不知道你有沒有把同一組訊號分發到別的地方。

這是為什麼「Claude Code 幫你自動化整個交易」目前只能停留在單機、單帳號、 有人在旁邊看的場景——不是能力沒到，是跨系統一致性這件事 MCP 不承擔。要它承擔，就要走一個中間的協調層（自家後台、broker 端邏輯、 或跟另一個 MCP server 打招呼），那已經不是「接一下 MCP」這種下午的事。

那 MCP 到底解了什麼

這是我看下來覺得比較被誤解的地方。MCP 沒有解「自動下單」——它從來也沒有要解。 它解的是「你把想法交給 AI 之後，AI 要在 TradingView 這個特定的視窗與資料脈絡裡動手的那些步驟」。

這三件事以前都要你自己開 TradingView、剪貼、切分頁、記筆記。 MCP 讓 AI 直接在你打開的視窗上做這幾件事。這已經是很實在的節省。 但這都是輔助生產，不是代你上線。

要走到全自動下單，MCP 之外你還要放什麼

按上面的分工，MCP 這一層把「AI 動 chart」這件事收好之後，剩下的責任其實不太多， 但每一條都是不能省的。這張清單不是給你抄的，是每一條缺哪一條你都能自己補回去。

• 一個獨立的 webhook 接收端（自己寫或用託管服務），觸發訊號來自 TradingView alert，不透過 Claude 的下一輪 tool call
• 接收端要有：payload 驗簽、去重（同一根 K 棒的訊號吃第一筆）、風控（部位上限、單日最大虧損停機）、dry-run 開關
• 交易所端的 API key 縮到最小權限：禁提現、綁 IP 白名單、開 2FA
• 一個「這一分鐘系統正常」的健康檢查——不然安靜地壞掉沒人知道

這幾件事都不是 MCP 該做的，也不是 Claude Code 需要負責的。它們是執行端的職責。API key 權限那條的細節在這篇講得比這裡完整；webhook 從零到能收到訊號則在完整教學。

舉例來說，TVSBot 的執行端就是為這條界線設計的——用你自己的 API key、 下單前先 dry-run、風控在帳戶層級套用——Claude Code 幫你把 Pine 寫好、alert 建好之後， 訊號打到執行端就交出去。這樣分工不是為了把功能拆散， 是為了讓「AI 動 chart」與「錢動」中間有一層人能看得到的關卡。

誠實的一段：這是路徑選擇，不是能力落差

上面說的「MCP 沒辦法自動下單」不是技術做不到——寫一個能下單的 MCP tool 是可以的，把 broker API 包成 MCP server 也已經有人做（雖然不是 tradingview 系的）。 所以更精確的說法是：目前檯面上活躍的 tradingview-mcp 專案作者都選擇不做這件事， 而 MCP 官方 spec 對這種會產生現實後果的 tool 也建議必須經過人工確認。這是路徑選擇，不是能力落差。

如果哪天有人真的做出「Claude Code 直接下單」的 MCP，那還是要問三件事：它去重嗎？ 它 dry-run 得了嗎？它壞掉的時候會不會安靜地把單一直送？——這幾個問題的答案跟這個工具 是不是 MCP 沒有關係，是任何自動化交易架構都要面對的問題。

常見問題