布欧的量化日记

币安 L2 盘口数据完全指南：免费能拿到什么、自录要怎么写、怎么验证数据是真的

Thu, 17 Sep 2026 00:00:00 GMT

import Callout from ’@/components/Callout.astro’;

做微观结构研究，第一件事永远是搞清数据的边界。这篇把币安公开的盘口数据拆开讲清楚： 哪些免费、哪些必须自己录、以及怎么确认你手上的数据是真的。

文里的目录结构、覆盖范围、文件体积、表头字段都是实测抓下来的，不是抄文档。

一、先明确你想要的是哪种”盘口数据”

市面上”L2 数据”这个词被用得很宽，但至少在三种不同粒度上被混用：

粒度	内容	典型来源
流动性分布	每分钟各价格带（±1%…±5%）的累计挂单量	币安官方归档 `bookDepth`
最优价	每次变动时的 best bid/ask 及数量	币安 `bookTicker`
逐档增量	每一个价位的每一笔增删（可完整重建订单簿）	自录 / 商业数据商

这三者对研究能回答的问题完全不同。 拿第一种去做队列位置研究，会直接得出错误结论。

币安官方归档里的 `bookDepth` **不是逐档订单簿**，而是"流动性分布快照"。实测 2024-05-01 的 BTCUSDT 文件，表头是：

timestamp,percentage,depth,notional
2024-05-01 00:00:07,-5,6459.27900000,382235430.86890000
2024-05-01 00:00:07,-4,5338.30600000,317281126.54950000

即”每分钟、每个百分比价格带的累计挂单量与名义价值”，一天 28,801 行（约 1440 个时间点 × 20 个档位）。

二、币安官方归档里到底有什么（实测）

数据在 data.binance.vision（S3 兼容），我实测列了 U 本位合约的目录：

日更目录（`/data/futures/um/daily/`）

aggTrades          ← 聚合成交
bookDepth          ← ★ 流动性分布（本文重点关注）
bookTicker         ← 最优价变动
indexPriceKlines
klines
markPriceKlines
metrics            ← 持仓量等指标
premiumIndexKlines
trades             ← 逐笔成交

月更目录（`/data/futures/um/monthly/`）

aggTrades   bookTicker   fundingRate      ← 月更多出资金费率
indexPriceKlines   klines   markPriceKlines
premiumIndexKlines   trades

文件组织与体积（BTCUSDT 实测）

数据类型	单文件体积	备注
`bookDepth`	约 452 KB / 天	一天一个 zip，含 `.CHECKSUM`
`aggTrades`	1.4 MB → 52.7 MB	随时间增长，早期到近期差 37 倍
每个 zip 附带	`*.CHECKSUM`	可用于校验下载完整性

我实测统计了目录下的标的数量，**差异很大**：

aggTrades    ~1000 个标的
trades       ~1000 个标的
metrics      ~1000 个标的
bookDepth     ~975 个标的
bookTicker    ~315 个标的   ← 只有前者的三分之一

所以”币安有全部标的的数据”是错的。 如果你选的标的不在某个数据类型的列表里，你得先换标的或换数据源，而不是写完代码才发现拿不到数据。

（上述数字取自归档列出的前 1000 个 key，是采样值而非精确全量。）

三、免费数据能回答什么、不能回答什么

这是本文最该记住的一张表：

问题	免费数据够吗	为什么
某时刻流动性在价格上如何分布	✅	`bookDepth` 就是干这个的
大额订单的滑点估算	✅ 粗略	用 `notional` 按价格带累积
最优价变动频率与价差	✅	`bookTicker`
成交流的方向（主动买/卖）	✅	`aggTrades`
持仓量 / 资金费率变化	✅	`metrics` / `fundingRate`
某一价位的挂单队列位置	❌	需要逐档数据
订单流失衡（OFI）	❌	需要每一笔增删
挂单撤单行为	❌	免费数据里没有撤单事件
盘口重建与做市仿真	❌	需要 `incremental_book_L2`

免费数据覆盖了"**看得见的盘面**"，但覆盖不了"**订单簿的微观行为**"。后者必须自录（或买商业数据）。

四、自己录一份逐档 L2：完整方案

上一节表里那四个 ❌，只能靠自录解决。下面是我建议的架构，以及最容易出错的那个地方。

4.1 为什么必须”快照 + 增量”拼接

币安 WebSocket 的深度流给的是增量更新，不是完整盘口：

depth@100ms  →  每个价位的数量变化（新增/修改/删除）

所以你无法”只订阅 WebSocket 就得到订单簿”。必须：

1. 先订阅 WebSocket 增量流，把收到的消息【缓存起来】
2. 再通过 REST 拉一份全量快照    /fapi/v1/depth?symbol=BTCUSDT&limit=1000
3. 用快照的 lastUpdateId 对齐缓存里的增量，丢弃快照之前的
4. 之后逐条应用增量，维护本地订单簿

顺序很重要：必须先订阅再拉快照。反过来做，中间那段增量就丢了。

4.2 ★ 唯一不能省的校验：序列号连续性

这是整个采集器里最关键、也最容易被跳过的一步。

币安的深度增量消息里带两个字段：

U  = 本条消息的第一个更新 ID（first update id）
u  = 本条消息的最后一个更新 ID（final update id）

正确的连续性判定是：

前一条的 u + 1 == 当前条的 U     → 连续，可以应用
否则                            → 中间丢包了，必须丢弃本地簿、重新拉快照

如果跳过校验、无条件应用增量，**丢包不会报错**——你的程序照常运行，但本地订单簿会**静默失真**：你以为某个价位有 12 个 BTC，实际只有 2 个。

这类失真最可怕的地方是它不产生异常。你的回测照常跑出结果，只是那个结果是错的。按你研究里的说法：这不是”数据不好”，是”数据在骗你”。

4.3 采集器骨架

import asyncio, json, gzip, time, aiohttp, websockets
from datetime import datetime, timezone

SYMBOL = "BTCUSDT"
WS = f"wss://fstream.binance.com/ws/{SYMBOL.lower()}@depth@100ms"

async def fetch_snapshot(session):
    """REST 全量快照 —— 必须返回 lastUpdateId"""
    url = f"https://fapi.binance.com/fapi/v1/depth?symbol={SYMBOL}&limit=1000"
    async with session.get(url) as r:
        return await r.json()

