jack/Chan
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
349 Commits 9 Branches 1 Tag
1ffc4fbb188162255e2f3e6c12f9e447cb6c6008
Commit Graph
349 Commits
This Branch
This Branch
All Branches
Author SHA1 Message Date
jackyu66gitandCursor 1ffc4fbb18 时段（亚/欧/美）是噪声，周日效应真实但与 mom60 过滤不可加 
用户问哪个时段更容易盈利。答案分两半：时段这个切法本身无效，换成星期几才
有东西，而那东西不该做成新过滤。

① 亚/欧/美三等分（UTC 0/8/16），毛R 1.127 / 1.006 / 1.079，段间极差 0.122，
置换检验 p=0.0895——随便把 24 小时切三份，9% 的概率能切出这么大的差。更要命
的是美盘两个时期反号：样本外 1.158（最好）→ 发现期 0.885（最差），噪声的
典型指纹。按真实开盘时刻切五段、把欧美重叠单列，结论一样。

这里不是输给 ATR 混淆。亚盘 ATR 中位确实最低（12.5 vs 14.1），本来最该是
混淆源，但控 ATR 后段间极差 0.101/0.108，和无条件的 0.122 几乎一样——时段
不是 ATR 的代理，它本来就小。

② 星期几有信号，集中在周日：毛R 0.893、胜率 66.6%、PF 2.76、余量 13.08bp，
对照周五 1.228 / 74.7% / 4.78 / 23.44。置换检验周日 p=0.0079、周末 p=0.0246，
两个时期方向一致，10 个币里 7 个周末更差（BTC 最甚 -0.336）。但幅度在发现期
塌了大半（-0.168 → -0.039）。

③ 关键在重叠。施加 step53 的 mom60<7 之后，周末差从 -0.132 缩到 -0.058、
周日从 -0.199 缩到 -0.104。重叠不在笔数上（mom60≥7 在周末占 22.9%、工作日
21.3%，几乎一样），是伤害重叠：周末真正亏钱的是那些追已走完行情的单子。
周末流动性薄，追高的代价被放大——这和 §3.391「势不能过头」是同一件事在另一
个维度上的投影。

④ 所以不加。决策表（发现期总R）显示 mom60≥7 + 周日 在 0~20bp 每一档都输给
mom60≥7 单用（5bp: 574 vs 658；10bp: 343 vs 394；15bp: 113 vs 131），叠加
只是白丢 10% 笔数。单用砍周日也要 12bp 以上才赢过等权。

这一步的价值是排除。「美盘流动性好该更赚」这种直觉很难自证伪，跑完才知道它
连随机切分都跑不赢；而顺手捞到的周日效应统计上真实，却因与已有过滤重叠而
不可加——显著和值得做是两件事，中间隔着一张决策表。

分析全部复用 step53 的 feather，未重跑采集。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-28 19:23:39 +08:00
jackyu66gitandCursor 17fe965a7c HANDOFF 跟上服务端：5.72 标题回退到旧结论，四条待办已完成 
拉取后对表，文档有几处和代码脱节：

1. §5.72 标题还写「inner_ms 的 3.3 倍是争抢」，而正文经 af029bc 已更正为
   1.49x。扫标题的人会被带偏，改成 30ms 地板 + 37ms 缓存浪费 + 1.5x 争抢。

2. 「实盘信号计算改用增量」已上线（§5.7，清空十币 560→247ms），标完成，
   并把「重建不要用 init_stream」这个坑记在同一条上。

3. 「shadow_report 的 BUDGET_BP」和「live 补中枢阶梯 + ATR 门控」都已做完
   （前者改为从 lib/shadow_budget import，后者见 shadow_signal.py:11-18），
   标完成并保留当初的理由，那两条的判断过程比结论有用。

4. §5.72 新发现的两个杠杆之前只在正文里，没进待办，补上：按币绑 worker
   （省 inner_ms 三分之一）与 add_indicators 增量化，并写明二者是叠加不是
   二选一，以及后者的拦路石是 Wilder RSI 的 avg_gain/avg_loss 状态。

另外给 mom60≥7 那条待办补一句现状：live 路径的三道过滤是同向 + 阶梯 +
ATR 门控，mom60 连算都没算，要上得先在信号侧补出这个字段。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-28 19:23:39 +08:00
jackandCursor 881cc5e77d 补上「一个币一个仓位、账户专用」这两个没落在代码里的前提 
三处都源于同一个隐含假设从未被写成代码。

① 同币并发会让 pnl_day 翻倍。blocks() 只查幂等键与三条计数闸，没有按币的
占用检查。同币开两笔时交易所净成一个仓位，于是 watch() 按 pair 判出场会让
两个 key 同时进 gone，_match_hist 给它们返回同一条历史记录，realized() 被
调两次。而 pnl_day 正是 MAX_DAY_LOSS 读的数：亏损翻倍提前停机，盈利翻倍让
闸变迟钝。sweep() 也会在第一笔截止时平掉合并后的整个仓位。

合并后的行为（一个止损、两个不同价位的止盈、超时一锅端）不是任何一版回测
建模的东西，所以在 on_signal 里跳过第二个信号，是最接近安全的近似。期望并发
0.18 笔，损失极小。另外给 _match_hist 加 positionId 独占认领，让这个不变量
在记账处本地成立，而不是依赖两百行外的检查——花钱的路径值得两道。

② positions() 返回账户全部仓位，三个调用点都没过滤。账户上任何第三方仓位
都会被 reconcile 在重启时市价平掉，而 watch() 会因该 symbol 一直在场而永不
结算，MAX_OPEN 名额泄漏、pnl_day 不再更新。加 PAIRS 过滤与 my_positions()。
残留局限记在注释里：同币上的第三方仓位仍分不出来，账户仍应专用。

③ oid_of 把非字母数字换成下划线，理由是 : 和 + 未必被接受，但调用方又拼了
"-tp" 把 - 加回去，自相矛盾。真被拒时止盈单会全部挂不上，而那条路径只告警
不停机，收益结构静默退化成「只有止损 + 超时」，且空跑验不到（dry 返回假
成功）。改用 _tp，并把字符集约束写进 oid_of 的文档。

实测：同币第二个信号被挡、别币放行、独占认领不重复计账、PAIRS 排除
PEPEUSDT、全部 clientOid 只含字母数字下划线。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-28 18:58:47 +08:00
jackandCursor 5ffbadb0b2 setup_symbols 不再无条件报"已设好"，失败要说出来 
那行"已设 N 个币为逐仓 10x"原先无条件打印，20 次调用全失败也照样这么说。
日志里写假话比不写更糟。而且这段只在真跑模式执行，空跑从没碰过它，第一次
运行就是上实盘的那一刻。

杠杆设失败是有经济后果的：仓位大小由名义额算、与杠杆无关，但保证金要求会
变。若交易所侧实际是 1x，每笔需 100 USDT 保证金，第 2、3 笔必然失败，且
可能只成一条腿、静默变成半仓——收益结构从「50% 在 3 ATR + 50% 在 8 ATR」
变成别的东西。

现在按失败项数如实报告，并推一条 Telegram。不硬性阻止启动：真正的失败会在
下单时暴露，但日志必须诚实。

