ARTICLE · 1273126
ai交易量化套利系统开发实战与策略分析-下
ai交易量化套利系统开发实战与策略分析-下接着说下文，下文主要说的是上服务器，实际跑起来的部分，核心观点在文章末尾，着急的，可以直接拉到最后看。 代码改完了，参数调完了，回测也做了，下一步就是实盘。但直接上大资金太冒险，我决定先用 100U 做实验。 方案设计：100U 总资金，分散到 5 个币种，每个币种 20U（现货 10U + 合约保证金 10U）。
关键设计：现货和合约各占一半（POSITION_RATIO_PER_SYMBOL=0.5）。这样 1 倍杠杆下，合约保证金 = 名义敞口，Delta 完美中性。 为了防止误操作，我设计了三道安全开关：
启用顺序：先 DRY_RUN=true 跑 1 周验证逻辑，再切到 DRY_RUN=false + ENABLE_LIVE_TRADING=false 跑 1 周观察「会下单」日志，最后才 ENABLE_LIVE_TRADING=true 真实下单。
前面提到的 DRY_RUN + ENABLE_LIVE_TRADING 双保险，是整个系统最重要的安全设计。核心思路是：任何一道开关没打开，都不会真实下单。 所有下单函数开头都调用这个检查，任何一道没过就直接返回模拟结果，不调用交易所 API。这样即使代码有 bug，也不会误下单。 套利开仓涉及现货和合约两笔下单，必须保证要么都成功，要么都失败。如果现货买成功了但合约开空失败，需要把现货卖回去（rollback）。 这里有个细节：合约做空的数量必须等于现货实际成交数量，而不是计划数量。因为市价单的成交价会波动，实际买到的现货数量可能跟预期不完全一致。用实际成交数量才能保证真正的 Delta 中性。 原本的代码有个问题：平仓后重开新仓，累计费率统计会重置。这意味着长期跑下来，你看不到真正的累计收益。 修法是加一个全局统计模块，跨平仓周期记录： 这些数据持久化到 risk_state.json，重启容器也不丢。这样长期跑下来，能看到真实的累计收益和交易次数。 实盘下单前，系统会自动执行一系列准备步骤，确保账户状态正确： 设置合约杠杆为 1 倍（防止误用高杠杆）； 切换到单向持仓模式（避免 hedge mode 报错）； 切换到逐仓模式（单仓爆仓不影响其他仓位）； 检查最小名义价值（低于 5U 直接拒绝）； 现货市价买入； 合约市价做空（用现货实际成交数量）； 失败时自动回滚。 这些步骤在 DRY_RUN 模式下全部「假装成功」，不会真实调用 API。只有切到实盘模式才会真正执行。
这次协作下来，AI 在这几个方面确实帮上忙了： 1. 快速定位代码 bug。比如给 None 变量赋值、调用方参数不匹配这类问题，AI 几秒就能扫出来。 2. 系统性梳理问题清单。AI 不会只看一个点，它会顺着调用链往上爬，把相关问题都列出来。比如发现 PnL 计算 bug 后，会去查所有用到 PnL 的地方。 3. 生成测试用例。让 AI 写测试脚本验证逻辑，比手动跑快多了。比如 1x vs 2x 对比回测，AI 半小时就写完了。 但也有几个明显的短板： 1. 上下文记忆差。我让它看 A 目录的代码，它可能跑去看 B 目录。我之前说过的约束条件，几轮对话后就忘了。必须反复重申。 2. 对真实 API 行为不了解。比如 Content-Type 头、newOrderRespType 参数、持仓模式切换这些，AI 写的代码在 DRY_RUN 模式下都「能跑」，但真实调用 API 时会报错。这些坑只有实盘才能发现。 3. 会犯常识性错误。最典型的是把风险率 19.88 理解成 19.88%。这种错误看起来低级，但如果用户没发现，可能做出完全错误的决策。 总结几条经验： 1. 明确告诉 AI 当前在看什么。不要说「分析一下代码」，要说「分析 /path/to/arb.py 这个套利策略代码」。路径越具体，AI 越不容易跑偏。 2. 关键数字要自己复核。AI 算账很快，但容易把单位搞错（百分比 vs USDT）。关键决策前自己再用计算器过一遍。 3. 多轮 review 比一次写完重要。AI 写完代码，别急着用。让它自己 review 一遍，再让人工 review 一遍，再让它做语法检查。三轮下来，大部分低级 bug 都能发现。 4. DRY_RUN 模式不能替代实盘测试。DRY_RUN 验证的是「逻辑正确性」，不是「API 兼容性」。实盘启用前，必须接受「第一次实盘可能会报错」的现实，准备好手动处理。
基于 4 天实测数据外推，三种场景下的年化预测：
需要强调：这些预测基于短期数据，实际收益取决于市场环境。资金费率会随市场情绪变化，过去 4 天的高费率不代表未来。 1. 收益集中度风险。当前 5 个币种中，SNDK 贡献了 65% 的收益。如果这个币种费率回归均值，整体收益会大幅下滑。建议增加币种分散度。 2. 极端行情风险。Delta 中性理论上对冲了价差风险，但极端行情下（比如单日 ±20%），滑点和流动性问题可能导致对冲失效。 3. API 故障风险。自动化系统依赖交易所 API。如果 API 故障或限频，可能错过开平仓时机。需要有手动干预的预案。 4. 政策风险。不同地区对加密货币交易的监管政策不同，需要关注当地法规。本文不构成任何投资建议。
这次从「交易所的一张套利截图」到「自己写一套量化系统」的过程，前前后后聊了几十轮，改了三轮代码，做了对比回测，最后还要用 100U 小心试水。 写这篇文章的目的，不是鼓励大家都去自己写量化系统——实际上，对大多数人来说，用现成的方案可能更划算。我只是想展示：当一个普通人坐下来认真对待一件事，借助 AI 的力量，能做到什么程度。 过程中 AI 犯过错（把风险率理解错、看错代码目录、API 接口细节没考虑到），我也犯过错（没说清楚路径、没复核关键数字）。但通过多轮 review 和实测验证，最终还是把一套能跑的系统搭起来了。 技术本身是中性的。套利策略也好，量化系统也好，都是工具。工具能赚钱也能亏钱，关键看用它的人是否理解它在做什么。 希望这篇文章对你有启发。如果你也在做类似的事情，欢迎交流。 方案阶段：自己写的时候，1个方法，先找在线ai问思路，然后根据ai给出的建议，提出各种刁钻问题，从各种角度，当然找不到，你就让ai左右互搏，让他自己说这个思路的问题，最后让他确定一套看起来至少是最稳妥的方案，如果你还不放心，可以再换一个平台，用刚才A的方案，让B去审核，给出反对意见，然后用反对意见，再去反问A为啥没有考虑到。这样的话，方案就会越来越稳妥。但是不建议过于互搏，因为太浪费时间，也不合理，他们最后可能会根据你的方案，给出完全没有任何风险的方案，但是这个方案，一点价值也没有，因为根本就是完美主义，市场上，根本不会出现完全满足对应条件的行情。所以差不多就行。 代码阶段：不知道咋写，就让他先根据github上的代码库，找一些示例，然后再写，其中调用部分平台的部分，可以让他去直接找交易所的帮助文档+接口文档，避免写错，导致浪费你时间，我之前就遇到过经典盘接口，他写的是最新的统一账户接口，导致实际的下单，会提示账户没权限之类的，让我浪费时间看自己账户问题。写完代码，一定要让ai进行代码检查，做各种基础的检查-比如变量名/函数名前后一致，代码导入模块，路径是否存在等等，这些问题，你不会代码的话，也不碍事，你可以让ai把常见的代码错误，都挨个排查一下，是否存在问题，他自己会想办法去查，另外就是做单元测试和集成测试，以及流程性的测试了。你不懂，就让他做各种测试。他也会做，大不了，也是左右互搏，换一个平台的模型，让他分析一个完整的项目代码包，找出来问题。这里还是推荐大家，用在线的平台，https://zchat.z.ai/，质谱官方的，免费，而且可以出1个完整的代码文件包，方便的很，deepseek网页端只能看1个文件，而且不能输出文件，只能输出内容，不合适一套代码分析。太费劲。 实盘阶段： 我的建议第一阶段是，前期不提供api key，直接让代码跑，这样会暴露很多基础的代码语法错误，因为ai再牛逼，也有百密一疏的情况，如果直接上直接的真实账户，就会出现各种奇葩问题，我遇到的有很多情况，比如一个币对，无限开仓、一堆仓位，平仓剩余渣渣，导致不能看新仓位，当天的日熔断触发了，但是代码有bug，还是继续开仓亏损等等。所以第一阶段，先找基础代码错误。 第二阶段，让ai把每一行代码，都写上日志，我说的比较夸张，因为前期ai排查问题，会反复的找不同的代码文件，联系上下文，分析那个地方的代码写的不对，但是有的时候，日志打印的不全，ai就会乱猜，乱分析，导致浪费时间。 第三阶段，让ai写一个模拟单模式，也就是不实际下单，但是走相关的代码逻辑，目的就是完整的走完一遍流程，避免有些奇葩代码写的有问题，你走实盘，就会触发这些隐藏的坑，模拟下单执行几天后，再走实盘。 第四阶段，真正实盘，把key提供后，真实账户，只放很少的资金，不是为了赚钱，只是为了验证实盘的钱，走完相关流程是否有问题。这个阶段，每天都要去服务器拉相关的日志文件，让ai去对日志进行分析，有哪些异常，有问题，及时处理发新代码。 第五个阶段，实盘小资金，确认，代码逻辑没啥问题了，但是盈利不稳定，继续把相关的交易行情的数据，让ai获取后，阶段性的复盘，分析，怎么改进。 第六个阶段，真正的盈利模式，从实际的小额资金，已经完全验证没有问题了，开始阶段性放入大额资金，但是需要注意，这个阶段，也是阶梯式的，比如你前期100u跑通了，再加，不要一步到位上10000u，先来300、500的，稳定一段时间后，再说。一点点加，但是需要注意的是，有的时候，你的盈利或者亏损，不一定是代码或者策略问题，有可能只是单纯的行情问题，如果你不懂这一点，就盲目的修改策略，或者放大资金，很容易，出现反向的行情，导致大额亏损。 状态问题：最后说点题外话，因为国内白天的时候，相关的行情一般波动很小，大部分出现行情的时候，都是晚上10点以后才开始，甚至是凌晨3-7点的时候，所以，搞这个很耽误睡眠。经常半夜还在想这个咋搞，所以，要有心理准备。我是折腾了半年，现在有点麻了。 最后了，相关的gitee上的代码，这套代码，我一个字没有自己写，都是ai写的代码，我看着哪里不顺眼，就让ai改的。大家随便下载，随便玩，我现在实盘跑的就是这套，但是还没有看到准确的盈利曲线，我觉得一般，但是整体代码逻辑没啥明显的bug，你可以喂给ai，让ai分析一下，有没有啥隐藏问题，再用。觉得不错，给star一下，虽然star不发钱，但是吹牛逼响亮啊。哈哈哈
七、100U 实验方案：小资金试水的设计
7.1 为什么要先用 100U 试
7.2 资金分配方案
7.3 实盘启用前的三道保险
八、代码核心思路：几个值得讲的设计
8.1 双重保险机制
def _can_place_live_order() -> Tuple[bool, str]:
"""检查是否允许真实下单（双重保险）"""
if DRY_RUN:
return False,
"DRY_RUN=true (观察模式)"
if not ENABLE_LIVE_TRADING:
return False, "ENABLE_LIVE_TRADING=false (实盘禁用)"
return True, "
（代码较长，此处仅展示核心片段）
8.2 失败回滚逻辑
def execute_arb_open(spot_symbol, fut_symbol, position_value_usdt):
1. 现货买入
spot_resp = _spot_buy_market(spot_symbol, position_value_usdt)
if not spot_resp:
return {"success": False, "error": "现货买入失败"}
2. 合约做空（用现货实际成交数量，保证 Delta 中性）
（代码较长，此处仅展示核心片段）
8.3 全局累计统计
全局累计统计（跨平仓周期不重置） _global_accumulated_funding: Dict[str, float] = {}
{symbol: 累计费率}
_global_total_pnl: float = 0.0 _global_total_trades:
int = 0 def record_global_funding(symbol, funding_rate): """每个结算周期调用一次"""
_global_accumulated_funding[symbol] += funding
（代码较长，此处仅展示核心片段）
8.4 实盘前的准备步骤
九、AI 协作写代码的反思
9.1 AI 擅长什么
9.2 AI 不擅长什么
9.3 协作的正确姿势
十、未来展望与风险提示
10.1 收益预期
10.2 主要风险
结语
我的建议
https://gitee.com/qiudoumasi/binance_arbitrage
