jack/Chan
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
66061f79a198b40c56b6e59e89b2815fb236b00f
Chan/research/HANDOFF.md
T
jackyu66gitandCursor 66061f79a1 research: 低滞后信号口径定稿与实盘前偏差审计 
fast_bsp3 改用 tol=-1 + require_touch=False，信号滞后从 5.8 根降到 2.2 根。
滞后与收益严格单调（年化 370% -> 906%，同一份数据同一套成本），
这是本轮提升的主因，也意味着实盘延迟会直接侵蚀收益。

新增 step31~39 验证策略能否落地：
- 跨品种样本外——8 个未参与调参的币，PF 2.73 / t 28.5，无一为负
- 时点重建——只喂到信号那一根重算，同根命中 100%，确认无未来函数；
  1m 在 2000 根窗口即饱和，计算耗时 0.20s
- 偏差审计——多空对称、中枢生效时刻零回退、滑点稳健至 30bp、持仓几乎不重叠
- 消融——alpha 来自缠论中枢的上下文定位，而非「收盘转强」这个触发动作

补 research/HANDOFF.md：记录确切口径与参数、已排除的偏差、
已验证无效因而不必重做的方向，以及下一步用影子交易器实测执行滑点的方案。

清理 step1~20 的输出：早期方法论已被推翻（存在未来函数偏差），
其结论不再被引用；脚本保留，需要时可重跑。

Co-authored-by: Cursor <cursoragent@cursor.com>
2026-08-27 17:47:41 +08:00

23 KiB
Raw Blame History

缠论信号研究 → 实盘落地：交接文档

最后更新：2026-08-27。写给接手这项工作的下一个 agent。 读完这份文档应该不需要再翻聊天记录。若确有需要，历史转录在 /Users/jack/.cursor/projects/Users-jack-Project-chan/agent-transcripts/。

0. 一句话现状

策略在回测和多重偏差审计下都站得住（跨 11 个币、7 年、多空对称、无未来函数）， 研究阶段基本结束；当前唯一的拦路问题是「实盘执行成本能否压进预算」， 下一步是写影子交易器实测滑点，而不是继续调参。

用户明确要求：不要再跑新的参数优化。 他的原话是「很多时候回测数据特别好， 一到 dry run 和实盘就歇菜了」。他要的是执行层的验证。

1. 策略的确切定义

这是全文最重要的一节。所有回测数字都基于以下这套口径，改任何一条数字就不可比。

1.1 信号生成（三层）

第一层  小级别(LTF) 自身的中枢         build_htf_zones(cdf, ltf, chan=chan_l)
第二层  中枢突破后回抽不回，收盘转强 → 入场   find_fast_bsp3(cdf, zones)
第三层  大级别(HTF) 分型方向必须同向        attach_htf_context(...) 后取 h1_agree == 1
可选    中枢阶梯方向过滤（顺向推进）        z_above / z_below，见 1.4

用户对「区间套」的定义（务必按这个理解，早期我理解错过）： 大级别（1h/4h）分型定位转折点 + 小级别（15m/5m/1m）中枢突破形成第三类买卖点。 不是大级别中枢突破。

1.2 find_fast_bsp3 的当前默认参数

research/lib/fast_bsp3.py：

参数 默认值 含义与注意
scan 200 中枢成立后向后扫多少根找突破
pullback_win 30 回抽窗口
tol -1.0 负值＝禁用「回抽未触及边界就跳过」。这是最关键的参数，见 3.2
max_per_zone 1 同一中枢只做首次入场，见 4.2
require_touch False 不要求回抽触及中枢边界，见 3.2

tol=-1 + require_touch=False 是当前口径，滞后 2.2 根。 早期默认（tol=0.003, require_touch=True）滞后 5.8 根，年化从 906% 掉到 370%。 新旧差异已完整量化在 step34（tol 扫描）与 step33（require_touch）里， 旧口径的原始输出已清理——不需要它，也不要回到旧口径。

1.3 交易执行口径

SL, TP, MAX_BARS = 1.5, 3.0, 48      # ATR 倍数止损/止盈 + 超时根数
run_trades(cdf, entries, SL, TP, MAX_BARS, fee=..., entry_delay=1)
  • 入场：信号次根开盘价（entry_delay=1），不是信号根收盘价
  • 研究口径成本：4bp 手续费 + 1bp 滑点 = 5bp（所有带「已扣 5bp」的数字都是这个）
  • ATR 取信号根的值（atr[sig_idx]），不是入场根

