我以前对交易策略实验的理解很简单：有一个想法，写出来，回测，效果好就继续，效果差就删掉。
这套流程看起来直接，但真正做久了会遇到一个问题：你很难判断一个实验到底失败在哪里。
是想法本身不行？
是样本不对？
是回测方式有偏？
是实盘环境和本地环境不一致？
还是代码刚好写错了？
如果这些问题混在一起，一个实验失败以后，最后只会剩下一句“效果不好”。这句话没有信息量。它既不能告诉你该丢掉什么，也不能告诉你该保留什么。
最近一次策略实验让我更明确地意识到：交易策略实验不能只当成“写策略”。它更像一个工程问题。
交易里最容易产生的是想法。
看到一个形态，觉得能做。看到一个指标，觉得可以过滤。看到一次错过的行情，觉得系统应该补一个条件。尤其是盯盘久了以后，每天都能冒出很多“如果当时这样就好了”。
问题是，这类想法通常都很便宜。
便宜不是说它一定没价值，而是说它太容易产生，也太容易被样本诱导。市场刚走完一段行情，你回头看，几乎总能找到一个规则解释它。真正难的是证明这个规则不是为刚刚那段行情量身定做的。
所以策略实验的核心，不是把想法尽快写进主策略，而是尽快把想法压进一个可以被验证、可以被丢弃的结构里。
一个想法如果只能靠口头描述存在，它就会越来越像信念。
一个想法如果能被拆成输入、状态、触发条件、退出条件、风险暴露和验证窗口，它才开始变成工程对象。
信念很难删除。
工程对象可以删除。
这次实验一开始也犯了一个常见错误：把长期实验改动和稳定主线放在同一个工作区里推进。
短期看这样很方便。
主线有新改动，合一下。实验里发现问题，顺手改一下。回测工具缺一点能力，也顺手补一下。几天以后，工作区里就混在一起了：
这时候再问“这个分支还有没有用”，就很难回答。
因为里面确实有有用的东西，也确实有应该丢掉的东西。
真正的问题不是分支有没有用，而是不同性质的改动被绑在了一起。
策略假设应该是可丢弃的。
基础设施应该是可复用的。
主线同步应该是可独立验证的。
这三者如果混在一起，实验失败时会不敢删，实验成功时也不敢合。
这次最后比较有价值的部分，其实不是策略 v2。
策略 v2 修了一个局部逻辑问题，但真实回放结果并不好。按策略本身看，它没有足够理由进入主线。
但为了验证它而补出来的能力是有价值的：
这些东西和某一个具体策略无关。
也就是说，策略实验失败了，但实验过程中产生的验证设施成功了。
这是很关键的分离。
如果把“策略是否上线”和“工具是否合入”绑在一起，就会浪费掉这部分收益。最后要么因为策略表现不好，把工具也一起丢掉；要么因为工具确实有用，把策略也顺手带进去。
两种都不对。
更合理的处理方式是：基础设施单独合入，策略逻辑留在实验分支，甚至直接删掉。
这听起来像多走一步，其实是在降低后续实验成本。
下一次再有新想法，不需要重新搭回放能力。只要把新假设接进同一套验证流程里就行。
很多策略实验的问题，不是没有开始，而是没有结束。
一开始觉得先试试。试完以后结果不够好，但又看到某几个局部案例有效，于是补一个条件。补完以后收益还是一般，但回撤好像改善了一点，于是再换一个窗口。窗口换完以后又觉得样本太少，再等几天。
最后实验变成一种长期悬挂状态。
它没有上线，也没有失败。它只是占着一个分支、一段注意力和一堆上下文。
这种状态很危险。
因为交易系统最怕的不是没有想法，而是有太多半死不活的想法。每个想法都觉得自己还差一次验证，每个分支都觉得自己还有一点价值。时间久了，主线会越来越难判断，实验也越来越难复现。
所以实验应该在一开始就有退出机制。
比如：
最重要的是最后一条。
因为很多实验不会彻底失败。它们会给你一个很暧昧的结果：局部对，整体不够好。
这时候如果没有提前定规则，就很容易陷入解释。
交易策略最不缺解释。
缺的是停止解释的规则。
工具越来越强以后，写代码本身的成本确实下降了。
但这不代表策略研究变简单了。它只是把难点从“能不能实现”转移到了“该不该相信”。
以前一个想法可能因为实现成本太高而自然死亡。现在实现成本低了，很多本来不会被写出来的想法都会被写出来。
这看起来是好事，但也会制造更多噪声。
如果没有验证设施，没有实验隔离，没有退出机制，低成本实现反而会让系统更乱。因为每个想法都能很快变成代码，每段代码又都带着一点局部合理性。
人的工作不应该是和工具比赛写代码。
人的工作应该是判断边界：
这些判断不会因为工具变强而消失。
相反，工具越强，这些判断越重要。
现在我更倾向于把交易策略实验拆成三层：
第一层是策略假设。它应该便宜、快速、可删除。
第二层是验证基础设施。它应该稳定、复用、单独上线。
第三层是上线决策。它应该保守，只看真实约束下的结果。
策略实验的目标，不是让每个想法都活下来。
相反，一个好的实验系统应该让不够好的想法更快死掉，同时把验证过程中沉淀下来的工具留下来。
这才是交易系统工程化真正有价值的地方。
它不是提高每一个策略想法的成功率。
它是降低错误想法长期占用系统的成本。
本文创建日期: 2026-06-14
最后更新日期: 2026-06-14