实测全部成功/一项失败/全部失败三种情形。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-28 18:41:37 +08:00
jackandCursor 668ebe1e44 探针把 40014 判为最小权限的正常表现，并翻译 parentId/权限/白名单 
Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-28 18:36:10 +08:00
jackandCursor f62b4f62a5 加只读探针定位资金所在账户：子账户/现货/币本位/USDC 本位一次看清 
Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-28 18:29:23 +08:00
jackandCursor c513455998 余额不足时算出能开几笔，并点明半仓风险：两条腿分别下单，第二条失败会静默改掉收益结构 
Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-28 18:25:35 +08:00
jackandCursor 7435cef61f 空跑打全余额字段：逐仓下管用的是 isolatedMaxAvailable，只看 available 会误判 
Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-28 18:23:57 +08:00
jackandCursor 9562b8c598 空跑补一次带签名请求，否则密钥与白名单根本没被验到 
dryrun 第 5 步声称"会真实验到密钥与白名单"，但 start() 在空跑下于密钥检查
之前就 return，全程只发了 contracts() —— 那是公开端点，不验签。于是空跑会
"通过"却什么都没测到。这种假保证比不测更糟：等第一个真信号来时才暴露，而
信号那时正在过期，没有从容排查的余地。

现在空跑返回前发一次 account()（只读），失败即退出并给出码表（40018 白名单
/ 40037 key 不存在 / 40001,40009 secret,passphrase / 40099 权限）。顺带报
可用余额，并在不足 MAX_OPEN 笔并发所需保证金时告警。

两处 SystemExit 会绕过 run() 的收尾，退出前不关 aiohttp 会话，日志尾部一串
Unclosed client session 会把真正的报错顶出视野。都补上了 close()。

BITGET_PASSPHRASE 现在也接受 BITGET_API_PASSPHRASE：另两项都带 API_，只有
它不带，很容易顺手写错，而后果是"像是填了"但签名一直失败。我自己就踩了。

启动时打一行 Telegram 是否启用。配错 token 的表现原本是完全静默。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-28 18:17:53 +08:00
jackandCursor d797adc77e dryrun: timeout 套进 sudo 内层，否则 SIGTERM 未必传到 ssh 
Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-28 18:09:29 +08:00
jackandCursor 040810d48d known_hosts 校验命令补 sudo：.ssh 是 700 chan，ubuntu 读不了 
Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-28 18:02:54 +08:00
jackandCursor d884de2c36 dryrun 的 ssh 探测适配强制命令，并分清指纹与认证两种失败 
采集机那侧的 authorized_keys 用了强制命令，把这把 key 锁成只能跑 tail，
拿不到 shell。副作用是任何请求都变成 tail -F 而它永不返回，原先
`ssh <host> 'echo ok'` 的探测会永久挂住——ConnectTimeout 只管建连，不管
命令时长。改成照 ship_signals 的真实用法读流：tail -c +0 先吐出整个文件，
数行数就等于对端总线条数，之后由 timeout 收掉。

失败诊断原先一律说"装 key"，但 Host key verification failed 是 known_hosts
空的，装 key 修不了，会把人引到错方向。现在分三类：指纹未确认、认证被拒、
其他，各给对应做法。指纹那条明确不建议 StrictHostKeyChecking=no——这条链路
上跑的是下单信号。

install.sh 的第 2 步补上 known_hosts：原先只说装 key，而服务跑起来会撞同一
个墙（BatchMode=yes 不允许交互确认）。

实测：强制命令下故意请求错路径，仍拿到真总线内容且 stderr 干净。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-28 18:01:01 +08:00
jackandCursor b6ed5c8b50 on_signal 校验字段，畸形记录只丢一条而不是停掉交易 
on_signal 直接取 r["emit_ms"]，总线上一条字段不全的记录就会抛 KeyError
打死 poll 任务，进而整个执行器停止交易。一行坏数据换全面停摆，代价不对等。
搬运侧已挡半行，但挡不住字段级的不全。

现在缺 key/sym/emit_ms/direction/entry_px/atr_pct 任一项即丢弃该条，记日志
并推一条 Telegram（这类事应当可见，否则只是少做几笔，统计上看不出来）。

实测：两条字段不全 + 一条非法 JSON + 一条正常，前三条分别被丢弃/被
read_all 吞掉，正常那条照常下单，进程存活。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-28 17:57:24 +08:00
jackandCursor 999ad924ad install.sh 报出模板新增的配置项，并给 --sync-env 追加 
live.env 装着密钥，所以安装时刻意不覆盖。但这样一来，往 live.env.example
里加配置，已有部署会永远拿不到、且毫无提示——静默漂移，等到某个开关根本
没生效才发现。这次加 TG_TOKEN 就撞上了。

现在重复安装会 diff 两边的变量名：报模板多出的项（提示跑 --sync-env），
也报配置里已被模板删掉的项（可能已废弃）。

--sync-env 独立成一个模式而不是塞进安装流程：追加要改一个装着密钥的文件，
这种事应当由人显式发起。只追加缺的项、连它上面的注释一起，不动已有任何
一行，先备份。实测原有内容逐行未变且重复跑幂等。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-28 17:45:48 +08:00
jackandCursor 15f4aa088e 加 Telegram 通知，并修好一道死掉的闸 
接 Telegram 时查出 Guard.realized() 定义了但全仓库没有调用点——pnl_day
恒为 0，MAX_DAY_LOSS 完全不生效。三条硬约束里最重要的一条是死的。

根因是止损与止盈都挂在交易所侧成交，本进程收不到通知，而 sweep 只在 48
分钟到点才查持仓。连带第二个后果：execs 条目不清，MAX_OPEN 把已出场的
仓位继续算在场，新信号被白挡到截止时刻。

补 watch() 循环（10s）：持仓消失即判出场，去 history-position 取
netProfit（= pnl + 资金费 + 开平手续费）记回闸并释放名额。盈亏取交易所的
数而不自己按标记价估——估会漏掉费用且方向总偏乐观。历史未落库时留到下轮，
不会漏记。字段名按文档与官方 TS 类型的差异同时兼容 ctime/cTime。

Telegram（live/tg.py，stdlib + aiohttp）：推开仓、平仓带已实现盈亏、被硬
约束挡住、报错、对账平仓、跨日结算、启动与停机。不推信号过期跳过（常态，
搬运重连会重放旧信号）与心跳，否则真事会被淹掉。启动那条兼作通道自检。
研究侧 tg_notify.send 改为复用生产的传输层，方向与 signal_bus 一致。

status.sh 增加一条判读：开过仓但 pnl 仍为 0 就是 watch() 出了问题。

实测：8 类消息渲染、_match_hist 的过早/方向不符/币不符/驼峰字段/取最近
五种情形、100 USDT 下 SOL 与 ADA 的端到端空跑（两腿等量，50/50 精确）。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-28 17:30:11 +08:00
jackandCursor 3e3d579e35 文档与实现对齐：停机是 SIGTERM 且会平仓，补充崩溃/主动停机的差异 
Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-28 17:13:56 +08:00
jackandCursor 1642b1bbfc 补上停机处理：SIGTERM 撤挂单平仓再退，并关掉 aiohttp 会话 
README 里原先写「执行器收到 SIGINT 会先平掉在场仓位再退出」，但代码里
完全没有信号处理——asyncio.run 外面连 except KeyboardInterrupt 都没有。
断言了一个不存在的行为，现在把它实现。

为什么停机要平仓而崩溃不用：崩溃后 systemd/docker 几秒内重启，reconcile
接着清掉遗留仓位，空窗期有交易所侧止损兜着。而主动停机后没人重启，仓位会
一直挂到止损或止盈，48 分钟超时腿丢了，跑的就不是回测那个出场结构。

必须显式挂 SIGTERM：docker stop 与 systemd stop 默认发的都是它，而 Python
对 SIGTERM 不抛 KeyboardInterrupt，不挂就是直接消失、没有任何清理。挂上后
systemd 单元里 KillSignal=SIGINT 那个绕法也去掉了。

主循环因异常退出时同样走停机流程，不把仓位留给已经没人管的进程。
顺带修掉 "Unclosed client session"（bitget_rest 本有 close() 但没人调，
Restart=always 下会漏 socket）。