class Book:
    """本地订单簿。只保留增量应用与连续性校验，不做撮合。"""
    def __init__(self):
        self.bids, self.asks = {}, {}
        self.last_u = 0
        self.resyncs = 0

    def load(self, snap):
        self.bids = {p: q for p, q in snap["bids"] if float(q) > 0}
        self.asks = {p: q for p, q in snap["asks"] if float(q) > 0}
        self.last_u = snap["lastUpdateId"]

    def apply(self, msg) -> bool:
        """
        返回 True 表示应用成功，False 表示检测到断档（调用方需重新同步）。
        ★ 这个函数是整个采集器的核心。
        """
        U, u = msg["U"], msg["u"]
        if self.last_u and U > self.last_u + 1:
            # 中间缺了消息 —— 不能假装没事
            self.resyncs += 1
            return False
        if u <= self.last_u:
            return True          # 过期消息，直接忽略
        for side, key in ((self.bids, "b"), (self.asks, "a")):
            for p, q in msg[key]:
                if float(q) == 0:
                    side.pop(p, None)
                else:
                    side[p] = q
        self.last_u = u
        return True

async def main():
    book = Book()
    out = gzip.open(f"{SYMBOL}-{datetime.now(timezone.utc):%Y%m%d}.jsonl.gz", "at")
    async with aiohttp.ClientSession() as session:
        while True:
            try:
                async with websockets.connect(WS, ping_interval=20) as ws:
                    # ★ 先订阅，再拉快照（顺序反了会丢增量）
                    pending = []
                    snap = await fetch_snapshot(session)
                    book.load(snap)
                    print(f"onboarded at lastUpdateId={book.last_u}")
                    async for raw in ws:
                        msg = json.loads(raw)
                        if not book.apply(msg):
                            # 断档：重新同步，而不是继续用失真的簿
                            snap = await fetch_snapshot(session)
                            book.load(snap)
                            continue
                        out.write(json.dumps({
                            "ts": int(time.time() * 1000),
                            "E": msg.get("E"), "U": msg["U"], "u": msg["u"],
                            "b": msg["b"], "a": msg["a"],
                        }) + "\n")
            except Exception as e:
                print(f"reconnect: {type(e).__name__}: {e}")
                await asyncio.sleep(2)

asyncio.run(main())

代码里刻意保留的两点：

apply() 返回 False 时必须重新拉快照，不能继续 —— 这是丢包恢复的唯一正确姿势
每行都记 U/u，下游可以独立复核连续性，不用信任采集时的判断

4.4 体积估算与运维

项	估算
单标的深度流消息频率	币安 `@depth@100ms`，最多 10 条/秒
原始 JSONL	约 100–300 MB/天/标的（视行情活跃度）
gzip 后	约 10–30 MB/天/标的（压缩比通常 8–15×）
一年（2 标的，压缩后）	约 7–22 GB

运维要点（和你做其他采集一样）：

systemd 常驻 + 崩溃自动拉起
每日 gzip 轮转，保留期按磁盘算
监控 resyncs 计数 —— 它突然变多说明网络或代码有问题，比看进程活着更有用
落盘前先写内存缓冲，避免高频 IO

五、怎么验证一份 L2 数据是真的

这一节与数据来源无关——不管你是自录还是买来的，都该做这三步。

5.1 内部自洽：增量重建 vs 定时快照

用增量流重建出 t 时刻的订单簿
再拉一份 t 时刻的 REST 快照
逐档比对

完全一致才能证明增量没丢。 有任何一档不同，先查是不是漏了消息。

5.2 跨数据源交叉：成交量的三方对齐

同一个时间段，用三种方式算成交量：

trades      逐笔成交求和
aggTrades   聚合成交求和
klines      1 分钟 K 线的 volume 字段

三者应当一致（aggTrades 与 trades 的差异仅在于聚合同一价格同一时刻的成交）。对不上说明数据有问题。

5.3 合理性检验：不该出现的状态

检查	期望
best bid ≥ best ask	不应出现（出现了说明簿已损坏）
任何价位数量 < 0	不应出现
时间戳单调不回退	应满足
单条消息跨越的价位数量	不应异常巨大（可能是快照混进了增量流）

它们不依赖任何外部权威，**只用数据自己就能证伪**。

这也是我对一份数据的最低要求：如果它无法被独立验证，它就不该被用来支撑结论。

六、免费数据怎么拿

币安官方归档是公开的，可以直接 HTTP 下载，不需要 API key：

# 目录列表（S3 兼容，返回 XML）
https://s3-ap-northeast-1.amazonaws.com/data.binance.vision?prefix=data/futures/um/daily/bookDepth/BTCUSDT/

# 单文件直链
https://s3-ap-northeast-1.amazonaws.com/data.binance.vision/data/futures/um/daily/bookDepth/BTCUSDT/BTCUSDT-bookDepth-2024-05-01.zip

注意事项：

每个 zip 附带 .CHECKSUM，下载后务必校验（长跑批量下载时一定会遇到截断）
归档有延迟（通常 T+1 或更长），当天数据拿不到
目录列表分页返回，脚本遍历时要处理分页，否则只会拿到前 1000 个 key （我实测时就踩到这个：aggTrades/BTCUSDT 只列出 500 天，实际远不止）

七、这份数据能支撑哪些研究

有了它，下面这些文章里的方法才有数据基础（陆续补上）：

做市容量评估      ← 用 bookDepth 的 notional 估算各价位可承载量
滑点与冲击成本    ← 用 bookDepth 按价格带累积，或用自录的逐档簿
订单流不平衡      ← 需要自录的逐档增量 + trades
高频 vs 分钟级边际 ← 不同采样粒度下同一信号的表现差异

一个诚实的提示：如果你要做的是分钟级以上的研究，免费的 bookDepth + aggTrades + klines 通常就够了，不一定需要自录逐档 L2。自录的成本（磁盘、运维、数据校验）只在做微观结构研究时才值得。

本文所有目录结构、覆盖范围与文件体积均为实测结果，采集时间 2026-09-17。数据来源为币安公开数据归档。本文仅供技术交流，不构成投资建议。

事件合约量化研究纪实：四条被否掉的路，和一个 56% 的边际

Thu, 17 Sep 2026 00:00:00 GMT

import Callout from ’@/components/Callout.astro’;

它讲的是一套短周期事件合约策略在几年里怎么被搭起来、又怎么被一条条否掉的过程。

公开的是思路和方法，不是可以直接抄走的策略。文中所有数值都来自我自己的回测与前瞻记录，口径已在文中标注。

本文假设你已经知道事件合约的赔率结构与平衡点怎么算。如果不清楚，先看 [币安事件合约 API 说明](/strategies/binance-event-contract-api/)—— 那篇里算清了 **55.56%** 这个数字，它是本文所有结论的分母。

一、先看规则：难度写在合约条款里

这里要交易的是数字货币交易所的事件合约：一种超短周期的二元期权。

以 ETH 10 分钟档为例，规则简单到可以用一行说清：

