企业官网建设流程全解析

简介：面向TradingView与3Commas交易用户的批量警报添加工具，基于TypeScript语言开发，主要解决TradingView缺少批量添加警报接口、不得不为大量交易对手动维护自定义警报的痛点。工具借助浏览器自动化框架驱动内置的Chromium浏览器实例，自动完成登录并逐条录入策略警报，适合量化交易者使用同一个指标覆盖数十甚至数百个交易对的场景。压缩包采用zip格式，共包含18个文件，整体大小13.9MB，主体由TypeScript源码、JSON配置、Shell部署脚本和Markdown说明文档构成，同时附有动画演示、条件配置示意图、示例配置与交易对过滤列表，目录与模块划分清晰。核心模块分别负责警报写入、页面操作、交易对拉取与类型定义，部署脚本可一键启动，结合说明文档与演示录屏，能完整看到自动化流程。已有1445人学习下载，适合具备一定TypeScript基础、希望用自动化方式维护TradingView警报的量化交易爱好者参考。

1. 批量把警报塞给 TradingView：3Commas 自动交易最缺的那一环

用 TradingView 配合 3Commas 跑自动交易的人，大多经历过同一个场景：策略里十几个交易对，每个都要去图表上手工建警报、填 webhook、再复制一遍 JSON payload，稍微改一个价格就要重新来一轮。add-tradingview-alerts-tool 就是冲着这个痛点来的，一个用 TypeScript 写的命令行工具，批量创建、更新和管理 TradingView 警报，并且每一个警报都是按 3Commas 的 TV 集成规范构造的。你不用再打开二十个图表页签手动点保存，也不用担心 JSON 里某个字段名写错导致机器人收到信号却不执行。这东西适合两类人：一类是刚接触 3Commas 信号集成、想照着配置就能跑通的新手；另一类是已经在跑多币种策略、被重复劳动逼疯的老手。

2. 3Commas 到底要什么格式：先把 signal payload 的链路理清

2.1 TradingView 警报不是下单指令，它只是个搬运工

很多人第一次做 3Commas 集成时会误以为 TradingView 警报能把"买入""卖出"直接发给机器人。实际不是这样。TradingView 警报触发后只做一件事：向你在警报配置里填写的 webhook URL 发送一次 HTTP POST，POST 的 body 就是这个警报里的 message 内容。

3Commas 的 TV 集成入口是https://3commas.io/tv_callback，它接收的是 JSON 格式的信号，而不是 TradingView 默认模板里那一堆{{ticker}}、{{close}}变量。如果你直接把 TradingView 默认的 message 模板原封不动发过去，3Commas 会返回一个错误，机器人不会有任何动作。正确做法是抛弃默认模板，在 TradingView 警报的 Message 输入框里写一个固定 JSON，让每次触发都发送相同内容。

{ "message_type": "bot", "bot_id": 12345, "email_token": "abcd1234abcd1234", "delay": 0 }

这个 JSON 就是 3Commas 能识别的核心信号。message_type决定触发类型，bot_id指明要控制哪个机器人，email_token是你在 3Commas 账户里开启 TV 信号时拿到的令牌，delay是延迟下单的秒数。

这里有个容易忽略的点：email_token不能乱填，它不是机器人 ID，也不是 API key。它在你登录 3Commas 后进入"信号"或"Webhook"设置页能看到，是一串比较长的字符串，相当于这个 webhook 通道的密码。填错的话，HTTP 请求能到达 3Commas，但会被判定为无权限而丢弃。

2.2 message_type 三选一：bot、deal、strategy 各自管什么

3Commas 的 tv_callback 不只支持控制机器人，还支持直接开平交易、启动策略。不同message_type对应不同业务含义，必填字段也不一样。我列了一张表，按我实际使用的频率排序：

绝大多数批量警报场景用的是bot类型。你需要先在 3Commas 里配置好机器人，把它停在"待命"状态，然后由 TradingView 警报触发的 webhook 来启动它。这里有个很多人踩过的坑：机器人的状态必须是"已开启"或"等待信号"，如果你在 3Commas 后台把机器人直接停用了，那 webhook 发过来只会收到一个错误响应，bot 不会自动复活。

deal类型适合你不想跑完整 DCA 策略、只想让某个交易开仓或平仓的场景。它的信号体比bot简单，但也意味着它不包含止盈止损等策略逻辑，所以我在实际项目中只把它用于手动辅助，不放在批量自动化里。

2.3 3Commas 会回什么：success 字段才是排查依据