实测：发 SIGTERM 后走完停机流程、无泄漏警告。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-28 17:12:41 +08:00
jackandCursor 335d891478 生产与研究分家：实盘执行器独立成 live/ 子树，加 AWS 部署 
实盘要跑在 AWS（API key 绑了 IP 白名单），而信号在新加坡那台算。借这次
把生产从研究侧摘出来，四条具体代价里第一条已经咬过：

1. live_state.json 原先落在 research/out/，而那里 shadow_hb 会自动 rename
   归档、研究脚本会写、人也手工清过。那文件装的是 MAX_DAY_LOSS 累计与已
   处理信号键，被清掉不报错，只是两道闸静默失效。改到 LIVE_HOME。
2. 采集器十币清空 300~560ms 直接叠在信号到达执行器的延迟上。
3. 研究侧探针 OOM 过一次（14.9GB），当时若有仓位在场会连坐执行器。
4. 为读两个常量 import 研究侧 step43，把 numpy/pandas/pyarrow 拖进实盘
   进程。抽出 stdlib-only 的 live/exit_params.py，install.sh 加断言挡回归。

新增 live/ship_signals.py：AWS 侧 ssh tail 拉总线，每次重连从文件头重放
+ 按幂等键去重，断线期间的信号自愈；旧信号由 staleness 闸挡掉不补做。
带时钟倒流检测——两机时钟不同步会让那道闸静默放宽。

部署件：systemd 两单元（搬运挂了执行器仍管在场仓位的超时平仓）、
install.sh、dryrun.sh（验密钥/白名单/时钟/ssh/取整）、status.sh、README。

验证：live_exec 重构后端到端空跑，SOL 多头与 ADA 空头的止损/两级止盈/
数量取整逐项核对正确，isolated + post_only + reduceOnly 都在；搬运的去重、
重启不重复追加、脏数据跳过、断线重连重放均已测。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-28 17:03:03 +08:00
jackandCursor af029bc26e 更正上一提交：争抢是 1.5x 不是 3.3x，并发现按币绑 worker 可省三分之一 
上一提交的 3.3x 基线是废的：离线每次喂同一窗口，append_bar 一根没追
（实测 6 次调用 stream 2001→2001 零增长），测的只是信号链地板 30ms，
拿它比在场 inner_ms 又是一次口径不对齐——和刚撤回的 22/86 同一类错。

对齐后：在场每次平均追 2.81 根（2 worker 各存一份缓存、各自漏掉对方
处理过的根），离线同口径 67.3ms，在场 100ms → 争抢 1.49x。
顺带修正「重建占 21.5%」：真重建只有 0.31%，此前把换 worker 的小幅
回退误判成重建。

新杠杆：symbol 固定到同一 worker，每次只追 1 根，离线 67.3 → 45.0ms，
在场约省 33ms/币（inner_ms 三分之一）。心跳判定改指这一刀。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-28 16:23:02 +08:00
jackandCursor cef894376c 定位 inner_ms 的 3.3 倍：是争抢不是算法档，撤回 22/86 拆分 
服务端跑 probe_inner.py 与本机对表：分档占比一致（TF_DF 两腿 68~74%，
信号链 16~21ms），此前报的「chan 构建 22ms / 信号链 86ms」是无效减法
——孤立环境的 1m append 减在场十币的 inner_ms，还漏了 5m 腿。

真实构成：inner_ms 100ms = 约 30ms 计算 × 3.3 倍争抢。逐个排除
_rebuild(1.6ms)、币种差异、周期重建(21.5%/1.5x)、批内次序(相关-0.083)
后，用外生的到达密集度确认（67→117ms），并以注入合成负载复现
（2 个满载进程 2.68x，3 个 2.86x，在场实测 2.24~3.34x）。

心跳判定不再推荐「继续压算法」，改为加核或减币。

第一版用 t_signal-inner_ms 反推并发区间得相关 0.533，是循环构造，
已废弃并在 §5.72 记下这个坑。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-28 16:19:25 +08:00
jack be442783a1 Merge branch 'chan' of ssh://git.jackyu66.com:2222/jack/chan into chan 2026-08-28 16:07:28 +08:00
jackandCursor f11c6507b0 实盘执行改走 Bitget v2 REST，止损挂到服务端 
丢掉 Hummingbot 的 PositionExecutor。它的连接器只暴露 LIMIT / LIMIT_MAKER /
MARKET，没有触发单，于是 control_stop_loss() 只能本地盯价、触发时才发市价单
——**进程一死仓位就是裸的**。而交易所本身支持 place-order 带
presetStopLossPrice，下单时就把止损挂到服务端。绕过连接器不是图省事，是为了
消掉一整类故障。顺带 TripleBarrierConfig 只有单级止盈，装不下两级，自己写更短。

## 三条出场腿各自挂在哪

    止损   交易所侧（presetStopLossPrice，随入场单一起到）→ 进程死了仍在
    止盈   交易所侧（post_only reduce-only 限价）        → 进程死了仍在
    超时   本进程，48 分钟到点市价平

所以进程死掉只会让持仓超过 48 根，不会变成裸仓，退化是良性的。

## 止盈不能用 presetStopSurplusPrice

它触发后按市价执行，而成本模型里止盈是 maker——那 60% 的出场不吃滑点、按
maker 费率计（LEG_IS_TAKER）。用 preset 会让这部分变成 taker，预算就不成立。
所以止盈单独挂 post_only + reduceOnly 限价单。止损反过来必须市价：stop-limit
在急跌里可能不成交，损失远大于省下的费。

## clientOid 是交易所级幂等，但要小心两个坑

信号键形如 SOL:1787904388411:+1，`:` 和 `+` 未必被接受，带过去直接拒单——而
拒单发生在入场腿上，等于这笔信号静默漏掉。

清洗时不能简单把非字母数字换成下划线：那样 `+1` 和 `-1` 都变成 `_1`，同一根上
的多空信号得到相同 oid，第二笔被当重复拒掉。方向显式编码为 L/S。

用 clientOid 而非只靠本地去重，是因为「已发出但没收到回复」这种情况本地判不了，
重试就会开两次仓。

## 空跑要走完 open_position

第一版在 on_signal 里 `if dry: return`，结果数量取整、价位对齐 tick、请求体
构造全都没被验到。现在空跑走完整条路径，不下真单由 Bitget(dry=True) 负责。

实测两笔：SOL 多头 entry 106.706 / ATR 11bp → 止损 106.471、止盈 107.058 与
107.645；BTC 空头 → 止损在上方 79747.5、止盈在下方。半仓精确一半（SOL 2.3+2.3、
BTC 0.0031+0.0031）。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-28 16:07:28 +08:00
jackyu66gitandCursor bfdb2f2e2a 引擎四处「算了没人要的东西」，append_bar 13.9ms → 6.6ms 
服务端把增量上线后回传两个热点：add_indicators 为加一根重算全表（占 34%）、
cal_bi_list 整表重扫（51%）。顺着查下来四处都不是算法慢，是算了没人读的结果。

1. cal_trend 挂到 lean 下。它不是笔的依赖（bi.py:221 在它自己的循环里读自身
   序列状态），服务端 verify_incr_parity 三币 1800 根已对拍定论。web 走非
   lean，klc_trend 图层不受影响。

2. check_fx_pattern 删掉拼完就丢的字符串。它把 klu.to_string() 拼成 p 只为
   一行注释掉的 print——2000 根上近 3 万次 f-string 加 6 万次 enum 格式化，
   而且在 cal_bi_list 内层。klu.pattern 只被 cal_klu_pattern 自己的双K/三K
   判定读，不出模块不进 web，所以整个调用在 lean 下也跳过。

3. ChanBI.add_klc 去二次方。去重原本线性扫 klc_list，且每加一根就把整笔所有
   KLU 的 macdhist 重累一遍，往一笔加 k 根是 O(k²)。改成下标集合加
   macd_hist/macd_div 惰性求值。这两个值只有背驰判定（bsp.py）读，lean 下
   bsp 根本不算。

