jack/Chan
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
310 Commits 9 Branches 1 Tag
ef2a85dd8c68dc95a059a82ea6355d8140f05790
Commit Graph
310 Commits
This Branch
This Branch
All Branches
Author SHA1 Message Date
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
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
jackyu66gitandCursor 0b4d7693b8 缠论引擎提速 2.6x，瓶颈是逐行 Series 查找而非指标计算 
原以为浪费在 add_indicators 算了太多用不到的指标，实测它只占全量构建的
1.3%——talib 是向量化 C 代码，便宜。真正的两处：

cal_kl_data 占 96%：每根 K 线 df.iloc[i] 新建一个 40 列 Series，再在其上做
几十次逐键查找。改为预取 ndarray 后 2 万根 1946ms → 824ms。

ChanKLC.cal_all_ema_status 占 25%：每次合并 KLU 都立即重算，而它产出的
ema_status / ema52_pos / ema52_status 全仓无任何读取方（含前端）。改为惰性
求值，保留属性形式以防将来有人读。顺带删掉 get_klc_list 里累加一整轮后直接
丢弃的 ema_up_list / ema_down_list。

另加 TF_DF(lean=True)：只构建到中枢，跳过线段/走势中枢/MACD 状态机——这些
只服务 bsp_list 与 web 展示，笔和中枢不依赖。研究与实盘走这条快 3.6x。

结果 2 万根 5m：full 1946 → 754ms，lean → 543ms。

step46_engine_parity.py 是配套的安全网，改引擎前先跑一次 --save。它对 KLC
端点与分型、笔起止价与 is_sure、中枢 zg/zd/available_ts/阶梯、信号全部输出列，
以及 26 个被下游消费的 dataframe 列取哈希。本次三处改动逐步验证，另用
git stash 切回改动前代码在 20 万根 × 5 用例上做了跨版本逐位对拍，全部一致；
增量路径与 web API 也各验一遍。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-28 04:04:44 +08:00
jackandCursor 3b14bba247 离线验证信号时刻流动性不更差，免掉攒 30 笔信号的 17 天等待 
三币过完三滤网只有 1.72 笔/天，攒 30 笔要 17 天。但滑点本来每根都在记，信号
时刻的测量只多回答一个问题：信号那一刻的流动性是否比普通根差。这个问题可以
用 210 天历史离线回答。

关键是必须做匹配对照。信号按 ATR ≥ 8bp 门控，信号根天然比平均根波动大，直接
和全体根比一定会「发现」一个我们自己施加的差异。所以对照组按「同时段 × 同
ATR 十分位」抽取，并排除距信号 48 根内的根（持仓期不独立）。自检 ATR 比值
0.976~1.004，匹配成立。

结果三币一致，方向与担心的相反：信号根成交额是对照的 2.1~2.6 倍、Amihud 非
流动性只有 0.47~0.60 倍、Roll 有效价差三个币都不显著。信号跟在突破后面，
突破自带成交量。所以全体根测出的冲击与价差偏保守而非偏乐观。

唯一真实差异是根内波幅宽 25~28%，但那是波动而非流动性，对应漂移而非冲击，
且可直接当缩放系数：1 秒延迟点漂移上调后仍只占预算 1.4%/3.0%/4.5%。

判读按流动性与波动分两组。初版把 range_bp 当成流动性红旗，会得出「信号时刻
更差、必须等样本」的相反结论——它是波动度量，且 ATR 已匹配。
检验用置换而非 t：成交额跨几个数量级，右尾太重。scipy 未安装，也不宜在采集
运行中动环境，所以用 numpy 自己实现。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-28 03:52:23 +08:00
jackandCursor 75fbf4167b 修掉 gzip 追加会毁掉整个文件的数据丢失，并分开买卖两侧的成交分布曲线 
两件事，都是「静默出错」那一类。

一、BookLog/TapeLog 追加到同一个 .gz，进程被 SIGKILL 时当前成员停在 deflate
块中间，下一轮追加的新成员接在垃圾字节之后。顺序解压在损坏点抛 invalid
block type，该点之后全部读不出来——包括后续每轮写进去的。而读侧的异常处理
把这个当成「正常的尾部截断」静默跳过，于是只读出 21 行还不报错。
原 docstring 里写的「只丢最后一个缓冲块，不会毁掉整个文件」是错的，已证伪。

