企业官网建设流程全解析

Claude、Codex、Gemini 谁最会看盘：三大 AI 接 TradingView 实测横评

【免费下载链接】tradingview-mcpAI-assisted TradingView chart analysis — connect Claude Code to your TradingView Desktop for personal workflow automation项目地址: https://gitcode.com/GitHub_Trending/tra/tradingview-mcp

当 Anthropic 在 2024 年底抛出 MCP（Model Context Protocol）时，很少有人想到它最先引爆的细分场景会是金融图表。短短一年多，TradingView 官方宣布向付费方案开放官方 MCP Server 公测，社区里也冒出了大量基于 CDP（Chrome DevTools Protocol）的开源桥接方案，头条甚至流传着"两句话就能让 Claude 和 Codex 自己连上官方 TradingView MCP"的说法。AI 看盘的门槛被拉到了近十年最低：不再需要写爬虫、不需要对接行情 API，只要一个支持 MCP 的 CLI 客户端，AI 就能"睁眼看 K 线"。

但接入容易，用得好不好是另一回事。同一个 MCP 服务器摆在 Claude、Codex、Gemini 面前，谁读图读得准、谁改指标改得顺、谁回放练盘练得稳？本文以开源项目 tradingview-mcp 的源码为基准，结合社区实际使用情报，拆解三大模型接入 TradingView 的配置差异与三项核心能力链路，并给出按场景的选型建议。文中涉及的具体工具、参数与代码均来自仓库真实实现，可对照 src/ 目录逐一验证。

一、赛道背景：官方公测与开源桥接两条路

先厘清一个事实：现在接 TradingView 的 AI，走的是两条完全不同的技术路线。

官方路线是 TradingView 自己发布的 MCP Server，目前向付费方案开放公测，接入方式极简——Google 新闻聚合里那条"全新 MCP Server，将 TradingView 带到 Claude：现向付费方案开放公测"的官方消息即为佐证，头条用户总结的"两句话连接法"（先问 AI 能不能连上官方 MCP，再让它直连）正是这条路的写照。

开源路线则是像 tradingview-mcp 这样的第三方桥接项目：它不碰 TradingView 的服务器，而是通过 Electron 内建的 Chrome DevTools Protocol（CDP）控制本地正在运行的 TradingView Desktop，架构如下（见 README.md 与 src/connection.js）：

Claude Code ←→ MCP Server (stdio) ←→ CDP (port 9222) ←→ TradingView Desktop (Electron)

两者定位不同：官方 Server 侧重托管数据能力，开源桥接侧重"操作你自己的图表"。而本仓库明确划定了边界——不访问 TradingView 服务器、不绕过付费墙、不执行真实交易，所有数据只在本地流转（README.md "What This Tool Does Not Do"）。这一点对下面所有横评都成立：模型比拼的是"操作本地图表"这条链路，而非行情数据本身。

二、配置差异：协议是平的，门槛全在客户端

横评的第一站是配置。结论可能出乎意料：三大模型在 MCP 接入层几乎没有差异，因为 MCP 是开放标准，Claude Code、Codex CLI、Gemini CLI 都以近乎相同的 JSON 方式注册外部服务器。

以开源路线为例，配置只需在 MCP 配置文件中声明一条服务器（README.md）：

{ "mcpServers": { "tradingview": { "command": "node", "args": ["/path/to/tradingview-mcp/src/server.js"] } } }

真正的差异发生在三层：

其一，客户端各自约定配置文件位置。Claude Code 读取~/.claude/.mcp.json或项目级.mcp.json（SETUP_GUIDE.md 有完整步骤）；Codex 和 Gemini CLI 各自维护自己的 MCP 注册表。这意味着"把 MCP 加进去"这一步的文案因模型而异，但协议层完全互通——这也是社区"所有 MCP 以后都可以这么连"说法的来源。

