Order、Execution 与 Decision¶
这三个标签不是三种不同的搜索方式，而是同一张订单的三层证据。新人必须学会用 Ticket 把它们串起来，而不是只截取一个价格字段回答客户。
三个标签分别回答什么¶
| 标签 | 核心问题 | 常用 ID | 最适合调查 |
|---|---|---|---|
| Order | 平台最终记录了什么订单结果？ | Ticket、Position ID | 是否存在、订单类型、数量、剩余量、价格、状态 |
| Decision | 系统为何采用这个规则、路径和客户价格？ | Dec ID、Ticket、Order ID、Position ID | 成交价投诉、路由判断、客户定价、规则命中、决策耗时 |
| Execution | 外部执行或对手方实际发生了什么？ | Exec ID、Ticket | 对手方、流动性池、拆单、滑点、延迟、失败原因 |
新人第一阶段：先看 13 个字段¶
不要一开始阅读全部 42 个字段。基础调查只按四步：
| 步骤 | 字段 | 要回答的问题 |
|---|---|---|
| 1 | Time、Ticket、Account、Symbol | 是不是正确客户、账户和订单？ |
| 2 | Side、Action、Type、Requested Vol、Filled Vol | 客户做了什么，数量是否成交？ |
| 3 | Request price、Filled price、Client fill price | 三个价格分别记录了什么？ |
| 4 | Final、Cost、Status | 最终显示多少、处理多久、结果是什么？ |
遇到市场价争议再查 Ticks；遇到 LP、拆单、timeout 再查 Execution。看不懂 Rule、Route、Mode 或 M/C/B 时，原样记录并交给 Senior，不需要新人自行解释。
第二阶段参考：完整字段分组¶
Decision 当前提供 42 个可选字段，默认显示其中 35 个。以下内容用于完成基础训练以后，在 Senior 指导下理解完整记录。
| 阅读顺序 | 信息组 | 主要字段 | 需要回答的问题 |
|---|---|---|---|
| 1 | 订单身份 | Time、Dec ID、Ticket、Order ID、Position ID | 找到的是不是客户投诉的那一张订单？ |
| 2 | 客户与交易环境 | Broker、Taker、Client、Account、Group、Sym、Taker sym | 订单属于谁、来自哪里、客户与上游品种如何映射？ |
| 3 | 订单内容 | Side、Action、Type、Requested Vol、Filled Vol | 买卖方向、开平仓、订单类型和数量是否与投诉一致？ |
| 4 | 价格链 | Request price、Filled price、Client fill price | 客户请求价、系统成交价、客户最终得到的价格分别是多少？ |
| 5 | 决策依据 | Tier、Tags、Buckets、Readings at hit、Rule | 当时的客户分层、标签、检测结果和命中规则是什么？ |
| 6 | 执行方式 | Route、Mode | 系统选择了什么路由和定价模式？ |
| 7 | 价格与时间组成 | Base VMD、M、C、B、Spread coef、Spread、Slippage、Delay | 哪些组成项参与了这次结果？不能把其中单项直接当作最终结果。 |
| 8 | 最终结果 | Final、Cost、Status | 最终差值、决策耗时和处理状态是什么？ |
进阶阅读顺序¶
每次都按下面的顺序，避免看到某个显眼数字就提前下结论：
Final、Cost、Status 必须一起读：Final 是该决策记录呈现的最终点数结果，Cost 是系统完成该决策所记录的耗时，Status 表示处理结果。它们回答不同问题，不能用 Cost 解释价格，也不能仅凭 FILLED 判断价格是否合理。
完整示例：Ticket 47892013¶
客户 CLT-18421 / Chen Jie 投诉 XAUUSD 买单成交价异常。进入 Orders → Decision，以 Ticket 搜索，并完整记录：
| 证据组 | 页面记录 |
|---|---|
| 身份 | DEC-89234、Ticket 47892013、Order ID ORD-12389、Position ID P-88412013 |
| 环境 | Apex Markets、Apex Live、账户 9022001、组 std-gold、XAUUSD → GOLD.v |
| 订单 | BUY、Open、Open Market、Requested/Filled 均为 1.00 |
| 价格链 | Request 2341.50 → Filled 2341.55 → Client fill 2341.80 (+25) |
| 决策依据 | Tier T5；Tags LOCKCHURN B4、PSEUDOSCALP B4；Buckets 与 Readings 均为 No hit；Rule Force STP — T5 |
| 执行方式 | Route STP；Mode 为 — |
| 组成项 | M +2.33、C +1.0、B +3.0；其余未记录为 — |
| 最终结果 | Final +5 pts；Cost 3ms；Status FILLED |
从这一行可以确认“系统记录了什么”，但不能只凭这一行断言报价市场是否正确。若投诉重点是“当时市场报价不可能是这个价”，下一步以同一品种和精确时间进入 Ticks；若重点是“LP 实际怎样成交”，进入 Execution；若怀疑同一时段存在系统性异常，再查 Alarm log / System summary。
调查结论写法¶
不要只写“成交价正常”或“系统显示 FILLED”。最低合格记录应包含：
已在 Orders → Decision 核对 Ticket 47892013。订单为 XAUUSD BUY 1.00，Request price 2341.50，Filled price 2341.55，Client fill price 2341.80 (+25)。决策命中 Force STP — T5，Route 为 STP；Final +5 pts，Cost 3ms，Status FILLED。若需判断当时市场报价是否支持该价格，将继续核对对应时点 Ticks；若需确认外部成交，将以相同 Ticket 核对 Execution。
Order：确认平台最终记录¶
Order 用于核对订单是否存在、方向与类型、请求和成交数量、剩余量、价格及最终状态。它适合回答“有没有这张订单”“是否部分成交”“最终状态是什么”，但不完整解释系统为什么采用某条规则。
Execution：确认外部执行过程¶
Execution 用于核对 Counterparty、Pool、Fill price、Filled、Slip、Latency、Status 和 Reason。同一 Ticket 可以有多条 Execution，因此必须搜索并读取所有结果；只引用其中一行可能漏掉拆分成交、failover 或超时。
用 Ticket 串联完整证据链¶
以 Ticket 为共同键，同时核对时间、数量和状态。不要把 Execution 的 Slip、Decision 的 Final、三段价格之间的差异混成同一个概念；页面没有给出的因果关系，也不要自行推断。
进阶自测¶
完成基础训练后，在 Senior 指导下找到 DEC-89240，再练习读取完整字段。此题不属于第一阶段考核。