11.8 策略热更新与版本管理
课前导读
本章目标
学完能解决什么困惑：你将理解为什么实盘策略不能盘中随意改规则，如何用版本号、灰度、回滚和变更记录，让策略迭代既有弹性又有边界。
适合谁学习：已经知道策略从研究、回测到实盘部署的大致流程，想把“改策略”变成可管理工程动作的 A 股投资新手。
难度：advanced
用时：约 40 分钟
知识正文
先做一个生活类比。
你正在开车上高速。
如果发现导航路线不太理想，你会立刻把方向盘猛打到另一条车道吗？
当然不会。
你会先看后视镜，确认车距，再打转向灯，最后平稳变道。
实盘策略热更新也是同样的道理。
策略在真实市场中运行，就像车已经上路。
规则修改不是在纸上擦掉重写。
它会影响持仓、订单、风险、复盘和投资者心态。
所以，热更新不是“想改就改”。
热更新的真正含义是：
在不让系统失控的前提下，把经过确认的新规则替换旧规则。
1. 什么是策略热更新
热更新可以理解为系统不停机或少停机地替换部分策略配置或规则。
例如调整股票池过滤条件。
例如修改单只股票最大仓位上限。
例如把某个风控阈值从较宽改为较严。
例如暂停某个子策略，只保留组合中的其他子策略。
这些都属于策略运行中的变更。
但要注意，本课程讨论的是安全管理思想。
我们不会提供真实券商接口、真实自动下单代码或可直接用于实盘的接口实现。
真正的实盘系统里，热更新必须和风控、日志、权限、复盘绑定在一起。
否则它就不是能力，而是隐患。
风险提示
盘中临时修改策略规则，最容易把“研究判断”变成“情绪交易”。没有审批、记录和回滚方案的热更新，不建议进入真实资金环境。
2. 为什么不能盘中随意改规则
A 股市场的波动很容易刺激人的情绪。
上午亏损时，你可能想把止损条件调紧。
下午反弹时，你又可能想把仓位加回来。
如果每次情绪变化都改策略，系统就失去了可解释性。
最后你无法分清亏损来自哪里。
是原策略不好？
是临时修改导致？
是市场环境突变？
还是执行环节失误？
盘中随意改规则的最大问题，是破坏了实验边界。
回测时你验证的是 A 规则。
实盘上午跑的是 A 规则。
下午你改成 B 规则。
晚上复盘时却拿 A 规则的预期去解释 B 规则的结果。
这会让投资者和开发者都陷入混乱。
3. 版本号：给每一次规则变化贴身份证
版本号就像策略的身份证。
没有版本号，你只能说“我好像改过”。
有版本号，你可以说清楚“从 11.8.1 改到 11.8.2，改了仓位上限和过滤条件”。
一个清晰的版本记录至少包含四件事。
第一，版本编号。
第二，变更内容。
第三，变更原因。
第四，生效时间和影响范围。
例如：
| 版本 | 变更内容 | 变更原因 | 生效范围 |
|---|---|---|---|
| v1.2.0 | 降低单只股票最大仓位 | 近期组合集中度偏高 | 模拟盘先验证 |
| v1.2.1 | 修正停牌过滤逻辑 | 发现停牌样本处理不一致 | 下一个交易日生效 |
版本号不只是给程序员看的。
它也是给投资者和未来复盘的自己看的。
4. 变更记录：写给未来的证据链
很多策略失败后，最难受的不是亏钱。
而是不知道为什么亏。
变更记录能保留证据链。
它回答以下问题。
当时为什么要改？
改之前看到什么证据？
改动是否经过回测或模拟验证？
谁批准了改动？
如果出问题，怎么回滚？
这些问题看似繁琐。
但它们能保护你不被盘中情绪牵着走。
一个好的变更记录，不需要华丽。
它只需要真实、完整、可追溯。
5. 灰度：不要一次把所有资金都推到新规则上
灰度发布来自工程领域。
用投资语言说，就是不要把新规则一次性应用到所有资金、所有股票、所有子策略上。
可以先在模拟盘观察。
再用小资金或小范围组合观察。
再逐步扩大影响范围。
就像试穿新鞋。
你不会第一天就穿它跑马拉松。
你会先走一段路，看看磨不磨脚。
A 股策略也一样。
新规则在回测里表现好，不代表实盘里立刻稳定。
它可能遇到滑点、停牌、涨跌停、成交不充分、申报限制等真实摩擦。
灰度的价值，是把未知风险限制在较小范围。
graph TD
A[新规则完成研究] --> B[历史回测验证]
B --> C[模拟盘观察]
C --> D[小范围灰度]
D --> E[扩大实盘范围]
E --> F[正式版本]6. 回滚：承认错误并快速回到安全状态
回滚不是失败。
回滚是成熟系统的刹车。
如果新版本出现异常，例如信号数量突然增加、订单失败率上升、组合暴露偏离预期，就需要回到上一版稳定规则。
回滚前必须知道上一版是什么。
必须知道当前持仓是否与上一版兼容。
必须知道回滚后哪些订单需要暂停。
必须知道复盘时如何标注这段异常。
这就是为什么版本管理和日志记录必须一起做。
没有版本管理，回滚会变成“凭感觉还原”。
7. A 股案例：临时放宽条件带来的偏差
假设你有一个 A 股低频选股策略。
原规则要求股票满足流动性、财务质量和波动控制三个条件。
某周市场热点很强，你发现策略没有买到几只热门股。
你在盘中临时放宽了波动控制条件。
结果策略买入了几只短期涨幅很大的股票。
第二天市场回落，组合回撤明显扩大。
晚上复盘时，你发现原策略并不会买入这些股票。
亏损不是来自原规则，而是来自盘中修改。
如果没有版本记录，你可能会误判“策略失效”。
如果有记录，你会看到真正原因是“临时放宽条件未经过灰度验证”。
这个案例说明，策略热更新最怕没有边界。
8. 哪些变更适合热更新
不是所有变更都适合热更新。
比较适合热更新的是低风险配置。
例如暂停某个明显异常的数据源。
例如把最大仓位从较高调到较低。
例如临时关闭新增买入，只保留风险降低动作。
不适合随意热更新的是核心逻辑。
例如选股因子整体替换。
例如买卖条件重写。
例如仓位模型从等权改成激进集中。
这些变化会改变策略性格。
它们应该走完整研究、回测、模拟、灰度流程。
关键心得
热更新越接近“风险降低”，越适合快速执行；越接近“收益增强”，越需要慢下来验证。
9. 发布窗口：什么时候改比改什么同样重要
A 股有明确交易时间。
盘前、盘中、盘后，每个窗口适合的动作不同。
盘前适合加载已经审批的新配置。
盘中适合处理风险降低类变更，例如暂停新增买入。
盘后适合做完整复盘、回测补充和版本发布准备。
如果把所有变更都挤到盘中，系统压力和心理压力都会上升。
更稳妥的做法是设定发布窗口。
例如核心策略规则只允许盘后准备、下一个交易日前生效。
紧急风控配置可以盘中生效，但必须记录原因。
10. 版本管理的四个角色视角
从专业老师角度看，版本管理是学习过程。
它让你知道每一次改变带来了什么后果。
从投资者角度看，版本管理是风险控制。
它避免资金暴露在未经验证的冲动规则里。
从量化开发角度看，版本管理是工程纪律。
它保证代码、配置、日志、实盘结果能够对齐。
从复盘角度看，版本管理是因果链。
它让你能把盈亏归因到具体版本，而不是模糊地怪市场。
11. 一段安全发布伪代码
下面只是流程示意，不是实盘接口实现。
如果 新版本 未完成变更记录：
禁止发布
如果 新版本 未经过模拟盘或小范围验证：
禁止扩大实盘范围
如果 发布后 告警等级达到紧急级：
暂停新增风险
回滚到上一稳定版本
记录回滚原因这段伪代码表达的是发布纪律。
它不是为了让系统变慢。
而是为了避免错误以最快速度扩散。
交互实验室
本节的交互产物是一张版本发布检查表。
请在每一次修改策略前完成，而不是亏损后补写。
| 检查项 | 问题 | 通过标准 | 我的记录 |
|---|---|---|---|
| 版本编号 | 是否给新规则设置唯一版本号 | 能明确区分旧版和新版 | |
| 变更内容 | 改了哪些规则或配置 | 能用三句话说清楚 | |
| 变更原因 | 为什么要改 | 有数据、复盘或风险证据 | |
| 验证结果 | 是否回测、模拟或小范围观察 | 结果与预期基本一致 | |
| 影响范围 | 会影响哪些股票、组合或资金 | 范围明确且可控制 | |
| 发布窗口 | 何时生效 | 避免盘中随意改核心规则 | |
| 回滚方案 | 出问题怎么办 | 能回到上一稳定版本 | |
| 复盘标记 | 如何记录结果 | 日志能追踪到版本 |
练习步骤如下。
回想你最近一次想修改策略规则的时刻。
写下当时的触发原因。
判断它是情绪驱动，还是证据驱动。
为这次变更设计一个版本号。
写出影响范围。
写出最小灰度范围。
写出失败后的回滚动作。
最后问自己：如果这次修改亏钱，我能不能说清楚原因？
示例：
| 项目 | 示例填写 |
|---|---|
| 版本号 | v1.3.0 |
| 改动 | 单只股票最大仓位从 15% 降到 10% |
| 原因 | 最近组合集中度偏高，回撤集中来自少数持仓 |
| 生效 | 下一个交易日前加载配置 |
| 回滚 | 若信号数量异常减少，恢复 v1.2.4 并复盘 |
练习提醒
真正成熟的策略，不是永远不更新，而是每一次更新都能被解释、被限制、被撤回。
核心复盘
知识清单：
- [ ] 我能解释热更新不是随意改规则，而是有边界地替换策略配置或逻辑。
- [ ] 我理解盘中随意修改核心规则会破坏复盘因果链。
- [ ] 我知道版本号、变更记录、生效时间和影响范围必须成套出现。
- [ ] 我理解灰度可以把新规则的不确定性限制在小范围。
- [ ] 我知道回滚是实盘系统的刹车，不是失败的羞耻。
- [ ] 我能为一次策略变更填写版本发布检查表。
金句总结
能热更新的系统不一定安全；能灰度、能回滚、能解释每次更新的系统，才有资格进入实盘。