我做了半年 Polymarket BTC 5分钟交易机器人后，发现真正难的不是预测方向

做自动交易之前，我曾经认为，一个交易机器人的核心问题很简单：

能不能正确预测下一段行情是涨还是跌？

如果预测准确率足够高，那么剩下的事情似乎只是连接交易 API、下单，然后等待结果。

但在持续开发和测试一个 Polymarket BTC 5分钟 Up/Down 自动交易系统之后，我越来越觉得：

“预测方向”可能只是整个交易系统里最显眼的一层，却不是最难的一层。

真正困难的是：

当一个信号出现以后，系统应该如何判断这一次到底值不值得交易？

这也是我现在开发 PolyNexus 时越来越重视的一个原则：

Signal ≠ Trade

一个信号，不应该自动等于一笔交易。

---

一、BTC 5分钟市场看起来简单，实际上非常适合暴露系统问题

Polymarket 的 BTC 5分钟 Up/Down 市场，从表面上看非常直接。

每一个窗口只有两个结果：

• Up

• Down

时间也只有 5 分钟。

这很容易让人产生一种错觉：

只需要做一个分类模型，预测 Up 或 Down 就可以了。

但真正开始做系统以后，会发现问题远远不止这些。

例如：

• 当前找到的是不是正确的市场？

• 行情数据有没有中断？

• 数据是否已经过期？

• 信号出现以后，市场环境有没有改变？

• 多个判断同时出现时应该相信谁？

• 当前仓位应该是多少？

• 账户余额是否允许交易？

• 当前盘口价格是否仍然值得成交？

• 订单到底有没有真正成交？

• 部分成交怎么办？

• 网络或者 API 出错以后怎么恢复？

• 程序重启以后，之前的状态还能不能继续？

一个方向判断即使是正确的，只要其中任何一个环节出了问题，最后的实盘结果都可能完全不同。

所以后来我逐渐把这个项目从：

“BTC 方向预测机器人”

重新理解成：

一套围绕 BTC 5分钟市场运行的完整自动交易系统。

目前公开版本已经覆盖市场发现、数据检查、信号判断、状态管理、仓位、风险控制、订单执行、成交跟踪、结算、日志和运行恢复等多个环节。(GitHub)

---

二、真正的交易流程，比“预测 → 下单”长得多

如果把一个简单的交易 Bot 写成流程，大概是：

获取 BTC 数据
    ↓
判断 Up / Down
    ↓
下单

但我现在的系统更接近：

发现当前 BTC 5m 市场
        ↓
检查数据连续性和新鲜度
        ↓
生成候选判断
        ↓
结合历史状态和当前市场环境复核
        ↓
KEEP / ADJUST / STOP
        ↓
确定最终方向
        ↓
计算仓位
        ↓
账户和执行风险检查
        ↓
允许交易 / 阻止交易
        ↓
发送订单
        ↓
跟踪成交、失败或部分成交
        ↓
等待市场结算
        ↓
更新状态
        ↓
进入下一个 5 分钟窗口

这两个流程看起来只是多了几个步骤，但它们对应的是完全不同的设计思想。

前一种系统实际上认为：

只要信号成立，就应该交易。

后一种系统则把两个问题拆开：

第一，方向是什么？

以及：

第二，现在是否值得为这个方向承担风险？

我越来越认为，第二个问题至少和第一个问题一样重要。

---

三、交易机器人必须学会“不交易”

这也是我最近很关注的一个问题。

很多人评价一个交易机器人时，很自然会关注：

• 胜率多高？

• 一天交易多少次？

• 捕捉多少机会？

但实际研究下来，我开始越来越重视另一个数字：

它拒绝了多少次交易？

因为市场不会永远处在适合某一种逻辑的环境里。

相同的价格变化，发生在：

• 长时间低波动之后

• 连续高波动期间

• 震荡噪声环境

• 突然发生结构变化的时候

意义可能完全不同。

因此，一个候选信号出现，并不意味着系统必须执行它。

最终结果可以是：

KEEP
保持当前判断

ADJUST
调整当前候选

STOP
不参与这个窗口

PolyNexus 当前公开历史回放中，18,633 个历史信号里有 348 次最终被系统 STOP，占约 1.87%。(GitHub)

这个比例本身并不是重点。

真正重要的是系统设计里的这个思想：

NO TRADE 也是一种合法的决策。

对于自动交易系统来说，“什么时候不要交易”，可能本身就是策略的一部分。

---

四、我越来越不相信“一个漂亮的回测数字”能说明全部问题

这是开发这个项目以后，我变化比较大的另一个观点。

很多量化研究最后会变成：

调整参数
↓
跑回测
↓
胜率提高
↓
继续调整
↓
找到一个漂亮数字

这样做最大的问题，是我们很容易在不知道的情况下，把历史数据里的偶然现象学进去。

PolyNexus 当前公开的历史代码回放区间为 2021-09-01 至 2026-09-01。

公开统计中：

• 历史信号：18,633

• 执行统计：18,285

• STOP：348

• 历史执行胜率：63.75%

• 最长连续亏损：8

统计采用固定 +4 / -5 的标准化评分体系。(GitHub)

但我并不会把：

63.75% historical win rate

直接理解成：

实盘一定可以获得对应收益。

这是两个完全不同的概念。

原因很简单。

历史回放主要回答的是：

如果当前这套规则按照历史顺序运行，它的方向判断表现如何？

