Stats
Actions
Tags
From latency-hunter
逐项审查交易系统的风控配置(risk_config.json/yaml)与 pre-trade 风控代码,定位"会让风控形同虚设、实盘爆仓"的工程缺陷,精确到 文件:行,按严重度输出"风控体检报告"。覆盖限额/回撤/杠杆/kill-switch/防胖手指/保证金/爆仓模拟/并发在途订单/单点故障/运维/密钥。触发词(中):风控审查、风控体检、风控配置、仓位上限、敞口上限、回撤止损、最大回撤、kill-switch、爆仓保护、强平、维持保证金、防胖手指、限额、在途订单。触发词(英):risk config、risk limit、risk audit、kill switch、kill-switch、fat finger、fat-finger、liquidation、margin、drawdown stop、position limit、in-flight order、risk-config-lint。不适用:策略 alpha/信号逻辑/调参寻优、行情数据源运维、回测可信度审查(用 backtest-guard)、连接器可靠性(用 connector-forge)、非风控的通用代码审查;也绝不承诺"绝对不爆仓/绝对安全"——本 skill 只做工程审查,不替代实盘风控演练。
How this skill is triggered — by the user, by Claude, or both
Slash command
/latency-hunter:risk-config-lintThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
风控是整条交易链路的**最后一道闸**:它平时不赚一分钱,存在感为零;可一旦漏了,就是本金归零、穿仓欠债。所以判断风控好坏,不看它"有没有",而看它"在最坏的那一刻有没有真正生效"。
风控是整条交易链路的最后一道闸:它平时不赚一分钱,存在感为零;可一旦漏了,就是本金归零、穿仓欠债。所以判断风控好坏,不看它"有没有",而看它"在最坏的那一刻有没有真正生效"。
本 skill 盯的是一类特别阴险的缺陷:看着有风控、实际没生效。配置里写满了 max_position、daily_loss_limit、kill_switch,下单路径却根本没调用它们;止损算法分母用错,账户从峰值深跌却永不触发;限额加载失败时 except: pass 继续裸奔下单;或者风控只看"已成交持仓",多笔并发在途订单合计早已超限——这些都比"压根没风控"更危险,因为它们给了你虚假的安全感。
审查时坚持三条判据:
再加一条贯穿全程的追问:它喂进去的状态、它放过去的并发,是真的吗? 限额只有在"持仓/资金状态真实"且"并发订单合并计敞口"时才真生效。
risk_config.json / risk_limits.yaml 之类风控配置,或 pre-trade 风控、下单校验代码丢过来,让你审"靠不靠谱/会不会爆仓"。不适用:策略 alpha/信号/调参(那是策略层),回测可信度(用 backtest-guard),连接器断线重连(用 connector-forge),热路径微秒优化(用 latency-audit)。本 skill 也绝不承诺"绝对不爆仓/绝对安全"——只做工程缺陷审查。
按以下步骤系统过一遍,不要跳:
place_order / submit_order / new_order / send)的唯一收口处。确认风控检查在 submit 之前(pre-trade)还是在 on_fill/对账回调里(post-trade)。文件:行 与触发它的具体场景,不要泛泛而谈。配置缺失项就指出"该有却没有"的字段。找不到证据的项标"未发现/需人工确认",不臆测。except: pass、空默认 dict、limits or {}、加载失败继续下单、状态对账失败仍放行——都是致命的 fail-open。log.warning 不 raise/return reject 的等于没拦。place_order 反向追踪到一个会 raise/return reject 的 gate,确认它被真正调用、并且喂给它的敞口口径包含在途订单。本 skill 力求自包含:下文已内联两大类陷阱中每一条的检测要点。
references/risk-pitfalls.md(若仓库提供)是可选延伸,含更细的代码反例与正则提示;该文件缺失时,仅凭本 SKILL.md 即可独立完成一次完整审查。
下单链路本身的硬约束。逐条检测要点:
on_fill/对账回调里才出现限额比较,而 submit 前没有。max_order_notional / max_gross_exposure,或下单直接照 signal_qty 走、对 NaN/inf/负数无拦截。initial_capital 而非 running peak;equity 只算 realized;peak 是进程内变量、无持久化。log/alert,无 cancel_all/flatten/进只减仓态的程序动作。cancel_all/flatten 与普通下单共用同一限频桶、无紧急配额。修复:紧急动作走独立配额或绕过普通限频。max_open_orders。限频严重度口径:限频(rate limit)缺失默认 HIGH;但当限频不当导致救命动作(撤单/平仓)也发不出去时,升级为 FATAL。
完整 14 条(含单品种上限、集中度、per-symbol 杠杆等)的更细代码反例,见可选的 references/risk-pitfalls.md 的 limits 段。
风控的"生存性"与运维面。逐条检测要点:
place_order 反向追踪,确认必经一个会 raise/return reject 的 gate。except Exception: limits = {}、limits or {}、加载失败仅 log 后继续。try/except: pass 后照常下单,遇到 edge case 就静默关闭,比没风控更危险。maintenance_margin/liquidation_price 计算,下单前不冻结/扣减可用资金。testnet/live 由同一可变标志切换、无强隔离,风控状态库 test 与 live 混用。alert 仅单一 telegram/邮件通道。api_key/secret 明文值而非 env 注入。完整 16 条的更细代码反例,见可选的 references/risk-pitfalls.md 的 ops 段。
审查结束后,用下面这张可截图的表格汇报。先给总览结论,再逐条展开。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
风控体检报告 / Risk Config Lint
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
审查对象 : risk_config.json + order_gate.py
体检结论 : ❌ 不可上线(4 致命 / 2 高危)
一句话 : 限额配置齐全但下单路径未调用,pre-trade gate 缺失且并发在途单不计敞口,风控形同虚设
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[FATAL-1] 风控只在 post-trade 拦截,缺 pre-trade gate
位置 : order_gate.py:42 submit_order()
现状 : submit() 前无任何风控校验,超限在 on_fill 才告警
影响 : 超额敞口已成交,极端行情平不出 → 爆仓
修复 : 所有订单提交前同步过统一 risk gate,任一不过即 raise RejectOrder
[FATAL-2] 缺失单笔下单上限 (max order notional)
位置 : order_gate.py:18 / risk_config.json 缺 max_order_notional 字段
现状 : 直接照 signal_qty 下单,NaN/巨大值无拦截
修复 : 按 notional 校验 + 拒绝 NaN/负数/inf,上限随净值缩放
[FATAL-3] 敞口口径漏算在途订单(并发竞态)
位置 : order_gate.py:30 check_exposure() 仅读 position
现状 : 检查与下单非原子,在途未成交订单不计入敞口;连发 N 笔各自合规、合计超限
影响 : 快速连发/并发时实际敞口数倍于限额 → 超限建仓 → 爆仓
修复 : 敞口=持仓+在途预留名义;检查-下单持锁原子化或 reserve-then-commit,testnet 并发复测
[FATAL-4] 限额加载失败 fail-open
位置 : config_loader.py:55 except Exception: limits = {}
现状 : 配置加载失败时用空 dict 继续,等于无限额
修复 : fail-closed,加载失败拒绝启动 / 保留上一份已知良好限额
[HIGH-1] 缺失日内回撤止损
位置 : 下单循环 strategy.py:80,无账户级回撤检查
修复 : 账户级 DAILY_LOSS_LIMIT + MAX_DRAWDOWN(分母用历史峰值、含浮亏),触发进只减仓态
[HIGH-2] 告警单点 + 无 deadman switch
位置 : alert.py:12 仅单一 telegram bot
修复 : 多渠道冗余 + 风控线程心跳 + 独立 watchdog
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
通过项 : ✅ 杠杆本地上限校验 ✅ 价格 fat-finger 边界
上线判定 : 致命项全部修复 + 复测前,禁止接实盘资金
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
要点:每条至少含 位置(文件:行)/ 现状 / 影响 / 修复;总览给出致命与高危计数;明确"能不能上线"的硬结论。找不到证据的项标"未发现/需人工确认",不硬凑。
| 级别 | 含义 | 处置 |
|---|---|---|
| FATAL 致命 | 会直接导致本金归零、穿仓欠债或风控整体失效(pre-trade 缺失、在途订单不计敞口、fail-open、无止损、无界杠杆、密钥泄露)。 | 上线前必修,不修则禁止接实盘资金 |
| HIGH 高危 | 显著放大爆仓概率或在常见故障下失效(集中度、单品种上限、限频缺失、救命通道未隔离、状态未对账、告警单点、无热加载)。 | 强烈建议上线前修复 |
| MEDIUM 中 | 维护性/受控性缺陷,极端场景才出问题(复位流程、schema 校验细节)。 | 排期修复 |
| LOW 低 | 风格、冗余、可观测性增强建议。 | 可选 |
限频严重度补充:限频(rate limit)缺失默认归 HIGH;若该缺失导致救命动作(撤单/平仓)也被限掉发不出去,则升级为 FATAL。
npx claudepluginhub paidaxing1234/latency-hunter-toolkit --plugin latency-hunterSearches MemPalace before answering questions about past work, people, projects, or prior decisions. Returns verbatim stored content instead of guessing from model memory.
Guides Payload CMS config (payload.config.ts), collections, fields, hooks, access control, APIs. Debugs validation errors, security, relationships, queries, transactions, hook behavior.
Implements vector databases with Pinecone, Weaviate, Qdrant, Milvus, pgvector for semantic search, RAG, recommendations, and similarity systems. Optimizes embeddings, indexing, and hybrid search.