AI 自动执行 vs 人工下单：30 天对照评估方法
要比较自动执行和人工下单，先冻结同一批信号、仓位规则和费用口径，再保存两条执行链的真实订单日志。本文给出一套可直接建表的 30 天方法。
1. 冻结比较条件 #
第 1 天之前，给每个信号固定 signal_id、UTC 生成时间和策略版本。两组同时收到相同的品种、方向、订单类型、数量、目标价、止损、止盈、信号有效期与取消规则；初始权益、杠杆、保证金模式、费率档位和交易时段也必须一致。现货与合约分开统计。
| 字段组 | 需要预先写明 |
|---|---|
| 信号 | ID、UTC 时间、策略版本或文件哈希 |
| 订单 | 市场、交易对、方向、类型、数量、目标价 |
| 风险 | 止损、止盈、杠杆、过期时间、部分成交规则 |
| 失败处理 | 重试上限、拒单、断线和人工覆盖规则 |
| 成本 | 实际手续费、资金费和其他已记录成本 |
如果系统只按固定规则发送订单，应称为自动执行器，避免把信号质量与订单路由能力混在一起。
2. 必需的订单日志 #
每次尝试都保留一行，包括拒单和未成交。最低字段是：signal_id、收到/提交/交易所确认时间（UTC）、订单 ID、方向、类型、请求价格与数量、成交数量、VWAP、状态或拒单代码、重试次数、取消时间、断线区间、手续费资产与金额、资金费、人工覆盖及原因、入场和离场基准价。
信号过期却没下单记为未执行；拒单记为执行失败；部分成交只按已成交数量计算。缺订单 ID、成交价或费用时，不用 K 线收盘价补齐。该信号可不进入净收益比较，但必须保留在数据缺失率和失败率中。
3. 逐信号比较 #
| 指标 | 口径 |
|---|---|
| 覆盖率 | 符合条件、已提交、已确认和已成交的信号数 |
| 延迟 | 提交时间减收到时间；报告中位数和第 95 百分位 |
| 成交质量 | 滑点中位数、第 95 百分位、部分成交率和拒单率 |
| 成本 | 实际手续费、资金费和其他已记录成本 |
| 净结果 | 按实际成交逐笔计算；两组数据完整时才算配对差值 |
最大回撤要使用相同的估值频率和时区。不能拿一组的分钟级未实现盈亏与另一组的日终余额比较。
4. 滑点与失败单 #
先固定基准价，例如信号进入系统时记录的市场中间价。买单滑点为 (VWAP − 基准价) ÷ 基准价，卖单为 (基准价 − VWAP) ÷ 基准价；乘 10,000 得基点，正值表示成交更差。
自动化不会消除滑点。市场波动、流动性和订单大小都可能让实际成交价偏离预期价，Binance Academy 的滑点词条也按这一含义解释。断线时记录缺口起止，不假定成交；拒单保留返回码；重试上限必须事前统一。
5. 可复算示例 #
以下是构造值，不是账户记录或 Binance 固定费率：线性合约多单 0.01 BTC，入场基准价 60,000 USDT，实际入场 VWAP 60,030，离场 VWAP 60,600；入场费 0.60 USDT、离场费 0.61 USDT、资金费 0.20 USDT。
- 入场滑点：
(60,030 − 60,000) ÷ 60,000 × 10,000 = 5个基点； - 毛盈亏：
0.01 × (60,600 − 60,030) = 5.70 USDT； - 净盈亏：
5.70 − 0.60 − 0.61 − 0.20 = 4.29 USDT。
两组分别使用同一公式，再按信号 ID 配对。这个例子只说明计算口径，不能证明哪种执行更赚钱。
6. 结论边界 #
30 天后先检查日志完整度。若可比较信号太少、品种或费率不同，或某组缺失字段很多，应报告限制，不给胜负结论。即使数据完整，一个月也只描述这段时间、这套信号和这些执行规则。
自动组可能延迟更低，也可能因程序、权限或网络故障漏单；人工组可能识别异常，也可能提交更慢。只能让成对的真实记录回答哪种流程更稳定，不能预设纪律、智能或盈利优势。
— AI 交易实验室，2026-09-24 修订