前言
策略在 K 线收盘价上算出买入信号，实盘用天勤TargetPosTask(..., price="ACTIVE")对价下单，实际成交价往往是当时的卖一价，和信号价会有几跳甚至更多差距，这就是滑点。回测若假设「信号价瞬间全部成交」，净值曲线会偏乐观；团队若没有统一记账，就无法判断是策略逻辑失效，还是执行成本吃掉了 edge。
天勤量化里，成交信息在api.get_trade()返回的字典里，每笔成交有价格、手数、时间等字段（以objs.py为准）；委托对象上还有trade_records。下面说明滑点相对谁算、怎么记日志、怎么反哺回测手续费假设。先要分清：信号价、发单价、成交价是三个不同概念。
一、名词对照
| 名称 | 含义 |
|---|---|
iloc[-2] | K 线表倒数第二行，常用作已收盘 bar 算信号 |
close | 该 bar 收盘价，常作信号参考价 |
ACTIVE | 对价模式，买用卖一、卖用买一 |
PASSIVE | 排队模式，成交路径不同，滑点分布不同 |
get_trade() | 成交记录字典，key 为成交号 |
trade.price | 实际成交价 |
signal_price | 团队定义的基准价，用于算滑点 |
TqBacktest | 天勤历史回测环境 |
TqKq | 快期模拟，用于统计实盘级滑点 |
二、滑点相对谁算
团队应固定一种「信号价」定义，全策略统一：
| 基准 | 适用 |
|---|---|
信号 bar 的close | K 线策略，与iloc[-2]一致 |
发单时刻last_price | tick 或 bar 边界触发 |
| 理论 ACTIVE 价 ask1/bid1 | 分析是否多吃了盘口 |
signal_price=kl.close.iloc[-2]api.wait_update()fortid,trinapi.get_trade().items():iftr.symbol==symbolandapi.is_changing(tr):slip_ticks=(tr.price-signal_price)/quote.price_tick log_slip(tr.datetime,signal_price,tr.price,slip_ticks)买方向滑点正负号约定要写进文档，避免复盘时符号反了。
三、为何回测要对齐
TqBacktest可设手续费，但成交模型未必等于 ACTIVE 吃盘。建议：
- 用
TqKq跑一段，统计信号价与成交价差的分布（几 tick、几元）。 - 回测在手续费外增加固定 tick 惩罚，或更保守的成交假设（团队自定，天勤不会自动替你加滑点）。
- 回测、模拟、实盘三环境
price="ACTIVE"或PASSIVE选择一致。
四、日终汇总与异常
按品种记：平均滑点、最大滑点、滑点占毛利比例。突增时查盘口是否变薄、是否涨跌停、是否大单未拆。部分成交时每笔trade都要记，不能只用最终持仓反推均价。
总结
对价下单的滑点是信号价与真实成交价之间的系统性偏差，不是多加一行手续费就能糊弄过去的。天勤在get_trade里给出成交价，你只要在成交发生时把同一笔信号用的bar_datetime和signal_price写入日志，就能在实盘建立滑点 baseline，再用来校准TqBacktest的成本假设。记账对齐后不难理解：回测好看往往因为成交太理想，记账对齐后，比较模拟与实盘才有意义。
FAQ
1）PASSIVE 滑点怎么记？
同样记信号价与成交价，可能为负滑点（更优价），分开统计。
2）一笔信号多笔成交？
用 signal_id 关联，按成交量加权算滑点。
3）开平都记吗？
建议都记；平今成本另在手续费账单体现。
4）没有成交怎么记？
记 signal 事件即可，成交字段为空，便于算成交率。
风险提示
以上内容用于执行成本记账参考，不构成投资建议。
