HIBT 事件合约策略：日赚 1,000–2,000 U，10 天后失效被封

先说结论，因为这篇的重点不在”我赚了多少”：

---

一、肉眼发现的异常：HIBT 的 GCEI 盘口”太规律”

起点很偶然。那段时间我在做事件合约，在一个小所（HIBT）上看行情时， 注意到了 GCEI/USDT 这个交易对（GCEI 是一个 Web3 算力协议代币）。

它的盘口有一种一眼就能看出来的不自然：

• 价格在一个很窄的区间里来回走，像被一只手按着
• 挂单与撤单的节奏感很强
• 波动不是随机的——它总是回到某个位置附近

做久了会有这种直觉。但直觉不能下注，它只能用来决定去哪看。

平台的事件合约界面。GCEI 是这个平台上唯一值得研究的标的—— 左侧一串对比项（BTC、ETH、XAUT、XAG、CLUSDT、SOL、BNB、NAS100、A50、SSE）的赔率都在 70%–85% 之间，但只有 GCEI 的盘口呈现出那种”被按住”的形态。

二、先解决执行

研究要回答的是”值不值得下单”，但在那之前得先能下单。

事件合约的下单入口在网页端，手动点单的节奏跟不上午夜边界的信号， 所以这部分必须自动化。我用的是一套现成的事件合约自动下单工具 （某位群友开发，非我本人作品），跑了两个多月，稳定性够用。

工具的工程细节不属于本文范围，这里只说明一件事： 我把它当作一个黑盒执行器——它负责把信号变成订单， 但它对”这个信号有没有优势”这件事一无所知。那是我的工作。

三、数据：从”总是回来”到”1 秒一次”

工具解决了”怎么下单”，但我的问题是”值不值得下单”。 而网页行情刷新太慢，根本看不出节奏。

所以我做的第一件事，是搭一套自己的数据采集：直接连平台的 WebSocket 行情推送， 把秒级 tick 全部落盘（接口地址在工具的实现里可以找到）。

关键变化是信息密度：

观察项	网页/常规 API	逆向 WS 后
更新频率	数秒一次且被合并	约 1s 一次
价格	只见中间价	逐笔 tick，可还原到秒
撤单行为	不可见

这一步是整个项目的转折点。 因为”1s 一次的行情”意味着一件事： 如果价格确实在均值附近做回复运动，那么在秒级粒度上， 回复过程就是可观测、可定量、可交易的。 粗粒度下它只是一个模糊的”总是回来”，细粒度下它才是一个能被证伪的过程。

四、搭一套数据管线

有了数据源，接下来是笨功夫。我搭了一套完整管线，让它 24/7 自己跑：

WS 采集器  ──►  raw JSONL  ──►  每日 01:01 gzip 轮转（保留 90 天）
（秒级 tick）                      │
                                  ▼
                            每日 02:30 重建 bar + 出统计分析报告
                                  │
                                  ▼
                            网页面板（实时 K 线 + 布林带 + 采集状态）

几个当时做了、后来证明很值的决定：

• 同时录 BTC 和 ETH 作为对照。没有对照，你无法区分”这是 GCEI 的特性” 还是”这是整个市场的普遍行为”。这是整个项目里最重要的一次性设计决定。
• 采集器用 systemd 常驻（开机自启、崩溃自动拉起），面板同理。
• 转储前先压缩：原始 JSONL 一天约 156 MB，gzip 后约 11 MB（压缩比 ~14.7×）。 不压缩一个月 5 GB，压缩后约 0.5 GB。

实际跑出来的规模（跑了 28 天后回看）：

指标	实测值
累计推送帧数	4,225 万帧
1 分钟 bar	51,240 根
重连次数	84 次
无故障连续运行	28 天以上

五、统计验证

这是最关键的一步。均值回归不能靠”看图觉得它会回来”来确认——图上看什么都像回归。 必须做可以证伪的检验。

事件的真实结算语义（这是前提，错了全错）

这个平台的事件合约是：押 N 分钟后的价格相对入场价是涨还是跌。

入场价 = 决策时刻的最新 tick
结算价 = 入场时刻 + N×60 秒整前最后一笔 tick
赔率   = +0.8 / −1.0  →  盈亏平衡胜率 55.56%

四个检验

④ 反向检验：它什么时候不回归

只验证”平均成立”是自欺，因为这类策略爆仓永远发生在”不回归”的那一次。 所以我还专门找了反例：哪些时段自相关转正了？哪些时段的偏离超出历史极值？

六、事件合约策略：fade 短期动量

验证通过后的策略逻辑很朴素：在分钟边界，fade 过去 30 秒的极端走势。

信号条件：过去 30s 的累计涨跌落在历史分位的极端区间
  · 刚跌到低位 → 押 UP（赌回归）
  · 刚涨到高位 → 押 DOWN（赌回归）

