开发系统的时候，我们很容易用“新增了多少能力”衡量一次更新。
但是，如果一个自动化决策系统经过多次迭代，每个新发现都追加一层处理、每一层又有自己的约束，那么另一个问题迟早会出现：我们还能清楚地解释最终结果是如何产生的吗？
这次 BTC 5 分钟研究系统的 v2.4 升级，让我重新思考了“做减法”的价值。
规则增多，并不等于决策链必须一直变长
研究新市场结构时，不同阶段发现的问题通常不同。为避免大改原有系统，最初以附加判断逐步迭代，是一种容易实施、也容易回退的工程选择。
但时间一长，代价就会显现：
- 同一项输出可能被多个阶段依次处理；
- 复盘时需要追踪它经历过哪些层；
- 数据依赖与异常处理散布在不同位置；
- 新旧能力共存，却缺少统一的解释入口；
- 新代码是否改变既有行为，越来越难验证。
真正麻烦的，不一定是规则数量，而是规则之间的关系逐渐变得隐含。
这次做减法，减的是什么？
不是删除经过研究验证的能力，也不是为了追求简洁而放弃已有研究结果。
在不改变现有基础决策和交易执行链路的前提下，这次升级将分阶段积累的决策扩展整合成一个统一的决策层，让每次输入都按照同一套工程约束形成可追踪的最终结果。
对外公开的重点不在于具体规则、内部条件或处理顺序，而在三个工程目标：
- 责任清晰。 每种补充判断只对自己的适用范围负责。
- 依赖局部化。 一项判断的附加信息不完整，不应无理由地否定其他可独立执行的判断。
- 结果可审计。 可以追溯最终决定的类别及其所依据的记录，而不必猜测某个中间层是否悄悄改动结果。
把这些关系变成明确的工程接口，比继续叠加额外调用层更容易长期维护。
“更清晰”必须通过行为保持来验证
架构整理最容易踩的坑是：代码看起来变整洁了，但原来的行为发生了不应该发生的变化。
因此，不能只看升级后的总分是否更高，而应该把不允许变化的部分单独列出，逐个核对：基础策略输出是否保持一致，既有数据输入与状态推进是否仍遵守原约定，最终执行结果是否能复现研究版本。
此次 v2.4 代码侧完整回放覆盖了 18,920 个有效上下文，并在设定的一致性检查中未报告差异。这说明在被验证的历史条件下，结构整理没有产生检查项所覆盖的意外漂移。
它仍然不意味着所有未来环境都已经验证过。
为什么审计轨迹比“最后做了什么”更重要？
如果一个程序只记录“本次未执行”，研究者就很难判断是没有合适机会、数据条件不充分，还是某一环节出现了异常。
一个可维护的系统，应该至少能够区分正常的决策结果与无法完成判断的运行问题。这不仅关系到回放对账，也关系到用户排障和版本回退。
复杂系统的可信度，并不来自它总是做出动作，而是来自它的动作和不动作都能被认真核实。
做减法之后，是否就更稳定了？
架构整合的直接收益是降低认知负担、减少隐式相互作用、改进测试与维护边界。历史回放也显示 v2.4 在多个统一计分指标上得到改善。
但不能简单把历史得分提高全部归因于“代码层数减少”。此次版本同时包含研究决策的演进，架构整理与策略行为改善是两个相关、但需要分别验证的命题。
我更愿意这样总结这次工作：不是把系统做得更简单，而是把复杂性放回有边界、能检查的位置。
本文仅讨论公开的系统工程原则，不公开任何专有策略的内部判断规则、参数或执行优先级。历史代码一致性也不是实盘盈利保证。
延伸阅读：从信号到自动执行 · 为什么生产代码必须逐笔复现 · 从机器人到可维护系统