 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
|
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 |
|