其二，模型对工具列表的消化方式不同。这个仓库注册了 84 个工具（src/server.js），从quote_get到replay_trade，粒度极细。Claude Code 有天然优势：仓库里的 CLAUDE.md 会在会话开始时被自动加载，其中写死了"哪个问题调哪个工具"的决策树。而 Codex 与 Gemini 没有这一专属注入机制，能否在 84 个工具里选对，完全取决于模型自身的工具选择能力——这正是下文实测差距的核心来源。

其三，启动侧的基础设施要求。开源路线要求本地 TradingView 以--remote-debugging-port=9222调试模式启动，Windows 上还要处理 MSIX 包授权问题（tv_launch工具会自动复制本地包再启动，见 SETUP_GUIDE.md）。这一层与模型无关，是环境问题，但决定了"你连的是哪一个 AI"之前的半小时体验。

三、看图：视觉理解是能力分水岭

"看盘"最直观的动作是看图。tradingview-mcp 为此设计了完整链路（CLAUDE.md 决策树）：

1. chart_get_state—— 拿到品种、周期、全部指标实体 ID
2. data_get_study_values—— 读取所有可见指标的当前数值（RSI、MACD、布林带、EMA…）
3. data_get_pine_lines/data_get_pine_labels/data_get_pine_tables/data_get_pine_boxes—— 读取自定义 Pine 指标用line.new()、label.new()、table.new()、box.new()画的支撑阻力、文本标注、会话统计表、价格区间
4. capture_screenshot—— 截图做视觉确认

这条链路在 src/core/data.js 里的实现很有讲究：getPineLines会对水平价位去重排序，getPineLabels默认只返回文本+价格对（上限 50 条），getPineTables把表格压成行 | 列格式的字符串。也就是说，喂给模型的不是原始图形对象，而是"价位列表 + 标注文本 + 表格行"，把一次 80KB 的读取压到了 5–10KB（RESEARCH.md）。

在这个基础上横向对比三个模型，差异是结构性的：

• Claude 系：对"先读状态、再读数值、最后截图确认"的多步编排最熟练，且 CLAUDE.md 决策树几乎是为它量身定做。社区大量"用自然语言问『我图表上现在有什么』"的实操帖都跑在 Claude Code 上，84 个工具不会把它绕晕（RESEARCH.md 明确记录："Tool Count Does Not Confuse the Agent"）。
• Gemini：多模态是它的长板。官方路线下"截图 → 让 Gemini 描述形态"的视觉推理链路流畅；但面对 84 个结构化小工具时，它的工具编排倾向更粗放，容易一上来就拉全量数据而不是先summary: true。
• Codex：中规中矩，读图靠截图+数值双通道时表现稳，但优势不在视觉而在后续批量处理——这正是它最该被用在"扫盘"而非"读盘"的原因。

四、写指标：Pine Script 全流程是重头戏

如果说看图是"眼力"，写指标就是"手艺"。Pine Script 是一门有系列类型、历史引用、重绘语义的 DSL，社区公认 AI 在这里的助攻价值最大（RESEARCH.md 的结论之一）。

仓库把写指标封装成了可闭环的编译调试循环（src/tools/pine.js）：

pine_set_source → pine_smart_compile → pine_get_errors → pine_get_console → pine_save

循环背后是三层硬核实现（src/core/pine.js）：

• 离线静态分析pine_analyze：不连图表，纯正则+词法扫描，能抓出array.get/set越界、对空数组调用first()/last()、写了strategy.entry却没有strategy()声明等典型错误——这些正是 LLM 写 Pine 时最常犯的错，测试用例覆盖在 tests/pine_analyze.test.js。
• 服务端编译pine_check：直接调 TradingView 的pine-facade/translate_light接口，无图表也能拿到真实编译错误与警告（含行列号）。
• 图表内编译pine_smart_compile：通过 CDP 找到 Monaco 编辑器注入代码、点击编译、读取标记、比对编译前后图表上的指标数量，返回study_added字段做闭环确认。

