来源归档
公开帖正文、引用内容与五张来源标注截图；原始媒体 SHA-256 一并保留。
01 / 来源与边界
先分清：谁说了什么
资料来源为 Captain（@mycndota）2026-11-05 的公开帖，以及帖内引用的 2026-11-03 内容。下方带来源标签的引文保留原帖自述；Panor 不把引文改写为卖家的效果判断。
原帖作者自述，样本待积累，不代表本商品或 Panor 的收益承诺。
查看公开帖原始来源。五张截图仅作为来源材料归档，均附有来源标注。本商品不含交易所密钥、实盘下单客户端、Captain 私有程序或授权背书，也不是投资建议。
02 / 原帖摘录
原帖摘录（来源：Captain @mycndota 公开帖）
最新策略已经可以稳定盈利！！暂时胜率 100%，样本待积累。（截图均为实测数据！）
策略：SPY 在 Arcus 挂单，成交后立刻在 Lighter 吃单对冲，只在积分加成时段开仓。
截上图跑了 22 轮了，Arcus 26万左右的量，费用 -$9.6，手续费大概是 -$0.0002 一笔，吃单 0.02maker 0.002，Lighter 吃单大概是 0.003taker，纯吃单亏损，但吃单的滑点可控，积分加成是10x（最高）这个亏损可以靠积分预期收益覆盖。
最开始没用 SPY，用的 BTC，发现差价太难覆盖吃单磨损和资金费率，换 SPY 之后，价格稳定，滑点小，资金费也低，就算两腿错开300ms，亏损也可控。
配置比较：1. 要用 API 挂单，网页手动下根本抢不到，成交后立刻对冲。2. 只开积分加成时段，别贪，非加成时段开仓就是给交易所送磨损。3. SPY 比 BTC 适合这个玩法，价差小但稳定，靠积分覆盖。4. 一定要控制对冲延迟，我 Python 写的对冲程序 7.5ms，但交易所那边有 300ms 延迟，这个没办法，只能靠优化本地端把能省的毫秒省下来。
Python 对冲程序的优化点：1. 用 websocket 推送而不是 REST 轮询，省掉一次往返。2. 预签名 + 连接池复用，别每次成交都新建连接。3. 本地算价差用 numpy 向量化，纯 Python 循环太慢。4. 对冲单提前组装好，成交回调里直接发，别等序列化。
算下来本地端能从 7.5ms 压到大概 3-4ms，所有琐碎优化加起来大概 0.003ms，聊胜于无，但积少成多。Rust 重写的话本地端能压到 <1ms，不过交易所 300ms 延迟还在，省下的 6ms 对整体几乎没影响，先不折腾了。
结论：这个策略核心不是预测涨跌，是拼毫秒和积分窗口。别在剧烈波动时段开，滑点会吃掉积分；腿错开太久就手动止损，别硬扛。样本还少，继续跑，后面有数据再更新。
引用帖亦为作者自述：22 轮、辅助年化收益、积分预期收益、7.5ms 与 300ms 等数字用于来源核对，不代表 Panor 的独立测量。
原帖作者自述，样本待积累，不代表本商品或 Panor 的收益承诺。
03 / 交付内容
一套可检查的工程文档
策略与延迟
流程、7.5ms 本地端、300ms 远侧延迟、350ms 风险讨论量级与配置比较表。
离线示例
22 轮公开数字的确定性汇总，不连接场所、不读取凭证、不发送订单。
实施边界
测量字段、人工停止条件、风险清单与验收顺序，全部用简体中文说明。
04 / 来源标注素材
截图是证据材料，不是商品封面
05 / 购买与交付
价格固定，内容边界写清楚
两个同类闲鱼链接均按 ¥9.90 成交。付款后由订单发送专属下载链接；下载页仅展示资料包、中文 PDF 与 12 小时窗口，不要求另开账号，不要求输入 API 密钥。资料包不包含后续行情、人工代部署或收益判断。
适合：想核对公开帖数字、搭建自己的测量日志、评估是否值得投入工程时间的读者。不适合：寻找可直接运行的自动交易程序或效果承诺的读者。