t 时刻按当前价入场 → t+10 分钟按结算价结算
结算价 > 入场价：赢，得 +0.8 × 本金
结算价 < 入场价：输，亏 −1.0 × 本金

先算一个数。设胜率为 p，期望为 0.8p − 1.0(1−p) = 1.8p − 1。要期望为正：

p > 1 / 1.8 = 55.56%

55.56%，就是全部故事的分母。

这意味着：一个”胜率 54%“的策略在这里是稳定亏损的；一个”看起来有 56% 胜率”的策略，扣掉一点执行成本就可能归零。市面上大多数”我找到了 60% 胜率的指标”的说法，都死在这个数字上。

规则里还埋着三颗钉子

做这件事的过程里，我最深的体会是：先把合约条款读透，比急着写策略重要得多。 这三颗钉子是后来所有坑的根源。

第一颗：结算价不是现货价。

合约按交易所的指数价（多家交易所合成的价格）结算，而绝大多数人的数据和直觉都建立在现货 K 线上。同一批信号，用现货回测和用指数回测，胜率差大约 2 个百分点——正好是 55.56% 之上那点薄边的量级。

也就是说：一个用现货数据回测出来 56% 的策略，按真实结算口径可能只有 54%，是亏的。

第二颗：账户有并发上限。

这类平台的合约是”一单到期后再开下一单”的槽位制，可同时持有的仓位通常在个位数（我用的口径是 5）。所有”一天几百单”的回测，如果不复刻并发约束，都在骗自己。我为这个坑专门付过一次学费，后面会讲。

第三颗：入场时刻是能观测到什么的边界。

入场发生在某根 1 分钟 K 线的开盘时刻。那么在按下按钮的那一秒，你已经能看到这根 bar 的开盘价，但看不到它的最高、最低、收盘和成交量——那些要等 60 秒之后才存在。

这三颗钉子决定了后面所有方法的形状。我把它压缩成一句话写在研究守则第一页：

先保证这个数是真的会赢，再去想它能不能赢更多。

二、方法论：我最后留下的十条军规

研究时间越长，越会发现：真正值钱的不是某个因子，而是那套能持续否掉自己的流程。 下面这十条是踩坑踩出来的，每一条背后都有一次具体的翻车。

1. 因果性：把”事后才知道”翻译成”当下能知道”

这是最容易被忽略、杀伤力最大的一类错误。它不表现为”用了未来的收盘价”这种低级形态，而是藏在计数和序列里：

说法	能不能在入场那一刻确认？
“连续第 3 根触发”	✅ 能，第 3 次触发的那一刻就知道
“恰好有 2 个条件满足”	❌ 不能，得等所有条件都走完才知道
“这一段波动结束了”	❌ 不能，需要等后面不再发生
“取最后一个触发点进场”	❌ 不能，得知道后面没有新的触发

我用过一个 10 分钟就能做完的判别测试，非常有效：

**把"只取特殊点（最后一个 / 峰值 / 极值之后的第一根）"改成"每个普通点都取"，然后重算。**

如果胜率大幅崩盘，原来的结果就依赖未来信息。

这条测试后来帮我避免了一次几乎要上线的灾难（见第五节）。

2. 只允许用决策时刻已存在的数据

具体到 1 分钟事件合约：特征只能用 t−1 及更早的已收盘 bar，或者入场时确实能观测到的开盘价。所有滚动窗口、分位数、标准化参数都必须只依赖历史。

这条听起来是常识，但它的边界比想象的细： 滚动 z-score 的分母、分位数的阈值、regime 的分类边界，每一项都可能是泄漏源。

3. 滚动标准化，不用固定绝对阈值

加密市场的波动率、流动性和微观结构在几年里变化极大。 2021 年的”极端跌幅”和 2026 年的”极端跌幅”完全不是一个数值。

所以新因子一律默认先做因果滚动标准化（滚动 z-score、滚动分位）再设阈值，用”相对近期市场有多极端”替代”是否越过某个历史绝对数值”。

4. Walk-forward：训练、选阈值、评估，三段严格分离

我的标准做法：

用 ≤ 某年 的数据训练模型
用紧邻的下一段数据选阈值
再往后逐年滚动，评估完全没参与过选择的数据

任何”全样本选参数、再全样本评估”的结果，我直接当无效处理。

5. 密封 holdout 只看一次

留出一段完全隔离的数据，在开发阶段一次都不碰。整个系统组装完成、所有层都冻结之后， 端到端跑一次，无论结果好坏都记录在案。

这条规则的价值在于：它把”我可以再调一次”这个诱惑物理地移除掉了。

6. 参数平台 > 参数尖峰

如果一个因子的最优窗口是”恰好 15 分钟”，把窗口改成 12 或 18 就失效，那这个结果大概率是过拟合。我要求参数邻域内连续一片都能过线，孤立尖峰一律丢弃。

同理，阈值敏感度也要查：阈值在 0.60–0.70 全为正，和”只有 0.645 为正”，是两种完全不同性质的结果。

7. 方向分离：做多和做空是两个问题

这一点反直觉但非常重要。我一度把 UP 和 DOWN 混在一个组合里挖，结果一个亏损的方向被另一个方向的成交量掩盖了。

后来改成硬性规定：

UP 单独挖、单独评估、单独过门槛
DOWN 单独挖、单独评估、单独过门槛
只允许在最后的组合层合并
同一分钟两个方向冲突 → 默认跳过

而且接受”某一侧就是没有可用的策略”。不要为了对称而强行凑出一条空头线。

8. 回测必须复刻实盘约束

并发上限、同分钟同向去重、冲突跳过、真实结算价——这些不是”实盘细节”，它们会直接改变结论的量级。

我曾经算出一版非常漂亮的收益曲线，后来发现忽略了并发槽位；补上真实约束之后，结论完全改变。 回测跑的是策略，不是理想世界。

9. 多重比较要认账

如果你试了 100 个因子，其中最好的那个表现优异，这个”优异”里有多少是运气？

我的做法是：

报告同一族参数的整体表现，而不是只报最好的那个点
用随机零假设对照（把标签打乱重跑同样的流程），看真实结果比随机好多少
明确写出”这个结果我看了几次”。同一个边际被反复观察 11 次，不等于 11 个独立证据

10. 每次研究都必须留下可复现的报告

每条研究线落地时，必须写清：

精确规则 / 决策时点 / 结算时点 / 数据范围 /
选择期 / 未触碰的评估期 / 赔付假设 / 样本数 / 胜率 / EV / 最大回撤

没有这份记录的研究，等于没做——因为三个月后你不会记得当时到底测了什么。

三、研究历程：四次换方向

回头看，整个过程不是”一条路走到底”，而是四次被迫换方向。每次换向都来自一次证伪。

