评估执行问题时应检查什么
什么是“执行问题”？
执行问题是指你预期的订单处理方式与提交后实际发生情况之间的任何不匹配。从实际角度看，可能表现为成交价格与预期不符、成交延迟、部分成交，或订单被拒绝或未成交。
要客观评估执行问题，需区分三个层面：
- 你的订单意图（你提交的确切参数）。
- 执行路径（市场和订单处理流程如何将该意图转化为成交）。
- 你的结果记录（你收到的内容：成交情况、时间戳和成本）。
这种区分有助于避免将正常的市场波动误认为是服务商或基础设施的问题。
如何检查执行机制（在记录中应核实的内容）
使用一个对比预期与实际行为的检查清单：
- 订单细节和假设
- 确认订单类型（例如市价单与限价单）以及你选择的所有参数。
- 明确你在计算示例时的假设（例如，“预期价格”指你提交订单时最后显示的报价）。
- 时间戳和顺序
- 核实订单提交时间，以及你收到确认和成交信息的时间。
- 查看提交与成交事件之间是否存在异常延迟。
- 确切的成交和定价信息
- 将请求的执行条件（如有）与实际成交价格进行比较。
- 注意价格差异是否在相同事件窗口内持续出现。
- 数量匹配和部分成交
- 检查请求的全部数量是否已成交。
- 如果出现部分成交，核实它们是否以不同价格成交，以及剩余数量是否稍后成交或完全未成交。
- 成本和净影响
- 确定结果记录中包含的所有相关成本（佣金、点差/交易成本，以及其他显示的费用）。
- 评估净结果：一旦计入成本，微小的价格差异可能被放大。
- 失败和拒绝标记
- 记录任何明确的拒绝/停止/“未执行”消息。
- 判断问题是订单层面的失败（无成交）还是执行层面的不匹配（成交但不符合预期）。
证据与示例：证明发生了什么（而非猜测）
评估事件的一种有效方法是仅使用你自己日志中可验证的数据，进行“预期 vs 实际”的对比。
示例框架（假设必须明确）：
- 假设预期价格 = 提交订单时最后显示的报价。
- 计算价格差异 = 实际成交价格减去预期价格（使用正确的符号约定）。
- 如果有多个成交（部分成交），按每笔成交分别计算差异，并使用已成交数量进行加权计算。
然后对模式进行分类：
- 无延迟的价格差异通常与参考价格和成交价格之间的市场变动一致。
- 延迟后最终成交可能表明市场变动速度超过了你使用的参考价格。
- 拒绝或缺失成交指向订单处理阶段的故障模式。
这种方法侧重于基于观察和记录的比较，而非归责。
局限性、风险及需关注的主要故障模式
执行结果受不断变化的市场状况、流动性和订单处理结构的影响。因此，即使有充分记录的“问题”也可能没有单一原因。
需关注的主要故障模式包括：
- 滑点（Slippage）：成交价格与你的参考价格不同。
- 部分成交（Partial fills）：你立即收到的数量少于请求，有时分多次成交事件完成。
- 订单拒绝或未执行（Order rejection or non-execution）：订单未能按预期进入执行阶段。
- 异步事件（Asynchronous events）：确认、修改、取消或成交信息以意外顺序到达。
验证局限性：历史关系（例如“之前发生X时，价格也类似变动”）不能证明未来结果。成本和市场行为可能发生变化。
验证及后续应提出的问题
为独立验证你的结论，请确保每一项主张都与你记录中可展示的内容相关联：
- 你是否有提交的确切订单参数？
- 你是否有时间戳，以便比较提交与成交时间？
- 你是否有完整成交和成本细节，涵盖全部已执行数量？
- 如果执行失败，你是否有明确的拒绝/错误消息？
如果确实存在差异，接下来的问题通常不是“谁造成的？”，而是“哪一层与我的意图不一致？”——是你的输入、时间、成交/定价细节，还是存在明确的失败消息？