4. add_indicators 批量挂列。2001 行上 TA 计算合计只有 2.5ms，而 30 多次
   df['x']= 要 3.6ms——开销大头是 BlockManager 逐列插入不是计算，改为一次
   concat。cal_volume_ratio 里为算一列 rolling 而 copy() 整张 40 列表，一并去掉。

实测（本机，2001 根窗口。服务端基线 21.8ms 是另一台机器，别直接比绝对值）：
  append_bar        13.9 → 6.6ms
  └ rebuild_bi_zs    8.7 → 2.8ms
  └ add_indicators   4.4 → 3.5ms
  TF_DF lean        49.8 → 32.9ms
  TF_DF full        72.7 → 64.9ms

对拍用 git worktree 检出改动前的提交，同一份 BTC 1m 4000 根跑 38 项指纹：
full 模式 19 项全部一致（web 那条路没动）；lean 模式差 2 项，正是设计要它差
的 klc.trend 和 klu.pattern，而 lean 下 bi/zs/seg/bsp/dataframe 全部一致——
这就是「这两个字段没人读」的实测证据：打空它们，下游一位不变。

瓶颈已经换位置了。新增 probe_inner.py 拆 inner_ms 分档：本机 TF_DF 两条腿占
70%、build_htf_zones 13%、htf_fx_timeline 6%，而服务端报的是 chan 构建 22ms /
信号链 86ms，机器差解释不了这个四倍差距。曾怀疑是 payload 反序列化，实测
_rebuild 只有 1.0ms，假设不成立。两边跑同一探针对分档表才能定位。

HANDOFF 顺带修掉一处 5.6 重号（增量落地那节改为 5.7，本节挂 5.71）。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-28 16:01:26 +08:00
jackyu66gitandCursor 06928d1d5f 开仓前那段：量要小、势要有但不能过头，换掉 vr60 那个开关 
用户提出看开仓之前的量与趋势方向。这是第三个位置——step50 管信号根、
step52 管持仓中，这里管入场前。step48 采集端补 vpre10/vpre30/mom10/mom60。

先纠正一个错的心智模型（我和用户都以为的）：B4/S4 不是回抽后进场。mom10
中位 +3.47 ATR，为负的只占 6%。信号触发时价格在前 10 根里已经顺着你的方向
走了三个多 ATR，2 ATR 止损是架在一段已经走完的行情后面。这也解释了 step50：
信号根是突破根，放量 = 追在最后一棒上。

① 入场前的量单调，越小越好（样本外毛R，Q1→Q4）：1.474 / 1.266 / 1.156 /
0.573。控 vr60 后仍成立（低量层 −0.284、高量层 −0.541），与 vr60 相关只有
+0.301，不是同一件事换个说法。

② 入场前的动量是驼峰形，不是单调（mom60 样本外毛R，Q1→Q4）：1.252 /
1.473 / 1.141 / 0.603。势要有——完全没动过的 Q1 也不如 Q2；但不能过头——
Q4 在发现期余量只剩 1.44bp，等于不能做。

驼峰形意味着中位数二分法会把它测没：控制表里 mom10 的毛R差是 +0.044，
看着无效，那是二分把 Q1+Q2 和 Q3+Q4 各自平均了。对非单调因子不要用中位数
分层做检验。

③ 砍 mom60≥7 全面优于 §3.39 定的砍 vr60≥4（发现期）：

  等权          保留 100%  盈亏平衡 13.5bp  R夏普 0.325  回撤 16.8  总R 596.6
  砍 vr60≥4     保留  69%  盈亏平衡 15.6bp  R夏普 0.411  回撤 10.8  总R 514.9
  砍 mom60≥7    保留  78%  盈亏平衡 17.5bp  R夏普 0.476  回撤  7.7  总R 657.7

每一项都赢，还多留 9 个点的笔数。更要紧的是总R 比不砍还高——被砍掉那 22%
期望为负，砍掉不是花钱买稳健，是纯赚。样本外同向。所以这个开关不需要等
影子测量：它在 0~20bp 每一档都不输等权。

附滑点决策表：5~12bp 区间砍 mom60≥7 通吃，只有 ≥15bp 才该上「三个都砍」，
而那时策略本身已在生死线上。

阈值 7 和 1.5 是贴着 Q4 边界取的整数，不是搜出来的，但也不是完全无关于数据
（看过分位表才取的整），上线前应确认阈值附近没有断崖敏感。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-28 15:55:49 +08:00
jackyu66gitandCursor 431e776905 持仓中放量不是出场信号，恰恰是最好那批单子的标记 
用户问：既然 step50 证明入场根放量是接盘，那持仓中出现放量根是不是也说明
这一波走完了、该直接平掉？测下来方向是反的，且比入场那条还干净。

规则：持仓期间任一根 vr60 ≥ 阈值就收盘市价平掉（taker）。同根内优先级
止损（盘中）> 目标（盘中）> 放量平仓（收盘）。10 币 3941 笔：

  基线（不看量）  毛R 1.068  R夏普 0.627  PF 3.80  余量 18.45bp  均持仓 30.0
  vr60≥3 就平    毛R 0.617  R夏普 0.459  PF 2.81  余量  7.81bp  均持仓 11.1
  vr60≥5 就平    毛R 0.858  R夏普 0.568  PF 3.37  余量 12.85bp  均持仓 19.8
  vr60≥8 就平    毛R 1.009  R夏普 0.617  PF 3.69  余量 16.68bp  均持仓 26.3

阈值越高、触发越少就越接近基线——这条曲线的最优点是「永不触发」，规则纯扣分。
「浮盈才平」的变体把胜率抬到 74.4%（基线 71.7%）而毛R 掉到 0.655，是过早
止盈的教科书特征：胜率上升、期望下降。

根因：vr60≥5 触发的 1769 笔若不平，止盈率 45.7%、止损率 16.6%，而全体基线
是 30.1% / 33.1%。持仓中的放量根标记的是最好的那批单子，平掉每笔让出 +0.484R。
幸存者偏差已控——按基线持仓 ≥K 根分层后 5/5 档同向，放量组止盈率约为无量组
两倍（K=5 时 41.2% vs 19.8%）。

同一个事件入场为负、持仓为正，区别只在站在它的哪一边：入场那根放量你是买方，
持仓中那根是资金来接你的货。用户「有资金的趋势才是好趋势」的直觉成立，
作用点在持仓期而非入场点。

自带逐根模拟器不走 walk_exits，所以先与它对拍基线（毛收益差 <1e-12、出场
原因零分歧），10/10 币通过才往下算。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-28 15:55:49 +08:00
jackandCursor 360e4e1c41 自动化实盘执行器：信号总线 + 两个半仓分解 + 四条硬约束 
## 架构：影子发信号，实盘执行，两个进程

不让实盘自己算信号。前两个理由是资源与隔离（2 核上再来一份十币计算会把清空
从 247ms 推到 500ms+；实盘崩溃不该影响正在采的数据集），第三个最要紧：
**实盘交易的必须是影子测量的那一个信号**。各算一份会让两边悄悄分叉，之后就
没法把实盘实际成交和影子测的滑点曲线对照——而那个对照是整件事的目的。

总线用 append-only JSONL + fsync：崩溃安全，且「影子在跑、实盘没在跑」会表现
为信号在攒着，而不是静默丢弃。

## 出场结构精确分解成两个半仓

TripleBarrierConfig 只有单级止盈，装不下 3ATR 减半 + 8ATR 目标。但已核实
exit_model.py:151 的 runner_stops 是从**入场价**算的（ret = (entry-low)/a），
且 RUNNER_STOP == SL == 2.0，所以两半共用同一个不动的止损，可精确分解为：

    半仓 A  市价入场 · TP 3ATR · SL 2ATR · 48min
    半仓 B  市价入场 · TP 8ATR · SL 2ATR · 48min

