为什么RPS参数越优化，实盘越执行不了？

Hello，

我是葱头，

一个写了26年代码的程序员。

现在在用缠论和RPS做主观交易。

今天我们来聊聊RPS参数过度优化像极了我当年写的通用框架

那是2013年，我还在做电信计费系统的中间件。领导拍板要搞个"通用配置框架"，支持所有运营商的计费规则——移动、联通、电信，甚至还要预留给未来可能接入的广电、虚拟运营商。我在白板上画了三天架构图，定了二十七个配置参数，八个策略接口，三层抽象工厂。代码写得漂亮，单测覆盖率92%，文档齐全，连架构评审组都鼓掌通过了。

上线第一周，移动广东分公司的一个冷门业务跪了。原因是他们的计费规则里有个"以元为单位向上取整"的奇葩逻辑，而我的框架只支持"以分为单位四舍五入"。为了兼容这1%的边缘案例，我加了第28个参数。第二周，联通的某省分公司要按"日租套餐+流量池共享"计费，框架里没有"共享池"概念，我又加了第九个策略接口。半年后，框架膨胀到六十多个参数，十五个接口，启动时间从200毫秒涨到3秒，新人不敢动，老人不想动，任何微小改动都要全量回归测试。

最后那个框架怎么死的？不是被重构替代的，是被业务方绕开了——他们直接在应用层硬编码计费逻辑，宁可维护五十套烂代码，也不愿再碰那个"通用框架"一行代码。我离职前最后一件事，是把那套引以为傲的架构文档扔进了回收站。

---

讲真，这事儿跟RPS参数优化有什么关系？

我看过太多交易者（包括当年的我）把RPS当成那个"通用框架"。周期选多少？5日、10日、20日、60日、120日、250日全挂上。阈值设多少？RPS>80、>85、>90、>95逐个回测。再加个成交量过滤、换手率过滤、换手率变化率过滤、市值分层、行业中性化、甚至还要接入北向资金流向、融资余额增量、期权隐含波动率……参数表一拉，密密麻麻三十多行，回测报告漂亮得像那份架构评审PPT，夏普比率2.5，最大回撤8%，年化收益45%。

实盘跑三个月，账户曲线比回测还难看。

---

为什么？因为市场不是单元测试，也不是回测引擎里的历史数据切片。

回测里，每个参数组合都是独立的、静态的、互不干扰的。实盘里，参数之间会耦合产生化学反应：你把RPS周期从20日改成10日，原本能过滤掉的震荡股突然全进池子了；你把阈值从85调到90，原本能捕捉的启动期龙头全漏掉了；你加了个"换手率>10%"过滤，结果把真正的主升浪低换手龙头误杀了。每加一个参数，不是在"精准筛选"，而是在把系统的自由度硬生生锁死——就像当年的通用框架，每加一个配置项，就少一分应对未知变化的弹性。

更要命的是过拟合的隐形成本。回测里你选出的"最优参数组合"，本质上是对历史噪声的拟合。市场结构一旦发生微小迁移——比如注册制全面推行后新股破发常态化、比如北向资金占比从5%涨到15%、比如量化做市商从提供流动性变成收割流动性——那些在历史上表现完美的参数组合，会在实盘里集体失效。这就像当年的计费框架，完美适配了2013年的三大运营商规则，却完全没预留应对"广电入网"、"虚拟运营商批发模式"、"5G融合计费"这些结构性变化的接口。

---

我2019年刚转行做交易那会儿，也是个参数党。

手里攒了三年的Tick数据，跑了两个月回测，把RPS从单周期优化到多周期共振，从固定阈值优化到自适应阈值，从简单排序优化到加权评分模型。最疯狂那会儿，Python脚本跑了一周，生成了四百多组参数组合的回测报告，每组配一张权益曲线图、一份风控指标表。我看着那些夏普比率3.0以上的组合，觉得自己捡到了圣杯——直到实盘第一个月，账户回撤18%，那些"完美参数"在真实滑点、真实流动性、真实情绪面前，全变成了笑话。

那个月我失眠了两周。盘中盯着分时图发抖，盘后对着回测报告发呆，明明参数优化得那么漂亮，为什么实盘就是跑不出来？后来复盘才明白：回测里没有"当下确定性"这回事。回测是上帝视角，已知未来走势，参数自然能拟合得完美；实盘是蚂蚁视角，只见当下一根K线未完待续，参数再多也弥补不了"不知道下一秒会发生什么"的本质焦虑。