调用 tv_callback 之后，3Commas 会返回一个 JSON 响应。如果一切正常，你会看到类似{"success":true}或带status字段的确认信息。如果你在批量工具里只关心"警报创建了吗"，就容易漏掉另一半链路：警报创建成功不代表 3Commas 会执行成功。

我在本地做验证时一般用一个简单的 curl 模拟 TradingView 的 POST 请求，直接打到 3Commas 的 webhook 地址，这样能快速区分问题出在警报端还是 3Commas 端。这个验证方法到后面第 6 章会展开写，这里先提醒一点：payload 里不要加多余字段，比如"price"、"ticker"这些看似有用的键，3Commas 不消费它们，一旦某个字段类型和预期不符，反而可能让整个请求被拒。保持最小化是最稳妥的。

3. 初始化与登录凭证：session token 是这个工具的黑匣子

3.1 安装与 CLI 第一条命令

这个工具通过 npm 分发，全局安装后就直接得到一个命令行程序。它要求 Node.js 版本在 18 以上，因为内部用到了原生的 fetch，低版本 Node 需要额外装 polyfill，没必要。

npm install -g add-tradingview-alerts-tool tv-alerts --version tv-alerts --help

如果你的网络对 npm registry 不太友好，也可以用仓库源码直接跑：克隆下来后执行npm install，再执行npm run build，最后用node dist/cli.js代替tv-alerts命令。两种方式效果一样，我一般推荐源码方式，因为你能看到它到底请求了哪个接口，排错时心里有数。

第一次运行时它会有个配置文件检测的提示。这个工具不会帮你自动生成配置，需要你手动创建一个 JSON 文件来描述要创建的警报。这个设计初看有点麻烦，但用在批处理场景就很合理：配置本身是可版本化的资产，你的策略参数、交易对列表、webhook 地址都该进 Git，而不是每次都敲命令行参数。

3.2 去浏览器取出 session token：一年只需要做一次

TradingView 的警报创建接口不是完全公开的 REST API，它需要携带浏览器会话凭证。add-tradingview-alerts-tool 内部使用的是 TradingView 网页端同源的警报接口，所以认证方式也复用了浏览器里的登录态。

具体操作是：打开 TradingView 任意图表页面，按 F12 进入开发者工具，切到 Application（应用）面板，在 Local Storage 下找到tv-auth-token字段，把它的值完整复制出来。这个值就是工具需要的TV_SESSION环境变量。如果你在 Local Storage 里没找到这个名字，也可能叫session或auth_token，不同账号体系下键名略有差异。

export TV_SESSION="粘贴这里"

这里有个细节值得说明：不要把tv-auth-token和 TradingView 的 API key 搞混。API key 是用于官方公开数据接口的，通常以Bearer头方式传递；而 session token 是网页端用于私有接口的会话凭证，两者权限范围完全不同。工具读的是后者，填错的话请求不会立刻报 403，而是可能卡在"警报列表为空"这种看起来诡异的阶段。

session token 的有效期取决于 TradingView 的登录策略，我遇到的大多数情况能撑一两天到一周不等，Token 过期后你只需要重新复制一次粘到环境变量里，不用重新配置其他任何东西。所以我说"一年只需要做一次"其实是夸张，但熟练后整个过程不到一分钟。

3.3 最小配置与 dry-run：上线前必过的检查点

配置文件的核心结构是：告诉工具"我要对哪些交易对创建什么条件的警报，发到什么地址，发什么内容"。一个最简的批量配置长这样：

{ "symbols": ["BTCUSDT", "ETHUSDT", "SOLUSDT"], "exchange": "BINANCE", "timeframe": "15m", "condition": "cross", "operator": "crosses", "value": 0, "webhook": "https://3commas.io/tv_callback", "message": { "message_type": "bot", "bot_id": 12345, "email_token": "abcd1234abcd1234", "delay": 0 } }

symbols是要监控的交易对列表，exchange对应 TradingView 图表里的交易所代码，timeframe是 K 线周期，condition和operator、value组合起来描述警报的触发逻辑。这里value: 0是占位，因为不同交易对的价格区间差异太大，批量创建时它通常会被覆盖逻辑替换掉，比如按前一根 K 线的最高价或布林带上轨动态取值。

在真正把警报推送到 TradingView 之前，一定要先跑一遍 dry-run：

TV_SESSION="粘贴这里" tv-alerts --config ./alerts.json --dry-run

--dry-run模式下工具只打印每个请求的完整 body，以及将要创建的警报标题列表，不会真正发送。这一步能帮你确认多少个警报会被创建、每个警报的触发条件是否如你所料。我会在看输出时重点数一下数量：配了 3 个交易对，就该看到 3 条警报，多一条少一条都说明配置有问题。