阶段一：写规则，然后发现自己用了未来（早期）

最早的做法很朴素：写一批技术指标规则，回测，挑胜率高的。

很快撞上第一颗钉子——我发现自己一直在用未来信息。修正因果性之后，一批原本”胜率 60%+“的规则全部回落到 50% 出头。

这一阶段的产出不是策略，是那套因果性检查清单（军规 1）。

阶段二：规模化因子挖掘（V13–V18 一线）

接受”手工写规则没用”之后，转向规模化：把几百个候选特征系统性扫一遍，用逐年样本外验证筛选。

这一阶段最重要的产出是一个否定的结论（见 4.1）：直接模型预测 10 分钟涨跌，准确率上限约 54%。而且这个 54% 不是噪声——所有实验的置信度十分位都单调上升，说明特征里确实含方向信息，只是信息量不够跨过 55.56% 的门槛。

阶段三：换框架——先分类市场，再找机会

既然”单一模型预测方向”有天花板，就换思路：先把市场状态分类，在不同类别里用不同的规则。

这个阶段发现了边际的形态（见 4.2）：反转类持续为正，动量类系统性亏损。 也第一次撞到了那个反复出现的”62% 天花板”（见 4.5）。

阶段四：换思路——从”找更强信号”到”只在高把握时下注”

最后一个转变是最关键的：不再试图提高模型的预测准确率，而是让它回答一个更窄的问题——“这一注该不该下”。

这就是”元标注”（meta-labeling）的思路，也是唯一一条通过了全套检验的线（见 4.3）。

直接让模型预测涨跌，它给出**高置信度**的那些点，实际胜率反而最差（51%）。

而让模型在”已经由规则定好方向”的前提下判断”这一注该不该下”，它的高置信度就变成真信息（校准相关系数 0.92–0.96）。

一个没有先验聚焦的模型，它的”自信”只是把概率撒在噪声上。

延伸：把方法搬到别的地方

这套流程（因果检查 / walk-forward / 密封 holdout / 随机对照）与具体市场无关。

我试过把它搬到其他标的上，结论是：方法可以搬，边际不能搬。 每个市场需要重新找它自己的边际。

四、结果：诚实的版本

4.1 宽口径的硬天花板

在把几百个候选特征系统性扫过、并用逐年样本外验证之后，我得到的最稳定的结论是：

用直接模型预测 10 分钟涨跌，准确率上限约 54%。

而且这个 54% 不是噪声——所有实验的置信度十分位都单调上升，说明特征里确实含方向信息，只是信息量不够跨过 55.56% 的门槛。

4.2 边际的形态：均值回归，且住在极尾里

两类主信号的对比极其干净：

类型	表现
反转 / 极值衰竭 / 跨品种价差回归	持续为正，逐年一致
动量 / 趋势跟随 / 领先滞后	系统性亏损

结论是：这个尺度上的边际，本质是短周期均值回归。 顺势追单在这里是负期望。

更关键的一个发现是它的分布形态：

真正的边际不是均匀铺在所有时点上，而是高度浓缩在极端尾部。

把模型输出的”赢的概率”分十分位看，实际胜率从 50.5% 单调升到 55.3%；只有最高的 5% 才勉强过平衡线，而实际部署用的阈值落在 top 0.1–0.3% 的位置。

这解释了一个长期困惑：为什么”精简”比”放量”更赚钱。 放松阈值不是”多赚一点、少赚一点”，而是在沿着一条单调曲线往下走，一直走到平衡线以下。

4.3 通过全套检验的那条线

最经得起检验的一条是”短周期反转 + 元标注过滤”：

检验项	结果
样本外逐年	三年均高于平衡线（56.0% / 58.4% / 62.2%）
独立前向窗口	三个不同窗口期的主信号全部为正，未出现崩塌
随机零假设对照	57.87% vs 随机 52.17% ± 0.94% → +5.71 个百分点
阈值稳健性	阈值 0.60→0.70 全区间为正且单调
月度一致性	18/29 个月过线，中位 58.0%
参数族整体性	11 个反转窗口里 10 个为正，不是单一参数走运

配合校准检验（模型输出的概率与实际胜率的单调性相关系数 0.92–0.96，校准误差约 1 个百分点），可以说：

这条线是项目里第一个通过了整套严格检验的边际。

4.4 但真实前瞻给出的数字要冷静得多

上面的结果都来自历史数据。真正干净的前向样本（固定规则跑在从未参与过选择的数据上）给出的数字是：

真实并发约束下    约 56%–57.5% 胜率
日均单量          18–28 单

薄，正，但统计上还不显著。 这就是诚实的现状。

这里需要区分两个口径：

口径	胜率
选择过的样本外（参与过筛选流程的数据）	约 58%–61%
完全干净的前向（固定规则跑在从未参与选择的数据上）	约 56%–57.5%

把两者放在一起看，得到的判断是：

这套东西的真实边际落在 56%–60% 这个区间，方向上确实高于 55.56% 的平衡线，但边际很薄，且对执行成本和数据口径高度敏感。

4.5 一个反复出现的”天花板”

在多个独立分支上，我都撞到了同一个量级的上限：约 62%。

它的表现方式很一致：无论走因子挖掘、走组合、走分类框架还是走元标注，最好的那些切片的胜率最终都收敛到 60% 出头，再往上推不动。

我试过大量被寄予厚望的正交数据源：跨品种广度、订单流失衡、爆仓数据、跨市场散度、第二个账户体系、宽网搜索……

结果高度一致：它们能增加成交量，但抬不动胜率。

这说明边际的来源非常集中——就是分钟级的价格 / 成交流 / 基差结构里的均值回归。在这个尺度上，它已经被挖得比较透了。

五、失败档案

如果这篇纪实只有一句话值得看，应该是这句：

我用大部分时间做的事，是证明某些想法是错的。

下面这些都是真实发生过、并且被明确否掉的。它们比成功的部分更有信息量。

5.1 用了未来函数，胜率从 80% 掉到 54%

假设：价格创新高/新低，但主动成交流没有跟上（背离），说明这段走势”衰竭”了，之后会反转。

结果：初版回测胜率 79.9%，期望值 +0.438，多段数据一致，看起来是项目里最强的发现。

问题：策略在”一波触发结束之后的第一根”进场。而”这一波什么时候结束”需要知道 后面 15 分钟内不会再有新触发——这在入场那一刻是不可能知道的。

改成因果版本（每个触发点都取，不挑”最后一个”）之后：

版本	单量	胜率	期望值
前视版（不可交易）	25,881	79.9%	+0.438
因果版（可执行）	72,928	53.7%	−0.034

