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 没有关系，是任何自动化交易架构都要面对的问题。

常见问题