量化交易必备：AutoHedge自动对冲系统设计与实现

做量化的朋友应该都有过这种体验：策略本身跑得好好的，但隔三差五就要被极端行情教训一顿——单边拉涨不敢追，瀑布式下跌舍不得割，仓位稍微重一点，晚上觉都睡不踏实。我前前后后折腾了大半年，试过手工加减仓、试过各种止损止盈的排列组合，最后发现问题的根源不在于策略胜率，而在于整个账户的风险敞口完全裸露在市场波动里。后来我干脆花了几周时间，自己动手写了这套AutoHedge自动对冲系统，思路很简单：让程序实时盯住账户的总敞口，一旦某个方向的净持仓超过阈值，就自动用反向仓位把它对冲掉，把“预测行情”和“控制风险”彻底拆开。

这套系统解决的核心问题，就是让我的主策略可以安心做方向性判断，而不用时刻提心吊胆担心黑天鹅。它适合谁用？跟我一样跑量化策略但风控模块比较薄弱的个人开发者，或者是手工交易但想给账户加一道自动保险的朋友。这篇文章我会把整套系统的设计思路、关键参数的计算方法、核心代码实现，以及我在回测和实盘中踩过的坑，全部整理出来。内容偏实战，建议收藏后对着代码一步步看。

1. 为什么需要一套自动对冲系统——从一次爆仓经历说起

1.1 手工对冲为什么总是慢半拍

先说我自己的教训。去年有一段时间我做加密合约的网格策略，网格本身收益很稳定，但账户里的净仓位是单向的——行情上涨时网格会自动累积空单，行情下跌时又会累积多单，本质上是在逆势加仓。遇到震荡行情没问题，一旦出现单边走势，账户浮亏就蹭蹭往上走。

当时我的应对方式是盯着盘面手工开对冲单，比如看到持仓多单多了，就手动开一张等量空单。但实际操作下来问题非常大：第一，人不可能24小时盯盘，凌晨三点的大行情经常就是几分钟内把账户打穿；第二，手工开单存在严重的反应延迟，等你发现风险敞口过大时，行情已经走了一大段，对冲成本高得离谱；第三，情绪会干扰判断——浮亏大的时候手会抖，本来该开100张对冲单，结果只敢开50张，反而让风险更加不可控。

手工对冲还有一个隐藏问题：它只对冲了“数量”，没有对冲“价格”。比如我持有100张多单，均价30000，行情跌到28000时我开100张空单对冲，表面上风险中性了，但这100张空单的均价是28000，如果行情反弹回29000，多单回血了一部分，空单却开始亏损，账户净值还是在波动。真正的对冲应该是动态的、连续的、同时考虑持仓均价和当前价格的，这恰恰是手工操作很难做到的。

1.2 主策略与风控分离的架构思路

吃了亏之后，我开始重新思考交易系统的架构。传统的做法是“一个策略同时负责开仓、平仓、止损、止盈”，所有逻辑耦合在一起，虽然写起来简单，但有个致命弱点：当你需要临时调整风控参数时，必须去改策略代码，改完还要重新回测验证，非常僵化。

AutoHedge 的设计哲学很明确：把交易系统拆成“主策略”和“风控层”两个独立的部分。主策略只负责产生交易信号、管理自己的仓位，它甚至不需要知道风控层的存在；风控层则独立运行，持续监控账户的总敞口、净持仓、保证金占用等指标，一旦发现风险超过阈值，就自动执行对冲操作。

这两个模块之间通过一个共享的订单状态表通信，主策略下单后把订单信息写入数据库，风控层读取数据库计算净持仓，而不是直接去交易所查询。这样做的好处有三个：一是主策略和风控层可以各自独立重启、升级，互不影响；二是所有订单都有记录，方便复盘和审计；三是就算交易所API出现瞬时故障，风控层也能基于本地数据库的订单状态做判断，不会因为查询失败而失明。

1.3 AutoHedge 到底解决了什么痛点

AutoHedge 名字里的 Auto 强调的是自动化，Hedge 强调的是对冲，合起来就是“用程序自动管理账户风险”。具体来说，它解决了三类痛点：

第一类是极端行情下的生存问题。单边暴跌时，系统不会像人一样恐慌犹豫，而是严格按照预设的阈值执行对冲，保证账户不会因为保证金不足而被强平。这相当于给账户买了一份“程序化保险”。

