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

500 lines
23 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 缠论信号研究 → 实盘落地：交接文档
> 最后更新：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 交易执行口径
```python
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 盘整」：当前中枢相对前一个中枢是否同向推进。
```python
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）：2019~2022 挑参数，2023~2026 验证 →
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：全周期 1m~1w，2172~2543 天
- 另有 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. 待办清单
- [x] **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