止损先到则两半都在 -2ATR 出场；3ATR 先到则 A 出场、B 继续且止损仍在 2ATR。
与回测逐情形一致。assert_decomposable() 在启动时挡住 RUNNER_STOP != SL 的
改动，否则实盘会跑另一个收益结构且不报错。

## 硬约束是这个文件的重点

一笔止损只亏约 1 USDT，所以「亏损可控」对单笔成立。但三类故障的代价**不随
仓位缩小**，必须显式封住：失控下单（MAX_OPEN=3 / MAX_DAY=15）、亏损累积
（MAX_DAY_LOSS=20）、裸仓（重启对账）。状态落盘且原子替换——不落盘的话反复
重启就等于反复重置日上限，而失控下单恰好常伴随反复重启。

已验：幂等去重、并发上限、日开仓上限、日亏损上限、跨日归零且保留 done 键、
重启后计数不清零、状态文件损坏时不抛异常。

## 重启对账选择平掉而非接管

崩溃重启后交易所可能还有仓位，而 executor 全没了，那些仓位没有任何止损在盯。
接管需要重建入场价/ATR/剩余半仓状态/已过根数，任一项猜错就让出场结构变成
另一个东西；平掉的代价只是一笔小额亏损，且行为确定。

## 已知风险：止损在机器人侧

Bitget 连接器只支持 LIMIT / LIMIT_MAKER / MARKET，无触发单。
PositionExecutor.control_stop_loss() 是本地盯价、触发时才发市价单，所以进程
一死仓位就是裸的。10x 下强平需逆向 10%（约 100 个 ATR），48 分钟内极不可能，
单次代价仍封在保证金内。下一步用 Bitget 服务端 TP/SL 计划单做兜底。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-28 15:52:03 +08:00
jackandCursor f716ddd149 推送带杠杆与保证金，名义额默认抬到 500 
杠杆只影响占用保证金，**不改**名义敞口、手续费、滑点、盈亏绝对值——费与滑点
都按名义额收。所以「用杠杆所以可以很小额」这个方向要说清：杠杆省的是本金
占用，不是成本。

它真正的用处是让「抬名义额」几乎免费，而抬名义额正好压掉步长取整。实测
取整到步长偶数倍后最差币的名义偏差：100U → 6.7%(SOL)、500U → 1.8%、
1000U → 0.6%。所以默认名义改 500、杠杆 10x，每笔占 50 USDT 保证金。

止损在 2 ATR ≈ 0.2%，而 10x 的强平约需逆向 10% = 100 个 ATR，差 50 倍。
这个止损紧到杠杆几乎不引入强平风险，所以这里没有「杠杆换风险」的取舍。
仍建议逐仓，让每笔最大损失被保证金封住。

推送里加上占用保证金与「触止损亏多少 USDT / 占保证金百分之几」，手工执行时
不必自己换算。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-28 15:44:39 +08:00
jackandCursor c57adc8cb0 推送按合约规则取整，减半腿精确一半 
100 USDT 的仓位在 Bitget 上不是最小下单量的问题（minTradeUSDT=5、
minTradeNum 极小，10U 都能下），是**步长取整**的问题：

  SOL  步长 0.1 币 ≈ 10.7U → 50U 腿只能取 0.4 币 = 42.7U，偏 14.6%
  LINK 步长 1 币 ≈ 11.7U   → 4 币 = 46.8U，偏 6.4%
  BTC  步长 0.0001 ≈ 8.0U  → 0.0006 = 47.8U，偏 4.4%

减半腿变成全仓的 43% 而非 50%，剩下 57% 暴露在 8ATR 目标上，而回测的收益
结构假设 50/50。小额下这不影响机制验证，但会让 P&L 读不出回测那个结构。

解法是入场量取到**步长的偶数倍**，这样一半天然落在步长上。实测十个币减半腿
全部精确 50%，名义额落在 93.6~106.7 USDT——小额实盘无所谓。

同时把价位对齐到 tick（priceEndStep × 10^-pricePlace），否则限价单会被拒。
规则拉一次缓存；拉不到就退化为不取整并打日志，不阻断推送。

费率一事已核实无需改动：预算假设的挂牌 taker 0.040% / maker 0.016% 正是
Bitget VIP2 的官方档（返 50% 后 2.0 / 0.8bp）。合约接口返的 6bp/2bp 是 VIP0
基础档，不适用。8bp 门控阈值不变。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-28 15:42:17 +08:00
jackandCursor 97457b0518 过滤网信号推 Telegram，供手工小额实盘 
自动执行链一行都还没写（下单/持仓状态/跨重启持久化/对账/熔断），而过全部
滤网的信号只有约 5.3 笔/天——低到人手能接。先手工跑一批，就能在写自动化
**之前**拿到真实费率档、真实成交价、真实出场行为，让执行链的每个假设都有
实测对照，而不是写完再发现出场模型不对。

推送内容按手工执行需要给全：参考成交价（回测口径的次根开盘）、按 2/3/8 ATR
换算的绝对价位、下单数量、该币滑点预算，以及一句「偏离超过预算就不值得做」。
剩余半仓止损保持 2ATR 不移成本，这是回测参数，移了就不是同一个收益结构。

时效是这条路最大的风险，所以起点取 kline_ts 而不是信号产生时刻——参考价就是
在 kline_ts 那一刻存在的，从信号时刻起算会漏掉数据延迟加计算那 0.5~1.5s，而
那段不可压缩。超过 TG_STALE_S 直接标记已失效，不让人自己判断：宁可漏做，不
要在偏离预算之外入场。

三条防线：lag 退化时不推（与「停开新仓」同一条规则，不能只在自动化里执行）；
按 (币, K线时刻, 方向) 去重，避免补根或池重建重放导致开两次仓；无预算的币
（如 TRX）不推。推送任何失败只打日志，不连坐采集——已验假 token 下降级为
HTTP 401 日志而非抛异常。

凭据走 tg.env（已 gitignore），给了 tg.env.example 说明怎么拿 token 和 chat id。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-28 15:35:17 +08:00
jackandCursor 0745e73b4f 判定要知道增量开没开，否则会推荐已经在做的事 
上线 9 小时后实测踩到：清空 326ms 触发「币数 > 核数」那一支，于是继续输出
「唯一出路是走增量」——而增量已经生效。同一个分支在增量前后给同一个答案，
等于没有判定。

现在分开：增量未开就指向开增量；已开则指出单币 102ms 里 chan 构建只剩约
22ms，其余是 build_htf_zones / find_fast_bsp3 / attach_htf_context，要继续
压得改这三个或减币。顺带把「宽裕」阈值从 300 提到 400ms——清空 326ms 在
数据到达中位 347~558ms 面前不是瓶颈。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-28 15:24:31 +08:00
jackandCursor 545fcc7c77 补验多 worker 交错下的一次追加多根 
原对拍每根都只追加 1 根，覆盖不到多 worker 交错的实际路径：
ProcessPoolExecutor 不保证同一个币落到同一个 worker，所以每个 worker 隔 nw
根才再见到这个币，一次要补 nw 根。「补 nw 根等价于连续追加 nw 次」是推理，
没实测过。

--interleave N 用 N 份独立缓存轮流接同一个币。BTC/SOL 各 300 根、2 份缓存，
逐字段零分歧，各缓存末窗 2299 根。

