加密貨幣交易機器人提示詞檢查清單：六段結構

你把一个想法喂给 AI，它吐出一段 Pine Script，你粘贴进去，第一次就编译通过了。然后你设置警报、填入 webhook 网址、点创建——什么反应都没有。没有错误信息，没有通知，一片安静。

这篇文章不讨论你用的是哪个 AI 工具的优劣，也不做工具对比。它只做一件事：把加密货币交易机器人的提示词拆解成六个部分，每个部分配有可验证的检查点，提交前还要过五层审核。

第零层：这个警报本身能发 webhook 吗？

写任何提示词之前，先确认你拿到的是指标警报还是策略警报。这决定了下面所有规则是否适用——如果警报类型本身就错了，再好的提示词也救不回来。

带 strategy. 前缀的占位符，只有在使用策略创建的警报中才有效；在指标警报中使用会替换为空值，不会报错。这是从官方定义推导出的结论，不是 TradingView 明确写出来的一句话。

你要做的第一件事：去图表右上角打开「添加警报」对话框，选好条件后滚动到「通知」部分，看「脚本」字段。把 AI 生成的提示词粘贴进去，点创建。如果看到「未创建警报。请选择策略而非指标」，说明你拿到的是指标类型的警报。

加密货币交易机器人提示词的六段骨架：每段都有可验证的检查点

把 AI 生成的提示词拆成六个部分，每个部分独立可验证。你不需要一次性写完所有内容，可以逐段跟 AI 确认，每段都要求它「给我具体的示例输出」，而不是只看代码长什么样。

三个技术术语，首次使用时解释：

第一部分：识别目标——是指标还是策略？

先问自己：最终的交易数量由谁决定，TradingView 平台端还是执行端？这个答案决定了你应该用哪种类型的警报。

如果有 strategy.entry、strategy.exit 或 strategy.position_size，那就是策略，可以发 webhook。红色警报：只有 ta.xxx 函数或 plot/bgcolor 输出，没有下单相关逻辑——那是指标，不要发到 webhook。

向 AI 提问时给明确指令，不要模糊地问「这段代码好不好」：

提示 AI：
        这段代码粘贴到 Webhook 位置后，用哪个字段来决定下单数量？
        给我具体的示例。

第二部分：输入参数——价格从哪里读取，用哪根 K 线？

向 AI 确认的关键问题：价格从哪读取？使用哪根 K 线？是否等待 bar 收盘？这些细节决定了你的信号是「回测好看但实盘漏单」还是真正可用。

陷阱：很多提示词只写「使用收盘价」但没有明确指定用哪根 K 线——如果警报设置为「每个 bar 一次」，但代码中使用的是 close[1]（上一根 K 线的收盘价），下单时间就错了一根 K 线。

向 AI 确认：
        列出所有输入来源：
        - 是否使用 request.security？如果是，写出时间框架和前瞻设置
        - 是否使用 barstate.isconfirmed？为什么要等待确认？
        - 是否使用 input.xxx 让用户在图表上修改数值？全部列出来
        - 警报频率是 alert.freq_once_per_bar_close 还是 alert.freq_once_per_bar？

        给我具体的示例。

第三部分：输出定义——下单数量由谁决定？

核心问题：最终下单数量由谁决定，TradingView 平台端还是执行端？两边都能控制，但机制完全不同。

TradingView 端使用 strategy.position_size 控制数量——这是 Pine 策略在 TradingView 服务器上完全模拟出来的数字，与你真实账户毫无关系。执行端（webhook）使用 qty_type（百分比、固定数量、手动）加上 quantity 决定实际下单数量。

向 AI 要求以下格式的输出：

请按行输出：
        alert_time | price | qty | direction | strategy.position_size
        2026-09-28T10:30:00 | 65432.50 | 10 | long | 5000

        说明每个字段的来源：
        - price：用的是哪根 K 线的收盘价？如果用了 request.security，前瞻设置是什么？
        - qty：固定值还是用 strategy.percent_of_equity 计算出来的？
        - strategy.position_size：这是 TradingView 模拟的数字，与你真实账户无关。