1.4 阶梯过滤（顺向推进）

对应缠论「趋势 vs 盘整」：当前中枢相对前一个中枢是否同向推进。

pg, pdn = z["zg"].shift(), z["zd"].shift()
z["z_above"], z["z_below"] = z["zd"] > pg, z["zg"] < pdn
push = z_above if direction == 1 else z_below

加上它 PF 从 2.72 → 3.41（30m/2h）。用户特别在意这一点，因为它印证了 缠论对趋势的定义（一个分型后第一个中枢就反转的概率低于出现第二个中枢后反转）。

1.5 各级别的确切配对

小级别 大级别(h1，做同向过滤) 备注
1m 5m step23 的配置是 1m:5m:15m，15m 只记录不过滤
5m 30m 统计量最强
15m 1h
30m 2h 单笔质量最高

2. 最优配置与核心数字

2.1 级别矩阵（step28，同向+阶梯，3 币）

组合 笔数 胜率 中位 PF t值
5m/30m 1321 53.1% +0.31% 1.98 10.16
30m/2h 258 65.1% +1.65% 3.41 8.51
5m/15m 1292 51.7% +0.24% 1.82 8.84
15m/1h 467 56.5% +0.74% 2.46 7.96

选择逻辑：30m/2h 单笔质量最好，5m/30m 统计显著性最强。1h 及以上小级别笔数不足。

2.2 跨品种样本外（step37）— 最有说服力的一项

参数一个没动，拿 8 个完全没参与调参的币验证：

分组 笔数 年笔数 胜率 中位 PF t值 剔10%PF
样本内(BTC/ETH/SOL) 2309 334 61.4% +0.531% 2.86 +19.11 1.77
样本外(8 个新币) 5859 884 62.9% +0.592% 2.73 +28.50 1.66

逐币最弱的 XRP 仍是 PF 2.21 / t 7.64。没有一个币是负的。

2.3 收益量级——务必用正确口径（step35 第 5 节）

这一条最容易被误读，历史上我自己也一度报错过口径：

口径 年化 回撤 Sharpe
A 1%风险+20倍上限+复利 +1323.8% 8.1% 10.38
B 1%风险+20倍上限+不复利 +270.0% 8.4% 10.38
C 固定名义1倍+不复利 +194.7% 8.4% 7.95
D 固定名义3倍+不复利 +584.1% 25.2% 7.95

只有 C/D 是可以直接对照的量级。 那些 906%/1323% 的数字来自复利+杠杆假设。 平均单笔杠杆 2.1x（中位 1.8x）。 未含资金费率，未含同时持仓的保证金约束。

3. 已验证成立的结论

3.1 没有未来函数（step38，最要紧的一项）

担心的是 incremental.py 里那句注释：「最后一笔 is_sure 允许收回」—— 中枢生效时刻 available_ts 取自笔的 sure_time，而那是全量重算得出的。

做法：对每个信号只喂到该根为止的数据（窗口 4000 根），重跑 TF_DF → 中枢 → fast_bsp3，看信号是否真的在那一刻存在。

结果：同根命中 100.0%（抽检 1217 个信号），完全消失 0.0%，假阳性 0.7%。 偏移中位 +0.0 根。回测口径可信。

3.2 滞后是收益的第一驱动（step34）

口径 笔数 滞后(根) 胜率 PF 年化 Sharpe
禁用跳过(现用) 2309 2.2 61.4% 2.86 +906.1% 9.02
tol 0 2214 2.7 60.4% 2.74 +731.3% 8.43
tol 0.1% 2134 3.6 58.7% 2.64 +569.8% 7.65
tol 0.3%(旧默认) 2045 5.8 55.4% 2.37 +370.4% 6.30
tol 1% 1561 9.9 48.3% 1.88 +112.0% 3.53

滞后与收益严格单调。这也意味着实盘延迟会直接侵蚀收益，是下一阶段的核心风险。