因果版里包含了近 4.9 万笔”以为跌完了、结果继续跌”的提前进场，胜率只有 42%。

同一套波次逻辑当时已经部署在一个小资金实盘策略上，随后也被关闭—— 它的真实表现会自动返回约 57%，而不是回测里的 69%。

留下的教训：这类”结构结束 / 序列完成 / 最后一个”的概念，必须逐个追问 “我在下单那一刻能确认它吗”。判别测试就是把”只取最后一个”改成”每个都取”。

5.2 一个单位换算错误，让错误结论活了很久

我在回测里模拟并发槽位：持有期是 10 分钟，最多同时持 5 单。

实际代码里，时间戳的单位是微秒（1 分钟 = 60,000,000），而持仓时长用了纳秒（10 分钟 = 600,000,000,000）。把纳秒当成微秒加上去之后——

600,000,000,000 / 60,000,000 = 10,000 分钟 ≈ 6.94 天

每一次开仓都把槽位锁了将近 7 天。 于是所有受并发约束回测的吞吐量都被压成了约 0.7 单/天。

这个 bug 造成的后果不是数字难看，而是一个错误的战略结论被反复确认： “并发槽位是吞吐的墙，高频根本不可能。”

发现它的线索很朴素：不管原始信号有多少（300 单/天还是 2 单/天），加上约束后吞吐都变成同一个数字。这在数学上不可能——5 个槽位、10 分钟持有期，理论容量是每天 720 单。

修正并交叉验证（修正后的回测与真实模拟盘记录吻合）之后的真相：

线路	修正后真实吞吐	真实胜率
高频因子线 A	18.0 单/天	57.7%
高频因子线 B	19.0 单/天	59.1%
组合策略	27.8 单/天	56.9%
元标注反转线	28 单/天	56.2%

吞吐量从来不是问题。 真正的问题从一开始就是另一个，只是被这个 bug 掩盖了很久：

在每天 20 单的量上，胜率能不能干净、稳定地站在 55.56% 之上？

5.3 用现货结算，高估了 2 个百分点

在薄边世界里，2 个百分点就是生与死的差别。

我用逐笔数据重建了真实的指数价序列，把同一批信号在两种结算口径下对比：

现货价结算    58.41%
真实指数价    56.51%

差距全部来自现货与指数之间的基差。 结论：此后所有用现货回测的结果，默认都要打约 2 个百分点的折扣。

顺带还发现了一个免费的小改进：入场不要卡在整点那一秒。 整点时刻的指数价经常处于跳动或滞后的状态；等 5–10 秒再入场，各年份表现都更好，且这是一个平台（不是孤立尖峰）。在最难的那一年，它把 54.12% 提升到 55.94%——正好从线下推到线上。

5.4 一个”看起来很强”的区域被证明是挑选出来的

在分类框架下重挖之后，我找到了一个全新的做空候选：高位 + 主动买入效率过高（多头过热）→ 做空。

它的数字非常漂亮：胜率 63.3%，样本内外一致，冷却后不衰减，与现有策略重叠不到 8%。

问题在敏感性检验里暴露了：

把极值分位从最极端的 5% 放松到 40%，期望值从 0.139 崩到 0.033，并且当年转负
边际严重依赖单一年份（一年 0.045，另一年 0.406）

更关键的是，在唯一一段没有参与过任何选择的干净前瞻数据上，它是所有模块里回归最狠的一个（选择期最强，前向 46.7%）。

**在选择期表现最好的模块，前向回归最严重。**

这不是巧合，是选择偏差的定义。最终这个候选被降级为只做纸面观察，不上真钱。

5.5 复现别人的策略：三种不同的结局

我花了不少时间复现外部提供的策略包。结果分成三类，每一类都有价值：

第一类：真实的。 一套基于基差偏离 + 超买超卖 + 趋势状态门的组合，在多段数据上复现出 61% 左右的胜率、日均约 14 单，逐年为正，置换检验 18.6 个标准差。 外部的说法可以被独立复现。

第二类：抬不动。 一套”宽池 + 打分模型、一天上百单”的方案。复现后确认：原始宽池确实”宽而弱”（52.6%），打分确实能把胜率抬升约 2.5 个百分点—— 但抬不到 55.56%。 三个分位档全部不达标，网格细化后依然如此。 打分有真实但极弱的信号，只是不够赚钱。

第三类：复现不出来。 一套宣称全期 65.35% 胜率、累计正收益、零亏损月的策略。按文档规则忠实复现后得到的是 55.37%、期望值约等于零、亏损月 23 个。差异量级约 56 个标准差。

我进一步做了成交假设的敏感性测试，找到了差异的来源：

成交假设	胜率
诚实口径（按文档描述的下一分钟开盘价成交）	55.4%
用”信号收盘价与下一开盘价里更好的那个”	57.7%
用”下一根 K 线的最有利极值”	63.0%

只有引入前视性质的成交假设，那个宣称的数字才会出现。

5.6 把思路搬到更细的时间尺度：不行

我认真测过”把同样的配方搬到秒级”这件事，而且分两条路分别测：

作为信号：同样的反转配方，预测未来 600 秒。

1 分钟 bar 上    55.15%
10 秒 bar 上     44.66%

作为执行：同一套信号，用更细的 bar 去挑更好的入场点。结果同样是 null—— 更细的粒度只带来噪声。

结论：这个边际锁死在”分钟级 bar + 10 分钟预测窗”这个尺度上，平移会消失。 秒级框架不是没用，但它需要找的是另一个、独立的边际，不是这一条的加速版。

5.7 被否掉的其他假设（简表）

假设	结论
动量 / 趋势跟随在这个尺度有效	否，系统性亏损
资金费率 / 溢价 / 持仓量 / 爆仓数据是新边际	否，作为触发和叠加层都不稳健
越多的正交数据源能提高胜率	否，只提高成交量
对称地做”超买做空”	否，结构性不对称：底部是事件，顶部是过程
直接用模型预测方向 + 置信度过滤	否，置信度是假自信
用凯利公式复利放大	否，在薄边上会让回撤达到本金的 3–6 倍
更细粒度的订单流能提升方向判断	否，相关性全部 ≤ 0.04
某个指标（RSI、MACD、%B）在秒级有效	否，数据量增加后效应归零

5.8 从样本外到实盘，还有一道折扣

这是最容易被忽略、也最贵的一课：“样本外表现”和”上线后的真实表现”之间，还有一段距离。

我跟踪过一条线的完整衰减过程：

离线样本外      58.7%
真实前向（同期） 54.6%
面板实际记录    48.0%   ← 但这一段样本量很小，含噪声

把差距拆解开之后，大致是三块：