写侧改成每轮运行一个文件；读侧按 gzip 成员边界扫描、坏成员单独跳过并出声
报告，同时把同前缀的多轮文件一并读入。旧损坏文件因此多恢复出 31/21 条
（tape）与 132/95 条（books）。

二、tape_shape 只统计主动买、只自区间顶部累积，这条曲线只适用于多头止盈。
exit_fill 两侧共用它，等于把空头的可成交量按多头分布高估。实测二者不对称：
主动买在顶部 20% 内已占 40%，主动卖在底部 20% 内只有 18%。分成 SHAPE_F 与
SHAPE_F_SHORT，avail_at 按方向查各自曲线。

两条曲线只有 45 根成交流样本，所以补了 --sensitivity：把空头可成交量砍一半，
10 万仓位下 BTC/ETH 预算完全不动、SOL 动 0.07bp。结论不依赖这 45 根样本。
顺带撤掉 step43 docstring 里已作废的「成交率 30%/16%/1.5%」。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-28 03:23:07 +08:00
jackandCursor 54792fe015 把 compute_ms 拆成排队与纯计算，据此否掉换机器这个方向 
compute_ms 一直是「提交进程池到拿到结果」的墙钟时间，排队和纯计算混在一个
数里，所以「加核有没有用」只能靠猜——这也是原先打算在 AWS 开第二台比 CPU
的依据。

worker 内部自己计时，连同父进程传入的提交时刻一起回传，拆出 queue_ms 与
inner_ms。实测中位 3ms / 695ms：2 个 worker 跑 3 个币并不排队，因为三个币的
收盘消息错峰到达。瓶颈全在单线程，加核压不到。

顺带把 README 里的内存数据从臆测的 1.5GB 改成实测 410MiB，并注明跨站点比
CPU 收益有限。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-28 03:02:06 +08:00
jackandCursor 95f2b614a2 延迟瓶颈实测为本机 CPU 而非机房位置，跨站对比主指标改为 compute_ms 
用户指出本机选新加坡是因为 Bitget 机房在新加坡。查证下来 ws.bitget.com 解析
到的是 CloudFront（dxotqhr62n6z4.cloudfront.net），落在新加坡 AS16509
（Amazon），即连的是 AWS 的 CDN 边缘而非 Bitget 自有机房。

腾讯云 ap-singapore（AS132203）到该边缘实测：ICMP 往返 2.1ms、TCP 握手
3.3ms、TLS 完成 9.0ms、首字节 87.8ms。首字节减 TLS 那约 79ms 是 CloudFront
回源开销，与我们的位置无关。

延迟构成（33 根样本）：数据到达中位 506ms、信号计算中位 646ms、合计 1315ms。
随机房位置变化的只有那 2ms 往返，占总延迟 0.15%。而 646ms 的信号计算是每根
在 2000 根 1m 加 800 根 5m 上重建缠论结构，本机 2 核、2 个计算进程，三币同时
收盘时第三个还要排队——这才是有改善空间的一项。

因此：
- 新增 deploy/netprobe.sh，把网络那一段单独量出来并入运行元数据。用到达
  延迟去比两个机房等于用公斤秤称克，必须把可变的那段拿出来单独看。
- compare_sites.py 主指标改为 compute_ms，lag_data_ms 降为自检项（两站应当
  接近；若差很多，先怀疑时钟而非网络）。元数据表加 nproc/cpu_model/往返。
- README 改写：第二台机器该测 CPU 规格而非地理位置，WORKERS 按核数减一给，
  币数多于 worker 数时排队时间直接计入 compute_ms。

另修正站点标签：本机是腾讯云而非 Hetzner，sg-hetzner → sg-tencent，标错的
33 行数据已清掉重采。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-28 02:51:51 +08:00
jackandCursor 1661bbbac9 gitignore: 运行元数据属采集产物，不入库 
Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-28 02:40:57 +08:00
jackandCursor 631d97e493 加跨地部署脚本与站点对比，数据全表加 site 列 
目的是在第二台机器（AWS）上跑一套完全相同的采集，看不同地理位置的数据差异。
滑点里最大的一项是延迟漂移，而延迟含网络传输，所以机房选址是可优化参数。