---

那是不是RPS没用了？不是。

RPS的核心价值一直是相对强弱的快速排序，帮你从五千只票里把关注名单压缩到五十只以内。它是漏斗入口，不是决策出口。问题出在把"排序工具"硬用成"信号发生器"，把"相对强弱"硬解释成"绝对买点"。

我现在的做法：RPS只跑两个周期——20日和60日。阈值固定RPS>80，不调了。成交量只看一条：今日成交额>5日均量的1.5倍。不加换手率、不加市值分层、不加行业中性化、不加北向资金、不加融资余额。筛出来的名单，扔给缠论结构去验证——有没有日线级别中枢震荡足够久？有没有周线级别一买/二买结构？有没有笔/线段级别的背驰确认？缠论说不行，哪怕RPS排第一也不动手。

参数少了，反而执行顺了。不用天天盯着回测报告纠结"要不要把阈值从82改到83"，不用周末跑几百组参数组合找"最优解"。省下来的精力，全花在盘中观察缠论结构的演变、复盘买卖点执行的得失、调整仓位管理的分层逻辑上了。

---

这让我想起代码里的一个原则：配置项越少，系统越鲁棒。

好的框架不是把所有可能性都配置化，而是把"不变的核心逻辑"固化下来，把"变化的业务细节"通过极简的扩展点暴露出去。Linux内核几千万行代码，核心调度逻辑二十年没大变；Windows注册表几十万个键值，改一个蓝屏一次。交易系统同理：RPS排序是不变的核心逻辑（相对强弱不变），缠论结构验证是极简扩展点（结构确认/否定），参数优化是那个会让系统崩溃的注册表。

哎，讲到这儿，突然想起个细节。前两周周末复盘，翻到2021年那本手写交易日志，翻到一页写着："RPS周期10/20/60/120，阈值85/90/95，回测年化38%，实盘亏12%"。旁边用红笔歪歪扭扭画了个大叉，后面跟着一行字："参数多不等于鲁棒，就像配置文件长不等于框架好"。那会儿刚从程序员转行做交易，程序员的职业病犯了——觉得参数越多、配置越灵活、回测越漂亮，系统就越牛。花了三年实盘教训，才把那堆参数砍成现在的样子。

---

有个隐喻可能不完全准：代码里的过度配置，损失是维护成本和上线风险；交易里的过度优化，损失是真金白银的本金。但本质上，都是把本该留给"当下判断"的自由度，提前锁死在"历史经验"里。代码里靠重构还债，交易里靠止损还债——区别是，代码重构最多加班熬夜，交易止损爆仓就是真归零了。

所以现在看到群里讨论"RPS周期选20还是30""阈值85好还是88好""要不要加个换手率过滤"，我一般不插话。不是不想帮忙，是这问题本身就带着"通用框架"的思维惯性——试图用参数穷尽不确定性。真正的不确定性，不在参数里，在盘面当下的缠论结构里，在你面对结构确认时敢不敢下单的执行力里，在连续十次止损后还能不能按规则打第十一单的肌肉记忆里。

---

再多说一句：参数优化还有一个隐性副作用，很少有人提。

当你把精力全花在调参数上时，你实际上是在逃避执行层面的痛苦。调参数很舒服，坐在空调房里跑脚本、看报告、挑最优，大脑分泌多巴胺，有一种"我在掌控一切"的虚幻掌控感。但盘中面对缠论二买确认时手抖不敢下单、面对止损位被触发时找借口不卖、面对加仓信号时贪多不敢加——这些才是决定账户生死的硬仗。参数调得再漂亮，不敢执行、执行变形，等于零。

就像当年的通用框架，文档写得再漂亮、架构评审通过得再响亮，业务方一句"这框架不好用，我自己写"，一切归零。交易更残酷：市场不会给你第二次机会重写"框架"，爆仓就是彻底出局。

---

RPS参数优化到底是不是伪命题？评论区见。

声明：本文不构成任何投资建议。市场有风险，交易需谨慎。

感谢你读到最后，记得帮我点个"赞"+"推荐"，并"分享"给更多人吧！

因调研工具暂时不可用，基于真实经验撰写