3.3 其余已排除的偏差

  • 中枢生效时刻（step36 §1）：0% 走 end_time 回退分支，全部用 sure_time
  • 多空对称（step36 §3）：做多 PF 3.12 / t 14.77，做空 PF 2.62 / t 12.27 → 不是单纯吃加密货币的上涨 beta
  • 时间样本外（step36 §4）：20192022 挑参数，20232026 验证 → PF 从 3.31 降到 2.44，t 仍 12.29。有衰减但成立
  • 滑点脆弱性（step35 §1）：加到 +30bp 仍 PF 1.73 / t 10.15
  • 入场后移（step35 §2）：后移 1→4 根平滑衰减（PF 3.18→2.53）， 未来函数会呈断崖，这里没有
  • 持仓重叠（step35 §3-4）：单腿平均并发 0.01，组合 9 腿平均并发 0.1， 有仓位时间仅 8.6% → t 值没被虚高，各笔基本独立

3.4 alpha 的来源（step32 消融）

逐条拆掉 fast_bsp3 的条件后发现：alpha 完全来自缠论中枢的上下文定位， 不是「回抽结束、收盘转强」那个触发动作本身。 触发条件只负责压低滞后。

这个结论回答了用户当时的问题（「如果有这个，那就可以去判断任何笔的端点了」）： 不能。脱离中枢上下文，那个触发条件没有预测力。

4. 已验证无效 / 不要重做的方向

方向 结论 出处
动态止盈（小级别三买后等大级别三买再调止盈） 无效。持仓期太短（8~13 根），大级别确认来得太罕见 step27
同一中枢重复入场（二次、三次） 质量骤降，只做首次 step25
缠论引擎原生 find_all_bsp 的 B3/S3 因 is_sure 确认滞后，统计上呈逆势、显著亏损。几何位置没错，但实时不可用 step30/31
刷交易额换 VIP 费率 成本收益不划算，见 5.3 step23
线段（Chan_XD）做大级别 滞后太大，且中枢极少 早期，用户也这么说

5. 实盘落地的现状与关键约束

5.1 交易所：这是当前最大的未决项 ⚠️

用户实际用 Bitget（手续费.xlsx 在项目根目录）：

VIP maker taker 升级门槛(月交易额)
1 0.020% 0.060% 0
2 0.016% 0.040% $3M
3 0.014% 0.0375% $20M

返还比例：手动 60%、API 50%。

框架支持情况（已查证，2026-08）：

框架 Bitget 永续 说明
freqtrade（本地已装 2025.4-dev） ❌ 源码里搜不到一处 bitget；SUPPORTED_EXCHANGES = binance/bingx/bitmart/bybit/gate/htx/hyperliquid/kraken/okx
NautilusTrader ❌ nautilus-bitget 是 0.0.0 空壳无 API；官方适配器列表（2026-06-30）无 Bitget。Bitget 只出现在第三方 Tardis 历史数据里
Hummingbot ✅ bitget_perpetual v2.0 连接器，2026 年 Bitget 官方合作。支持单向/对冲、限价/市价，有 Perp Candles Feed

用户最后问的就是「还有没有其他框架支持 Bitget」，答案是 Hummingbot—— 这个问题还没得到他的回应，需要先确认交易所再定框架。

其他信息：Hummingbot V2 的 PositionExecutor 结构恰好匹配我们的 「入场 + 止损 + 止盈 + 超时」，架构上契合。用户的费率表里还有一列空着的 HL （Hyperliquid），而 Hyperliquid 在 freqtrade 和 Nautilus 都是原生支持的。

5.2 网络：Bitget 必须走代理 ⚠️