第四部分：条件逻辑——什么时候触发，会不会漏单？

问：这些条件在实盘中会和回测时一样触发，还是因为「bar 没走完」而漏单？这是最常见的情况——回测看起来很好，但实盘不达标。

barstate.isconfirmed：如果条件使用现价，加上 and barstate.isconfirmed，防止 bar 还没走完就触发。request.security：跨时间框架调用时，写出前瞻和 barmerge 设置，避免未来数据泄露。关于这个前瞻陷阱的详细调试流程，见 request.security 前瞻陷阱：回测很好，实盘不匹配。

对于有疑问的条件，问 AI：「这些条件在实盘中会漏掉多少笔交易？barstate.isconfirmed 会阻挡几笔？」

第五部分：时间框架和数据源

跨时间框架调用是 Pine Script 最容易出错的地方。用高时间框架过滤趋势、低时间框架精确下单——听起来合理，但 request.security 的前瞻设置错了就会偷到未来数据。

向 AI 要求以下格式的输出：

列出所有 request.security 的使用，格式如下：
        request.security(timeframe, source, expression, lookahead, barmerge)
        - timeframe: 1D / 4H / 1H / 60 / 30 / 15 / 5 / 3 / 1 / 600
        - source: 同图表 / 不同图表 / 不同时间框架
        - lookahead: barmerge.lookahead_off（默认）或 barmerge.lookahead_on

        解释为什么需要跨时间框架：
        - 是用高时间框架的趋势来过滤？
        - 还是用低时间框架的数据做精确下单？

        用示例说明。

默认是 barmerge.lookahead_off（安全值），只有显式传入 barmerge.lookahead_on 才会引入未来数据。提示词应该说「默认是安全的，不需要特别设置」，而不是「你必须设置，否则会有未来数据泄露」。

第六部分：风险控制和边界

先把底线说清楚：TradingView 对 webhook 「送达 / 重试 / 延迟时间」**没有书面承诺**——这是推导，不是官方原话。

单一警报在 3 分钟内最多触发 15 次，超过就不再发送。策略回测运行在 broker 模拟器上，成交的是模拟订单，与真实账户无关。Webhook 延迟通常在 1–5 秒之间，但没有官方上限。

问 AI：「这段代码在 webhook 延迟 5 秒后下单，会和回测结果差多少？」这个问题没有标准答案，但提示中应该包含应对方法。

实战示例：BTC 网格交易机器人的提示词骨架

把六段结构应用到真实策略，每段的核心要求都整理成表格。你可以直接按照这个骨架去构建完整提示词：

向 AI 提问时，每段都要求「给我具体的示例」，而不是只看代码长什么样。完整提示词示例可以从这个表格逐段组装。

五层审核：提交前自检

提交前逐层过一遍。如果任何一层卡住，回去改提示词，不要强行通过：

• 第零层：这个警报是指标还是策略？如果是指标，整个提示词需要重写。
• 第一层：代码编译通过了，但能自动下单吗？差距在哪里？
• 第二层：订单数量由 TradingView 控制（strategy.position_size）还是执行端（webhook qty）？
• 第三层：request.security 的前瞻设置是什么？有没有用 barstate.isconfirmed？
• 第四层：Webhook 延迟、重试、漏单的风险在哪里？提示词有没有提到应对方法？

上面提到的观察值（编译成功率约 95%、能自动下单的比例约 30–50%、Webhook 延迟通常 1–5 秒）会因警报类型、执行端配置和交易所响应速度而有很大差异。提示词应该要求 AI「给我具体的示例」，而不是只看代码长什么样。

常见问题

还有两个常见问题：

本文不构成投资建议。加密交易风险极高，请先评估自己的风险承受能力再行动。