数据侧两处必需改动：

- 全部输出加 site 列（三张 CSV 加 gzip 里的盘口与成交流）。没有这一列，两台
  机器的数据合起来就分不清来源。为免四处 writerow 漏加一处产生静默空值，
  改在 _SiteWriter 里统一注入。
- start.sh 在时钟未同步或偏移超 10ms 时**拒绝启动**。所有延迟数字都是
  「本地时钟 − 交易所 K 线收盘」，时钟偏 50ms 就全部同向偏 50ms，且不报错，
  只会让跨地对比得出一个干净且完全错误的结论。

deploy/ 下四个文件：setup.sh（docker + chrony + 拉镜像）、start.sh（校验时钟、
写运行元数据、起容器）、status.sh（健康速查）、README。运行元数据记 git commit、
镜像摘要、时钟偏移——两地数据对不上时，这三项任一不同都足以解释差异。

compare_sites.py 做配对对比：只取各站都有的 K 线（不取交集可能在比不同时段，
而延迟对市场活跃度敏感），并报配对差的符号占比而非两个中位数相减。已用注入
120ms 的合成数据验证能精确还原。另有一条自检：同一固定延迟点上两站漂移应当
相同——漂移是市场性质，若也差很多则先查时钟与时段对齐。

status.sh 里按列名取字段下标而非写死数字：加 site 列时字段整体右移过一次，
写死 $8 会静默变成读 lag_signal_ms 而非 lag_data_ms。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-28 02:39:47 +08:00
jackandCursor 01c4a4ab4d 主口径仓位定为 10 万 USDT，并量出限价单前方的排队量 
用户 2026-08-28 确认资金规模不会更大，故仓位档改为 25k/50k/100k/200k
（上下留档是为了读出局部斜率，单点看不出再大一倍会怎样）。该规模下两条
约束都不绑定：冲击占预算 0.1~11.1%，成交量效应使预算降幅不足 1%。

新增 queue_ahead：排队是唯一还没建模的成本项，exit_fill 假定我们能吃到该
价位的全部对手方成交量。10 万仓位相对最优档为 BTC 0.2 倍、ETH 0.7 倍、
SOL 69.7 倍。SOL 畸高是 tick 更细所致（同样的量摊到约 10 倍价位上），
对它应看 5bp 档（0.17 倍），但仍是三币中排队压力最大者。

同时在 shadow_depth 模块头标注：composite_fill 只算首次触及那一根的可成交
量，系统性偏悲观，不作为成交率结论——真实成交率见 lib/exit_fill.py。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-28 02:39:47 +08:00
jackandCursor 28075173af 出场模型改为按成交量结算止盈限价单，并出预算对仓位规模的曲线 
exit_model.walk_exits 给止盈记的毛收益是 target*a/entry，即假定限价单全额
成交在目标价。新增 lib/exit_fill.py：两张挂单常驻（半仓 3ATR、半仓 8ATR），
每根按该根在限价之上的可成交量逐步吃进，未成交部分继续持有，止损触发时
市价平掉剩余。可成交量 = 形状函数 f(k) × 该根主动买成交额，f 由影子成交流
实测（近似线性，即区间内均匀分布，故结论对形状假设不敏感）。

结果：预算对仓位规模远比预期稳健。到 100 万名义额，BTC 10.97→10.69、
ETH 15.34→15.20、SOL 17.21→15.83bp。原因是挂单常驻多根而非只在首次触及
那一根成交，且价格决定性穿过限价时整根成交量都可用。