约 4 个百分点是真实的前向衰减（市场结构本身在变化）
约 2 个百分点是口径差异（用现货价检验、实际按指数价结算）
剩下的主要是小样本噪声（面板那一段的样本量还不足以区分 48% 和 53%）

关键结论不是”这个数字是多少”，而是：回测里的样本外数字，本身还需要再打一次折。

所以我的收益评估流程里有一条固定动作：新策略先跑纸面/模拟观察，用真实成交口径累积够样本之后，才用它决定是否放大仓位。而且监控要看三件事——胜率是否低于样本外预期、成交量是否异常、单条线是否出现了超出历史范围的连亏——而不是只看总盈亏。

六、几个反直觉的发现

6.1 边际住在尾巴里

不是”这个策略有 58% 的胜率”，而是”这个策略在最极端的 0.1%–0.3% 时点上才有 58% 的胜率”。

这个形态决定了所有事：它意味着边际天然是低频的，意味着”放量”和”提高胜率”在这个边际上是同一个旋钮的两端，也意味着任何”我又多下了一倍的注”的想法，实际是在稀释自己。

6.2 模型需要先验，不然它的自信是噪声

直接让模型预测涨跌，它给出高置信度的那些点，实际胜率反而最差（51%）。而让模型在”已经由规则定好方向”的前提下判断”这一注该不该下”，它的高置信度就变成真信息。

一个没有先验聚焦的模型，它的”自信”只是把概率撒在噪声上。

6.3 吞吐量不是问题，边际厚度才是

我花了很长时间（还因为一个 bug 走了弯路）纠结”能不能做到一天 20 单”。最后发现：一天 20 单很容易，难的是在这个量上仍然是正的期望值。

6.4 选择偏差会精确地惩罚你

在选择期表现最好的模块，前向表现最差。这不是巧合，是选择偏差的定义。这意味着”在我反复看过的数据上最好的那个”恰恰是最不该相信的那个。

6.5 分类框架本身是防过拟合手段

第一反应可能是”层数越多越容易过拟合”。实际上：层数增加的是结构，不是拟合参数。

一个主要由规则构成的多层流水线，其可调参数可能远少于一个全模型的两层方案，而”把方向判断和风险取舍拆开”本身就是一种防过拟合的设计。

真正决定过拟合的是三件事：总拟合参数数量、同一段样本外数据被看了几次、最窄那一层的样本量。

七、这件事教会我的

第一，规则比策略重要。 合约条款里的三个数字（55.56%、2 个百分点、5 个槽位）决定了整个研究的形状。不先把它们算清楚，后面所有工作都建立在错误的假设上。

第二，能被证伪的方法才是最贵的资产。 我最满意的一批成果其实不是某条策略，而是那套能持续打掉自己乐观结论的流程：因果性检查、随机零假设、密封 holdout、参数平台、选择偏差审计。它们在这一路上至少拦下了三次会真金白银亏钱的部署。

第三，薄边世界里，2 个百分点就是全部。 结算价用现货还是指数、入场卡整点还是等 5 秒、并发约束复刻得对不对——这些在别的领域里是”工程细节”，在这里是策略生死。

第四，要接受”没有结论”。 到目前为止，我真实的、干净的前向记录只支持一个结论：这套方法找到了一个薄弱但真实的正期望边际，约为 56%–60%，且它还不稳定到可以作为定论。 这个结论不性感，但它是真的。

附：这套方法的可迁移部分

如果你在做类似的事，下面这些是可以直接拿走的，与具体市场无关：

先算平衡点，再谈策略。 赔率决定了你需要多高的胜率，这个数字应该在写下第一行回测代码之前就贴在墙上。
给”未来函数”建一份检查清单，并且把”恰好 k 个 / 最后一个 / 序列结束 / 峰值之后”这些词当作红色警报。
参数邻域必须成片。 孤立的最优点等于过拟合。
方向分离。 别让一个方向的成交量掩盖另一个方向的亏损。
回测复刻真实约束。 并发、去重、结算价、入场延迟，一项都不能省。
留一段数据一次都不碰，最后端到端跑一次。
用随机对照检验你的模型，而不是只看它自己的准确率。
记录每一次失败。 失败档案是你未来最省时间的文档。

币安事件合约 API：用开源库实现自动下单，以及 55.56% 那道线

Thu, 17 Sep 2026 00:00:00 GMT

import Callout from ’@/components/Callout.astro’; import ReverseEngineeringNotice from ’@/components/ReverseEngineeringNotice.astro’;

有粉丝问怎么把事件合约做成自动化，这类需求很集中，所以我把接口层单独写一篇。

接口实现不是我写的——用的是一位开发者开源在 GitHub 上的库（thuhollow2/Binance-Event-Contract-Interface， MIT，Python）。下面讲的是怎么用、以及哪里会踩坑，顺带把它和策略的关系说清楚。

**它能做的**：把币安事件合约的下单流程自动化——扫码登录、保存凭证、调用下单接口。

它不能做的：告诉你该不该下单。

这两件事的差距，比大多数人以为的大得多。原因见第二节的那个数字。

一、事件合约是什么：一句话和三个参数

币安的事件合约是一种超短周期二元期权：

t 时刻按当前指数价入场
t + N 分钟后按结算价结算
结算价 > 入场价 → 赢，得 +payoutRatio × 本金
结算价 < 入场价 → 输，亏 −1.0 × 本金

下单接口的 payload 直接把这几个参数暴露出来：

{
  "orderAmount": "5",
  "timeIncrements": "TEN_MINUTE",
  "symbolName": "BTCUSDT",
  "payoutRatio": "0.80",
  "direction": "LONG"
}

三个关键参数就是：金额（orderAmount）、周期（timeIncrements）、方向（direction）。而 payoutRatio 是交易所给的赔率，你改不了。

二、★ 0.80 这个数字决定了一切

payoutRatio: "0.80" 意味着：赢一次赚 0.8 倍本金，输一次亏 1.0 倍本金。

设胜率为 p，期望值：

EV = 0.8p − 1.0(1 − p) = 1.8p − 1

要 EV > 0：

p > 1 / 1.8 = 55.56%

**55.56%** —— 一个"胜率 54%"的策略在这里是**稳定亏损**的。

市面上大量”我找到了 60% 胜率的指标”的说法，都死在这个数字上：它们要么没算过平衡点，要么用了未来函数（回测好看，实盘归零）。

所以拿到这个库的第一件事不是接信号，是先把这个数字写在墙上。

这也是为什么我把这篇和另一篇拆开写：

文章	回答的问题
本篇	怎么把订单自动发出去
事件合约量化研究纪实	在 55.56% 之上站住到底有多难

三、接口形式：两个端点，两套凭证

