执行算法：VWAP/POV 跟量与 ATR 波动率定仓
策略给出“买 10 万股”只是决策，真正的成本发生在执行——一次性砸市价，冲击成本会把 alpha 吃掉一大截。
机构和散户的差距，很多时候不在选股，而在同样的信号，谁的执行更省。
结论先行：EasyQuant 把执行拆成两层——“下多少”由 ATR 波动率定仓决定，“怎么下”由执行算法（TWAP/VWAP/POV/ICEBERG/SLICED）决定，冲击成本与成交质量用 TCA 事后度量。
一、两个独立问题：下多少 vs 怎么下
- 下多少（sizing）：仓位不应是固定股数，而应按标的波动率调整——波动大就少下，波动小可多下
- 怎么下（execution）：一笔大单要切成小单，沿时间/成交量分布铺开，降低冲击
这两件事正交。EasyQuant 分别用 ATR 定仓和执行算法引擎处理，互不耦合。
二、下多少：ATR 波动率定仓
用 ATR（平均真实波幅）把“风险预算”翻译成“下单量”：目标是让每笔头寸承担相近的波动风险，而不是相近的名义金额。波动率高的标的自动缩量，波动率低的适度放量。这套定仓与海龟等趋势策略天然契合（C 端叙事见策略学院《海龟交易法则》一篇）。
三、怎么下：执行算法引擎
执行算法收敛在 execution/algo 包，由 AlgoExecutionEngine 驱动，AlgoType 定义类型：
| 算法 | 类 | 思路 |
|---|---|---|
| TWAP | TwapAlgo |
沿时间均匀切片 |
| VWAP | VwapAlgo |
按历史成交量分布铺量，贴合市场节奏 |
| POV | PovAlgo |
跟量：按实时成交量的固定占比参与，量大多下、量小少下 |
| ICEBERG | IcebergAlgo |
冰山，只露小额挂单 |
| SLICED | SlicedAlgo |
通用切片 |
母单（AlgoParentRequest）在 AlgoContext 下被切成子单（SliceDecision），OrderFlowGuard 约束下单节奏，StrategyAlgoRoutingService 决定某策略的订单走哪种算法。POV 是本轮新增的重点——它不按时间表死板铺量，而是跟着真实成交量走，在流动性好的时候多成交、清淡时收手。
四、执行质量要能被度量：TCA
切片下单省了多少，不能靠感觉：
ImpactCostEstimator：下单前按盘口深度（walk-the-book）估算冲击成本，见 30 L2 行情统一OrderTcaService/OrderTcaCalculator：事后做 TCA（交易成本分析），把成交均价与基准价对比，量化滑点
有了事前估算 + 事后 TCA，执行算法的选择就从“听起来更高级”变成“数据证明更省”。
结语
同样的信号，执行差一档，长期收益就差一截。执行算法不是锦上添花，是把 alpha 留在账户里的最后一道工序。
把“下多少”和“怎么下”拆开，用 ATR 定仓 + VWAP/POV 切片 + TCA 度量，EasyQuant 把执行从“一把梭”升级为可度量、可路由的机构级能力。