首版实现有个静默 bug 值得记：avail_above 里有个 `hi <= 0` 的守卫，而空头
用「价格取负」处理，负价格空间里 hi 恒为负——所有空头挂单的可成交量一律
判 0，空头全被拖到 48 根超时收盘。下跌段里那比 3ATR 目标赚得多，于是预算
反而偏高 0.76bp，表现为「一个看似合理的模型差异」。已改为显式方向参数，
并加 assert_converges：仓位趋近 0 时必须逐笔收敛到 walk_exits，不符即抛错。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-28 02:39:47 +08:00
jackandCursor 181bca303f 影子测量改用框架吃单原语，并补齐容量与 maker 成交率两项测算 
吃单查询换成 Hummingbot 的 OrderBook.get_vwap_for_volume：手写的 walk_book
返回的是按计价币吃单的加权均价，但框架的 get_price_for_quote_volume 返回
边际价、get_vwap_for_volume 收基础币量，两者语义不同。改为按基础币下单
（真实委托与 PositionExecutor.amount 均是基础币计价），深度不足由
query_volume/result_volume 判定，框架此时返回 nan 而非一个看似正常的
部分成交均价。

落盘完整盘口（双边 50 档）。此前只记三个固定名义额的成交价，这批数据的
寿命就等于那几个档位的寿命；存完整深度后任意资金量级的冲击都能离线重算。
仓位档同时从 1k/5k/20k 提到十万量级，此前低估真实仓位约两个数量级。

订阅成交流，按根按价位聚合。买卖分开存——多头在目标位挂卖出靠主动买盘
成交，混在一起会把成交率高估约一倍。BTC 每根总成交额中位与 210 天历史
的 volume×close 差 0.3%，可确认采集完整。

新增两项测算：
- 冲击不是绑定约束。32 万仓位单边冲击 0.19~2.39bp，对 8.58~20.64bp 的
  预算只占 1.6~14.2%，冲击反推的资金上限 100~500 万。
- maker 成交率才是。止盈位被首次触及时，限价在该根价格区间中的位置
  中位 k=0.28（63.9 万次触及，三币一致）；合并每根成交额后，32 万仓位
  的全额成交率仅 30.1%/15.6%/1.5%。要 80% 全额成交，仓位须 ≤ 4.7 万
  /1.4 万/0.26 万——比冲击反推的上限低 40~370 倍。

回测把这些止盈按「全额成交在目标价」计，故预算所依据的收益流本身需重估。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-28 02:39:47 +08:00
jackyu66gitandCursor 6259f7380b research: 重算新出场口径下的并发，并修正「各笔基本独立」的说法 
分批出场把 1m 平均持仓从 9.9 根拉到 29 根，§3.3 的并发数字是旧口径的。
重算后 8 币组合平均并发 0.043→0.120、有仓位时间 4.0%→10.2%，峰值仍是 6。

更要紧的是顺带查出来的相关性：同一小时内有 ≥2 个币发信号的时段占 20.9%，
其中 92.7% 方向完全一致。所以「有仓位时间低 → 各笔基本独立」这个推理不成立
——时间上不重叠不等于统计上独立。t 值有一定虚高（不足以推翻，t 在 43 以上），
但更实际的后果是：加币不产生分散，仓位不能按「1% × N 个币」线性放。

用户问「整个市场都是正相关的，是不是很少有独立行情」。市场相关是真的，
但这不是伪装成策略的 beta：多空各占 50.7% / 49.3%，做空 PF 4.40 还略好于
做多 4.05，所有时段净方向合计仅 +185 笔。分年看，2021 大牛年做空的 PF 5.34
是整张表最高的一格，七年里没有一年、没有一个方向是亏的。空头占比随行情
切换（牛市 46.5% → 熊市 55.9%）。

所以 92.7% 同向该理解为「检测器正确识别到全市场级别的结构」——若 6 个币
同时发信号却方向随机，那才说明信号是噪声。

另补 3.33 扩币筛选：ATR 对门控阈值与流动性是两条方向相反的约束，最优区间
在中间。BTC 输在波动不够（ATR 中位 2026 仅 6.5bp，预算垫底），TRX 2026 门控
后只剩 4.2% 信号。保证金约束那条待办从「预计影响小」改为扩币前置条件。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-28 00:45:32 +08:00
jackyu66gitandCursor 32c18f0201 research: 1m 出场口径重定、费率修正，与影子测量的判据常数 
起因是用户看图指出「止盈没做好」，查下来 TP=3.0 确实把右尾截早了，
而且 1m 不该沿用 5m/15m/30m 的参数——成本固定在 bp、目标随 ATR 缩放，
1m 的 3 ATR 只有 0.39% 而 30m 是 1.87%，成本占比差 5 倍。