第二类是多策略共存时的敞口汇总问题。我自己的实盘账户里同时跑着网格策略、趋势策略和套利策略，单独看每个策略的风险都不大，但把它们加总起来，某个时刻可能会在同一个方向上累积出很大的净头寸。AutoHedge 做的事情很简单：把所有策略的持仓汇总成一个账户级风险视图，然后针对这个总视图做对冲，而不是分别处理每个策略。

第三类是资金利用率的优化问题。很多人觉得对冲是浪费资金，因为多空同时持仓会占用双倍保证金。但实际上，AutoHedge 做的是“净敞口对冲”，只在总敞口超标时才出手，大多数时候账户其实是满仓运行的，资金利用率反而更高。

2. 系统整体设计思路——模块划分与数据流

2.1 五个核心模块的职责边界

AutoHedge 的整体架构我分成五个模块，每个模块只做一件事，模块之间通过消息队列或数据库解耦。

第一个模块是行情采集模块。它的任务是从交易所拉取实时价格、深度数据，并计算各种衍生指标，比如涨跌幅、波动率、资金费率等。这个模块是系统的“眼睛”，要求延迟低、稳定性高。我使用的是 WebSocket 连接，断线自动重连，数据落盘到本地时序数据库。

第二个模块是持仓监控模块。它定期扫描账户在交易所的真实持仓，以及本地数据库中的订单记录，实时计算净持仓量、持仓均价、浮动盈亏、保证金占用等指标。这个模块解决的是“知道自己现在到底处于什么风险状态”的问题。

第三个模块是风险计算模块。这是系统的“大脑”，核心功能是把持仓监控模块算出来的原始指标，转换成风险分数和动作指令。比如当前净持仓多单10 BTC，账户总权益50万U，风险阈值设定为净持仓占总权益的20%，那么10 BTC对应50万U的20%就是10万U，当前风险已经接近甚至超过阈值，系统就会生成对冲信号。

第四个模块是订单执行模块。它负责把风险计算模块生成的信号落地成真实订单。这里有一个很重要的细节：执行模块必须支持“部分成交”和“超时重试”的逻辑，因为大额对冲单在极端行情下很容易只成交一部分，如果程序不处理这种情况，就会出现“以为对冲了其实没对冲完”的危险状态。

第五个模块是日志与告警模块。所有关键操作都会记录日志并推送通知到手机。我个人用的是 Telegram Bot 推送，你也可以用钉钉、企业微信或者邮件。告警的粒度要分层：普通日志、风险提示、严重告警，每层对应不同的处理响应。

2.2 数据流：从行情到对冲单的完整链路

用一个实际场景来串一下数据流。假设当前 BTC 价格 65000，账户持仓情况是：策略A持有2 BTC多单，策略B持有1.5 BTC空单，策略C持有0.8 BTC多单。

行情采集模块持续接收 tick 数据，每秒钟更新一次价格快照。持仓监控模块每5秒执行一次账户同步，从交易所拉取真实持仓，同时读取本地订单表，合并计算出当前净持仓为：2 - 1.5 + 0.8 = 1.3 BTC 多单。

风险计算模块拿到这个净持仓后，开始计算风险指标。假设账户总权益为 10 BTC，那么净持仓占比 13%，如果风险阈值设置为 10%，此时系统判定为“风险超标”。紧接着，模块计算出需要的对冲数量：目标净持仓应该为0，所以需要开 1.3 BTC 的空单。但考虑到价格滑点和成交延迟，系统不会一次性开满，而是采用“分批对冲”策略，先开 60%（约0.78 BTC），成交后再评估一次，如果净持仓仍然超标，继续开剩余部分，以此反复，直到净持仓回落到阈值以内。

订单执行模块收到开空 0.78 BTC 的指令后，拆分为几个小单发到交易所，用限价单 or post-only 模式控制成本。下单成功后，订单状态回写到数据库。持仓监控模块在下一轮扫描中感知到持仓变化，更新净持仓数据，整个闭环就完成了。

2.3 为什么选择“净敞口对冲”而不是“完全对冲”

设计之初我考虑过两种对冲模式：完全对冲和净敞口对冲。完全对冲的逻辑是“不管主策略仓位多少，我都开一个等量反向仓位，让账户 Delta 恒等于0”。这样做的好处是风险绝对可控，坏处是资金效率极低，而且每个策略的信号独立存在，主策略做多、对冲做空，两边手续费和资金费都在烧钱，长期下来成本非常可观。

