策略版本与激活：草稿、发布与「为什么改了不生效」
量化团队里最高频的误解之一，是把编辑草稿等同于已经影响实盘/仿真。
在交付型系统里，必须区分三层东西：策略实例（活配置）、草稿（编辑区）、已发布版本（不可变快照） 以及 当前激活版本（执行与回测的真正口径）。
结论先行：EasyQuant 的执行与组合回测以 激活版本 上的 dslJson / paramsJson / riskProfileJson 为准；只改草稿或只保存未发布，都不会改变线上口径。
把这条规则产品化，才能消灭「我明明改了规则为什么没信号」的团队摩擦。
一、四个概念：一张表分清
| 概念 | 是什么 | 常见误区 |
|---|---|---|
| 策略实例 | 可启停的一条策略配置（周期、市场、绑定等） | 以为改名字/绑定就算「策略变了」 |
| 草稿 | 未发布的规则与参数编辑区 | 在草稿里改了很久，但从未 publish |
| 版本 | 发布后生成的不可变快照 | 版本很多，但不知道哪条是「激活」 |
| 激活版本 | 当前用于调度/信号/风控策略解析的版本 | 回测选了别的版本或用缓存的本地 JSON |
产品心智：草稿是「工作台」，版本是「发行物」，激活版本是「系统唯一承认的生产口径」。
二、为什么必须用「不可变版本」？
没有版本边界时，会发生：
- 复盘时无法证明「当时跑的是哪套参数」
- 回测与仿真对不上，却无法对齐输入
- 多人协作时互相覆盖，责任不清
因此发布动作的本质是：打快照。快照一旦生成，便于审计、对比与 provenance 引用（与 04：Provenance 一脉相承）。
产品与控制台：典型流程
- 在 策略中心 打开实例，编辑规则（草稿区）。
- 发布 生成新版本（版本号递增或按产品规则展示）。
- 将其中一个版本设为 激活版本（部分环境在发布时自动激活，以实际 UI 为准）。
- 在 运行监控 / 诊断 中核对：当前激活版本 ID 是否与预期一致。
若「改了不生效」，按顺序自查：
- 是否已 发布？
- 发布的是否被设为 激活？
- 回测页是否指定了 历史某次 provenance，而非「当前激活」？
- 是否在看 另一个租户 / 另一个实例？
技术落点（便于工程师对齐代码）
- 域模型与 API 围绕
strategy_instance与strategy_version分层；激活关系在实例上指向当前版本。 - 信号引擎（如
StrategySignalEngine）从激活版本读取 DSL 与参数，而不是直接读草稿表。 - 回测运行应写入 provenance（输入区间、成本模型、版本 ID 等），便于与仿真侧对照。
更完整的模块划分见 docs/ARCHITECTURE.md；用户操作路径见 docs/USER_GUIDE.md 策略相关章节。
结语
策略版本不是官僚流程，而是团队对齐「生产口径」的唯一办法。
下一篇若你只关心「多账号、多团队怎么共用一套平台」，请读：多租户与 RBAC。
延伸阅读