币安的账号允许同时登录 1 个 App 端和 1 个 Web 端，所以有两套可用的调用方式。

App 端：用 `x-token`

curl 'https://www.binance.com/bapi/futures/v2/private/future/event-contract/place-order' \
  -H 'content-type: application/json' \
  -H 'clienttype: android' \
  -H 'x-token: app.<ID>.<TOKEN>' \
  -X POST \
  --data-binary '{"orderAmount":"5","timeIncrements":"TEN_MINUTE",
                  "symbolName":"BTCUSDT","payoutRatio":"0.80","direction":"LONG"}'

Web 端：用 `p20t` + `csrftoken`

curl 'https://www.binance.com/bapi/futures/v2/private/future/event-contract/place-order' \
  -H 'content-type: application/json' \
  -H 'clienttype: web' \
  -H 'csrftoken: <CSRF_TOKEN>' \
  -b 'p20t=web.<ID>.<TOKEN>' \
  -X POST \
  --data-binary '{"orderAmount":"5","timeIncrements":"TEN_MINUTE",
                  "symbolName":"BTCUSDT","payoutRatio":"0.80","direction":"LONG"}'

两者的区别（这是最容易踩坑的地方）

	App 端	Web 端
凭证字段	`x-token`	`p20t`（Cookie）+ `csrftoken`（Header）
格式	`登录方式.ID.Token`	`p20t` 同格式；`csrftoken` 是 www.binance.com 的 CSRF token
获取方式	抓包工具	浏览器开发者工具
有效期	未知	最长 5 天

App 端凭证有效期没有公开结论，Web 端明确是**最长 5 天**。

这意味着一个必须处理的问题：凭证会静默过期。

如果你的程序跑得好好的、某天开始所有下单都失败，第一件事应该去查凭证—— 而不是去怀疑策略。这是个很低级但很常见的误判。

四、它怎么拿到凭证：扫码登录 + 持久化

它选择了模拟 Web 端登录这条路（而不是让你手工抓 App 端的 x-token），因为对使用者更友好：

1. 用 Playwright 启动浏览器，打开币安登录页
2. 终端里渲染二维码，你用币安 App 扫码
3. 登录成功后，从浏览器上下文里取出 p20t 与 csrftoken
4. 写入 token.json（含 expirationTimestamp）
5. 之后调用 place_order_web() 时读取该文件

依赖很轻：

requests
playwright     ← 用于扫码登录
qrcode         ← 终端渲染二维码
pillow

pip install -r requirements.txt
playwright install chromium
playwright install-deps
python main.py

跑完会在当前目录生成 token.json。

`token.json` 里存的是**可以直接下单的登录凭证**，明文。

两件事必须做：

加进 .gitignore —— 别把能下单的凭据推到公开仓库（这是最常见的泄露方式）
不要放在共享目录或云同步盘（iCloud / Dropbox / 网盘同步目录）

一个能下单的凭证，等于你的账户资金。它不是你自己的 API key，你无法在后台单独吊销它—— 只能改密码让所有会话失效。

五、工程层面的风险（法律风险见文首声明）

文首那份声明讲的是法律与合规。这里讲工程层面会实际遇到的问题：

风险	具体表现	应对
没有兼容性承诺	币安随时可改接口、加签名、加风控，你的程序直接失效	监控下单失败率，失败率突变时先怀疑接口而非策略
凭证静默过期	Web 端最长 5 天；过期后所有下单失败但不报错	显式检查 `expirationTimestamp`，临期自动重新登录
凭证泄露 = 资金风险	`token.json` 是明文的、可直接下单的凭据	加 `.gitignore`；不放同步盘；泄露后改密码使全部会话失效
无官方支持	出问题只能自己排查	保留详细的请求/响应日志（但注意别把凭据写进日志）

这些不是”注意一下”就能规避的，而是需要写进代码里的处理逻辑。

顺带说一句我在别处踩过的坑：“交易所跟用户对赌”这个结构本身也是一种风险。 在事件合约这类产品上，你的对手方就是平台。持续盈利会提高你被风控关注的概率—— 这是我在另一个平台上真实经历过的事，写在另一篇文章里了。

六、所以：接口有了，然后呢

这是我最想强调的一点。

把下单自动化，只是把”手动亏钱”变成”自动亏钱”。 它不改变期望值。

而在 0.80 的赔率下，你需要稳定站在 55.56% 之上才能赚钱。这个门槛有多难？

我把同一批研究的完整纪实单独写了一篇，里面有：

十条研究军规（因果性检查、密封 holdout、参数平台、方向分离、多重比较）
八个真实被否掉的方向，包括一个因未来函数让胜率从 79.9% 掉到 53.7% 的策略
诚实的结论：真实前向约 56%–57.5%，薄、正，但统计上还不显著

→ 事件合约量化研究纪实：过程、结果和失败档案

七、给你的使用顺序建议

如果你确实要用这个库，我建议这个顺序：

1. 先把平衡点算清楚            ← 55.56%，写在墙上
2. 用它只做【信号记录】，不下单  ← 累积你自己的前瞻样本
3. 累计够样本后，算胜率的置信区间 ← 看下界有没有过平衡线
4. 只在样本足够、下界过线时才考虑上真钱
5. 上真钱后先小仓位跑纸面观察期   ← 样本外到实盘之间还有一道折扣

第 2 步是关键，也是最多人跳过的一步。 大部分人拿到自动化工具后第一反应是”接个信号跑起来”，但你没有前瞻样本时，你根本不知道自己的信号在真实口径下是什么胜率。

这个库真正的价值不是”帮你赚钱”，而是让你能低成本地积累真实口径的前瞻记录。把它当测量工具用，不是当赚钱工具用——这个定位差别，决定你是先亏钱还是先有数据。

本文仅供技术交流，不构成投资建议。文中提到的接口库为第三方开源作品，与作者无隶属关系。接口逆向与自动化交易存在账号与资金风险，请自行判断。

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

Wed, 16 Sep 2026 00:00:00 GMT

import Callout from ’@/components/Callout.astro’;

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

1. **优势是真实存在的**——不是运气，统计上极度显著（z = 33.8，p < 0.001）。按当时的仓位，**实盘日赚约 1,000–2,000 U**，十天没有一天亏损。 2. **它消失了**——大约 10 天后，同一个策略从 63.75% 掉到 53.17%，转为亏损 3. **账号被封了**——它最终死于对手方风险，不是死于策略失效

我把完整过程写下来，是因为这三件事凑在一起才是完整的教训。只讲第 1 点是在卖课，只讲第 2 点会让人以为策略没用，只讲第 3 点会让人忽略方法论。

一、肉眼发现的异常：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，可还原到秒
撤单行为	不可见	{/* TODO */}