顺带记清亲和性的性质：缓存是 worker 进程内的 dict、键含 symbol，不存在
「worker A 的状态被 B 读到」或「拿到别的币的状态」。亲和性影响的是内存
（每个 worker 最终缓存全部币）与补根次数，不影响正确性。实测内存
597→598MiB，代价在噪声里。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-28 06:24:51 +08:00
jackandCursor 34a8f37b39 HANDOFF：更正 cal_trend 依赖那句，补 §5.6 增量落地 
原先写「cal_trend 不能跳过——bi.py:221 读 klc.trend，笔的计算依赖它」。这条
不成立：221 行在 cal_trend 自己的循环里，读的是它自身的序列状态，不是
cal_bi_list 的依赖。1,800 根对拍定论——增量追加的 klc 其 trend 恒为 UNKNOWN，
与批量构建（trend 有值）逐字段相同。这处偏差是读代码读出来的，对拍一次就
定论了，同类判断优先用对拍。

另标注「append_bar 32ms 对 800ms 有 25 倍余量」的口径问题：单币构建不是信号
总延迟，多币要串行清空，且 800ms 哨兵测的是数据到达、不与计算共享预算。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-28 06:19:00 +08:00
jackandCursor 0a0fd2f682 影子信号走增量：清空十币 560ms → 247ms 
compute() 每根新建 TF_DF 换成按 (symbol, timeframe) 缓存的流式对象。worker
进程被复用，所以缓存跨根存活；2 worker 轮流拿 10 币，每个 worker 最终缓存
全部 20 条流，实测内存开销落在噪声里（597→598MiB）。

## 前提先验，否则整个改动建立在沙子上

init_stream/append_bar **没有 trim**，dataframe 靠 pd.concat 无界增长。所以
增量必然让窗口每根 +1，只能周期性重建拉回，两次重建之间窗口是 [W, W+500]
而非恒定 W。于是必须先证明 compute() 输出对窗口长度不敏感——否则增量等于
静默换掉一批信号，不报错不崩。

verify_window_sens.py：三币 75 个信号窗口，+200/+500/+1000 三档全部逐字段
一致。step39 说的是「命中率在 2000 根饱和」，饱和不等于不变，这是两回事。

## 对拍

verify_incr_parity.py：三币 1,800 根、21 个命中、各跨 1 次重建边界，逐字段
零分歧。不能引用 HANDOFF §5.5——那验的是 bsp_list 那条链的整体哈希，而这里
是 find_fast_bsp3 那条链，且流式对象跨根复用，状态污染只会让信号悄悄换一批。

对拍顺带定论一件读代码定不了的事：cal_bi_list **不依赖** klc.trend。
init_stream/append_bar 从不调 cal_trend（它只在 get_klc_list 里），所以追加
出来的 klc 其 trend 恒为 UNKNOWN，而批量构建的有值；两者结果逐字段相同。
HANDOFF §5.5 那句「bi.py:221 读 klc.trend，笔的计算依赖它」不成立——221 行
在 cal_trend 自己的循环里，读的是它自身的序列状态。

## 重建不走 init_stream

init_stream 是逐行 dataframe.iloc[idx]，正是引擎提速刚修掉的反模式：2001 根
要 238.5ms，而批量 lean 只 74.3ms，慢 3.2 倍。第一版用它重建，10 个币启动时
各来一次，清空反而涨到 1686ms。改用 TF_DF(df, lean=True) 重建，append_bar
靠 _ensure_stream_state 就能接上。

## 实测

append_bar 21.8ms vs 批量 lean 重建 77.7ms = 3.56x，与研究侧测的 3.7x 一致。
拆解：add_indicators 全表 7.5ms（34%，为加一根重算 2001 行）+ cal_bi_list
整表重扫 11.1ms（51%）+ concat 1.4ms。这两项都在引擎侧，值得反馈。

十币 / 2 核：清空 560→247ms，排队 92→10ms，纯计算 219→108ms。判定从
「加 worker 无用，唯一出路是增量」变成「宽裕，无需优化」。

注意 inner 108ms 里 chan 构建只占约 22ms，其余是 build_htf_zones /
find_fast_bsp3 / attach_htf_context。**瓶颈已不在 chan 构建**，再压增量收益
有限。

stream_bars 落到 latency CSV：恒等于 2001 说明缺口判定在每根都回退重建、
增量静默失效，这一点从耗时上看不出是哪一环。实测窗口稳定长大。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-28 06:17:47 +08:00
jack c8a0062707 Merge branch 'chan' of ssh://git.jackyu66.com:2222/jack/chan into chan 2026-08-28 05:19:15 +08:00
jackandCursor f5f456c523 计算判定改看「清空全部币」，并挡掉空窗口 
判定原先比逐根的 queue_ms 与 inner_ms，结构上错了两处，十币下直接指反：

判据错。要紧的是一个收盘时刻清空所有币要多久，不是单币的 q 或 i。币同一秒
收盘，币数超 worker 数时后面的币串行等待，这笔代价不出现在任何单根的 q 或 i
里。现在按 kline_ts 聚合取各币最大 compute_ms，落到 clear_hist。

出路错。「排队为主 → 加核」只在还有空闲核时成立。worker 已等于核数时加
worker 不增吞吐，只把等待从 queue 挪到 inner。十币实测正是如此：inner 被
争抢从 144 抬到 192ms 反超 queue 135ms，于是判定落到「量级已低、无需优化」
——而此时最后一个币已在 1376ms。现在币数超核数就直接指向增量路径。

顺带修一个瞬时故障：WS 重连瞬间 feed 的 deque 可能为空，空窗口放行会让
worker 抛「DataFrame for 1m is empty」，白占一个计算槽（币数超核数时会推迟
后面所有币），而报错文本还会让人以为是缺历史数据。加 MIN_BARS 守卫。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-28 05:19:14 +08:00
jackyu66gitandCursor d4fbe9d905 量因子该做成开关不是权重；前序因子不该进仓位 
把 step49/50 两个分层结论做成仓位因子做组合层面评估，结果与分层表给人的印象
不一致，两个因子的命运相反。

方法上设了三道约束——分层结论转仓位规则最容易在这三处翻车：

  1 阈值取整数（vr60 切 1/2/4）、权重取整数比，一个参数都不搜。观测到的四分位
    边界在不同时段并不一致（样本外 0.63/1.26/2.28/5.34、发现期 0.62/1.48/
    3.11/7.97），用样本分位数等于在同一批数据上既发现又调参
  2 权重归一化到均值 1，各方案投出去的平均资金相同，均R 才可比
  3 判据是四项一起看：均R / R夏普 / 最大回撤 / 峰值加权并发。只看均值必然误判

全样本 3941 笔，假定滑点 5bp/taker 腿：

                     盈亏平衡滑点  R夏普  回撤R  峰值并发  总R/峰值并发
  等权（现状）           16.7bp   0.420  17.3    7.00      371.4
  仅量因子（加权）       18.2bp   0.442  12.7    7.98      367.4
  仅前序因子             17.0bp   0.421  19.2    8.46      312.6
  硬砍高量档（vr60≥4）   18.6bp   0.496  11.2    6.00      389.3
  硬砍 + 前序权重        19.0bp   0.500  11.0    7.19      332.1

① 前序因子不能做仓位。+6bp 余量在 5bp 滑点假设下只值约 0.011R，而这批信号
按定义 100% 发生在别的币已有仓位时——加权就是在敞口最集中的时刻加杠杆。
盈亏平衡只买到 +0.3bp，峰值并发 7.00→8.46、回撤 17.3→19.2，按峰值保证金归一
后是净负的（371→313）。§3.31 里「可用于加仓位权重」那句作废。出路可能是改用
放宽 ATR 门控兑现（多做几笔而非每笔做大），未测。

② 量因子「不做」优于「少做」。硬砍付笔数 −22%、总R −10%，换回撤 −35% 和峰值
并发 7→6。并发这一项单独就值：§3.31 已把峰值敞口列为扩币的前置约束。

③ 优势的形态是削尾不是抬均值。均R 差在各滑点档几乎恒定（0.085→0.082），但
基数在塌，所以相对优势随成本上升放大：15bp 处总R/回撤 2.57→11.86，靠的是回撤
从 150.5 掉到 60.3。这两个因子买的是尾部风险，不是收益。

