AI 交易机器人：从 Pine Script 到自动下单

你把交易想法告诉 AI，它丢回一段 Pine Script，贴进图表一次就编译通过。这件事现在真的不难。 没人提前告诉你的是：「代码能编译通过」和「代码能自动下实盘单」是完全不同的两道关卡，Pine Script 有一长串规则决定你落在哪一边。 这篇文章不评论你用的是哪个 AI 工具好不好——我们没有做过这种测试，这篇也不会做。

这篇文章不是教你写 Pine（一种专为交易图表设计的脚本语言），而是给你三件事：

• 哪些 alert 有资格发送 webhook
• 为什么你设的条件会重复触发
• 怎么设计才会安静地坏掉

第 0 层——这个 alert 本身有没有资格发 webhook？

这层过滤最简单，但最常被忽略。你必须确认自己的 TradingView 方案支持 webhook，否则后面所有设计都是白费。

Free 方案不支持 webhook，这是明确写出来的限制。如果你看到「免费就能跑自动交易」的教学，第一步就错了。

webhook 是用来从图表推送到你自架服务器的一串 URL，让你能接到当条件满足时的信号。简单来说，就是图表信号的「通知管道」。

第 1 层——snapshot 机制让你的 alert 没有记忆

你设的 alert 会在每一根 K 线上重新评估。这听起来是好事——每根 K 线都检查一遍，确保条件满足时就触发。但问题是：这个 alert 本身没有记忆。

这不是 bug，这是设计。但很多 AI 生成的策略没有意识到这一点，写出「上周金叉、本周死叉」之类依赖跨 bar 记忆的逻辑，结果每根 K 线都在从头开始。

如果你需要跨 K 线保留状态，必须用 var 关键字：

var 让变量跨 bar 保留值

var int signalCount = 0 if crossover(sma(close, 14), sma(close, 28)) signalCount := signalCount + 1 alert("Golden cross #" + tostring(signalCount), alert.freq_once_per_bar)

没有 var 的话，signalCount 每根 K 线都会从 0 开始算，永远都是 1。

还有一个进阶关键字 varip（variable intrabar persist），它不仅跨 bar 保留值，还会在「同一根 K 线内」的多次价格更新中持续保留。这在即时交易场景很有用——但回测时不会重现这种行为，因为历史数据没有 tick 级的更新。

第 2 层——你拿到的是 indicator，还是 strategy？

很多「AI 交易机器人」给你的，就是单纯的 indicator。indicator 只有两种状态：above/below、crossed up/down。它不会告诉你：「我刚刚才触发过，别再通知我一次了。」

Pine Script 有两种发送 alert 的方式：

alert() 的默认频率是 freq_once_per_bar——也就是说，同一根 K 线内只要 alert() 被调用一次就会触发。如果你把 alert() 放在 if 条件里，而且这个条件在一个 bar 内可能被评估多次（例如用 calc_on_every_tick=true 的策略），它就可能触发好几次。

要更严格的防重复，可以用 freq_once_per_bar_close，让 alert 只在 K 线收盘时才发送一次。这能避免「未确认信号」的问题——也就是在 K 线还没结束时，价格可能会来回晃动导致条件反复满足。

第 3 层——equity 的模拟陷阱

TradingView 会用 strategy.equity 来计算 webhook 发出的数量。strategy.equity 是 Pine 策略完全在 TradingView 服务器上模拟出来的数字，等于 initial_capital + netprofit + openprofit。

数字情境：假设你的回测用 10 万美元 initial_capital 跑，default_qty_type 设成 strategy.percent_of_equity、数值 10（即 10%）。你实际的交易所账户里只有 2,000 美元。

当 alert 触发、webhook 打到你的执行服务器，实际会发出多少数量？

答案是：TradingView 会用「这根 K 线当下的 strategy.equity」的 10% 去算这笔单的数量——而 strategy.equity = strategy.initial_capital + strategy.netprofit + strategy.openprofit，所有数值由 TradingView 服务器计算与存储。如果你的回测表现好，equity 变大，webhook 发出的订单数量也会跟着变大——即使你的真实账户根本没有那么多钱。

第 4 层——webhook 延迟与丢失

TradingView 从未针对自己故障期间漏掉的 alert 公布任何 SLA。我们也没有替 TVSBot 公布正常运行时间保证，因为我们自己也没有可以拿出来的公开 SLA。

这意味着如果你的执行服务器（TVSBot、自己的后端、或是任何 intermediary）在 3 秒内没有回复 HTTP 200，TradingView 就会放弃这次发送。它不会重试。

此外，TradingView 有频率限制：如果三分钟内触发超过 15 次 alert，系统会自动暂停发送。这在回测时不会碰到（因为历史 bar 的处理是批量的），但在即时交易时可能成为瓶颈。

设计能降低漏单的概率、缩小影响范围，但没办法把可能性归零。

第 5 层——交易所的断线自动撤单，不是人人有份

交易所挂了，我的仓位会自动被关掉吗？没有任何一份官方文件直接写明会或不会。但我们查过 Binance、OKX、Bybit、Bitget 的断线自动撤单机制，范围都严格限定在撤销挂单——没有一份提到仓位。

重点是：这些功能**都不是默认开启的**。每一家都需要手动设置，而且有的还有客户等级限制。

唯一可以确定的是：四家交易所都不会在你断线时自动平仓。如果你的仓位已经成交，价格继续往不利方向走，你可能会面临超出预期的亏损。

常见问题

本文不构成任何投资建议。所有提及的数字均来自官方文件、公开访谈、链上数据 — 引用来源在文末 RelatedPosts 之后可索取。加密交易风险高，请评估自身风险承受能力。