净敞口对冲的逻辑则是“只在总敞口超标时才出手”。比如账户总权益 50万U，多单净敞口 8万U，风险阈值20%，此时未超标，系统不做任何操作；但如果行情上涨导致多单浮盈变成12万U，超过阈值，系统才开空对冲，把净敞口压回10万U以内。

这种模式相当于给账户设置了一个“风险缓冲区”，在缓冲区以内完全放任自由，触发阈值才干预。好处是大多数时候系统处于静默状态，交易成本极低；坏处是需要精细调节阈值和恢复区间，否则系统会在阈值附近反复触发，产生不必要的磨损。我最终选的是净敞口模式，并且在代码里加了一个“死区”（dead zone）机制——当净敞口超过阈值后，系统会一直对冲到净敞口低于阈值减死区才停止，避免频繁触发。

3. 核心模块实操——关键参数与实现细节

3.1 风险阈值的量化逻辑：净敞口占比怎么算

AutoHedge 最核心的参数就是风险阈值，它直接决定了系统什么时候出手。我用的计算公式是：

net_exposure = abs(sum(position * direction * price)) exposure_ratio = net_exposure / total_equity

其中 direction 做多取 +1，做空取 -1，price 是当前标记价格。total_equity 是账户总权益，包括可用余额和所有持仓的未实现盈亏。

阈值设置我的经验是分三层：预警线 10%，对冲触发线 20%，强平保护线 50%。预警线只发通知不动作，让你知道风险在累积；对冲触发线是系统实际执行对冲的起点；强平保护线一旦触碰，系统不再考虑成本，直接市价单打到净敞口为0，优先保命。

为什么是20%而不是30%或者10%？这里面有个历史回测数据支撑。我回测了 BTC 和 ETH 一年多的15分钟K线数据，统计了单日最大波动幅度。结果显示，BTC 单日波动超过20%的情况一年大概出现2-3次，ETH 会更多一些。如果把对冲触发线设置在20%，那么大部分常规行情系统都不会干预，只在真正的极端行情中出手，既控制了成本，又保住了账户。

具体的回测方法后面会详细讲。这里先给一个结论：阈值设置需要结合品种的波动特性、账户的杠杆率、以及你对回撤的最大容忍度来综合确定。杠杆越高、品种波动越大，阈值就应该设得越低。

3.2 对冲数量的拆分与执行策略

确定了要对冲的方向和总数量之后，还有个关键问题：怎么把这笔单子发出去。我强烈不建议一次性市价单打满，原因有两个：第一，大额市价单在深度薄的市场里会造成巨大滑点，成本可能占到名义本金的千分之几甚至更多；第二，如果交易所接口出现部分成交的情况，程序很难判断接下来怎么处理——是按剩余量继续发，还是取消重来？

我的做法是把对冲单拆成若干个小单，每个小单的名义金额不超过账户权益的3%。比如需要开 1.3 BTC 空单，账户权益10 BTC，那么每单最大0.3 BTC，总共拆成4-5个单子依次发出。每笔订单使用限价单，挂在对冲方向的最优买一/卖一价附近，设置30秒超时，超时未成交就撤单，然后用新价格重新挂单。

这里还有一个“等待确认”的逻辑：每发一个子单后，程序会暂停几秒钟，等待交易所回报成交信息，同时重新计算一次剩余净敞口。如果行情剧烈波动导致已经成交的子单滑点很大，系统会动态调整后续子单的价格和数量，而不是机械地按原计划执行。整个过程相当于一个简化的 TWAP（时间加权平均价格）策略，专门用在风控场景里。

3.3 持仓均价如何参与对冲决策

很多人在对冲时只看“持仓数量”，忽略“持仓均价”，这是个很容易吃亏的细节。假设你手里有一笔多单，开仓均价30000，数量1 BTC，当前价格28000，浮亏2000 U。这时候系统计算净敞口，如果用当前价格28000计算，净敞口是28000 U；但如果你用开仓均价30000计算，净敞口是30000 U。两个数字差异不大，但在极端行情下会被急剧放大。

