mike/Hermes-Skills

Fork 0

Files

T

mike f46abb8ca3 trading skills: 文档同步 (单币上限规则/平仓盈亏字段/静默规则/推送模板)

2026-09-25 01:25:13 +08:00

5.6 KiB

Raw Blame History

v4.5.95 (2026-09-13/20) 新格式动作信号 parse 失败 = 白名单内信号跟丢 + GET 签名 Invalid Sign + 熬鹰分批减仓模式

会话背景

9/13-9/20 信号风暴后半段: ZEC / UNI / ZAMA / BTC 全周期 + 熬鹰币安实盘开始用两种格式混发。

🚨 发现 1: 新格式动作信号 parse 全灭 → 白名单内信号静默跟丢

两种格式并存 (同一 trader 同一天)

老格式 (能解析):

【熬鹰币安实盘】
📈 注意，大佬加仓了
【币种】：UNIUSDT 永续 | 全仓 | 2x
【方向】：做多 🟩
【持仓量】：12324.00 UNI

新格式 (parse 失败,静默跳过):

熬鹰交易信号

📈 注意，平仓
币种：ZECUSDT 永续 | 全仓 | 5x
方向：做空 🟥
平仓数量：334.88 ZEC
开仓均价：1194.44 USDT
当前价格：1214.09 USDT
更新时间：2026-09-09 12:34:50 UTC+8

区别: trader 无【】前缀 / 字段用全角冒号无【】标签 / 多了"原仓位/现仓位/更新时间"字段。

危险性评估

v4.5.93 的结论"'当前全部持仓'汇总播报 parse 失败即安全,不必适配" 只对汇总播报成立。本次实测:

熬鹰交易信号 的 ZEC 平仓/加仓动作信号 全部 parse 失败 → 没跟
熬鹰币安实盘 新格式加仓信号 (UNI 加仓 2x->1x) 也曾 parse 失败
白名单内 trader 用新格式发动作信号时,信号被静默丢弃 = 跟单完全失效

当时是运气好: 熬鹰交易信号的 ZEC 多单与你持仓的 ZEC 空单方向相反,parse 失败反而避免了反向操作。但不能依赖运气。

待 user 决策 (不要擅自适配)

两个方案:

A. 扩展 parse_signal 适配新格式 (全角冒号 + 原仓位/现仓位字段 + 无【】trader 行) — 风险: 汇总播报也会被解析,可能误 execute 状态推送
B. 保持 parse 拒绝,新格式信号一律丢弃 — 风险: 白名单内 trader 换格式后跟单失效,且 user 不知道跟丢了

处理原则: 发现 parse 失败的白名单信号时,明确告知 user "这条信号格式解析失败,没跟",让 user 决定是否手动跟/是否适配 parse。禁止静默丢弃不报告。

🚨 发现 2: GET 请求带 params 的签名 — 必须字典序排序,否则 50113 Invalid Sign

现场

无持仓但 frozenBal 显示 $132,想查挂单确认:

r = okx_get('/api/v5/trade/orders-pending', {})  # 空 params
# → {"msg": "Invalid Sign", "code": "50113"}

根因

_okx_raw_request 的 GET 签名规则: auth = ts + method + path + '?' + sorted_query。query 参数必须按 key 字典序排序后 urlencode 拼接。手写模板里 query='?'+'&'.join(f"{k}={v}" ...) 没排序也没 urlencode → 签名不匹配。

正确签名模板 (GET)

sorted_q = '&'.join(f"{k}={urllib.parse.quote_plus(str(v), safe='')}" for k, v in sorted(params.items()))
auth = ts + 'GET' + path + '?' + sorted_q
# 请求 URL 也用同一个 sorted_q

铁律: GET 带参数的 raw REST 调用必须走 _okx_raw_request (它已正确实现排序),不要手写简化版签名。POST 的 body 是 json.dumps 后直接拼,无排序问题。

📊 发现 3: 熬鹰"分批减仓兑现"模式 (trader 行为)

ZAMA 持仓 4,989,469 张浮盈 +$67k 后,熬鹰没有一次全平,而是连续 5+ 条减仓信号:

4989469 → 4984285 → 4974200 → 4959477 → 4937656 (每次减 0.1~0.5%)
已实现盈亏: $75 → $229 → $357 → $450 → $765 (逐级累加)

模式解读: 大浮盈时用小步多次兑现利润,剩余仓位继续吃趋势。这与内幕哥 HYPE "死拿不清"相反,是边涨边卖策略。

跟单含义: 每条减仓信号只减 0.1-0.5%,advisor 算出的跟单张数会小于最小变动单位 (张),大概率 "单币超限跳过" 或 0.00x 张无效。实战处理: 累计多条减仓信号后一次性按总比例减,不要每条都试。

📊 发现 4: close 信号要与"当前全部持仓"汇总交叉验证

现场 (9/13 UNI/ZAMA)

熬鹰币安发 UNI 平仓信号 → 你跟平 UNI ✓ (正确)
同期 ZAMA 浮盈 $52 时也平了 (疑似连带平仓/或独立 close 信号)
之后熬鹰"当前全部持仓"汇总显示 ZAMA 还拿着 4,989,469 张,一路涨到浮盈 $74k

教训

close 信号执行后,如果该 trader 的下一条汇总播报显示币种还在持仓,说明:

close 可能只是减仓了一部分 (信号显示"平仓"但实际是 reduce)
或 trader 有多个账户,平的只是其中一个

实战处理: 平仓后若再收到该 trader 的同币种加仓/减仓信号,不要惊讶,按信号重新跟。错过 ZAMA 后续 $67k 浮盈是因为他"汇总还拿着"而你以为他清仓了——以最新信号为准,不用后悔,也不用反向追。

本 session 其他验证 (已录入旧版本,不重复)

advisor reduce 方向 bug 第 4 次: SKHYNIX 减仓信号被报成"加仓 1.045 张" (v4.5.88 已录)
advisor 建议量偏差: ZEC 52→157 张 (3x) / ZAMA 811→2544 张 (3.1x) / BTC 0.85→2.58 张 (3x) (v4.5.91 矩阵已录)
59108 降杠杆拒绝: UNI 1→2x / BTC 10→5x 全部失败,cross 模式分账户余额不足 (v4.5.93 已录)
推送成功 ≠ 订单落地: CL 减仓"已推送 21 张"实际一股未减,手动按比例减 (v4.5.84 已录)
frozenBal 幽灵: 无持仓但冻结 $132 (挂单未成交/未撤),权益含冻结部分,不影响真实性

一行式汇报格式 (本 session 起默认)

信号处理回复压缩为一行: 信号类型已处理; 持仓概要 (币种张数@杠杆浮盈亏); USDT可用$X/权益$Y。中间过程 (proxy 重试/dedup 清理) 不展开,除非 user 问。

5.6 KiB Raw Blame History