4. 批量创建警报的核心实现：读懂 TypeScript 主循环就够了

4.1 警报数据模型：一个 AlertJob 描述一个任务

如果你准备改这个工具，或者想把它集成进自己的自动化系统，最值得读的文件就是定义数据模型的那一段。工具内部把每个警报抽象成一个AlertJob，这个对象把 TradingView 警报所需的全部参数和 3Commas 的 payload 装在一起。

type ThreeCommasSignal = { message_type: "bot" | "deal" | "strategy" bot_id?: number strategy_id?: number email_token: string delay?: number } type AlertJob = { symbol: string exchange: string timeframe: string condition: "cross" | "greater" | "less" operator: string value: number webhook: string title: string message: ThreeCommasSignal }

这个模型的直观之处在于它把"警报条件"和"触发后的动作"拆开了。symbol、timeframe、condition描述的是 TradingView 侧的警报规则，而webhook和message描述的是触发后发给 3Commas 的动作。两个部分可以独立修改：你想改触发价位，只动value；想换控制的机器人，只动message.bot_id。

我一般在读这种代码时先看类型定义而不是直接看函数体。类型定义能反映设计者对问题域的切分方式，这里切分得很干净：没有把 3Commas 的 email_token 和 TradingView 的会话 token 混在一个配置字段里，前者出现在message里发给 3Commas，后者只通过环境变量进入请求头。

4.2 创建警报的主循环：幂等、并发与返回结果

工具的核心逻辑是一个遍历 AlertJob 列表的循环，逐个调用 TradingView 的警报保存接口，收集每个请求的成功与否。简化后的实现思路如下：

import { promises as fs } from "node:fs" const TV_ALERT_ENDPOINT = process.env.TV_ALERT_ENDPOINT ?? "https://www.tradingview.com/alert/save" async function createAlerts(jobs: AlertJob[], sessionToken: string) { const results: Array<{ symbol: string; ok: boolean; alertId?: number }> = [] for (const job of jobs) { const payload = { symbol: `${job.exchange}:${job.symbol}`, timeframe: job.timeframe, condition: job.condition, operator: job.operator, value: job.value, title: job.title, webhook: job.webhook, message: JSON.stringify(job.message), } try { const response = await fetch(TV_ALERT_ENDPOINT, { method: "POST", headers: { "Content-Type": "application/json", "Authorization": `Bearer ${sessionToken}`, }, body: JSON.stringify(payload), }) const text = await response.text() results.push({ symbol: job.symbol, ok: response.ok, alertId: extractAlertId(text), }) } catch (error) { results.push({ symbol: job.symbol, ok: false }) } } await fs.writeFile("alert-results.json", JSON.stringify(results, null, 2)) return results }

循环本身不复杂，关键在两处：一是message字段被JSON.stringify成字符串后再放进外层 payload，这是 TradingView 警报接口的格式要求，不是笔误。如果你把message直接传成嵌套对象，接口会拒绝或把它原样丢给 webhook，导致 3Commas 收到一个转义过的字符串。

二是每次都把结果写入alert-results.json。这个文件相当于批处理的账单，后续做幂等判断、排查哪个交易对失败了都靠它。我在自己项目里会把这个文件纳入监控，只要发现ok: false的记录，就说明当天的警报更新没有完全生效。

4.3 两个值得调的参数：delay 和 throttle

job.message.delay是 3Commas 收到信号后延迟下单的秒数。它真正的价值不在"防抢跑"，而在给机器人一个缓冲：当多个交易对在短时间内同时触发警报时，同时向交易所下多单容易触发风控或滑点，设置 2 到 5 秒的延迟能让订单有序进入。

另一个参数藏在循环外面，工具一般会带一个--throttle或--interval选项，控制每次请求之间的间隔：

tv-alerts --config ./alerts.json --throttle 1500

1500表示每次创建警报请求之间间隔 1500 毫秒。之所以需要这个参数，是因为 TradingView 的接口没有公开速率限制文档，但实际请求太密集时会返回 429 或 5xx。我见过有人一次性创建 50 个警报不加节流，结果前 20 个成功、后面 30 个全部超时。加个 1.5 秒的间隔，50 个也就多等一分多钟，成功率高很多。

顺带一提，--throttle只影响创建请求的发送节奏，不影响你配置文件里的delay。前者是你和 TradingView 之间的礼貌，后者是 3Commas 和交易所之间的策略。

5. 警报保存成功但机器人不动：四个避坑记录

5.1 现象：工具提示全部成功，但 3Commas 后台没有任何动作记录