AutoHedge 在计算净敞口时，统一使用当前标记价格，而不是持仓均价。原因很简单：风险管理的本质是应对“现在”的风险，而当前价格是唯一真实的退出价格。持仓均价只用于计算浮盈浮亏，不参与敞口计算。这样做还有一个好处——不同时间、不同价格开的仓位可以无障碍地汇总计算，不需要考虑它们各自的成本。

但持仓均价也不是完全没用。在决定对冲单的“目标仓位”时，我会参考一个指标：如果当前价格与持仓均价偏离超过一定百分比（比如3%），系统会认为这是极端行情，开启“激进对冲模式”，一次性把敞口打到接近0；如果偏离不大，则走常规的渐进式对冲。这个逻辑本质上是一种“基于压力程度自适应调节”的风险响应策略。

3.4 回测框架怎么搭：以历史数据模拟极端行情

AutoHedge 上线之前，我搭了一个简单的回测框架来验证参数，重点是模拟极端行情下的表现。回测框架的输入是历史K线数据（包含开盘、最高、最低、收盘、成交量），输出是账户权益曲线、最大回撤、对冲触发次数、对冲成本等指标。

框架的核心是一个事件循环：遍历每一根K线，先计算主策略的持仓变化（这里我用的是一个预设的仓位序列，相当于假设主策略已经在回测前跑好了），再让风控层检查净敞口是否超标，超标则执行模拟对冲。模拟对冲时，我假设对冲单能在K线收盘价成交，滑点设置为0.05%，手续费设置为0.04%，资金费按8小时一次扣除。

回测结果给我提供了几个重要参考。第一，20%的阈值在BTC一年数据里触发次数大约7次，每次成本平均在0.2%左右，全年对冲总成本约1.4%，换来的是最大回撤从45%降到12%，这个性价比非常划算。第二，死区参数设置在阈值的30%到50%之间效果最好。举例来说，阈值20%、死区5%，意味着系统会把净敞口压到15%以内才停止对冲，避免在19%到21%之间反复触发。第三，激进对冲模式在极端行情下效果显著，单次触发能够减少约70%的最大回撤深度，但会带来更高的滑点成本，所以只在价格偏离持仓均价超过3%时启用。

3.5 核心代码：风险计算与对冲指令生成

下面贴一段 AutoHedge 的核心代码，功能是风险计算与对冲指令生成。这是整个系统最核心的部分，我尽量把注释写详细。

import time from dataclasses import dataclass @dataclass class Position: symbol: str side: str # "long" or "short" size: float # 持仓数量（张或币） entry_price: float mark_price: float @dataclass class RiskConfig: warn_ratio: float = 0.10 # 预警阈值 10% hedge_ratio: float = 0.20 # 对冲触发阈值 20% protect_ratio: float = 0.50 # 强平保护阈值 50% dead_zone: float = 0.05 # 死区 5% max_single_order: float = 0.3 # 单笔最大下单数量 partial_pct: float = 0.6 # 首次对冲比例 class RiskEngine: def __init__(self, config: RiskConfig): self.config = config self.positions = [] self.equity = 0.0 def update_positions(self, positions): """更新持仓列表和账户权益""" self.positions = positions # 这里应该调用交易所API获取账户权益，示例简化处理 self.equity = self._fetch_equity() def _fetch_equity(self): # 实际项目中从交易所或者本地数据库获取总权益 return 10.0 # 占位示例，单位BTC def calc_net_exposure(self): """ 计算净敞口。返回符号表示方向： 正数=净多，负数=净空。 """ net = 0.0 for pos in self.positions: direction = 1.0 if pos.side == "long" else -1.0 net += direction * pos.size * pos.mark_price return net def calc_exposure_ratio(self): net_exp = self.calc_net_exposure() if self.equity == 0: return 0.0 return abs(net_exp) / self.equity def generate_hedge_signal(self): """ 根据当前净敞口和阈值，生成对冲指令。 返回值：None 表示无操作；dict 表示对冲指令 """ net_exp = self.calc_net_exposure() ratio = self.calc_exposure_ratio() side = "short" if net_exp > 0 else "long" target = 0.0 # 判断达到哪个风险等级 if ratio >= self.config.protect_ratio: # 强平保护模式：一次性打到净敞口为0 target = abs(net_exp) mode = "protect" elif ratio >= self.config.hedge_ratio: # 常规对冲模式：压到阈值减去死区 target = ratio - (self.config.hedge_ratio - self.config.dead_zone) target = target * self.equity mode = "normal" elif ratio >= self.config.warn_ratio: # 预警模式：只发通知，不执行 return {"mode": "warn", "net_exposure": net_exp, "ratio": ratio} else: return None # 分批处理：首次只发 partial_pct 比例 amount = target * self.config.partial_pct amount = min(amount, self.config.max_single_order) if amount <= 0: return None return { "mode": mode, "side": side, "amount": amount, "remaining": target - amount, "net_exposure": net_exp, "ratio": ratio, }