可操作口径要用发现期：盈亏平衡滑点样本外 18.2bp、发现期只有 13.5bp（硬砍后
15.6bp），差距就是 2026 的 ATR 压缩。13.5 与 shadow_budget 的 15.19bp 同量级，
互为印证。影子测量要对标 13.5 / 15.6，不是 18.6。

开关先不上：只是 live 信号路径加一行，随时能加。等实测滑点出来再定——远低于
13.5bp 则等权就够，贴着 13.5bp 则这 2.1bp 就是生死线。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-28 05:08:34 +08:00
jackyu66gitandCursor ef584b8d49 成交量假设方向是反的：高量入场毛R 0.794，低量 1.421 
用户假设「有资金的趋势才是好趋势」，预期开仓根成交量越大越好。成交量在信号根
收盘时可知，符合 step48 立的「只用开仓时已知信息」纪律，是合法的可交易切法。
10 币 × 80 万根、实盘口径 3941 笔，结论与假设相反。

按 vr60（当根量 / 前 60 根均量）四分位：

  量最低（中位 0.63）  毛R 1.421  余量 27.18bp   ← 样本外
  量最高（中位 5.34）  毛R 0.794  余量 13.47bp

单调递减，且样本内外、两套量比基准（前 10 根 / 前 60 根）全部同向。稳健性达到
step49 那条的标准：ATR 四分位 4/4 同向、逐时段 7/7 同向，不是 ATR 换脸。

机制在出场结构里，伤害全在止损命中率：

  量最低  止盈 33.5%  止损 22.5%  超时 44.0%  赢时均R 1.830  亏时均R −1.098
  量最高  止盈 26.1%  止损 45.3%  超时 28.6%  赢时均R 1.651  亏时均R −1.106

亏损幅度四档全是 −1.10（止损就是止损），赢时均R 只降 10%，止损率翻倍是全部
损失来源。这里有个判别点：若只是「2 ATR 止损相对突然放大的波动太窄」的尺度
错配，超时单应按原比例分流进止盈和止损两侧；实际是超时（−15.4pp）和止盈
（−7.4pp）一起流进止损（+22.8pp）。方向本身在变差，不只是止损太窄。

为什么直觉会反：B4/S4 在突破根上进场。大量根意味着这一冲已经由别人的资金
完成，你在它的收盘价接手。「有资金」要能获利必须在资金到达之前进场，不是同时。

与「有前序」是两件独立的事（有前序组 vr10 中位 1.76 vs 无前序 1.46），可叠加：
低量 × 有前序 253 笔，毛R 1.398、余量 31.00bp，是目前见过最宽的执行容忍度。

step48 的采集加 vr10/vr60 两列。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-28 05:08:03 +08:00
jack 2b9a837a58 Merge branch 'chan' of ssh://git.jackyu66.com:2222/jack/chan into chan 2026-08-28 04:50:16 +08:00
jackandCursor ef2a85dd8c 币池可配，实测十币的排队代价；标出漂移的 tick 地板 
加 --syms（start.sh 传 SYMS），默认仍是三币。TRX 不进十币池：实盘口径 208 天
只有 5 笔，ATR 门控几乎全刷掉。

十币实测（对比三币）：

  queue_ms        2 → 169ms（P90 519ms，每刻最大排队中位 533ms）
  inner_ms      144 → 196ms（CPU 争抢也拖慢了纯计算）
  lag_signal_ms 621 → 958ms；同一收盘时刻最后算完的币中位 1376ms

排队从可忽略变成主项，与「10 币 × 196ms ÷ 2 核 ≈ 640ms 突发」吻合。这也是
之前「加核没用」那个结论唯一会翻转的场景：CPU 占用率只有约 3%，问题纯粹是
所有币同一秒收盘的突发，加核压的是并行度而非单币耗时。

但 800ms 哨兵不受影响——它喂的是 t_data − kline_ts（数据腿），十币下逐币
154~532ms 全在线内。加币不碰那道闸。

另外发现一个会被静默误读的东西：ADA/AVAX/DOGE/LINK/LTC 的漂移中位精确等于
半个 tick 且在四个延迟点上完全相同。那不是漂移，是中价的最小变动量——ADA 半
tick 就有 2.34bp。拿这个数去比预算会误判某币不可做。shadow_report 加了
tick_floor() 标注；方向上安全（真实漂移只会更小，这些是上界）。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-28 04:50:09 +08:00
jackyu66gitandCursor 27a4360ce8 「有前序信号」通过样本外验证：6/6 时段、4/4 ATR 分层全部同向 
step48 那条唯一可交易的线索（开仓时过去 5 分钟内已有别的币发过信号，
则滑点余量更高）用更长历史验证。10 币 × 80 万根，2025-02 ~ 2026-08 共
3941 笔，发现期 1161 笔、样本外 2780 笔。

  样本外 无前序 2326 笔  毛R 1.086  PF 3.91  余量 18.83bp
  样本外 有前序  454 笔  毛R 1.275  PF 4.60  余量 24.89bp

逐时段 6/6 全部同向，余量差中位 8.03bp。发现期毛R 差只有 0.085，样本外
放大到 0.189——不是过拟合衰减，是发现期恰好偏保守。占比各时段 13~19%，很稳。

ATR 混淆已排除：有前序的 ATR 确实略高（中位 15.04 vs 13.13bp），但按四分位
分层后 4/4 层同向，层内余量差 3.29/8.39/5.16/4.14bp，与不分层的 +6.06 同
量级。毛R 本身是 ATR 归一化指标，其 +0.19 不可能是 ATR 假象。

可用方式：这 16% 的信号多容忍约 6bp 执行成本，可加仓位权重，或对这批放宽
ATR 门控（最低 ATR 层里有前序余量仍有 14.92bp vs 对照 11.63）。放宽门控尚未
回测，先别改。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-28 04:36:39 +08:00
jack 7c13781f90 Merge branch 'chan' of ssh://git.jackyu66.com:2222/jack/chan into chan 2026-08-28 04:35:17 +08:00
jackandCursor d13a0f85bc 固化窗口召回率：2000 根窗口不丢信号（90/90） 
全量历史找出的最近 30 笔信号，在 2000 根窗口里逐笔重算，BTC/ETH/SOL 各
30/30 全部复现且过全部滤网。这是窗口左边界效应的一半答案：窗口不丢信号。

另一半没答，且对实盘更危险——窗口会不会多造出全量历史没有的信号（会多开
仓）。那要反向扫描：遍历窗口找命中再回全量核对。lean 之后单窗 130ms，抽样
2 万个窗口约 43 分钟，已经可做，docstring 里记了。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-28 04:35:12 +08:00
jackyu66gitandCursor 550eafdd9d 簇内顺序看着是圣杯，43% 的落差里有 34 个点是未来信息 
用户提出研究多币同时段开仓的先后顺序。事后按位次切落差很大：簇内第 1 笔
胜率 81.6%、毛R 1.441，第 2 笔 1.085，第 3 笔 0.733，比孤立组 0.832 高 73%。

但「我是首发」的含义是「接下来 5 分钟没有别的币再发」，这是未来信息。首发
赢面大恰恰因为后面真跟出来了别的币、那波行情是真的，而会不会跟出来在下单
那一刻不可知。

换成开仓时真正可知的信息（过去 5 分钟有无别的币先发）：

  无前序      979 笔 (84%)  毛R 0.938  PF 3.19  余量 14.13bp
  有前序 ≥1 个 182 笔 (16%)  毛R 1.021  PF 3.71  余量 21.88bp

43% 的落差塌成 8.8%，方向还反过来。但残留不是零，且滑点余量高 55%
（14.13 → 21.88bp），对 1m 是实打实的——1m 的生死线就在执行成本。