入场：分钟边界 + 延迟 2 秒（模拟真实下单延迟）
结算：入场后 1 / 3 / 5 / 10 分钟

为什么加 2 秒延迟：这是为了确认”这个边缘扛不扛得住真实执行的延迟”。 如果一个边缘必须在零延迟下才成立，它就不是可交易的边缘。 实测结论是 2–3 秒延迟影响很小，边缘扛得住。

我还做了两个变体作为对照：dual（5 秒与 30 秒窗口同向极端才开仓）、 dualloc（在 dual 基础上再加位置过滤）。

七、结果：优势真的存在

下面是实盘口径（含 2 秒延迟）的影子信号结算结果。 统计区间 2026-08-13 ~ 08-22，共 10 天：

指标	数值
已结算单数	15,130
胜率	63.75%
盈亏平衡线	55.36%
累计 PnL	+2,304 单位
相对 50% 的显著性	z = 33.84（p < 0.001）
相对平衡线的显著性	z = 20.66

这不是运气。 z = 33.84 意味着如果这真是抛硬币， 出现这个偏离的概率低到在宇宙寿命内都不会发生一次。

按结算档位拆开，还有一个很漂亮的结构：

结算档位	n	胜率	平衡线	优势
1 分钟	7,122	62.12%	55.87%	+6.25pp
3 分钟	3,479	63.44%	55.56%	+7.88pp
5 分钟	2,665	65.48%	54.64%	+10.84pp
10 分钟	1,864	68.13%	54.05%	+14.08pp

胜率随持有时间单调递增。 这个结构本身就在告诉你机制是什么： 偏离越大、给回归的时间越长，回归完成得越充分。

两个方向都成立，没有方向性偏差：

DOWN 信号  n=7,740  胜率 62.33%
UP   信号  n=7,390  胜率 65.25%

逐日表现（10 天全部为正）：

日期	单数	胜率	PnL
08-13	871	59.93%	+63.4
08-14	1,021	66.11%	+190.7
08-15	1,346	65.01%	+233.3
08-16	1,622	66.03%	+313.5
08-17	1,503	65.07%	+266.5
08-18	1,621	62.80%	+221.9
08-19	1,850	63.57%	+279.1
08-20	1,912	65.38%	+351.6
08-21	1,770	61.47%	+199.9
08-22	1,614	61.52%	+184.6

十天，没有一天亏损。按当时的仓位，这对应每天大约 1,000–2,000 USDT。

下面是平台账户页自己记录的收益曲线。它和上面从原始数据算出来的数字互相独立—— 一个是平台记账，一个是我从逐笔 tick 重算，两者指向同一个结论：

自己后台的收益曲线，胜率 63.7%，累计 +13,573.2 U。账户名显示为「云顶之弈（被禁）」。

横轴是平台的滚动时间窗口（约 13 天），不代表实际盈利只发生在这段。 后面第八节会说明：这 13,573 U 的形态（前期稳定爬升、后期转平）与我独立重算的数据是一致的。 按约 10 天的盈利期折算，日均约 1,300 U，与当时的实盘感受（1,000–2,000 U/天）吻合。

注意右上角那行小字：「账号被封（历史数据不可用）」。 先记住它，第十一节再回来看。

最初的计划是”别太狠”——这个细节到第十一节会显得很有意味。

八、然后它消失了：优势衰减的实测数据

从 08-23 开始，同样的策略、同样的参数，数字变了：

时期	n	胜率	平衡线	PnL	显著性
08-13 ~ 08-22	15,130	63.75%	55.36%	+2,304	z = +33.84
08-23 起	52,061	53.17%	55.31%	−2,003	z = −9.76

两件事都极度显著。 这不是”从有优势变成噪声”—— 53.17% 相对 55.31% 的平衡线是 z = −9.76， 意味着后期它在统计上确实是个亏钱策略，而不是回到了随机。

换句话说：这不是优势消失了，是优势反向了。

事后回看我做对了什么：我保留了完整的逐日记录， 所以能在它失效的第一周就看出来——而不是继续亏两个月才怀疑策略。

做错了什么：看到衰减之后的第一反应是”调参数”， 而不是”接受它已经死了”。这件事浪费了一些时间。

九、账号被封——小所与事件合约平台的对手方风险

我事前有认知，但程度远远不够：

• 我把它当成”需要注意的风险”，而不是”随时会发生的终止条件”
• 我设计了延迟模拟、仓位上限、健康度监控—— 但我的风控里没有一个字段叫”平台随时会没收本金”
• 我更没有为”本金被扣”准备任何应对

这是这次真正的教训。它跟策略无关，跟市场无关。