这段代码的逻辑很直白：先算出净敞口和敞口占比，然后分三个风险等级处理。值得注意的一点是，target的计算方式取决于当前风险等级。强平保护模式直接取全部净敞口作为目标对冲量；常规模式则只对冲超出阈值减死区的部分——比如阈值20%、死区5%，当前敞口占比25%，那么目标就是把敞口从25%压到15%，也就是对冲10%的权益。

首次对冲只执行目标量的60%，每单上限0.3 BTC，这是为了控制单笔冲击成本和部分成交风险。剩余的40%留到下一轮扫描中继续处理，形成渐进式收敛。

3.6 订单执行模块的容错设计

订单执行模块是系统最容易出 bug 的地方，我从实盘中总结了几条必须处理的边界情况。

第一，部分成交。发出的限价单可能只成交一半就碰到了行情反转，剩余部分一直挂着。如果不处理，程序会以为对冲指令已经完成，但实际敞口还是超标的。我的处理方式是：每笔订单挂单后启动一个30秒定时器，超时后无论成交多少都撤掉剩余量，并重新计算剩余敞口。如果剩余量仍然超过阈值，就生成新订单继续对冲。

第二，重复下单。由于持仓监控是周期性扫描的，如果上一次的对冲单还没有完全成交，下一轮扫描又开始了，程序可能重复生成对冲指令。为避免这种情况，我引入了订单状态管理：所有活跃订单都记录在本地数据库里，状态包括 PENDING、PARTIAL_FILLED、FILLED、CANCELED。风控引擎在生成新指令前，必须检查是否存在 PENDING 或 PARTIAL_FILLED 状态的同方向订单，如果有，就在下一轮再评估，而不是直接开新单。

第三，交易所API限流。实盘中经常遇到 API 调用频率超限的报错，特别是在行情剧烈波动的时候。我的处理方式是做一个简单的请求队列，所有交易所 API 请求都排队执行，每秒最多发出5个请求；同时设置失败重试机制，单个请求最多重试3次，每次间隔递增。

4. 常见问题与排查技巧实录

4.1 阈值设得太小导致频繁对冲、手续费侵蚀利润

这是最常遇到的问题，也是我一开始犯的错误。最初我把对冲触发线设置在10%，结果系统在震荡行情里几乎每隔几个小时就触发一次对冲，手续费和滑点成本算下来，居然把主策略的大部分利润都吃掉了。

排查的方法很简单，看回测报告里的“对冲触发次数”和“对冲总成本”两个指标。如果触发次数过多且成本占比超过总收益的20%，说明阈值设置太敏感，需要调大。我用的是“单次对冲成本 × 年度触发次数”来推算年度成本，把这个数字控制在年化收益的10%以内才合理。后来我把阈值从10%调到20%，触发频率肉眼可见地下降了，年度对冲成本从4.6%降到了1.4%左右。

4.2 死区参数不合理导致对冲指令反复横跳

死区（dead zone）是防止系统在对冲线附近反复触发的重要机制。但死区设得太大会导致一个问题：系统明明已经把风险控制住了，却还要继续对冲一大笔，白白增加成本和方向风险。

比如阈值20%、死区10%，意味着系统要等到敞口占比降到10%以下才停止对冲。如果账户权益10 BTC，当前净多3 BTC，风险占比30%，系统会一直开空单，直到净持仓降到1 BTC才收手。如果行情恰好反弹，这1 BTC的空单反而成了新的风险源。

我实测下来的经验是：死区设置为阈值的30%到50%之间比较平衡。阈值20%，死区5%-7%比较合适；阈值15%，死区4%-5%。这样既能避免反复触发，又不会过度对冲。

4.3 极端行情下 API 超时导致“裸奔”