谁在领跑无稳定结构：首发率 BTC 8.6% ~ DOGE 18.4%，158 次首发摊到 10 个币
平均 15.8 次，离散度基本是抽样噪声。

给这个方向定了条纪律：组合空间大而样本只有 158 个簇，每个切法必须能写成
「开仓那一刻已知的信息」。凡用到簇共几个币、我是第几个、簇跨度多长的，
都含未来信息。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-28 04:27:43 +08:00
jack 99ae072cc6 Merge branch 'chan' of ssh://git.jackyu66.com:2222/jack/chan into chan 2026-08-28 04:24:54 +08:00
jackandCursor d37bfcb26b 心跳的优化建议改看绝对量级 
lean + 新引擎后纯计算约 128ms，仍固定提示「需改增量计算」是误导：尾部已由
数据腿主导（lag_data P90 1482ms vs compute P90 237ms），压计算换不到东西。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-28 04:24:48 +08:00
jackyu66gitandCursor 2a59dcb9dc 扎堆开仓反而更赚，但好处全在「错开几分钟」那一档，同分钟的最差 
承接上一条：既然同时开的必然同向，那关键是这批交易比孤立的好还是坏。
11 币 / 1161 笔 / 实盘口径：

  真孤立（±5 分钟内无同伴）  763 笔  胜率 65.5%  毛R 0.832  PF 2.83
  错开：5 分钟内但不同分钟   240 笔  胜率 82.1%  毛R 1.443  PF 7.31
  同一分钟撞在一起          158 笔  胜率 63.3%  毛R 0.777  PF 2.20

必须把两者分开——结论相反，混在一起会得出错误判断。错开的是全样本最好的
一档，同分钟的反而略差于孤立组。机制上：错开 = 行情从某个币扩散开，后发是
对先发的确认；同分钟 = 全市场同时被一个冲击打中，即追高。

簇级复核（±5 分钟合一簇，排除重复计数）：多笔簇簇均毛R 1.180 vs 单笔簇
0.832，簇级 R 夏普 0.848 vs 0.459，结论不是重复计数撑起来的。多笔簇内
全赢 59.5%、全输 10.1%，簇内风险不可分散但偏度有利。

集中度上两类没差别（整簇同向 99.4%），差别纯在收益。所以「限制最多 N 个
并发仓位」把两类一视同仁是错的，它们期望收益差 1.9 倍。

注意：同分钟 vs 错开是看过数据后才划的切法，不是事先定的，208 天 158 个簇
容易切出噪声。当仓位规则用之前必须换一段时间验证。目前只有「扎堆整体更好」
是稳的（簇级也成立）。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-28 04:24:31 +08:00
jack 4a4f8727fd Merge branch 'chan' of ssh://git.jackyu66.com:2222/jack/chan into chan 2026-08-28 04:24:22 +08:00
jackandCursor 6c843639d5 影子路径开 lean 模式，实测完整链路 1410 → 683ms 
拉到新引擎后在服务器侧直接实测，没有沿用 3.4 倍那个换算——那是在旧代码上量的。

先做等价性验证。不能直接引用 step46 的对拍结论：它固化的是 bsp_list 那条链的
哈希，而影子路径走 find_fast_bsp3 + build_htf_zones + htf_fx_timeline +
attach_htf_context，两条链读的东西不一样。所以新建 verify_lean_parity.py 在
这条路径上逐根对拍 compute() 的每个返回字段。

其中一个坑：随机取窗口测不到信号分支。信号密度约 1/2000 根，头 12 个窗口命中
0 个，「一致」只覆盖了早退路径。改成一半窗口对齐到已知信号根，命中率才上来。
最终 180 窗口 / 两模式各 90 命中 / 零分歧。

生产实测（inner_ms，容器内同口径）：

  compute_ms      646 → 132ms   4.89x
  inner_ms        612 → 128ms   4.80x
  lag_signal_ms  1410 → 683ms   完整链路，落回 800ms 线内

比 3.4 倍更好，因为是引擎 ~3.5x 叠 lean ~1.35x。

两点判读上的订正：

- lag_data_ms 那 576→490ms 是噪声，不要记在引擎账上。均值 721±36 vs
  740±127，重叠；而且引擎本来就影响不到交易所与网络那一段。
- 仍有 44% 的根超 800ms，但尾部现在完全由数据腿主导（lag_data P90 1482ms
  vs compute P90 237ms）。计算既不是瓶颈也不是尾部主因了，继续压计算换不到
  尾部改善。800ms 那道闸取的是最近 30 根的中位数，683ms 已满足。

start.sh 加 SHADOW_LEAN（默认 1），设 0 可退回 full 复量两模式差异。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-28 04:24:08 +08:00
jackyu66gitandCursor 9f4d7fec73 11 币的开仓时刻：不是同时开，但同时开的那批 100% 同向 
用户问 11 个币的开仓时间差距。1161 笔 / 208 天 / 实盘口径（深色 ∧ ATR≥8bp）：

相邻两笔间隔中位 122 分钟，62.8% 超过 1 小时，每天仅 5.58 笔。
同时持仓数：90.9% 的时间空仓，7.5% 只有 1 仓，≥2 仓合计 1.7%，峰值 8。

所以绝大多数时候不会撞车，但左尾是硬的：7.4% 与前一笔同分钟、20.7% 在
5 分钟内。而同一分钟出现多笔的 72 个时刻里，方向完全一致的占 100%
（§3.31 此前测到的是 92.7%，全样本下更极端）。

这批同时开的仓不是分散，是同一笔押注被拆到几个币上做——名义 3 个仓位，
实质 3 倍单向敞口。由此两条：保证金不是约束（91% 时间空仓，峰值并发只占
0.1% 的时间），真问题是资金闲置；并发上限必须按同向净敞口设，按仓位个数
设等于默许成倍的单向敞口。

另：TRX 在实盘口径下 208 天只有 5 笔，ATR 门控几乎全刷掉，应从币池剔除，
实际可用是 10 个币。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-28 04:17:19 +08:00
jackyu66gitandCursor d2fcb27d01 否掉 bis[2]：修右边缘重画会把 alpha 打成零，重画是必付代价 
§5.41 发现 available_ts 取「中枢最后一笔」是右边缘重画的根因，改取「第三笔」
能把重画率从 6.5% 压到 1.2%，当时据此判断它是「唯一可能同时改善收益与稳定性」
的改动。那个判断只测了稳定性，过早了。

8 个样本外币 × 30 万根 1m，两组共用同一个 TF_DF，只切 available_ts 的取法。
实盘口径（深色 ∧ ATR≥8bp，955 vs 989 笔）：

  毛 R      0.933 → -0.000
  净均 R    0.798 → -0.147
  PF        3.22  → 0.80
  滑点余量  15.07 → -2.20 bp

判决依据是毛 R 那一行：扣任何费用之前 edge 就没了，所以不是成本、门控或出场
参数的问题，是信号本身不再有预测力。逐币 8/8 全部变差。滞后确实降了
（2.16 → 2.01），但换来的是另一批交易——两组重合度只有约 30%。

原因是中枢没发育完就下注，支撑/压力还没立住。「等中枢最后一笔」那段等待不是
可以优化掉的延迟，它就是 alpha 本身。由此得一条一般规则：任何以「让信号更早
确定」为目标的改动，先测毛 R，不能只看重画率和滞后。

开关 AVAIL_BI_INDEX 保留只为可复现该 A/B，默认 -1 维持现行口径。环境变量在
调用时解析而非 import 时——fork 启动的子进程会继承已 import 的模块，import
时读会固化成父进程的值。

顺带交叉验证：现行口径本次算出滑点余量 15.07bp，与用优化前代码算的同组同期
15.19bp 吻合。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-28 04:05:01 +08:00