而真实交易还多了非常多变量，例如：

• Polymarket 的真实成交价格

• 买卖盘流动性

• 手续费

• 滑点

• 网络延迟

• API 状态

• 部分成交

• 下单失败

更重要的是，历史行情本身曾经参与过策略研究，因此整个五年区间不能被包装成一段完全没有接触过的纯 out-of-sample 数据。项目公开报告也明确保留了这个限制。(GitHub)

所以我现在越来越倾向于问：

这个回测到底证明了什么？

而不是：

这个回测数字看起来够不够漂亮？

---

五、没有“偷看未来”，也不代表没有过拟合

这是一个很容易被忽略的问题。

量化开发里，我们经常会检查：

代码有没有使用未来数据？

当然，这是必须检查的。

但即使完全没有 look-ahead bias，也仍然可能产生过拟合。

举一个很简单的例子。

假设最近一段行情里，某种情况连续导致策略亏损。

于是我找到一个规则：

如果出现条件 X，就不要交易。

重新回测以后发现：

• 最近亏损少了

• 胜率提高了

• 回撤也改善了

这个规则看起来非常好。

但问题在于：

我之所以想到 X，本身就是因为我已经看到了最近这段亏损。

因此真正需要研究的不是：

X 能不能修复最近的数据？

而是：

X 有没有更稳定、更普遍的解释？

这也是为什么我现在越来越重视不同时间区间的验证、逐事件回放，以及新规则对原有历史决策有没有产生意外改变。

---

六、Research Code 和 Production Code 必须是同一个逻辑

这可能是整个项目里最“软件工程”的一个问题。

很多策略在研究阶段表现很好，但真正进入生产代码后会发生各种微妙变化：

Backtest:
A → B → C

Production:
A → B' → C

表面上看，两边的最终收益可能差不多。

但实际上，它们已经不是同一个策略了。

因此我现在认为，验证生产代码不能只看：

总胜率是不是差不多？

还应该尽可能进行 event-by-event replay。

也就是逐个历史事件比较：

时间
市场窗口
候选来源
基础方向
后置处理
最终方向
STOP 状态
最终结果

如果一次代码修改理论上只应该影响某个局部模块，那么历史中其他没有被修改的事件最好仍然保持完全一致。

这其实和普通软件开发里的 regression testing 很像。

只不过这里 regression 的对象不是 UI 或 API，而是：

交易决策本身。

---

七、策略和交易系统，其实应该被分成三个层次

做了越来越多工程以后，我现在比较喜欢把一个自动交易系统拆成三个部分。

第一层：Research

研究层负责回答：

市场里到底有没有可重复的结构？

包括：

• 历史研究

• 不同时间区间表现

• 稳定性

• 市场状态变化

• 过拟合检查

• 新规则是否值得接受

这一层的工作不是下单。

而是尽量不要欺骗自己。

---

第二层：Decision

这一层负责：

现在到底应该做什么？

可能有多个候选判断。

系统需要结合：

• 当前市场环境

• 已经发生的状态

• 候选之间的冲突

• 当前条件是否仍然成立

最终只产生一个结果：

UP
DOWN
NO TRADE

具体策略规则、阈值和内部逻辑当然不会公开，因为这是系统真正的策略部分。

---

第三层：Execution

最后才是：

如何真正把这个决定变成一笔交易？

这里需要处理：

• 市场发现

• 账户余额

• 仓位计算

• 风险限制

• Order Type

• 成交确认

• 部分成交

• API 异常

• Settlement

• 状态持久化

• 重启恢复

这也是为什么我现在越来越觉得：

一个交易机器人和一个交易策略，是两种不同的东西。

策略只是系统的一个模块。

---

八、为什么我还在继续研究 BTC 5分钟？

BTC 5分钟是一个非常有意思的实验环境。

每五分钟，一个新的窗口重新开始。

新的价格行为。

新的市场环境。

新的结果。

这意味着反馈速度非常快。

同时也意味着：

策略失效、环境变化、执行问题，都会更快暴露出来。

刚开始做这个项目时，我最关心的问题是：

哪个策略效果最好？

但现在我更经常问的是：

如果市场开始变化，我能多快发现原来的方法正在失效？

再往后，则是：

一个交易系统能不能不仅发现变化，而且对变化作出合理反应？

这可能也是我接下来很长一段时间都会继续研究的问题。

---

写在最后

开发 PolyNexus 到现在，我对自动交易最大的认知变化可能就是：

以前我认为：

好的交易机器人 = 好的预测策略。

现在我认为：

好的交易系统 = 研究 + 决策 + 风控 + 执行 + 验证 + 对“不确定”的处理。

一个信号可以是正确的。

但它未必值得交易。

一个历史策略可以表现很好。

但它未必能够适应今天的市场。

一个回测数字可以非常漂亮。

但它未必意味着实盘结果。

所以我现在越来越喜欢一句非常简单的话：

Signal ≠ Trade.

预测市场会往哪里走，只是第一步。

真正困难的是：

什么时候应该相信它，什么时候应该调整，什么时候应该什么都不做。

这才是我现在真正想解决的问题。

---

项目：PolyNexus / Polymarket BTC 5m Automated Trading System

GitHub：naka2027/polymarket-bot

研究博客：Naka Research

本文讨论的是个人量化研究与软件开发过程，不构成投资建议。历史回放结果不代表未来表现，自动交易存在本金损失风险。