mcpField
P
prediction-market-live-ops

prediction-market-live-ops

github.com/agiprolabs其他456148 次安装8 周前更新
代码仓库

关于 prediction-market-live-ops

面向预测市场运营者的实盘策略验证与执行技能,涵盖从回测到小额实盘的证据门槛、订单安全措施和实验规范。

主要功能

  1. 01按证据逐步推进策略
  2. 02回测与成交验证规则
  3. 03实盘订单及风险控制
  4. 04仓位扩张门槛
  5. 05成交分组与实验记录

适用场景

  1. 01扩规模前验证策略
  2. 02排查实盘订单执行问题
  3. 03检查盈亏是否过度集中

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/agiprolabs/claude-trading-skills --skill prediction-market-live-ops

安装后在 Claude Code 中输入/prediction-market-live-ops确认已加载。

详细介绍

预测市场交易准则

来自 Kalshi 实战活动的宝贵经验(2026 年 8 月至 9 月: 加密货币/大宗商品做市阶梯、市场状态倾斜、网球尘埃盘扫荡——所有策略都经过诚实检验并被证伪,基础设施已开源)。参考实现:https://github.com/agiprolabs/kalshi-stack。 作为 prediction-market-strategy(优势选择/仓位 sizing)的补充——本技能涵盖运营层面:如何在真实市场中验证、执行并终止策略,同时将损失控制在学费范围内。

首要原则

每项策略决策都必须以证据为依据:回测 → 模拟交易 → 真实小额试探 → 逐步加码。每个阶段都要预先声明终止条件,并正确校准概率计算,在数据出现之前写下来。如果发现阈值校准不当,就公开修正并重新声明——绝不能悄悄朝任一方向移动目标线。

回测规范(每条规则都曾被违反过一次,代价惨重)

  • 被动成交策略的逐笔成交回放 EV 是上限,绝不是估算值。 静态挂单实际捕获的成交记录,是磁带中经过不利选择的样本(足以深入触及你的队列偏差的扫单,往往对应真正的崩盘)。一个网球尘埃盘通过成交记录测得 +125%/$,但实盘 78 次全未成交(P<2%)。只有按成交条件筛选的实盘结果,才能验证做市策略。
  • 时间序列连接要使用结束时间 ≤ 决策时刻的最后一根 K 线。 包含该时刻的 K 线会造成前视偏差,凭空生成样本外消失的协变量。
  • 吃单回测需要成交记录确认可执行性,不能依赖报价卖价优势——过时报价会产生虚假成交。
  • 任何按桶审查 PnL 时都要包含 Top-N 占比列。 彩票式收益的订单簿会集中 EV;所谓的“模式”如果只由两轮巨额收益构成,那就是噪声。留出集“获胜”时也遵循同一规则:先检查集中度,再决定是否相信。
  • 提前结算会产生偏向亏损方的选择偏差(崩盘结束得快;逆转则需要较长的比赛/回合)。切勿依据快速结算的前缀下结论。
  • 如果静态倾斜在磁带前后两半之间改变符号,那就是市场状态押注,而非优势。 条件化方案必须在两半数据及每天的数据上都胜过基线;预先登记规则,不得按天拟合。
  • 镜像/互补市场是同一笔押注——计算基于独立性的概率前先去重。

实盘执行规则(事件账本)

  • 通过真实的 1 手往返交易,对每条实盘下单路径进行冒烟测试(下单、确认订单仍挂单、撤单、确认订单已消失),然后策略才能通过该路径交易。模拟交易无法测试交易场所的路由参数。成本:$0.01。
  • 如实处理撤单结果:区分已撤单/订单已不存在(已成交!)/撤单失败。404 不代表撤单成功——这意味着路由到了错误的分片,或发生了成交竞态。忽略撤单失败并不断重新锚定,会导致持仓失控叠加(我们曾因此在一个晚上损失 $84)。
  • 在每次调用中始终一致地指定交易所分片(exchange_index)——下单、读取、撤单、抵押品操作,无一例外。下单前必须先在对应分片上备好抵押品。
  • 通过小额订单实测速率限制(逐级加大发单突发量,并进行持续测试)。公布的额度与实际每单消耗可能相差 10 倍。按实测速率控制突发下单节奏,并在收到 429 后重试并重新入队。
  • 任何做市策略都必须使用 post_only——市场价格在你的价格区间内交易时,“激进做市”价格会悄无声息地变成吃单成交,形成另一笔未经验证的交易。所有已实现 EV 账目中,做市成交和吃单成交必须分别标记并分组统计。
  • 始终设置防护机制:每批订单下达前检查停机文件(文件出现时全部撤单);通过独立调度器驱动回撤熔断器,并检测存款突增;设置每笔订单和每个市场的规模上限,并记录异常事件;触及权益底线时停止交易。熔断器基准值应在每次交易时段开始时,根据操作者声明的可承受损失设定。
  • 在便士价位的做市簿中,队列优先级就是核心优势。对于同步开盘的交易场所:使用 NTP,并在边界时刻 +0 发单,同时探测重试(测量交易场所从开盘切换到可交易状态的延迟)。对于事件驱动型交易场所:基于推送的发现机制(生命周期 WebSocket 通道)优于轮询;新市场的订单簿是空的,因此最先挂单者可在其存续期间占据该价位。
  • 在活动边界时重启守护进程;在轮次中途重启会使内存状态成为孤儿(订单未受跟踪、结算被遗漏)。
  • 地理围栏确实会执行:下单来源 IP 很重要,不同类别(体育/选举与金融产品)规则不同,执行方式也可能一夜之间改变。数据中心位置属于合规态势的一部分。

扩展原则

  • 用盈利滚动加仓:只有当当前阶段的已实现利润足以覆盖下一阶段的增量风险,且轮次数和 EV 连续性门槛均通过时,才将规模翻倍。若滚动表现恶化,则退回上一阶段。
  • 先测量容量曲线(按每笔成交上限计算 EV/$),再相信任何规模扩展预测;之后的瓶颈就是捕获率 × 实测资金池,而捕获率只有通过实盘才能测量。
  • 每次提高规模时,成交质量都是尚未验证的环节——每个阶段的模拟/实盘 EV-per-$ 比率决定是否进入下一阶段。

实验操作

  • 在写入时按类别记录每笔成交(做市/吃单、价格区间、来源)——事后归因才能揭示错误对结论的污染。
  • 一次只调整一个变量;在同一时间窗口内同时改变规模和下单逻辑,会破坏归因。
  • 使用冻结的基线,在模拟交易中运行 A/B 变体(小规模变体、共享轮次,并以 EV/溢价-$ 作为不受规模影响的评判标准)。
  • 将所有内容记录到只追加的账本中;将已实现 PnL 与交易场所自身的成交/结算记录核对,而不是与内部估值核对。
  • 将结果(成功和证伪结果)都发布到操作者的频道;每次发布、退役和终止都要编写决策记录,列明证据和回退条件。

评论

支持 Markdown