这一步是整个项目的转折点。 因为”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%

`+0.8 / −1.0` 意味着赢一次赚 0.8，输一次亏 1.0。所以盈亏平衡点是 `1 / 1.8 = 55.56%`——**不是 50%**。

这一步必须先做。很多人做这类策略亏钱，不是策略错，是从头就没算过平衡点。

四个检验

{/* TODO(作者)：这三项填真实数值 ① lag-1 自相关（相邻变动负相关 → 支持均值回归） ② 回复半衰期（OU 过程拟合，决定持仓周期） ③ 偏离幅度分布（决定阈值，以及尾部有多厚）脚本：analyze_hibt.py / analyze_1m_hibt.py / mine_factors_1m_hibt.py */}

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

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

{/* TODO(作者)：这一节必须填。哪怕结论是”样本太少、没能找到可靠反例”，也要如实写 —— 这本身就是重要的局限说明。 */}

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

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

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

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

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

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

我把所有信号——**包括没开仓的分钟**——全部记录进 CSV，并用一个独立的「影子信号」进程按实盘口径（含延迟）逐条模拟结算。

也就是说：我在用真实盘口数据做 walk-forward，而不是拿回测数字骗自己。 这件事的价值在后面才完全体现出来。

七、结果：优势真的存在

下面是实盘口径（含 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，意味着后期它在统计上确实是个亏钱策略，而不是回到了随机。

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

一个在 10 天里 z 值高达 33 的边缘，会在某一天突然变成负的—— 这件事本身才是这个领域最重要的常识。

原因通常有三个，而且往往同时发生： · 对手方调整——价格形成机制变了（平台开始干预做市） · 参与者结构变化——别人也发现了，套利把它磨平 · 你自己的规模——下单量本身改变了盘口

我无法从数据上区分这三者，这也是我没有把它们写成结论的原因。

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

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

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

在一个价格由平台控制的交易对上，**你赚的钱就是平台亏的钱**。当你持续从这个交易对里提取利润时，你不是在做市，你是在从对手方口袋里拿钱。

它关掉你的账号不需要你违反任何规则——“不允许稳定盈利”本身就是隐含规则。

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

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

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

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

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

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

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

注意这张表里两个细节：

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

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

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

注意它的形状：

8/15 前后起跳  →  8/16 达到峰值（日佣金 70+）→  8/23 之后归零

而我从 47 万行原始 tick 数据里独立算出的结论是： 优势在 08-22 结束，08-23 起转为负值。

两条完全独立的证据链指向同一个日期。 返佣曲线是平台自己记的账，归档数据是我自己录的盘口—— 它们不可能串通，但它们说的是同一件事。

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

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

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

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

2026-09-04 的客服对话。

**「您账号肯定触发风险账号了」** **「钱取不出」** **「盈利还是亏钱，反正标记风险用户就可以不提钱」**

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

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

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

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

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

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

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

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

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

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

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

最后

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

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

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

布欧的量化日记

币安 L2 盘口数据完全指南：免费能拿到什么、自录要怎么写、怎么验证数据是真的

一、先明确你想要的是哪种”盘口数据”

二、币安官方归档里到底有什么（实测）

日更目录（/data/futures/um/daily/）

月更目录（/data/futures/um/monthly/）

文件组织与体积（BTCUSDT 实测）

三、免费数据能回答什么、不能回答什么

四、自己录一份逐档 L2：完整方案

4.1 为什么必须”快照 + 增量”拼接

4.2 ★ 唯一不能省的校验：序列号连续性

4.3 采集器骨架

4.4 体积估算与运维

五、怎么验证一份 L2 数据是真的

5.1 内部自洽：增量重建 vs 定时快照

5.2 跨数据源交叉：成交量的三方对齐

5.3 合理性检验：不该出现的状态

六、免费数据怎么拿

七、这份数据能支撑哪些研究

事件合约量化研究纪实：四条被否掉的路，和一个 56% 的边际

一、先看规则：难度写在合约条款里

规则里还埋着三颗钉子

二、方法论：我最后留下的十条军规

1. 因果性：把”事后才知道”翻译成”当下能知道”

2. 只允许用决策时刻已存在的数据

3. 滚动标准化，不用固定绝对阈值

4. Walk-forward：训练、选阈值、评估，三段严格分离

5. 密封 holdout 只看一次

6. 参数平台 > 参数尖峰

7. 方向分离：做多和做空是两个问题

8. 回测必须复刻实盘约束

9. 多重比较要认账

10. 每次研究都必须留下可复现的报告

三、研究历程：四次换方向

阶段一：写规则，然后发现自己用了未来（早期）

阶段二：规模化因子挖掘（V13–V18 一线）

阶段三：换框架——先分类市场，再找机会

阶段四：换思路——从”找更强信号”到”只在高把握时下注”

延伸：把方法搬到别的地方

四、结果：诚实的版本

4.1 宽口径的硬天花板

4.2 边际的形态：均值回归，且住在极尾里

4.3 通过全套检验的那条线

4.4 但真实前瞻给出的数字要冷静得多

4.5 一个反复出现的”天花板”

五、失败档案

5.1 用了未来函数，胜率从 80% 掉到 54%

5.2 一个单位换算错误，让错误结论活了很久

5.3 用现货结算，高估了 2 个百分点

5.4 一个”看起来很强”的区域被证明是挑选出来的

5.5 复现别人的策略：三种不同的结局

5.6 把思路搬到更细的时间尺度：不行

5.7 被否掉的其他假设（简表）

5.8 从样本外到实盘，还有一道折扣

六、几个反直觉的发现

6.1 边际住在尾巴里

6.2 模型需要先验，不然它的自信是噪声

6.3 吞吐量不是问题，边际厚度才是

6.4 选择偏差会精确地惩罚你

6.5 分类框架本身是防过拟合手段

七、这件事教会我的

附：这套方法的可迁移部分

相关阅读

币安事件合约 API：用开源库实现自动下单，以及 55.56% 那道线

一、事件合约是什么：一句话和三个参数

二、★ 0.80 这个数字决定了一切

三、接口形式：两个端点，两套凭证

App 端：用 x-token

Web 端：用 p20t + csrftoken

两者的区别（这是最容易踩坑的地方）

四、它怎么拿到凭证：扫码登录 + 持久化

五、工程层面的风险（法律风险见文首声明）

六、所以：接口有了，然后呢

七、给你的使用顺序建议

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

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

二、先解决执行

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

四、搭一套数据管线

五、统计验证

日更目录（`/data/futures/um/daily/`）

月更目录（`/data/futures/um/monthly/`）

App 端：用 `x-token`

Web 端：用 `p20t` + `csrftoken`