这个坑我踩过不止一次。批量工具返回ok: true只代表 TradingView 接受了警报，不代表 webhook 真的被 3Commas 成功处理。

原因通常是message里的 JSON 是合法的，但语义不对。最常见的是bot_id填成了别的数字，或者email_token对应的不是当前 3Commas 账户。TradingView 不会校验你 webhook 内容里的业务字段，它会原样发送，所以这部分错误只能靠 3Commas 端响应暴露。

解决：先不用工具，手动在 TradingView 里创建一个测试警报，webhook 填 3Commas 的 tv_callback，message 填最简单的那条 JSON，触发后立刻看 3Commas 的通知中心有没有"信号已接收"记录。没有记录就去 3Commas 的设置页核对 email_token。这个步骤能排除 60% 的"保存成功但没反应"。

5.2 现象：请求返回 401 Unauthorized，但 TV_SESSION 明明填了

session token 过期是最常见原因。tv-auth-token不是永久的，TradingView 会在登录态失效或异地登录后吊销旧 token。如果你是从浏览器复制的值复制到一半，或者多复制了一个空格，也会看到 401。

解决：回到 TradingView 页面，确认浏览器里仍是登录状态，重新从 Local Storage 复制一次，粘贴前检查首尾无空格。然后再跑一次 dry-run 验证请求头。这里没有别的技巧，重复执行"复制-设置-测试"三步，直到请求头通过。

5.3 现象：重复运行命令后，TradingView 警报列表里出现一摸一样的多个警报

TradingView 的警报保存接口没有天然幂等机制，你把同一个配置文件跑两遍，它就会创建两条标题相同、条件相同的警报。这在单次手动操作时无所谓，但在批处理里会快速污染警报列表。

解决：用alert-results.json做幂等依据。第一次运行时记录每个警报接口返回的 alert ID，第二次运行时先按交易对和标题查询现有警报，匹配到就把创建改为更新。工具如果提供了--update或--sync模式，优先用它，不要重复执行裸创建命令。我自己定了一条死规矩：批量创建永远只跑 dry-run 加一次正式执行，后续改动一律走更新参数。

5.4 现象：警报触发了，但比预期晚了十几秒，甚至错过行情

这个"玄学延迟"其实不玄。TradingView 的警报检测本身就有轮询周期，尤其是免费账户，检测粒度可能不是秒级；3Commas 收到 webhook 后还要经过任务队列、交易所下单排队两个环节，叠加起来十几秒的延迟很正常。

解决：区分"警报检测延迟"和"下单延迟"。前者取决于你的 TradingView 账户等级，后者由 3Commas 服务端负载决定。你唯一能控制的是delay参数——不要把它设成 0 就以为零延迟，实际的端到端延迟由整条链路决定。如果策略对时效要求极高，建议把警报条件留出容差，或者改用 3Commas 的原生价格订阅做备选触发，不要把所有希望押在单条 webhook 上。

6. 验证闭环：新手怎么确认警报真的能点火

看到这里你已经能批量创建警报了，但"能创建"和"能交易"中间还差一个验证闭环。我的做法是分三步：先在本地模拟 3Commas 回调，再让一个真实警报空跑一次，最后才让机器人带真仓位。

第一步，用 curl 直接模拟 TradingView 的 POST 请求，打到 3Commas 的 webhook 地址：

curl -s -X POST https://3commas.io/tv_callback \ -H "Content-Type: application/json" \ -d '{"message_type":"bot","bot_id":12345,"email_token":"abcd1234abcd1234","delay":0}'

看返回内容里有没有 success 字段，有就说明 JSON 有效、token 有效、机器人在线。这一步不要在你的主账号上做，最好用测试机器人和小额资金。

第二步，在 TradingView 上手动建一个触发条件极其宽松的测试警报，比如价格低于当前价 50%，让它几分钟内必然触发，webhook 指到自己的本地调试地址或 Webhook.site，确认触发的 POST 内容和你配置文件里的 message 完全一致。这一步验证的是 TradingView 侧的发送行为。

第三步，把 webhook 改回 3Commas 的 tv_callback，让测试警报真正触发一次，全程盯着 3Commas 的日志和机器人状态。如果这一步成功了，说明整条链路已经打通，剩下的工作全部交给批量工具就行。从那以后，我每次换新策略或者换新机器人，都会强制把这三步走一遍，换一次配置就走一遍，哪怕自以为没改什么关键字段。批处理工具能一次性创建 50 个警报，也能一次性把 50 个警报同时配错，及早验证永远比事后排查省时间。希望这三步对你也有用。

本文还有配套的精品资源，点击获取