这是最危险的一种情况。上次 BTC 在几分钟内暴跌8%的时候，我的对冲系统连续触发了3次超时重试，但交易所 API 一直报错，等恢复时价格已经跌了一千多美金，对冲单的成交价比预期差了很多。

之后我加了两个保险。第一，所有核心 API 请求都设了独立的超时时间，不跟随全局配置，一般取3-5秒；第二，增加了一个“紧急市价单”通道——当风险占比超过50%时，系统不走限价单的逻辑，直接发市价单，哪怕滑点大也要确保成交。这套双通道设计后来救了我一次，在另一次暴跌中虽然对冲成本高了0.8%，但账户避免了被强平的风险。

4.4 不同交易对的汇率换算导致敞口计算错误

如果你同时交易 BTC、ETH 和 SOL，计算净敞口时会遇到一个问题：它们的价格单位不一样，不能直接相加。BTC 的价格是65000，ETH 的价格是3200，如果直接把持仓数量乘以各自价格再相加，得到的敞口数字是以 USDT 计价的，没问题。但如果某个交易对是用 BTC 计价（比如 ETH/BTC），那计算出来的敞口单位就是 BTC，不能直接和 USDT 计价的敞口混在一起算。

AutoHedge 的统一处理方式是：把所有敞口都换算成计价币种（通常是 USDT 或 USD），在数据层做一次汇率转换。具体做法是给每个交易对维护一个“换算汇率”，从交易所的行情接口实时获取。这一步很容易被忽略，但一旦忽略，多币种账户的风险计算就完全失真了。

4.5 常见问题速查表

4.6 上线前的模拟盘验证方案

正式实盘之前，我强烈建议至少跑两周的模拟盘。模拟盘的目的是验证三个东西：一是程序的稳定性，二是参数设置的合理性，三是异常场景下的容错能力。

具体做法是：把交易所 API 切换到模拟交易环境，注入历史K线数据做“伪实时”回放。系统会按照真实的时间节奏逐根K线推进，主策略信号和风控信号都实时处理和记录。第一天先观察日志有没有异常，第二天开始故意制造一些故障——比如手动断掉交易所 API 连接、模拟部分成交、修改数据库里的持仓数据，看看风控层能不能正确应对。这些小测试能提前暴露很多隐蔽 bug，远比直接上实盘再踩坑要划算。

5. 进阶：AutoHedge 的后续扩展方向

实盘稳定运行两个月以后，我开始琢磨怎么让这套系统更聪明。目前版本本质上是一个规则驱动的风险控制系统，所有阈值都是静态预设的。下一步我计划加入一些自适应逻辑，让它能根据市场环境动态调整参数。

比如，不同波动率环境下，“危险”的定义是完全不同的。在横盘震荡期，净敞口占比20%可能很安全；但在波动率飙升的行情里，同样20%的敞口可能几天内就导致爆仓。所以我准备引入一个基于历史波动率的“动态阈值”机制——当短期波动率高于长期波动率1.5倍时，自动把对冲触发线从20%下调到12%左右；波动率回归正常后再逐步恢复。这样可以做到风控的“逆周期调节”，比固定阈值更贴近实战需求。

另一个方向是跨交易所对冲套利与风控的结合。我目前运行的主策略主要在 A 交易所，但同一时间 B 交易所的合约价格可能存在价差。如果 AutoHedge 判断需要开空对冲，完全可以选择在价格更高的 B 交易所执行，除了实现风险对冲之外还能赚到一部分价差收益，让对冲从“纯成本”变成“低风险套利”。这个改进需要重构订单执行模块，加入交易所路由逻辑，我打算在下个版本中尝试。

最后再说几句实操体会

AutoHedge 这套系统从写第一行代码到实盘稳定运行，前前后后大概用了三周时间。最大的体会是：做量化交易，策略研究固然重要，但风险管理才是账户能活得久的根本保障。我见过太多人花大量精力调参追求更高的收益率，却忽略了账户在极端行情下的生存能力。

如果你是第一次尝试写自动对冲系统，我的建议很简单：先用模拟盘跑通流程，把订单管理、部分成交、API 超时这些边界情况处理干净，再考虑优化参数和成本。不要一上来就追求“完美风控”，先做到“在最坏的情况下不会死”，就已经比大多数手工交易者强了。希望这篇分享能让你少走一些我走过的弯路。