直连  失败 NetworkError: bitget GET https://api.bitget.com/api/v2/spot/public/coins
代理  OK 2.39s  (http://127.0.0.1:7897)

盘口实测（BTC/USDT:USDT 永续）：bid 79492.7 / ask 79492.8， 价差仅 0.01bp，100 档深度。即时价差成本可忽略。

但代理会把延迟从几百毫秒放大到秒级，而 1m 那条腿的滑点预算只有 3.9bp。 实盘这条腿最终必须落到境外 VPS，否则测出来的滑点是代理的账，不是策略的账。

5.3 1m 那条腿的经济性（用户的核心问题）

用户原话：「1m 测的是返佣后是否能够不亏钱」，配合「一边刷交易额，一边走大点周期」。

1m 同向信号实测：3578 笔 / 2.28 年 / 3 币 = 524 笔/年/币， 毛均收益 +0.0991%，胜率 54.2%，平均持仓仅 8.3 分钟。

按 Bitget 真实费率算滑点预算：

档位 双边费率 PF=1 滑点上限 t>2 实用上限
VIP1 taker + API 返50% 0.060% 3.9bp ~2.5bp
VIP1 taker + 手动返60% 0.048% 5.1bp ~3.8bp
VIP2 taker + API 返50% 0.040% 5.9bp ~4.5bp
VIP1 maker + API 返50% 0.020% 7.9bp ~6.5bp

四条腿的滑点余量对比（VIP1 taker + API 返50%，即双边费率 0.060%）：

级别 笔数 毛均收益 平均持仓 滑点余量
1m 3578 +0.0991% 8.3 根 3.91bp
5m 1984 +0.3253% 9.7 根 26.53bp
15m 689 +0.4436% 12.1 根 38.36bp
30m 340 +0.9504% 11.7 根 89.04bp

1m 和 30m 的余量差 23 倍。

重要判断：1m 若失败，唯一的结论是「执行成本超了 3.9bp」， 绝不能拿它去否定 5m/30m。 三条腿的成本敏感度不在一个量级上。

风险点：入场条件恰好是「收盘突破转强」，那一刻价格正朝我们的方向跑， 所以延迟造成的是系统性的追高/追低，不会正负抵消。这正是 「回测漂亮、实盘歇菜」最常见的具体机制。

5.4 实时计算窗口（step39，已跑完）

research/step39_pit_1m.py（新写，已跑完：3 币 × 每币 60 信号 = 180 笔抽检）：

窗口(根) 覆盖天数 同根命中 ±3根内 完全消失 同向过滤也成立 假阳性 耗时中位 耗时P95
2000 1.4 100.0% 100.0% 0.0% 100.0% 0.0% 0.20s 0.22s
4000 2.8 100.0% 100.0% 0.0% 100.0% 0.0% 0.40s 0.42s
8000 5.6 100.0% 100.0% 0.0% 100.0% 0.0% 0.81s 0.84s
16000 11.1 100.0% 100.0% 0.0% 100.0% 0.0% 1.68s 1.81s

分币种（最大窗口）：BTC/ETH/SOL 各 60 笔全部 100% 命中，零偏移。

结论：1m 在 2000 根窗口（1.4 天）就已完全饱和，单次计算 0.20s，假阳性 0%。 比 15m/30m 的 step38 结果还干净（那里有 0.7% 假阳性）。耗时对窗口严格线性 （约 0.105ms/根），所以没有任何理由带更长的历史。

这一步顺带解决了一个更重要的问题：1m 的回测口径本身是可信的， is_sure 回撤对 1m 同样没有影响。1m 现在唯一的风险就剩执行成本。

⚠️ 延迟预算的分解（这直接决定 1m 生死）：

环节 实测 说明
信号计算 0.20s 2000 根窗口，可控
走代理访问 Bitget 约 2.4s 单次 REST 往返（含建连），这才是瓶颈

计算只占延迟的一小部分，网络是主要来源。所以影子交易器必须： 用 WebSocket 订阅而非轮询 REST 拉 K 线，并尽快把实盘迁到境外 VPS。 否则测到的滑点全是代理的账。

为什么这一步必要：step38 只验证了 15m/30m，从没验证 1m。而窗口 4000 根 对 15m 是 41 天、对 1m 只有 2.8 天，中枢的左边界效应完全不是一个量级。 窗口同时牵动两头：太短则中枢被截断信号不符，太长则算得慢延迟大滑点高。

6. 接下来要做的事（按优先级）

第 1 步：跑完 step39，确定实时窗口 ✅ 已完成

结果见 5.4 节。结论：影子交易器用 2000 根 1m 窗口，单次计算 0.20s。 完整输出在 research/out/step39.log 与 step39_pit_1m.csv，无需重跑。

（若日后要重跑：python research/step39_pit_1m.py --symbols BTC,ETH,SOL --probe 60 --workers 3，约 4 分钟。瓶颈不在窗口重建，而在 run_one 开头 那次 120 万根 1m 的全量 TF_DF。）

第 2 步：向用户确认交易所（当前的阻塞项）

这个问题必须他回答，因为它决定框架：

  • 留 Bitget → 只有 Hummingbot 支持，或用 ccxt 自己写执行层
  • 换 Hyperliquid / Binance / Bybit / OKX → freqtrade 和 Nautilus 都能用

他已选定先只上 1m（在我问「先从哪条腿落地」时选的 1m_first）。

第 3 步：写影子交易器测滑点（核心工作）

关键判断：测滑点不需要任何交易框架。 完整框架解决的是「如何可靠下单」， 而当前的未知量是「成交价会差多少」。所以先写一个不下单的影子跑法：

每根 1m 收盘 → 拉最新 K 线 → 算信号（窗口取第 1 步的结论）
           → 信号触发时抓真实盘口(bid/ask + 深度)
           → 按仓位吃单深度算出真实成交价
           → 等下一根 K 线出来，取其开盘价（回测假设的成交价）
           → 两者相减 = 真实滑点

必须把时间戳拆开记录，否则不知道该优化哪里：

时间戳 含义
t_close K 线收盘时刻
t_data 数据到手时刻 → 拉取延迟
t_signal 信号算完时刻 → 计算延迟
t_book 盘口快照时刻 → 下单时点

滑点应分解成三块：延迟漂移（t_book 中间价 − 次根开盘价）、 盘口价差（ask − 中间价）、深度冲击（加权成交价 − ask）。 预期延迟漂移是主项，价差可忽略（0.01bp）。

建议路径 research/live/shadow.py，复用 research/lib/ 下同一套信号代码， 这样两边数字直接可比。代码量约两三百行。

实现要点：

  • 数据格式必须与 lib/data.py 一致：timestamp(int64 ms), date(tz Asia/Shanghai), open/high/low/close/volume
  • ccxt 拉 Bitget 需 proxies = {'http': 'http://127.0.0.1:7897', 'https': ...} 和 options={'defaultType':'swap'}
  • 持仓也要影子管理：SL/TP/48 根超时，出场同样记录真实盘口
  • 状态要落盘，重启不能丢

第 4 步：根据滑点结果决策

  • 滑点 ≤ 2.5bp → 1m 可行，t>2，可以进入真实 dry run
  • 2.5~3.9bp → 1m 勉强不亏但无统计显著性，考虑争取 60% 手动返佣或 VIP2

  • 3.9bp → 1m 放弃，但 5m/30m 不受影响（余量 26bp / 89bp）

第 5 步（后续）：1m 与 5m 分实例

用户问过「1m 和 5m 分成两个实例跑呢？」——对，而且是硬要求： freqtrade 一实例只能一个 timeframe；另有资金池隔离、统计独立、 API 限流风险隔离三个好处。

⚠️ 有个坑要提前处理：两个实例可能在同一个币上同时持反向仓位 （1m 出三卖做空、5m 出三买做多），单向持仓模式下会互相平掉或直接报错。 要么开对冲模式，要么两个实例分配不同币种（币种够多，分开还能看出品种间差异）。

7. 环境与数据

7.1 数据

  • 位置：data/binance/futures/{SYM}_USDT_USDT-{tf}-futures.feather
  • BTC/ETH/SOL：全周期 1m1w，21722543 天
  • 另有 8 个样本外币种（BNB/XRP/DOGE/ADA/AVAX/LINK/LTC/TRX）： 48 个文件已全部校验，2020~2026-08-26，零缺口零重复
  • 读取统一走 research/lib/data.py 的 fetch_ohlcv(symbol, tf, limit)， 本地优先，回落到 https://provider.jackyu66.com（该服务只有 BTC/ETH/SOL， 且小周期仅 90 天，别指望它）

7.2 代理

本地代理 127.0.0.1:7897。Binance 和 Bitget 的 API 都需要它。

7.3 已修过的两个 bug（别再踩）

  1. 时间戳精度（lib/data.py）：不能用 date.astype("int64")//10**6， 该值单位取决于列精度（[ns] 给纳秒、[ms] 给毫秒），对毫秒精度的文件 会把时间戳砸平，再被 drop_duplicates 删掉九成数据。 正确写法：(date - pd.Timestamp("1970-01-01", tz="UTC")) // pd.Timedelta("1ms")
  2. 相邻中枢撞同一 entry_idx：会让下游 set_index("entry_idx") 抛 InvalidIndexError。已在 find_fast_bsp3 末尾按 ["entry_idx","occ","zone_i"] 排序后 drop_duplicates("entry_idx") 去重。

7.4 跑长任务的注意事项

  • 用 shell 工具的原生后台执行（block_until_ms=0）， 不要用 nohup——早期用 nohup 的后台任务多次莫名消失
  • 1m 全量数据（120 万根）的 TF_DF 约需 2 分钟，任何涉及 1m 全量的脚本 都要预留时间
  • 多进程用 ProcessPoolExecutor，记得在子进程里重新 sys.path.insert 并 warnings.filterwarnings("ignore")
  • 内存很大（用户说「随便用」），但 1m 全量 × 多进程仍可能吃掉几十 GB

8. 代码地图

8.1 研究库 research/lib/

文件 作用
data.py 数据层，本地 feather 优先
fast_bsp3.py 核心：自研低滞后第三类买卖点。滞后 2.2 根
nested_level.py build_htf_zones：构建中枢，可传入已建好的 chan 复用
nested_bsp.py htf_fx_timeline / attach_htf_context：区间套上下文。
confirm_ts 已 +period 修正 K 线收盘时刻
fx_signal.py 分型信号提取与背驰
breakout.py 事件驱动回测。run_trades 支持 entry_delay/slippage/
boost_dir（动态止盈，已验证无效）

8.2 缠论引擎 chanlun/

  • TF_DF(df, 1, tf) 是入口，.dataframe 拿到含缠论标注的 DataFrame
  • pipeline/builders/incremental.py：增量更新（init_stream / append_bar / replace_last_bar / rebuild_bi_zs）。注释写明「最后一笔 is_sure 允许收回」， 这是 step38 要验证的那个隐患（已证实无影响）。 实盘若要用增量而非全量重算，需重新验证
  • pipeline/orchestrator.py：TF_DF 方法的门面
  • web/：图表与分析服务，无下单/订单管理功能，实盘用不上

8.3 实验索引

step 一句话
1~14 早期探索：信号有效性、滞后测量、直接预测收益（后发现有未来函数偏差，已弃）
15~18 区间套雏形；fast_bsp3 诞生（降滞后）
19~20 级别配对批量扫描 + 并行化
21 最优配置的尽调（尾部依赖、成本敏感）
22 执行压力：收盘价 vs 次根开盘、滑点
23 费率分档 + 刷量测算（1m 经济性的数据来源）
24 信号聚簇：同一大级别分型下的多信号是否独立（是）
25 同中枢重复入场（只做首次）
26 中枢阶梯序列（趋势 vs 盘整，印证缠论定义）
27 动态止盈（无效）
28 全级别矩阵（最优配置来源）
29 信号漏斗诊断 + 参数敏感性
30/31 引擎原生 B3/S3 对比 + 方向反转诊断（引擎信号因滞后而亏损）
32 消融研究（alpha 来自中枢上下文，非触发动作）
33 require_touch=False 的影响（显著提升）
34 tol 扫描（滞后与收益严格单调）
35 高收益审计（口径、滑点、并发）
36 偏差审计（生效时刻、多空、时间样本外）
37 跨品种样本外（8 个新币）
38 时点重建（无未来函数）
39 1m 时点重建 + 窗口扫描（新写，待跑完）

输出都在 research/out/。2026-08-27 清理过一轮：step1~20 的输出（早期方法论 已被推翻，含未来函数偏差）与旧口径备份一并删除，只留支撑当前结论的证据。 脚本都还在，需要时可重跑。step31 及之后的 .py 都在 research/ 下。

9. 与用户协作的注意事项

  • 用中文回复（用户规则）
  • 用户技术判断力强，会主动纠正方向（他纠正过我对区间套的理解、 指出内存回收、指出结论印证缠论定义）。他的领域直觉值得认真对待
  • 他反复强调不要再调参，要落地验证
  • 他讨厌长时间等待，早期多次问「还在跑吗」「好了吗」。 长任务要后台跑并主动汇报进度，不要让他干等
  • 报数字时必须交代口径（复利/杠杆/费率），否则会误导

10. 待办清单

  • step39：1m 时点重建 + 窗口扫描 → 2000 根窗口饱和，计算 0.20s， 假阳性 0%，1m 回测口径可信
  • 向用户确认交易所（阻塞后续框架选择，这是当前第一件事）
  • 写 research/live/shadow.py 影子交易器，测 1m 真实滑点。 务必用 WebSocket 而非 REST 轮询——代理下单次 REST 往返约 2.4s， 而信号计算只要 0.20s，网络是延迟主项
  • 收集 1~2 周影子数据，与回测口径逐笔对比
  • 按 6.4 的判据决策 1m 是否可行
  • 若可行：选框架（Bitget→Hummingbot）做真实 dry run
  • 补一项研究阶段的缺口：资金费率从未计入任何回测。 30m 腿平均持仓 6.5 小时会跨结算点，需要评估影响
  • 补：同时持仓的保证金约束也未建模（组合有仓位时间仅 8.6%， 预计影响小，但没算过）
Reference in New Issue View Git Blame Copy Permalink