这个循环对三个模型的意义完全不同。Claude 系因为能结合log.info()输出与错误行列号做"改一行、编一次、看报错"的快速迭代，社区评测普遍认为它是当前写 Pine 指标体验最好的模型。Gemini 写小指标（几行plot(close)级别的模板）很利索，但遇到array.new_float(0)后接first()这类空数组陷阱时，静态分析的提示比模型自查更可靠——此时模型间的差距被工具兜底了。Codex 的优势在于它把"写代码"当本职，多文件、多脚本的指标工程化（配合 scripts/pine_push.js、scripts/pine_pull.js 的拉取推送）更顺手。

一个需要所有模型共同警惕的坑：pine_get_source读复杂脚本可能返回 200KB+，CLAUDE.md 的上下文管理规则明确要求"避免读取、除非要编辑"——三家的上下文窗口都烧不起这个量级，谁能忍住不调这个工具，谁的会话就更长。

五、回放：多步状态跟踪考验临盘纪律

回放（Bar Replay）是 TradingView 的练盘功能，也是最能拉开模型差距的第三项能力。仓库提供的链路（src/tools/replay.js、src/core/replay.js）：

replay_start(日期) → replay_step / replay_autoplay → replay_trade(buy/sell/close) → replay_status → replay_stop

源码里藏着几个只有实测才会发现的细节：

• replay_start会校验isReplayAvailable()，并在页面上下文中 awaitselectDate()——注释明确写到"若不等 Promise 完成，回放显示 started 但步进无效"（issue #26 的教训）。模型如果跳过这层等待直接replay_step，就会踩到状态未就绪的坑。
• replay_autoplay对速度参数做了白名单校验（100/143/200/300/1000/2000/3000/5000/10000ms），非法值直接报错，注释写着"非法值会永久损坏云端账户状态"——这是 CDP 直操真实客户端时的防御性设计。
• replay_step之后要轮询 currentDate 直到变化，因为doStep()是异步的，currentDate大约 500ms 后才更新。

回放的本质是一场多轮状态游戏：模型必须持续追踪"当前日期、持仓方向、已实现盈亏"，并在每一步做出买卖决策。这里三家的差距最直观：

• Claude 系在多步工具调用中保持状态一致性最好，能完整跑完 skills/replay-practice/SKILL.md 定义的"设品种→加指标→截图→逐根步进→开仓→确认持仓→平仓→复盘"全流程。
• Gemini 和 Codex 单步执行没有障碍，但超过十步的连续决策链（每步都可能插一次截图、读一次replay_status）容易出现状态丢失——replay_status返回的 position 与 realized_pnl 是唯一的权威状态源，谁在决策前忘记调它，谁就会"以为自己在持仓其实已经平仓"。

社区普遍认同一点：回放模式不适合让模型自由发挥，而适合"AI 执行、人做决策"的陪练结构——这恰好呼应了 RESEARCH.md 中"Human-in-the-Loop"的设计讨论。

六、选型建议：按场景匹配模型

把三章实测收拢成一张决策表：

最后必须强调两个横评之外的共识。其一，模型只是大脑，链路才是护城河：这份仓库把"紧凑输出、去重价位、状态轮询、非法参数拦截"都固化进了工具层，任何模型接入后都受益——选型差异远小于"有没有接对工具"的差异。其二，合规红线不因模型而松动：无论是走官方公测还是开源桥接，程序化读取与操作都需遵守 TradingView 条款（README.md Disclaimer 罗列了完整的禁止事项清单），且本工具明确不执行真实交易。选哪个 AI 看盘，最终取决于你想让它当"分析师、工程师还是陪练"——而不是它跑在哪家云端。

【免费下载链接】tradingview-mcpAI-assisted TradingView chart analysis — connect Claude Code to your TradingView Desktop for personal workflow automation项目地址: https://gitcode.com/GitHub_Trending/tra/tradingview-mcp