step41（5m/15m/30m）与 step42（1m）跑同一张全网格：
SL × TP × MAX_BARS × 分批（3 ATR 减半 → 剩余目标 × 剩余半仓止损位）。

- 1m 最优 SL2 / 3ATR 减半 / 剩余止损保持 2.0 / 目标 8ATR / 48 根，
  样本外 8/8 币、7/7 年全面提升，均R/R夏普/回撤/剔10%PF 四项全赢
- 分批要做，但**减仓后不要动止损**。止损位 0/0.5/1/1.5/2 ATR 严格单调，
  越紧越差，三组初始 SL 全一致。保本损是全表最差的一档
- SL=1.0 在 1m 上是废的：剔10%PF 0.78~0.99、中位收益 −0.122%

费率此前写的 taker 3bp / maker 1bp 隐含「原始 taker 6bp」的错误前提，
实际是原始 taker 0.040% / maker 0.016%、返 50% 后 2.0 / 0.8bp。方向是保守的，
所以首轮跑出来的数字全部偏低。exit_model 已改，费率只在分析阶段套用，
不必重跑模拟。改完 1m 的均R +8%，5m/15m/30m 只动 2%——费率只对 1m 有杠杆。

顺带查证了用户的一个假设：余量逐年递减是不是跟波动率有关。成立，而且
r = +0.989。毛/ATR 七年在 2.26~2.67 之间没有趋势，衰减的是 ATR 本身
（2021 的 22.1bp 压到 2026 的 8.8bp）。**是波动率压缩，不是 alpha 衰减。**

由此引出 ATR 门控：低 ATR 桶的毛 R 其实最高（1.16 vs 高 ATR 桶的 0.94），
断崖只在扣费之后出现。所以阈值是**费率的函数**（约 5 + 1.1×taker费），
不是市场常数。当前费率下 ≥8bp，在 5m/15m/30m 上几乎不触发，可作全局规则。

lib/shadow_budget.py 放影子测量要对照的常数：逐币预算、门控阈值、
腿→maker/taker 映射、lag 阈值、判据。记录与报表归 research/live/，
分工的理由是这些数会变——今天预算就动了四次。