十、当时的多账户分摊结构（以及我因此多赚了多少）

原帖里那句”跟几个群友一起设计了个策略”，实际落地的组织形式是多账户。

原因很直接：在一个价格由平台维持的交易对上持续盈利，单账户的被关注度会快速上升。 所以当时开了多个账户，用上下级关系挂成一套结构：

HIBT 后台的账户清单。代理商／直客、上级 UID、各自的开仓本金与胜率都列在里面。

注意这张表里两个细节：

• 账户胜率差异很大（47% 到 70%），不是每个账户都在赚钱 —— 这正是”分摊”的含义， 不是所有账户用同一个信号、同一个节奏
• 上下级关系是显式记录的（上级 UID 一列），这套结构在平台后台是可查的

多账户还带来一项策略本身之外的收入：返佣。

HIBT 返佣后台的 90 天趋势。「我的佣金」口径下累计 38,191.7662。

这里还有一个我必须写出来的事实：返佣让这个项目的实际收入高于策略本身的盈亏。 也就是说，我当时有动机去开更多账户、做更大流水—— 而这个动机恰好和”不要引起对手方注意”是冲突的。

事后看，多账户本身就是一种信号：它让平台更容易识别出”这是一组协同操作的账户”。 我以为自己在分散风险，实际上可能在集中暴露。

十一、平台是怎么说这件事的

下面是我和平台客服的实际对话。它比我的任何分析都更直接地说明了这类平台的运行逻辑：

2026-09-04 的客服对话。

看这段对话时，注意它的逻辑结构——这比情绪更重要：

1. 平台不需要指控你违规，只需要给你打一个标记（“风险账号”）
2. 标记一旦打上，出金通道关闭，而且和你的盈亏无关
3. 理由是自洽的：在一个价格由平台自己维持的交易对上，你赚的就是它亏的
4. 所以”盈利”这件事本身，就构成了它标记你的充分理由

我事前以为风险是”平台可能跑路”。 实际发生的风险是：平台合法地、按规则地、平静地，把你赚到的钱留在它那里。

这两件事的应对方式完全不同。前者靠分散，后者靠根本不参与。

十二、如果重来一次：动手前的定级表

我会在写第一行代码之前先填这张表：

维度	问题	这次的答案
收益来源	钱从谁的口袋来？	平台自己 ❌
平台动机	它为什么允许你赚？	它不允许 ❌
提取难度	出金是否顺畅？
本金暴露	最坏情况损失多少？	全部本金 ❌
可验证性	盈亏能否被第三方核对？	不能 ❌
优势稳定性	有无衰减监控？	有 ✅（唯一做对的）

六个维度里四个负分。 这个项目从一开始就不该以”能赚多少”来评估， 而应该以”这笔钱我能不能接受全部损失”来评估。

十三、可复现的部分：事件合约均值回归的检验清单

策略已经失效，不值得复现。但方法论值得：

1. 肉眼的”不自然感”是有效信号——但它只能决定你去哪里做检验，不能作为交易依据
2. 换更细的粒度看——很多”看不懂”的行情，在秒级粒度上是可解释的过程
3. 先算清盈亏平衡点——+0.8/−1.0 的平衡点是 55.56%，不是 50%
4. 录对照标的——BTC/ETH 对照能区分”个别现象”和”市场普遍行为”
5. 用真实盘口做 walk-forward，包含执行延迟——回测数字不能替代这件事
6. 保留全部逐日记录——这是你唯一能在优势衰减时及时发现的工具
7. 优势会消失，而且可能反向消失——把”监控衰减”当作策略的一部分来设计
8. 动手前先给对手方风险定级——而不是等到被封号才想起来

相关阅读

这件事的教训可以拆成两条独立线索，我都单独写了：

• 币安事件合约 API：能自动下单，但 55.56% 那道线还在 —— 接口层怎么做，以及为什么”能下单”和”该不该下单”是两件事
• 事件合约量化研究纪实：四条被否掉的路，和一个 56% 的边际 —— 十条研究军规 + 八个被否掉的方向。如果要从头做这件事，先看这篇

最后

这条研究跑到最后，最有价值的产出不是那 +2,304 单位，而是三个数字：

63.75%  —— 优势存在时它是多少（z = 33.8）
53.17%  —— 优势反向后它是多少（z = −9.8）
10 天   —— 从第一到第三之间隔了多久

我把它写出来，是因为网上绝大多数策略文章只给你看第一个数字。 而第二个和第三个，才是决定你会不会亏钱的东西。

这一策略的实盘截图

来源：交易所后台

不可独立验证以下为交易所后台截图。交易所后台只有图片，没有 API、也没有可分享的页面，因此这些图无法被独立回溯核对——它们说明「我在做」，但不构成可验证的业绩证据。