简介一套面向量化交易与自动交易场景的TypeScript开源工具用于将自定义警报批量写入TradingView专为3Commas等平台的Webhook机器人集成而设计解决手工逐条维护数十或数百个交易对警报的痛点。工具借助Puppeteer控制自带Chromium浏览器自动操作TradingView警报页面无需官方API即可完成重复性配置支持三大主流桌面系统压缩包共18个文件以TypeScript源码为核心包含JSON配置文件、Shell部署脚本、CSV黑白名单、YAML样例、Markdown说明、操作演示GIF与截图等整体大小13.9MB。源码按主流程、页面操作、交易对拉取等模块划分配合操作演示动图、条件设置截图与市场列表数据便于快速复现运行环境和二次开发降低将指标信号接入交易机器人的门槛。目前已有1445人学习下载适合有一定编程基础、希望优化多交易对警报管理流程或在TradingView与3Commas之间实现信号自动化的用户使用。1. add-tradingview-alerts-tool 到底解决什么问题给 3Commas 对接警报手工创建早就过时了做 3Commas 自动交易的人十有八九都卡在同一个环节策略在 TradingView 上要挂几十上百个警报一个接一个在网页里点鼠标设交易对、设周期、粘贴消息格式、保存……重复操作不仅累还特别容易出错。一个格式错位警报推过去 3Commas 不认bot 原地罢工资金却还在仓位上。add-tradingview-alerts-tool 就是为了解决这个场景把「在界面上手点警报」变成「用脚本批量生成、批量导入、批量更新」而且它生成的消息体直接按 3Commas TV 警报集成的要求拼好不用你手工逐字段调整。本文按「先理解原理再落地跑通」的顺序来写读完你不仅知道怎么装还能处理掉大部分匹配规则、消息格式、重复警报之类的坑。2. 批量导入的三种常见做法为什么脚本方案最值得上手2.1 TradingView 警报集成的三种落地途径对比对接 TradingView 和 3Commas常见做法有浏览器自动化、TradingView 主动 Webhook 推送以及本地/云端脚本批量生成警报三条路。浏览器自动化比如用 Puppeteer 或油猴脚本模拟点击创建警报优势是视觉上直接看到界面反馈但代价是速度慢、依赖页面 DOM 结构——TradingView 只要改一次界面布局整套脚本就报废。主动 Webhook 推送适合实时交易不适合批量导入历史警报因为警报规则本身由 TV 触发你没法用一根请求把几十个警报一次性灌进去。add-tradingview-alerts-tool 选的是第三条路在本地或服务器上运行脚本一次性生成所有警报的配置内容然后通过 TradingView 的警报 API 或导入机制写入。核心逻辑不依赖界面框架所以不容易被前端改版影响而且脚本可以重复执行警报规则要改参数时不用在页面里逐条编辑。这套方案的投入产出比最高尤其适合警报数量超过 20 个的场景。2.2 选脚本方案的四个理由可复用、可追溯、可批量、防手滑手动创建警报最大的隐患不是慢而是不一致。同一个策略你昨天手写的消息体和今天复制的消息体之间可能差一个空格、差异一个字段名3Commas 解析时直接判为非法负载。脚本生成则保证所有警报的消息体模板完全一致唯一变化的是交易对、周期、价格等参数位。另一个好处是可追溯。脚本文件本身就是配置的版本记录改了什么一目了然比翻网页历史记录靠谱得多。批量导入虽然首次搭建要花点时间但后续每次调整策略只需要改脚本里的参数列表重新执行一遍生成流程即可。所谓防手滑指的是你不需要在几十个警报之间来回核对参数有没有写错脚本会用统一的循环结构和日志输出替你校验。3. 跑通 add-tradingview-alerts-tool从 clone 到生成第一批配置3.1 环境准备Node.js 版本与依赖安装这个工具常见实现是基于 JavaScript/Node.js 编写的命令行工具目的是解析配置文件、生成 TradingView 警报 URL 或消息体。建议在 Node.js 18 以上版本运行因为新版本自带 fetch很多工具不再依赖额外的 HTTP 库。# 克隆工具仓库以常见开源项目结构为例 git clone https://github.com/your-local-path/add-tradingview-alerts-tool.git cd add-tradingview-alerts-tool # 安装依赖 npm install依赖安装完成后重点检查 node_modules 里是否生成了config或dist目录这决定你后续是直接改根目录的配置文件还是改构建后的产物。如果你不熟悉 Node.js 生态请留意package.json里的scripts字段通常会有build、start、test三个入口后面运行都靠它们。3.2 配置文件结构拆解symbols、strategies、alert_settings三块各管什么配置文件是批量导入的核心常见的格式是 JSON 或 YAML建议优先选 YAML——支持注释可以写说明后期维护方便。一个最小可用的配置大概长这样# config.example.yaml symbols: - BTCUSDT - ETHUSDT - SOLUSDT strategies: - name: ema_cross message: {strategy: ema_cross, symbol: {{symbol}}, close: {{close}}} alert_settings: time_frame: 15m alert_name_prefix: 3C-EMA sound: false如果你第一次接触这份配置要理解三个字段分别管什么symbols决定生成哪些交易对的警报strategies决定每个警报触发时推送的消息体模板其中{{symbol}}、{{close}}这类占位符会在运行时替换成真实值alert_settings是全局控制项比如周期、名称前缀、是否播放提示音。最需要花时间调的是strategies因为它直接对接 3Commas 解析逻辑字段名和 3Commas 文档不一致警报推过去就是无效信号。3.3 核心命令generate、import、dry-run是三个必学入口这个工具一般会拆出三个明确的子命令来对应不同阶段的任务。dry-run是最先要跑的它只渲染消息体和警报列表不执行真正的导入用来检查你的模板有没有语法错误。跑通后进入generate阶段生成完整警报配置文件最后执行import写入 TradingView。# 1. 先验证配置模板能不能解析 node index.js dry-run --config config.example.yaml # 2. 生成警报清单文件通常输出为 alerts.json node index.js generate --config config.example.yaml --out alerts.json # 3. 把警报真正写入 TradingView 账号 node index.js import --file alerts.jsonimport阶段需要处理 TradingView 的认证信息常见做法是通过传递TV_SESSION或TV_TOKEN环境变量完成登录态校验。这里要特别提醒TradingView 没有公开的官方批量写入接口所以多数工具采取的方式是构造内部请求这个环节最依赖网页端登录态token 失效就需要重新导出 cookie。如果你的项目是开源的通常作者会建议你通过浏览器扩展手动复制 token而不是在配置文件里硬编码。4. 专为 3Commas 定制的消息格式这部分决定你的 bot 会不会乱开单4.1 3Commas TV 警报集成接收的消息结构3Commas 的 TradingView 警报集成在接收端其实是一个 Webhook URLTradingView 警报触发后向该 URL POST 一个 JSON 负载。这个负载的结构直接决定 3Commas 识别成哪个策略、哪个交易对、什么方向、以多少数量入场。典型的格式如下{ message_type: bot, bot_id: 12345, email_token: your-secret-token, delay_seconds: 0, pair: BTCUSDT, signal: buy }在使用批量工具时你要确保模板生成的 JSON 结构能和 3Commas 的字段对应上。特别是email_token很多新用户会漏掉或写错结果警报触发后 3Commas 返回 401bot 完全无反应。pair字段必须和你配置里的交易对名称完全一致比如 Binance 永续合约通常写成BTCUSDT现货是BTCUSDT但如果你的交易所是 FTX则可能是BTC/USDT这个差异必须在模板层处理好。4.2 动态字段把 TradingView 的{{close}}映射成 3Commas 的入场价TradingView 警报消息体支持占位符语法比如{{close}}、{{open}}、{{ticker}}这些值由是触发时的实时数据替换。批量工具做的最重要一件事就是把 TradingView 的占位符语义翻译成 3Commas 的字段名。比如你希望 3Commas 以警报触发时的收盘价作为入场价那么消息体里得写成price: {{close}}而不是price: {{current}}——后者在 TradingView 里并不存在会导致消息体最终带上空字符串。一个稳妥的写法是把 TradingView 变量放在一个映射层统一转成 3Commas 可读的字段。比如// mapper.js const mapTVto3C (tvPlaceholder) { switch (tvPlaceholder) { case close: return price; case ticker: return pair; default: return tvPlaceholder; } };这段映射代码的核心价值是解耦将来如果 TradingView 改了变量名你只需要改这一处映射不需要在所有模板里逐个替换。而如果你直接在几十个警报里写死字段名将来改一个变量的成本就是逐个改文件。4.3 多策略同时导入每个策略对应一组警报而不是一条消息3Commas 里你可能会同时跑马丁格尔 bot、网格 bot、信号 bot每种 bot 对警报负载的要求不一样。批量工具的配置结构通常允许你按strategy拆分组每组独立生成警报。这意味着每个策略要有独立的模板、独立的bot_id、独立的交易对列表。# config.multi-strategy.yaml strategies: - name: ema_cross bot_id: 12345 email_token: token-a message_template: templates/ema.json symbols: - BTCUSDT - SOLUSDT - name: rsi_reversion bot_id: 67890 email_token: token-b message_template: templates/rsi.json symbols: - ETHUSDT运行时每对strategy × symbol会生成一个独立警报。假设策略 A 有 2 个交易对策略 B 有 1 个交易对你最终得到 3 条警报。这个设计让你能精确控制每个交易对由哪个策略接管不会出现一个交易对同时被两个 bot 触发导致重复开单的情况。5. 避坑指南批量导入 TradingView 警报最容易翻车的五个细节5.1 现象警报成功导入但 3Commas 从未收到信号日志里显示 204原因你的 TradingView 警报设置里Webhook URL 没填对或者填成了 3Commas 的 API 地址而不是 Webhook 专用地址。3Commas 的 TV 警报集成地址一般形如https://webhook.3commas.io/tv/v1/新用户经常误用成https://api.3commas.io开头的地址。解决检查你的 3Commas 后台找到 TV 警报集成页面复制「Webhook URL」粘贴到批量工具的全局配置里而不是每次生成时手抄。多处手抄最容易出现「中间多个斜杠」这类低级错误。5.2 现象消息体里pair字段显示为BTCUSDT但 3Commas bot 拒绝执行原因交易对名称在不同交易所的格式不一样。Binance 期货是BTCUSDT但 3Commas 内部可能要求BTC_USDT或BTC/USDT取决于你 bot 绑定的交易所和合约类型。解决先在 3Commas 里手动创建一个测试 bot查看它的交易对下拉列表里实际显示的名称格式然后把批量工具配置里的symbols全部改成这个格式。批量工具只负责原样替换不会帮你做名称标准化。5.3 现象dry-run正常import后警报数量在 TradingView 里变少了一半原因TradingView 免费账户对警报数量有上限通常一个策略最多挂 10 条警报超过部分会被静默丢弃。很多用户把 100 个交易对塞进配置跑完一看只导入成功 10 条。解决在配置里加一个max_alerts校验逻辑或者在脚本里加入计数和警告。最直接的做法是分段导入每 20 个交易对跑一次import确认导入成功后再跑下一批。别相信脚本执行结果以 TradingView 网页端实际显示的警报数量为准。5.4 现象警报触发后 3Commas 收了消息但 bot 没有按计划开单反而报错原因消息体里的delay_seconds、signal如buy/sell或message_type写错。message_type如果写成bot但你的 bot 实际是composite3Commas 会判定找不到对应 bot。解决批量导入前先发出一个测试警报等 3Commas 页面状态变化后把消息负载手动复制和模板生成的结果做 diff。无人值守的批量处理需要先做一次端到端验证确认无误后再全量导入。5.5 现象导入脚本运行几分钟后报TimeoutErrorTradingView 返回 429原因请求太快TradingView 的 Web 端有频率限制。你通过脚本直接内部接口写入警报短时间大量请求容易触发限流。解决在import函数里加一个sleep或delay参数比如每条警报之间等 300~500 毫秒。宁可导入速度慢一点也不要贪快。如果已经出现 429停 10 分钟再继续别反复重试同一个批次。6. 进阶技巧用时间周期变量和动态占位符把脚本用成生产力工具批量导入工具真正拉开差距的地方不是「能导入」而是「能不能灵活导入」。我一般会在配置里加入time_frames和multiplier两类变量前者控制同一策略在不同周期下的警报后者控制价格偏移量。# config.advanced.yaml strategies: - name: bollinger_breakout message_template: templates/bollinger.json time_frames: - 5m - 15m - 1h offset_percentage: 0.002运行时脚本会把每个时间周期都渲染成独立警报全部导入后在 TradingView 里你会看到BTCUSDT-5m-警戒线、BTCUSDT-15m-警戒线这样一组命名规范的警报列表。offset_percentage参数会在生成消息体时对入场价做百分比偏移比如现货网格单希望在收盘价上方 0.2% 挂单直接配置即可不需要在每个策略模板里做手工计算。另外一个实用技巧是给成功导入的警报做本地备份。每次脚本运行完生成一个带时间戳的alerts_YYYYMMDD.json这样将来删除错配警报后你还能快速回溯当时批量导入时用的哪些交易对、哪些字段。这个习惯救过我好几次。这套方案做下来我在几十个交易对上批量建立、更新警报从原来的两三个小时手动配置缩短到几分钟脚本运行。不过要说教训最值得记住的是导入工具只是省了重复劳动但消息格式、bot 状态、交易对命名这些「业务规则」依然得靠你亲自验证。希望我的这些踩坑经验能帮你省掉几个急躁的排查夜晚希望帮到你。本文还有配套的精品资源点击获取