out/*.feather 转为 ignore：70MB+ 且重跑可得，摘要都在 HANDOFF。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-28 00:05:56 +08:00
jackyu66gitandCursor 9b72173285 feat: 第四类买卖点（B4/S4）融入缠论引擎与 web 展示 
研究侧的 fast_bsp3 一直只活在 research/lib/ 里，web 端看不到，回测与目视
两条线对不上。这次把它搬进引擎，作为独立的第四类买卖点。

之所以单独立类而不是当作 B3/S3 的低滞后版：step30/31 显示引擎原生的
B3/S3 统计上呈逆势、显著亏损（胜率 27.4%、PF 0.66、t −18.76），而同一组
过滤器把 B4 从 PF 1.59 提到 2.26 却对它无效（0.66→0.71）。两者选的是
不同的交易群体，不是同一信号的早晚两版。

- chanlun/analysis/fast_bsp.py 原样搬入 find_fast_bsp3 与 build_htf_zones，
  另加 add_zone_ladder / htf_fx_timeline / attach_htf_agree
- research/lib/ 两个模块改为转发，所有 step 脚本导入不变，信号逐条比对一致
- 大级别上下文用 resample 从同一份 df 构建，不额外拉数据，因此与界面上选的
  周期和时间范围无关
- 前端三个复选框 + 过滤模式下拉；未过滤的原始信号用浅色，避免与主口径混淆

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-28 00:05:26 +08:00
UbuntuandCursor 7e339d2a54 research: 影子交易器落在 Hummingbot 上，并修掉 Bitget 连接器的换根延迟 
1m 腿的滑点余量只有几个 bp，所以要测的必须是生产路径的滑点——换个运行时
测出来的数就不作数。框架因此从「滑点已知后再定」提前到测量阶段就定为
Hummingbot（Spot/Perp 连接器均 v2.0，Bitget 是 Foundation Partner）。

新增 research/live/。前置测量：

- bench_compute.py 本机算力，1m 单币 0.318s、三币串行 1.38s
- venue_parity.py Binance 与 Bitget 同根信号重合仅 14.6~42.6%
- signal_sensitivity.py 0.25bp 扰动就换掉一半信号
- aggregate_robustness.py 但总体期望不降——脆的是信号身份，不是 alpha
- bitget_baseline.py 因此改用 Bitget 原生基线定预算：余量 BTC -0.13bp、
  ETH +4.02bp、SOL +2.92bp。BTC 本就为负，只作延迟测量的参照物

运行时选型：

- parity_env.py 容器与本机信号逐一相同（下标、中枢数、checksum 全等），
  容器内 0.26s/币反而更快。故 chanlun 直接挂载进容器，不必另起信号服务。
  装进现有 .venv 那条路走不通：Hummingbot 要 numba>=0.61.2 与
  aiohttp<3.14，与本机 Python 3.14 冲突
- latency_ccxt.py / latency_hummingbot.py / latency_compare.py 初测显示
  Hummingbot 比 ccxt.pro 慢约 1030ms，90 根逐根配对里 80~97% 更慢
- probe_ws_action.py 否掉「丢弃 snapshot」的猜测：换根首条就是 update
- probe_hb_vs_raw.py 与 latency_attribute.py 四路归因——容器网络 2~18ms、
  Hummingbot 处理 -10~-30ms，1350~1480ms 全落在解析方式上
- probe_ws_payload.py 定位根因：Bitget 换根会推一条带两根的消息
  [上一根, 新一根]，而上游取 data["data"][0] 拿到的是上一根，新一根要等
  下一条单元素消息

修复：

- patched_candles.py 处理消息里的全部元素。不能简单改成 [-1]——那样上一根
  的收盘价会永远停在换根前约 1 秒的那次推送上，而信号对 0.25bp 都敏感
- verify_patch.py 60 根配对验证：拿回 1060~1090ms，与原始 WS 只差 5~14ms
  已贴理论下限，19 根已收盘 K 线 OHLCV 逐根未变。折算 ETH 省 0.54bp、
  SOL 省 0.42bp。此 bug 值得向上游反馈

影子交易器：

- shadow_hb.py 不下单，读连接器真实盘口按仓位吃单深度算成交价，与次根开盘价
  （回测 entry_delay=1 的口径）相减，分解成延迟漂移、盘口价差、深度冲击。
  盘口 10Hz 滚动缓冲 30 秒，把延迟变成自变量：每个信号记 0.5/1/2/5s 与实际
  算完时刻各一个滑点值，本机算得慢也不影响能读出的曲线
- shadow_signal.py 信号计算隔离到子进程。0.26s 是纯 CPU 且 chanlun 受 GIL
  限制，放进 asyncio 循环会把行情处理一起卡住
- shadow_report.py 首日延迟门槛与滑点曲线报表

不用 paper trade 测滑点：它的成交由 Hummingbot 自己的撮合模型模拟，
测出来是模型行为而非市场行为。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-27 23:51:57 +08:00
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
UbuntuandCursor b286cb0137 chore: 忽略 Office 文档与虚拟环境目录 
手续费.xlsx 一类文件放在仓库旁但不属于仓库；~$ 开头的是 Excel 打开工作簿
时生成的锁文件，每次都会重新出现并占据 git status。

.venv 一并声明：venv 自 3.11 起会在它创建的目录内写 .gitignore，但仅覆盖
该目录，换个位置或用旧版本就失效。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-27 02:08:12 +08:00
UbuntuandCursor a243edd2d3 docs: 补依赖清单与 README 
此前仓库无任何依赖声明。按 AST 扫描全部 import 后按用途切分：
requirements.txt 为核心运行时 8 个包，requirements-dev.txt 追加测试与
research/ 所需。

matplotlib / mplfinance / xgboost / scikit-learn 只出现在 ChanPY.py、
ChanLun_Classifier.py、Find_Trend.py、ChanHeng.py 这四个零引用文件中，
故不纳入清单；ChanPY.py 依赖的外部 chan.py 库本就未安装。

README 记录目录结构、启动方式、库用法、分析流程九步与数据约定，并注明
三处现存问题：web/DEPLOY_GUIDE.md 引用的 6 个部署脚本已在 7f393b9 删除、
web/README.txt 指向不存在的 web/requirements.txt、systemd unit 的端口
8123 与 config.py 默认的 8128 不一致且 gunicorn 未声明。

清单已在全新空 venv 中验证：仅装 requirements.txt 时 57 个模块可导入、
Flask 16 条路由正常；装 dev 清单后测试 24 通过。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-27 02:01:53 +08:00
UbuntuandCursor 206b27fe72 refactor: 以自实现指标替换 talib 与 technical 依赖 
chanlun/indicators/ta.py 接口兼容 talib.abstract，实现代码实际用到的
SMA/MA/EMA/RSI/ATR/MACD/BBANDS；chanlun/pipeline/resample.py 替代
technical.util.resample_to_interval。调用点只改 import，逻辑未动。

暖机长度与平滑种子按 TA-Lib 的约定实现，差一根 K 线就会让下游所有
笔/线段/中枢整体位移。其中 MACD 需特别处理：TA-Lib 让快慢两条 EMA
在同一根 K 线出首值，因而快线的种子取 x[slow-fast:slow] 的均值，而非
从 fastperiod-1 一路递推——两者在百元价位上相差约 0.17。

BBANDS 是有意的分歧：TA-Lib 用 sumsq/n - mean² 求方差，短窗口远离零
时灾难性抵消（timeperiod=2 误差 8.7e-7），本实现用 rolling std，对 50
位精度基准误差为 0。项目实际使用的周期两者一致到 1e-10。

顺带清理 12 个文件中 16 处从未调用的 talib/technical 导入。

验证：9440 组随机对拨；真实 K 线端到端比对 add_indicators 全部 33 个
指标列，NaN 模式一致、MACD 柱符号 100% 相同；屏蔽两个包后 60 个模块
均可导入。新增 test_ta_compat.py 将输出逐 bar 钉在 TA-Lib 上，但该文件
在 TA-Lib 缺失时静默跳过，改动 ta.py 需在装有 TA-Lib 的环境复跑。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-27 02:01:43 +08:00
jackyu66gitandCursor 7f393b93ed refactor: 精简仓库为 chanlun 核心与 web 分析，移除威科夫与遗留模块 
删除根目录旧 Chan 模块、策略、配置、文档及 wyckoff 相关代码；更新缠论 pipeline 与笔中枢计算；补充 research 研究与 web 测试。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-27 01:05:12 +08:00
jackyu66gitandCursor 5c10e35b76 refactor(web): 移除主图威科夫选项与叠层 
去掉区间/阶段/时间/VP 开关、Cycle 摘要面板及绘制逻辑；分析请求默认 include_wyckoff=0。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-26 01:27:51 +08:00
jackyu66gitandCursor 8c165f11cd fix(web): 未完成笔/线段终点对齐图表最新 K 线 
各周期使用对应 kline 数据，终点时间 snap 到 candles，优先使用分析 end_price。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-26 00:40:41 +08:00
jackyu66gitandCursor 97e77847d0 fix(web): 开关缠论元素保留视窗；分周期 Trend 涨跌配色 
本地重绘统一冻结视窗；次/次次周期 Trend 上涨下跌使用独立颜色。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-25 23:56:55 +08:00
jackyu66gitandCursor 90499533fb fix(web): 分析/自动刷新后保留 K 线视窗位置 
拆分手动分析与自动刷新拉数路径；全量重建用 logical 优先恢复视窗，
增量 recent 用 scroll+barDelta；避免 barSpacing 重锚与重复冻结导致往右跳。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-25 23:38:20 +08:00
jackyu66gitandCursor 8ee11317d3 fix(web): 自动刷新保留 K 线视窗；威科夫与图表增量更新 
自动刷新改用 tail update 与 scrollToPosition 恢复视窗，避免 setData 后跳到最右；拆分 chart_tv 模块并扩展 analyze/recent API。同步威科夫分析、pipeline 增量构建及相关策略与配置。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-25 22:57:43 +08:00
jackyu66gitandCursor 1e60ab3bfa docs: 补强 ECR-004 CODE_REVIEW 复审记录 
Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-06 18:47:18 +08:00
jackyu66gitandCursor d3188ca83c fix: ECR-004 威科夫区间评分硬化与 VP 绘图减负（已审） 
评分选 TR、阶段最小跨度、elements_only 门闩、Top-8 VP；无币种独立参数。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-06 18:46:08 +08:00
jackyu66gitandCursor ac6be80278 docs: 开启 ECR-004 威科夫硬化与 VP 减负（Draft） 
跟进 ECR-003 Review Findings；待 Approve 后实现。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-06 18:35:25 +08:00
jackyu66gitandCursor 081a57a90e feat: ECR-003 主站威科夫分析与图表叠层（已审） 
独立 wyckoff 引擎 + 按需 include_wyckoff；主站 Lightweight 绘制区间/阶段/事件/VP。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-06 18:33:57 +08:00
jackyu66gitandCursor df27b4dde8 refactor: ECR-002 拆分 runtime 包并加深 analyze 契约（已审） 
将 web/services/runtime.py 拆为 runtime/ 子模块并保持门面兼容；补齐 ESS 文档、门面/契约/TF_DF 测试与 CODE_REVIEW Approve。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-06 18:15:23 +08:00
jackyu66gitandCursor 9f1e7361b6 fix: 修复主站自动刷新内存泄漏，并完善 chan_tv 图表体验 
主站重建前完整 dispose、去掉重复 sync 监听，自动刷新默认增量更新；顺带消除首屏重复 analyze、复用 ChanMACD，以及全版 TV 指标/未完成中枢/布局本地缓存。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-06 16:09:48 +08:00
jackyu66gitandCursor 6b0f3b5837 release: 发布系统版本 v1.0.0（ECR-001） 
落盘 CODE_REVIEW Approve 与 RELEASE_REPORT，标记首个正式 release。

Co-authored-by: Cursor <cursoragent@cursor.com>
v1.0.0 		2026-08-05 18:53:04 +08:00
jackyu66gitandCursor 74dec4e50b refactor: 缠论引擎包化与 Web 分层（ECR-001） 
将根目录引擎迁入 chanlun/ 并保留兼容 shim；拆分 TF_DF 与 web 服务；
前端模块化；strategies 改用 chanlun 导入；补充 ESS 文档与 golden 回归。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-05 18:48:20 +08:00
jackyu66gitandCursor e2e45bc1bc chore: 移除不再使用的 ChanMacro、system、tests。 
这些目录已废弃，从仓库中清理。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-05 18:11:29 +08:00
jackyu66gitandCursor f2e77e1bdb chore: 将 data_provider 拆出为独立仓库。 
数据服务已迁移至 jack/data_provider，不再随 chan 维护。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-05 18:10:29 +08:00
jackyu66gitandCursor b31215057e chore: 将 bsp_monitor 拆出为独立仓库。 
监控服务已迁移至 jack/bsp_monitor，不再随 chan 维护。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-08-05 18:09:43 +08:00
jackyu66git 2e905e7238 feat: 所有页面接入 Google Analytics (G-LVVXH3TL04) 2026-07-02 15:57:15 +08:00
jackyu66git 02a52c04dd feat: 所有页面接入 Google Analytics (G-LVVXH3TL04) 2026-07-02 15:38:31 +08:00
jackyu66git 19c8f86862 docs: API 手册新增 Onchain Metrics 专题 + endpoints 表更新 2026-07-02 15:19:45 +08:00
jackyu66git ffe7074fef data_provider: 新增链上指标模块 (btc_netflow/stablecoin_supply/etf_flow/mvrv_zscore) 
- onchain_metrics.py: 独立模块，CoinMetrics/CoinGecko/Farside 免费数据源
- main.py: 集成后台线程 + REST API (/api/onchain/metrics, /latest, /available)
- requirements.txt: 添加 requests 依赖
- 5分钟自动刷新，CSV 落盘到 data/onchain/
 2026-07-02 15:09:02 +08:00