很多策略升级报告会从一个问题开始：新版本的历史收益有没有提高？
而真正准备让一个系统长期运行时，我会先问另一个问题：这次升级有没有意外改变本来不应该变化的东西？
这个问题很少出现在营销材料里，但它决定了研究结果能不能被可信地交付为软件。
结果更好，不代表实现就正确
假设研究版本的最终总分是 +1000，生产代码跑出来也是 +1000。
这仍然不足以证明两者一致。完全可能有一部分窗口被错误改成盈利，另一部分被错误改成亏损，最终总分刚好抵消。
因此，总分相等不是逐笔一致；逐笔一致也不是实盘成交成功。验证层级必须分开。
升级前，先列出“不变项”
在自动化交易系统里，不变项是指那些即使模块内部重新组织，也不应该无意改变的行为约束。
公开层面可以讨论几类通用检查：
| 检查层级 | 核心问题 |
|---|---|
| 数据与时间 | 同一目标窗口是否使用相同定义和结算标签？ |
| 基础决策 | 未被本次升级授权改变的基础输出是否保持一致？ |
| 状态更新 | 历史状态推进是否仍遵守原有时间顺序？ |
| 最终动作 | 相同上下文是否生成预期的一致结果？ |
| 独立计分 | 是否可以不依赖原决策模块重新核算结果？ |
| 运行边界 | 原有下单、安全保护和配置链路是否保持原约定？ |
这些问题针对的是系统正确性，不涉及公布内部策略配方。
为什么必须保留逐个目标窗口的证据？
v2.4 的代码侧完整回放包含 18,920 条有效策略上下文：目标窗口没有重复，信号窗口与目标窗口的时间关系经过检查，结算标签完整，回放错误为零。
更重要的是，报告分别核对了基础决策、最终动作和独立 PnL 计分的一致性，并记录了相应检查项零差异。
这种证据的价值在于：如果未来发现某个窗口的行为不符合预期，我们有机会回到具体样本、输入和审计记录去定位原因，而不是只能比较两个总分。
一致性检查需要区分“允许改变”和“意外改变”
升级策略自然希望某些历史决策发生变化。否则，就谈不上升级行为本身。
验证的重点，不是要求新版和旧版每一笔都相同，而是明确：哪些差异属于研究批准的变化，哪些边界必须继续相同。
只有在这个前提下，才有意义讨论新版本相对旧版本的结果差异。
类似地，软件架构整理也应单独证明自己没有让数据获取、账户状态、风险保护或订单执行路径发生未经授权的改变。
代码侧完整回放能证明什么、不能证明什么？
它能够对已记录的历史数据和测试条件给出强有力的实现核查：结果是否可复现、是否有遗漏或重复上下文、计分是否独立一致。
但它无法独自证明：
- 未来不会出现新型网络或数据异常；
- 真实订单能够按照历史假设价格成交；
- 费用、滑点、市场冲击和动态仓位后的真实权益路径同样改善；
- 长期反复研究后的选择偏差已经消失。
所以，代码完整回放是生产研究一致性的必要环节，但不是完整的实盘经济验证。
升级后的实际工作并没有结束
完成回放后，还应当持续检查版本差异、运行日志、数据新鲜度和真实订单状态。如果出现新的异常，应当根据可追踪的记录定位问题，而不是仅凭最近的亏损就立即修改所有参数。
对一个长期迭代的系统来说，可靠升级意味着两件事：该变化的地方有证据地变化，不该变化的地方有证据地保持不变。
本文讲述公开的软件验证方法，不涉及内部策略参数或决策细节。回放一致性不等于实盘盈利保证。
延伸阅读：回测结果对了还不够 · 没有偷看未来，回测就可靠吗？ · 从信号到自动执行