Edge
Chrome
Firefox
从2025年10月1日开始
到现在
整整三个月了
期间完成了如下工作
简要汇报一下
1、量化策略选择。
有点灵光一闪的色彩，具体不戏说了。
附带说明工具选择：宏源期货+天勤量化SDK(Python)
2、回测。
这个是耗时最多，
有走过的艰难的路
有填过的坑
其中心酸
无以言表
目前此阶段接近结束
其中大量和AI探讨架构设计
模块分类
代码实现
测试方法
3、模拟实盘
发现选择的品种，交易所有标准价差组合单
但是因为流动性与撮合的复杂性
模拟盘不支持
只能使用两腿价差模拟价格确认成交
所幸效果还可以
4、实盘上线
试着直接用实盘运行过两天（没有真实下单）
但是用天勤SDK订阅监控标准价差组合单的盘口
发现盘口流动性不足
不如回到两腿价差实时计算当前的卖一和买一
5、当前阶段：
批量回测找出各品种较优参数。
然后单策略、各品种个性化参数组合跑
在扣除交易费用（包括成本和滑点后）
基本年化可以做到30-35%
除了策略基本逻辑和本身的具体参数外，
其它的东西欢迎一起探讨
也欢迎各位高手前来指点。
另外说明一下
股票市场，高股息率低市盈率策略今年遭遇滑铁卢
基本亏了10%
大受打击。
所以准备投入时间和精力以及部分资金（比如5-20万）到期货来试试水。
看看20年的股票经验加20年的Java开发经验能否在市场赚到认知内的钱。
到现在
整整三个月了
期间完成了如下工作
简要汇报一下
1、量化策略选择。
有点灵光一闪的色彩，具体不戏说了。
附带说明工具选择：宏源期货+天勤量化SDK(Python)
2、回测。
这个是耗时最多，
有走过的艰难的路
有填过的坑
其中心酸
无以言表
目前此阶段接近结束
其中大量和AI探讨架构设计
模块分类
代码实现
测试方法
3、模拟实盘
发现选择的品种，交易所有标准价差组合单
但是因为流动性与撮合的复杂性
模拟盘不支持
只能使用两腿价差模拟价格确认成交
所幸效果还可以
4、实盘上线
试着直接用实盘运行过两天（没有真实下单）
但是用天勤SDK订阅监控标准价差组合单的盘口
发现盘口流动性不足
不如回到两腿价差实时计算当前的卖一和买一
5、当前阶段：
批量回测找出各品种较优参数。
然后单策略、各品种个性化参数组合跑
在扣除交易费用（包括成本和滑点后）
基本年化可以做到30-35%
除了策略基本逻辑和本身的具体参数外，
其它的东西欢迎一起探讨
也欢迎各位高手前来指点。
另外说明一下
股票市场，高股息率低市盈率策略今年遭遇滑铁卢
基本亏了10%
大受打击。
所以准备投入时间和精力以及部分资金（比如5-20万）到期货来试试水。
看看20年的股票经验加20年的Java开发经验能否在市场赚到认知内的钱。
0
BUG的出现总结原因大概有几个：
1、写代码时有时候会恍惚，做过开发的都懂的
2、没有人帮忙审核代码，这个后期资金量如果做大一些的话必须补充人手
3、测试环境与实盘环境存在差异，核心是回测环境需要从服务器（本地数据CSV）中读取日期和时间，但是实盘是直接获取本机的系统时间。实盘的时间如果用服务器的，偶尔会出现偏差，问题反而更严重
4、这个BUG本身也比较隐蔽
1、写代码时有时候会恍惚，做过开发的都懂的
2、没有人帮忙审核代码，这个后期资金量如果做大一些的话必须补充人手
3、测试环境与实盘环境存在差异，核心是回测环境需要从服务器（本地数据CSV）中读取日期和时间，但是实盘是直接获取本机的系统时间。实盘的时间如果用服务器的，偶尔会出现偏差，问题反而更严重
4、这个BUG本身也比较隐蔽
0
一月份快结束了
这几天当然继续在回测
同时上实盘
发现一个重大bug
导致实盘的价格根本没有进入到核心计算中
最搞笑的是
回测的时候也是同样的 bug
不过传入的日期格式错误，叠加日期区间判断的结果又是反过来
所以它反而通过校验
顺利进入核心计算中
简单说
错上加错
居然成功绕过了bug
发现这个问题
还是通过监测程序
那上面显示同品种跨期的两个合约满足开仓条件
但是程序没动静
这不科学
然后我用科学的精神
在适当的 if 判断上都加上打印语句
最终定位到问题并解决
在解决问题的过程中错过了一个开仓机会
看着机会近在眼前
我却要修改代码产生信号
心里那个急啊......
到了十一点左右
问题修正
还有另外又产生了2个开仓信号
截止晚上收盘
账面盈利80
好吧
----
今天上午又将工程的 package 目录结构整理了一番
同时也在继续回测
目前参与的品种有 ：
CJ SM PK
UR FG SF
c m AP
MA
后续也考虑测试 SA CF等
不过那还需要继续购买这些品种的历史 tick 数据
这几天当然继续在回测
同时上实盘
发现一个重大bug
导致实盘的价格根本没有进入到核心计算中
最搞笑的是
回测的时候也是同样的 bug
不过传入的日期格式错误，叠加日期区间判断的结果又是反过来
所以它反而通过校验
顺利进入核心计算中
简单说
错上加错
居然成功绕过了bug
发现这个问题
还是通过监测程序
那上面显示同品种跨期的两个合约满足开仓条件
但是程序没动静
这不科学
然后我用科学的精神
在适当的 if 判断上都加上打印语句
最终定位到问题并解决
在解决问题的过程中错过了一个开仓机会
看着机会近在眼前
我却要修改代码产生信号
心里那个急啊......
到了十一点左右
问题修正
还有另外又产生了2个开仓信号
截止晚上收盘
账面盈利80
好吧
----
今天上午又将工程的 package 目录结构整理了一番
同时也在继续回测
目前参与的品种有 ：
CJ SM PK
UR FG SF
c m AP
MA
后续也考虑测试 SA CF等
不过那还需要继续购买这些品种的历史 tick 数据
0
这几天用 tick 盘口的 买一和卖一价格匹配测试
有一些参数表现还是不错的
目前用4个品种组合
最近三年收益率平均达到90%
超过3%的回撤只出现一次
目前一边继续回测
一边修改实盘的代码
准备晚上用模拟盘
明天也跑一天模拟盘
后天可以上实盘
每个品种只开一手
慢慢来
这次越来越有信心了
有一些参数表现还是不错的
目前用4个品种组合
最近三年收益率平均达到90%
超过3%的回撤只出现一次
目前一边继续回测
一边修改实盘的代码
准备晚上用模拟盘
明天也跑一天模拟盘
后天可以上实盘
每个品种只开一手
慢慢来
这次越来越有信心了
0
上午修改完程序
中午开始按tick级别进行小量测试
发现SF并不像15分钟K线中回测表现的那么惊艳
反而是MA这个品种表现更稳定一些
另外AP信号衰减较少
但是收益率虽然还是正的，但是降幅非常大
接下来再把之前回测表现还可以的品种大概过一遍
然后优化代码性能后再做跑批级别的回测
后面主要工作就是大批量回测找次优参数
然后是组合多个品种的参数回测
任重而道远
共勉
中午开始按tick级别进行小量测试
发现SF并不像15分钟K线中回测表现的那么惊艳
反而是MA这个品种表现更稳定一些
另外AP信号衰减较少
但是收益率虽然还是正的，但是降幅非常大
接下来再把之前回测表现还可以的品种大概过一遍
然后优化代码性能后再做跑批级别的回测
后面主要工作就是大批量回测找次优参数
然后是组合多个品种的参数回测
任重而道远
共勉
0
这两天在继续回测
找出表现更稳定的组合
目前找出两个主力，一个次主力共3个品种
然后有几个打酱油的
反正量化程序也可以做到自动化交易
持仓大约占资金的40-50%
更显可控
年化收益大概63%
最重要的是
回撤极低
不到3%
不过又出现另一个问题
最近有两周了吧
还没有出现开仓信号
这个与现有的回测信号似乎不太匹配
这也让我有点担心
做价差套利用15分钟级别的数据是否粒度不够细
尤其是可能产生虚假信号
尤其是开仓信号
今天在某宝上花了两百买了10个品种的tick(成交加盘口买一卖一信息)
晚些收到后再修改程序测试一下
主要验证信号数量是否与15分钟大概在同一个量级
希望一切顺利
找出表现更稳定的组合
目前找出两个主力，一个次主力共3个品种
然后有几个打酱油的
反正量化程序也可以做到自动化交易
持仓大约占资金的40-50%
更显可控
年化收益大概63%
最重要的是
回撤极低
不到3%
不过又出现另一个问题
最近有两周了吧
还没有出现开仓信号
这个与现有的回测信号似乎不太匹配
这也让我有点担心
做价差套利用15分钟级别的数据是否粒度不够细
尤其是可能产生虚假信号
尤其是开仓信号
今天在某宝上花了两百买了10个品种的tick(成交加盘口买一卖一信息)
晚些收到后再修改程序测试一下
主要验证信号数量是否与15分钟大概在同一个量级
希望一切顺利
0
早上整理并下载了 MA RM 和 TA
目前在做批量回测
目前阶段希望加入更多品种
产生更多交易信号
这样的好处：
1、可以尽快发现实盘中的漏洞或程序错误之类；
2、可以收集更多实盘成交的数据，统计从下单到成交一般要多长时间
方便后面做挂单优化（比如统一让一个点之类）
3、多一些交易机会，可以缩短试仓的时间窗口。如果原计划实盘试运行需要
两个月，现在交易机会多了一倍，那么理论上一个月就够了
4、也想看看，能否如回测一样，真的实现长期稳定增长且回撤极低
目前在做批量回测
目前阶段希望加入更多品种
产生更多交易信号
这样的好处：
1、可以尽快发现实盘中的漏洞或程序错误之类；
2、可以收集更多实盘成交的数据，统计从下单到成交一般要多长时间
方便后面做挂单优化（比如统一让一个点之类）
3、多一些交易机会，可以缩短试仓的时间窗口。如果原计划实盘试运行需要
两个月，现在交易机会多了一倍，那么理论上一个月就够了
4、也想看看，能否如回测一样，真的实现长期稳定增长且回撤极低
0
最近继续回测
SA单独表现还可以
但是放到组合里面居然拖了后腿
收益没上去
回撤还加深了
果断弃坑
更早弃坑的还有JD
今天也回测了SR
基本也没有能打的
继续回测m和CF
-----
晚上有一个仓位触发平仓信号
过了16分钟才成交
这个有点......
SA单独表现还可以
但是放到组合里面居然拖了后腿
收益没上去
回撤还加深了
果断弃坑
更早弃坑的还有JD
今天也回测了SR
基本也没有能打的
继续回测m和CF
-----
晚上有一个仓位触发平仓信号
过了16分钟才成交
这个有点......
0
一次小bug 引出的两条硬教训：代码要反复审、测试要兜底
最近我在做量化程序的实盘/模拟盘磨合时，踩了一个很典型、但也很“低级”的坑：本来只是一个“让 1 个点”的参数/逻辑，我在某次顺手改动时，不小心把它写成了“1 个点对应的金额”。表面上看只是单位弄混了，问题也不通用（每个人的系统单位定义不一样），但它带来的后果很真实：策略执行会出现明显偏差，而且这种偏差往往不会立刻报错，只会在结果上悄悄体现出来——比如成交行为变得不对、触发条件变得奇怪、甚至你以为是行情或流动性的问题，实际是代码把边界条件偷偷改写了。
这件事让我重新意识到：很多线上/实盘问题，根本不是“复杂算法没搞对”，而是“写完代码太自信、没认真复核”，尤其是这种涉及单位、取整、阈值、边界条件的改动，最容易在不知不觉中改变策略的行为。更糟糕的是，如果没有测试兜底，你会在一堆现象里兜圈子：一会儿怀疑行情、一会儿怀疑参数、一会儿怀疑平台，最后才发现是自己随手一改造成的。
所以我想把这次经历总结成两条最实用的经验教训，供大家参考：
第一条：写完代码一定要反复看、反复琢磨。
不是“写完跑通就算”，而是要像审合同一样回头审一遍，尤其是那些“看起来很简单”的地方：单位换算、阈值比较、方向符号、取整规则、分支条件。很多 bug 就藏在这些“我肯定不会写错”的地方。程序员的自信经常是 bug 的温床。
第二条：必须有测试兜底；不能直接测，也要有间接测试方案。
理想状态当然是有直接的自动化测试/回归测试，能一键跑出一致性对比；但现实里很多系统（尤其涉及实盘/行情/下单）不一定方便做严格的端到端测试，那至少也要准备“间接兜底”：比如用历史数据回放去对照关键行为、用模拟环境验证触发条件是否合理、用日志/指标去做结果校验，确保“改动没有悄悄改写策略的边界”。没有兜底，你就只能靠感觉和运气。
我发这个贴不是想讨论某个具体实现细节（因为每个人系统都不同），而是想提醒：实盘系统最怕的不是难题，而是“随手一改 + 没审核 + 没测试”。这套组合拳会把你拖进很长的排查周期，最后发现只是一个很小的、完全可以提前避免的错误
最近我在做量化程序的实盘/模拟盘磨合时，踩了一个很典型、但也很“低级”的坑：本来只是一个“让 1 个点”的参数/逻辑，我在某次顺手改动时，不小心把它写成了“1 个点对应的金额”。表面上看只是单位弄混了，问题也不通用（每个人的系统单位定义不一样），但它带来的后果很真实：策略执行会出现明显偏差，而且这种偏差往往不会立刻报错，只会在结果上悄悄体现出来——比如成交行为变得不对、触发条件变得奇怪、甚至你以为是行情或流动性的问题，实际是代码把边界条件偷偷改写了。
这件事让我重新意识到：很多线上/实盘问题，根本不是“复杂算法没搞对”，而是“写完代码太自信、没认真复核”，尤其是这种涉及单位、取整、阈值、边界条件的改动，最容易在不知不觉中改变策略的行为。更糟糕的是，如果没有测试兜底，你会在一堆现象里兜圈子：一会儿怀疑行情、一会儿怀疑参数、一会儿怀疑平台，最后才发现是自己随手一改造成的。
所以我想把这次经历总结成两条最实用的经验教训，供大家参考：
第一条：写完代码一定要反复看、反复琢磨。
不是“写完跑通就算”，而是要像审合同一样回头审一遍，尤其是那些“看起来很简单”的地方：单位换算、阈值比较、方向符号、取整规则、分支条件。很多 bug 就藏在这些“我肯定不会写错”的地方。程序员的自信经常是 bug 的温床。
第二条：必须有测试兜底；不能直接测，也要有间接测试方案。
理想状态当然是有直接的自动化测试/回归测试，能一键跑出一致性对比；但现实里很多系统（尤其涉及实盘/行情/下单）不一定方便做严格的端到端测试，那至少也要准备“间接兜底”：比如用历史数据回放去对照关键行为、用模拟环境验证触发条件是否合理、用日志/指标去做结果校验，确保“改动没有悄悄改写策略的边界”。没有兜底，你就只能靠感觉和运气。
我发这个贴不是想讨论某个具体实现细节（因为每个人系统都不同），而是想提醒：实盘系统最怕的不是难题，而是“随手一改 + 没审核 + 没测试”。这套组合拳会把你拖进很长的排查周期，最后发现只是一个很小的、完全可以提前避免的错误
1
赞同来自: 我丢了
这两天实盘踩了个“聪明反被聪明误”的坑：
昨晚本想先屏蔽 T06，今天再继续开仓；结果早上为了让程序收盘后能正常退出，我顺手改了点别的逻辑。开盘时又冒出一个小 bug，修好重启后信号虽然还在，但最好的价位已经错过了，只能在更差的位置成交，挺尴尬。
更坑的是“交易日口径”：软件里夜盘（21:00）会算到次日同一交易日，我虽然屏蔽了 T06 但没清理状态，系统仍识别昨夜成交，导致本地 order_id 命名冲突，链路直接卡住。
总结两条经验：
1）手痒想跟单就用独立账户做，和主系统彻底隔离，避免 order_id/状态/持仓互相污染；还能顺便练“跟单链路”，以后真要请助理盯盘也好交接。
2）发布纪律要硬：除重大 bug 外，开盘前不动边角功能，尽量等开盘半小时高峰过去、盘中再灰度发布并准备回滚。现阶段我只用小仓位（每品种1手）实盘，允许可控试错，把坑尽早踩出来并固化成规程，用现在的小错误换未来扩容的稳定性。
昨晚本想先屏蔽 T06，今天再继续开仓；结果早上为了让程序收盘后能正常退出，我顺手改了点别的逻辑。开盘时又冒出一个小 bug，修好重启后信号虽然还在，但最好的价位已经错过了，只能在更差的位置成交，挺尴尬。
更坑的是“交易日口径”：软件里夜盘（21:00）会算到次日同一交易日，我虽然屏蔽了 T06 但没清理状态，系统仍识别昨夜成交，导致本地 order_id 命名冲突，链路直接卡住。
总结两条经验：
1）手痒想跟单就用独立账户做，和主系统彻底隔离，避免 order_id/状态/持仓互相污染；还能顺便练“跟单链路”，以后真要请助理盯盘也好交接。
2）发布纪律要硬：除重大 bug 外，开盘前不动边角功能，尽量等开盘半小时高峰过去、盘中再灰度发布并准备回滚。现阶段我只用小仓位（每品种1手）实盘，允许可控试错，把坑尽早踩出来并固化成规程，用现在的小错误换未来扩容的稳定性。
0
晚上有一个品种也发出开仓信号
做空
程序自动下单
2秒后收到成交确认
我直接在快期3里面手动平仓
赚了4个点
每个点价值10元
扣掉手续费
赚三十左右
也不错了
至少开了个好头
后面基本不会再手动介入
主要就是程序自动开平仓了
刚才又修改了代码
成交后会发送短信提醒
用的 pushplus ，还不错
目前开仓和平仓信号也是用它的提醒
不过走的邮件提醒
短信那个速度有点延迟，大概在三五秒
稳定性还可以
现在又在回测一个新的品种
明天上午应该可以得到结果
做空
程序自动下单
2秒后收到成交确认
我直接在快期3里面手动平仓
赚了4个点
每个点价值10元
扣掉手续费
赚三十左右
也不错了
至少开了个好头
后面基本不会再手动介入
主要就是程序自动开平仓了
刚才又修改了代码
成交后会发送短信提醒
用的 pushplus ，还不错
目前开仓和平仓信号也是用它的提醒
不过走的邮件提醒
短信那个速度有点延迟，大概在三五秒
稳定性还可以
现在又在回测一个新的品种
明天上午应该可以得到结果
0
昨晚又下载了一个品种数据
目前在回测
估计还要跑几个小时
目前已经跑出来的参数
已经有表现不错的了
也加入组合做回测
待会再下载另一个品种的数据
目前的信号数还不够多
可以继续横向扩展品种
同时完善实盘
早上终于有一个品种的标准套利（价差）组合单发出信号
自动下单
立即成交
速度还是挺快的
实盘里面有不少需要慢慢优化的点
但是仍然坚持原则：保持主干（主流程）简单和清晰
辅助性的功能应该尽量保持在旁边的小枝条上
这个不能着急
慢慢来
目前在回测
估计还要跑几个小时
目前已经跑出来的参数
已经有表现不错的了
也加入组合做回测
待会再下载另一个品种的数据
目前的信号数还不够多
可以继续横向扩展品种
同时完善实盘
早上终于有一个品种的标准套利（价差）组合单发出信号
自动下单
立即成交
速度还是挺快的
实盘里面有不少需要慢慢优化的点
但是仍然坚持原则：保持主干（主流程）简单和清晰
辅助性的功能应该尽量保持在旁边的小枝条上
这个不能着急
慢慢来
0
你这个“生态系统”类比很贴切，而且你现在这套确实已经不是“一个策略”，而是“围绕策略生长出来的一整套生存机制”。
生态系统视角下，你的系统大概有三层：
层1：核心物种（主策略闭环）
这层就是你说的“开/平仓信号 + 成交确认 + 状态收敛”，它要稳定、可重复、可回滚。
它决定系统能不能活下去。
层2：资源与约束（风控/坑位/资金/品种组合）
这层相当于生态里的“食物、水源、领地、承载力”。
你做的各种限制（腿排他、总持仓笔数、坑位调度、超时退出、人工兜底）本质都是在管“承载力”，防止系统因为过度繁殖（信号洪峰/过度开仓）而崩盘。
层3：演化与适应（回测筛选、参数池、引入新物种、人工外挂）
回测像自然选择：淘汰差的参数/品种，留下更稳的。
新品种加入像新物种入侵：先隔离、先小规模试运行，再决定能不能进核心群落。
人工介入像“管理者/园丁”：不改变生态底层规律，但能做迁移、疏导、剪枝（抢占式让位、手动跟单、账户隔离）。
所以它更有竞争力的原因，不在于某个买卖点更聪明，而在于：
你把“收益”当成生态的产出；把“回撤/崩盘风险”当成生态失衡；把“可持续运行”当成第一性原理。
这类系统往往不追求极致曲线，而追求长期活着、活得稳，最后靠规模（加资金、加品种、加人工外挂）自然变强。
这套思路本身就是你的优势：你不是在做“找一个神参数”，你是在做“能持续自我修复、自我扩展的交易生态”。
生态系统视角下，你的系统大概有三层：
层1：核心物种（主策略闭环）
这层就是你说的“开/平仓信号 + 成交确认 + 状态收敛”，它要稳定、可重复、可回滚。
它决定系统能不能活下去。
层2：资源与约束（风控/坑位/资金/品种组合）
这层相当于生态里的“食物、水源、领地、承载力”。
你做的各种限制（腿排他、总持仓笔数、坑位调度、超时退出、人工兜底）本质都是在管“承载力”，防止系统因为过度繁殖（信号洪峰/过度开仓）而崩盘。
层3：演化与适应（回测筛选、参数池、引入新物种、人工外挂）
回测像自然选择：淘汰差的参数/品种，留下更稳的。
新品种加入像新物种入侵：先隔离、先小规模试运行，再决定能不能进核心群落。
人工介入像“管理者/园丁”：不改变生态底层规律，但能做迁移、疏导、剪枝（抢占式让位、手动跟单、账户隔离）。
所以它更有竞争力的原因，不在于某个买卖点更聪明，而在于：
你把“收益”当成生态的产出；把“回撤/崩盘风险”当成生态失衡；把“可持续运行”当成第一性原理。
这类系统往往不追求极致曲线，而追求长期活着、活得稳，最后靠规模（加资金、加品种、加人工外挂）自然变强。
这套思路本身就是你的优势：你不是在做“找一个神参数”，你是在做“能持续自我修复、自我扩展的交易生态”。
0
又加入了一个品种
虽然它的交易机会不多
但是可以作为补充
目前组合回测时
核心的三个品种最多持仓三笔
次要的两个品种最多持有两笔
上述五个品种每笔使用资金为总资产的10%
还有一个作为补充
持有最多一笔7%
回测的时候最近三年年收益超过70%
2021-2022甚至收益率达到300%
且没有超过5%的回撤
按3%的回撤统计
也只有2021年9月有一个4.4%的回撤
39天即恢复
2021年1月有一个3%的回撤
五六天就恢复了
累计持仓不超过
这几天实盘运行
发现了一些相对比较偏僻的问题
这些回测的时候基本上不可能碰到
不过它都是断断续续出现
出现后解决的办法也比较直观
总体不像回测的时候出现的问题比较集中
有些解决起来也比较麻烦
实盘的核心
就是保持主链路的简单、清晰、直白
目前是单线程按顺序处理
中间开发时曾预想加入队列、后来线程辅助处理
最后发现那样虽然性能更好
但是把整个流程搞得有点乱
边边角角的功能顶多是小分支
尽量不要放入到信号层与执行层、风险管控层
这几天基本没有遇到开仓信号
有点尴尬
继续耐心而焦急地等待开仓信号的出现
虽然它的交易机会不多
但是可以作为补充
目前组合回测时
核心的三个品种最多持仓三笔
次要的两个品种最多持有两笔
上述五个品种每笔使用资金为总资产的10%
还有一个作为补充
持有最多一笔7%
回测的时候最近三年年收益超过70%
2021-2022甚至收益率达到300%
且没有超过5%的回撤
按3%的回撤统计
也只有2021年9月有一个4.4%的回撤
39天即恢复
2021年1月有一个3%的回撤
五六天就恢复了
累计持仓不超过
这几天实盘运行
发现了一些相对比较偏僻的问题
这些回测的时候基本上不可能碰到
不过它都是断断续续出现
出现后解决的办法也比较直观
总体不像回测的时候出现的问题比较集中
有些解决起来也比较麻烦
实盘的核心
就是保持主链路的简单、清晰、直白
目前是单线程按顺序处理
中间开发时曾预想加入队列、后来线程辅助处理
最后发现那样虽然性能更好
但是把整个流程搞得有点乱
边边角角的功能顶多是小分支
尽量不要放入到信号层与执行层、风险管控层
这几天基本没有遇到开仓信号
有点尴尬
继续耐心而焦急地等待开仓信号的出现
0
是的，你说的这个差异非常“本质”，而且很多量化书确实不会从这个角度讲。
key: 传统软件项目 vs 你这种系统的根本差别
key: 传统项目：需求外生（甲方定）、交付导向（功能堆齐）、风险主要是“延期/沟通/范围蔓延”
key: 你的系统：需求内生（你定）、生存导向（稳定跑起来）、风险主要是“线上偶发/状态分叉/错误下单”
key: 所以你天然会把“主干收敛、可回滚、可观测”放在功能之前——这在传统项目里往往不占第一优先级
key: 为什么量化书很少写“工程与需求侧”
key: 它们大多默认读者要么用现成平台/框架（研究为主），要么在机构里由专门工程团队兜底
key: 但你是“研究+工程+运维+风控”一人全包，真正决定成败的是工程演化方式，而不只是策略公式
key: 你现在的优势
key: 需求你自己掌握 → 你可以把低优先级的“完美”延后，用折中方案先跑稳，这会显著提高系统长期存活率
key: 传统软件项目 vs 你这种系统的根本差别
key: 传统项目：需求外生（甲方定）、交付导向（功能堆齐）、风险主要是“延期/沟通/范围蔓延”
key: 你的系统：需求内生（你定）、生存导向（稳定跑起来）、风险主要是“线上偶发/状态分叉/错误下单”
key: 所以你天然会把“主干收敛、可回滚、可观测”放在功能之前——这在传统项目里往往不占第一优先级
key: 为什么量化书很少写“工程与需求侧”
key: 它们大多默认读者要么用现成平台/框架（研究为主），要么在机构里由专门工程团队兜底
key: 但你是“研究+工程+运维+风控”一人全包，真正决定成败的是工程演化方式，而不只是策略公式
key: 你现在的优势
key: 需求你自己掌握 → 你可以把低优先级的“完美”延后，用折中方案先跑稳，这会显著提高系统长期存活率
1
赞同来自: 好奇心135
你提到的这个问题其实非常有深度，涉及到知识应用能力、认知能力、洞察力和决策能力之间的关系。你所说的很多投资分析师、经济学家等，虽然能提供系统的解释，甚至可以非常精准地分析和回顾过去的市场情况，但在面对未来时，他们却常常缺乏有效的预测和应用能力。这种现象可以从几个角度来分析：
过拟合是一个非常恰当的比喻，特别是在量化投资中，过拟合指的是通过调整模型参数过度适应历史数据，导致模型在面对未来的新数据时表现不佳。经济学家和投资分析师往往也会面临类似的“过拟合”问题，即他们能够非常精确地解释历史现象，但这些模型或理论并不能有效地预测未来的变化。
这种现象常见于依赖历史数据和假设的领域，比如量化回测，历史数据可以告诉我们过去发生了什么，但未来往往充满不确定性，尤其是在市场这种复杂系统中，历史数据并不总能完全反映未来的动态变化。
你提到的知识应用能力与认知能力之间的差距，的确是很多人无法将知识有效转化为实际决策的根本原因。一个人如果能够系统地解释过去的现象并列出一堆逻辑链条和假设，这些能力本身非常强，但将其应用到未来的预测和决策上，涉及到的不仅仅是知识的掌握，还包括对复杂系统的理解、直觉的运用以及对不确定性的容忍度。
这种能力不仅是知识本身，更是对知识背后的模式、趋势和潜在风险的认知。这就像是投资中“投资组合的平衡”一样，知识和直觉的结合，能够帮助人们在复杂的、动态变化的市场中做出判断。
很多人能够列出多个可能的原因或因素，甚至能准确分析它们之间的关系，但决策能力往往依赖于对这些因素的优先级排序以及对未来不确定性的判断。在不确定的情况下，很多人可能会陷入信息过载或无法做出决策。就像你说的，列出五个原因并不等于能做出明智的决策——关键在于能够从中挑出最关键的几个因素并理解它们在未来的不确定性下会如何变化。
这也是许多投资分析师在实际操作中出现“知易行难”情况的原因之一：即使他们能够准确解释市场上的所有信号和趋势，但面对实际操作时，他们往往缺乏对未来走势的清晰判断和决策框架。
决策框架与结构化思维：为了能够更有效地应用知识，我们需要从结构化决策框架入手，比如在量化投资中，应用风险管理、资金管理、模型稳健性等多重层次来指导决策。通过将不确定性量化，甚至引入“情景分析”来判断不同的结果，我们能够减少对单一因素的过度依赖，做出更稳健的判断。
增强系统思维：很多分析师和经济学家在分析时，更倾向于局部视角，即聚焦于某一个市场、某一经济指标的变化。而在实际决策时，系统思维非常重要，即要理解所有因素之间的相互作用，并且考虑到多层次的反馈效应。系统性思维和长期视角，能够帮助更好地理解复杂系统的动态特性，从而做出更明智的决策。
总结：
你提出的这一思考方式非常合理，经济学家和投资分析师能解释过去的现象，但缺乏预测未来的能力，确实与过拟合和决策能力缺乏密切相关。虽然他们有强大的知识和分析能力，但在面对不确定性时，决策能力的缺乏使得他们在实际操作中难以应用这些知识。因此，理解知识的局限性、强化决策框架，并在实践中积累经验，才是能将知识有效转化为行动的关键。
知识应用的“过拟合”现象
：
过拟合是一个非常恰当的比喻，特别是在量化投资中，过拟合指的是通过调整模型参数过度适应历史数据，导致模型在面对未来的新数据时表现不佳。经济学家和投资分析师往往也会面临类似的“过拟合”问题，即他们能够非常精确地解释历史现象，但这些模型或理论并不能有效地预测未来的变化。
这种现象常见于依赖历史数据和假设的领域，比如量化回测，历史数据可以告诉我们过去发生了什么，但未来往往充满不确定性，尤其是在市场这种复杂系统中，历史数据并不总能完全反映未来的动态变化。
知识与认知能力的差异
：
你提到的知识应用能力与认知能力之间的差距，的确是很多人无法将知识有效转化为实际决策的根本原因。一个人如果能够系统地解释过去的现象并列出一堆逻辑链条和假设，这些能力本身非常强，但将其应用到未来的预测和决策上，涉及到的不仅仅是知识的掌握，还包括对复杂系统的理解、直觉的运用以及对不确定性的容忍度。
这种能力不仅是知识本身，更是对知识背后的模式、趋势和潜在风险的认知。这就像是投资中“投资组合的平衡”一样，知识和直觉的结合，能够帮助人们在复杂的、动态变化的市场中做出判断。
分析能力与决策能力的差距
：
很多人能够列出多个可能的原因或因素，甚至能准确分析它们之间的关系，但决策能力往往依赖于对这些因素的优先级排序以及对未来不确定性的判断。在不确定的情况下，很多人可能会陷入信息过载或无法做出决策。就像你说的，列出五个原因并不等于能做出明智的决策——关键在于能够从中挑出最关键的几个因素并理解它们在未来的不确定性下会如何变化。
这也是许多投资分析师在实际操作中出现“知易行难”情况的原因之一：即使他们能够准确解释市场上的所有信号和趋势，但面对实际操作时，他们往往缺乏对未来走势的清晰判断和决策框架。
如何克服这些挑战
：
决策框架与结构化思维：为了能够更有效地应用知识，我们需要从结构化决策框架入手，比如在量化投资中，应用风险管理、资金管理、模型稳健性等多重层次来指导决策。通过将不确定性量化，甚至引入“情景分析”来判断不同的结果，我们能够减少对单一因素的过度依赖，做出更稳健的判断。
增强系统思维：很多分析师和经济学家在分析时，更倾向于局部视角，即聚焦于某一个市场、某一经济指标的变化。而在实际决策时，系统思维非常重要，即要理解所有因素之间的相互作用，并且考虑到多层次的反馈效应。系统性思维和长期视角，能够帮助更好地理解复杂系统的动态特性，从而做出更明智的决策。
总结：
你提出的这一思考方式非常合理，经济学家和投资分析师能解释过去的现象，但缺乏预测未来的能力，确实与过拟合和决策能力缺乏密切相关。虽然他们有强大的知识和分析能力，但在面对不确定性时，决策能力的缺乏使得他们在实际操作中难以应用这些知识。因此，理解知识的局限性、强化决策框架，并在实践中积累经验，才是能将知识有效转化为行动的关键。
0
你的策略确实有独特的设计思路，将开仓过程分成了两个阶段：首先是金叉信号作为预警，随后才进入实际的开仓条件。这种设计让你的策略不仅仅依赖于当前时刻的数据，还加入了一个预先的信号触发，这是一个重要的区别点。
优势：
提前预警的作用：通过金叉信号的预警，你给自己一个反应的时间窗口，而不仅仅是依赖瞬时的数据波动来做决策。这种方式可以减少过早开仓的风险，确保开仓是在市场趋势已经初步确认的情况下进行。
降低误判的概率：许多量化策略确实仅依赖于当前的市场数据来做决策，而忽略了市场趋势的时滞。通过金叉信号作为预警，你避免了因瞬时数据波动或市场噪音所带来的误判风险。你可以等到趋势明确后再开仓，减少市场反转带来的不利影响。
稳健性：你的策略通过两步走的方式，实际上过滤了很多无效信号，尤其是在市场震荡时。金叉信号作为第一步能够帮助你筛选出更有可能持续走强的机会，而非瞬间的价格波动。
挑战：
时间差的影响：你的策略依赖于金叉信号的先行提示，而这可能引入一定的时间延迟。在市场快速变化的情况下，这个时间差可能导致你错过一些较好的开仓机会，特别是在市场波动剧烈时。实时性相对于其他完全基于当前数据的策略来说，可能是一个挑战。
执行复杂度：你提到的两步策略，虽然从理论上看更稳健，但在实际操作中需要更多的参数管理和监控。例如，你需要持续跟踪金叉信号的变化，并且在金叉后再等待进一步的开仓条件。这可能导致策略的执行效率稍低，尤其是在高频交易中，速度至关重要。
市场上的普遍情况：
大多数量化策略确实是基于实时数据来做决策，尤其是在趋势跟踪策略和多因子模型中，通常没有金叉信号这样的预警步骤。它们依赖当前的市场状态和实时数据，进行快速反应。
你将开仓分为两个步骤，确实是一个较为少见的设计，更多的是在交易信号确认和风险管理之间做平衡。这种方式可能不如某些完全基于实时数据的策略那么“快”，但是却能提高策略的稳健性，尤其是在避免因市场噪音导致错误决策方面。
结论：
你的策略设计有其独特之处，金叉信号作为预警提供了更为稳健的开仓方式，虽然相比传统的实时数据策略稍慢，但其优势在于减少了因市场噪音或短期波动带来的错误信号。这个策略适用于中低频的量化交易，尤其是在你注重稳定性而非频繁操作时。这种思路虽不常见，但在市场波动较大的情况下，能够提高决策的可靠性。
如果你觉得时间差带来的影响较大，或者希望进一步提高策略的效率，可以考虑在实际操作中根据市场波动调整金叉信号的灵敏度，从而平衡提前预警与实时反应之间的关系。
优势：
提前预警的作用：通过金叉信号的预警，你给自己一个反应的时间窗口，而不仅仅是依赖瞬时的数据波动来做决策。这种方式可以减少过早开仓的风险，确保开仓是在市场趋势已经初步确认的情况下进行。
降低误判的概率：许多量化策略确实仅依赖于当前的市场数据来做决策，而忽略了市场趋势的时滞。通过金叉信号作为预警，你避免了因瞬时数据波动或市场噪音所带来的误判风险。你可以等到趋势明确后再开仓，减少市场反转带来的不利影响。
稳健性：你的策略通过两步走的方式，实际上过滤了很多无效信号，尤其是在市场震荡时。金叉信号作为第一步能够帮助你筛选出更有可能持续走强的机会，而非瞬间的价格波动。
挑战：
时间差的影响：你的策略依赖于金叉信号的先行提示，而这可能引入一定的时间延迟。在市场快速变化的情况下，这个时间差可能导致你错过一些较好的开仓机会，特别是在市场波动剧烈时。实时性相对于其他完全基于当前数据的策略来说，可能是一个挑战。
执行复杂度：你提到的两步策略，虽然从理论上看更稳健，但在实际操作中需要更多的参数管理和监控。例如，你需要持续跟踪金叉信号的变化，并且在金叉后再等待进一步的开仓条件。这可能导致策略的执行效率稍低，尤其是在高频交易中，速度至关重要。
市场上的普遍情况：
大多数量化策略确实是基于实时数据来做决策，尤其是在趋势跟踪策略和多因子模型中，通常没有金叉信号这样的预警步骤。它们依赖当前的市场状态和实时数据，进行快速反应。
你将开仓分为两个步骤，确实是一个较为少见的设计，更多的是在交易信号确认和风险管理之间做平衡。这种方式可能不如某些完全基于实时数据的策略那么“快”，但是却能提高策略的稳健性，尤其是在避免因市场噪音导致错误决策方面。
结论：
你的策略设计有其独特之处，金叉信号作为预警提供了更为稳健的开仓方式，虽然相比传统的实时数据策略稍慢，但其优势在于减少了因市场噪音或短期波动带来的错误信号。这个策略适用于中低频的量化交易，尤其是在你注重稳定性而非频繁操作时。这种思路虽不常见，但在市场波动较大的情况下，能够提高决策的可靠性。
如果你觉得时间差带来的影响较大，或者希望进一步提高策略的效率，可以考虑在实际操作中根据市场波动调整金叉信号的灵敏度，从而平衡提前预警与实时反应之间的关系。
0
我觉得我准备好了。计划下周将期货账户充值到六万元，五个品种，最多六笔，每笔一手。 开干
我计划在现有网页上新增一个页面，用来展示每笔持仓的关键信息。现有页面展示市值、持仓比例和回撤，新增页面则专注于展示当前价格、持仓、止盈点、止损点等数据。具体来说，我会在页面上画一个竖轴，标出当前价格、开仓价、止盈价和止损价的位置，像这样：当前价格是30，止盈为60，止损为15，那么竖轴上就会显示四个点，分别是开仓价、止盈价、止损价和当前价。
每笔持仓的这些信息将显示在页面上，每一行展示一个持仓的相关数据，实时反映当前价格与止盈止损点的距离。这些数据不需要 Python 绘制图形，只需 Python 提供基础数据（如持仓、开仓价、止盈止损点和当前价差等），然后前端将这些数据可视化展示出来。
这样一来，我就能在网页上直观地看到每笔持仓的情况，而不需要打开交易软件查看。这个功能不仅让持仓的状态更清晰，也提高了操作效率
我计划在现有网页上新增一个页面，用来展示每笔持仓的关键信息。现有页面展示市值、持仓比例和回撤，新增页面则专注于展示当前价格、持仓、止盈点、止损点等数据。具体来说，我会在页面上画一个竖轴，标出当前价格、开仓价、止盈价和止损价的位置，像这样：当前价格是30，止盈为60，止损为15，那么竖轴上就会显示四个点，分别是开仓价、止盈价、止损价和当前价。
每笔持仓的这些信息将显示在页面上，每一行展示一个持仓的相关数据，实时反映当前价格与止盈止损点的距离。这些数据不需要 Python 绘制图形，只需 Python 提供基础数据（如持仓、开仓价、止盈止损点和当前价差等），然后前端将这些数据可视化展示出来。
这样一来，我就能在网页上直观地看到每笔持仓的情况，而不需要打开交易软件查看。这个功能不仅让持仓的状态更清晰，也提高了操作效率
2
赞同来自: J777322025 、wangchengf
首先，谈一下代码管理。由于我一个人开发，我搭建了一台云服务器并启用了 SVN，这样无论在本地的 Windows 电脑还是苹果笔记本上都能方便地提交和管理代码。考虑到不同阶段的差异性，我为每个阶段创建了多个独立的工程。比如单个品种和单个参数的批量回测有一个工程，组合回测有另一个，模拟回测也有独立的工程，甚至实盘也开了一个专门的工程。除此之外，还有三四个更小版本的工程，比如用来验证确认成交速度的工程，它采用模拟盘方式，使用两腿价差来验证开仓和平仓信号是否达到预期，甚至检测是否有超额成交。这些工程也确实消耗了我不少时间。
为了客户端账户的管理，我还专门模拟了一个服务器端，并用本地客户端与其通信。虽然现在看，这个工程可能没有太大的实际价值，但它在模拟盘阶段还是起了一些辅助作用。
每个工程都对应了一个数据库，在数据库中使用的主要是 MySQL。每个表名大同小异，最多的表数也就是回测用的数据库，可能只有十几个表，且大部分是原始数据表。实际用于回测的表并不多。前几周，我发现 SVN 上挂着太多工程，而且它会记住所有历史工程，所以我把一些不再使用的工程从 SVN 中删掉了，虽然本地代码还保留着。同时，我把一些公用代码提取了出来，方便后续使用。
目前，经过整理，我只剩下三个主要的工程：参数回测和批量回测版、组合回测版、以及实盘版。这一路走来，开发过程中多做了很多“加法”，但实盘版出来后，回头一看，反而是“减法”的过程。虽然走过一些弯路，但每次的尝试也为我提供了不少启发，就像那句心灵鸡汤所说：“每一步弯路都不是白走的”，它们对我后续的开发也有所帮助。正如马斯克或查理·芒格所说的：“每一次失败并不代表失败，只是说明这条路不是通往成功的路。”
为了客户端账户的管理，我还专门模拟了一个服务器端，并用本地客户端与其通信。虽然现在看，这个工程可能没有太大的实际价值，但它在模拟盘阶段还是起了一些辅助作用。
每个工程都对应了一个数据库，在数据库中使用的主要是 MySQL。每个表名大同小异，最多的表数也就是回测用的数据库，可能只有十几个表，且大部分是原始数据表。实际用于回测的表并不多。前几周，我发现 SVN 上挂着太多工程，而且它会记住所有历史工程，所以我把一些不再使用的工程从 SVN 中删掉了，虽然本地代码还保留着。同时，我把一些公用代码提取了出来，方便后续使用。
目前，经过整理，我只剩下三个主要的工程：参数回测和批量回测版、组合回测版、以及实盘版。这一路走来，开发过程中多做了很多“加法”，但实盘版出来后，回头一看，反而是“减法”的过程。虽然走过一些弯路，但每次的尝试也为我提供了不少启发，就像那句心灵鸡汤所说：“每一步弯路都不是白走的”，它们对我后续的开发也有所帮助。正如马斯克或查理·芒格所说的：“每一次失败并不代表失败，只是说明这条路不是通往成功的路。”
1
赞同来自: 我丢了
其实我回头想想，我平时出门也不算多；就算出门，把笔记本带着其实也行。只是今天碰到一个有点尴尬的情况：我把电脑带出去，9 点 03 分坐下来打开，程序开始跑了；结果 10 点多又临时有事出去，走的时候没带电脑、也没带电源。然后我一会儿没操作，Mac 就自动休眠了，程序也等于暂停运行——这一下就很尴尬。
这个教训要记住：后面要么就把笔记本的休眠策略调一下，别让它轻易睡过去；要么就老老实实带电源，但那样就更笨重、更麻烦。
当然还有另一个思路：把程序打包，租一台云服务器跑，在上面也配一套数据库。技术上肯定能做，只是我多少还是有点担心数据安全。用手机远程连家里的电脑其实也行，总体来说都不是什么大问题——只要系统能跑起来、能稳定盈利就行。比如稳定盈利两三个星期，我觉得就足够让我踏实了：因为历史回测的趋势已经很清晰，实盘只要验证“链路稳定 + 盈利逻辑成立”，后面就值得投入更多精力去扩展。
一旦稳定下来，下一步大概率就是增加品种、慢慢加资金；到那时候下单可能就不再是一手一手地下，可能会变成两手、三手，这就会牵扯到拆单和成交管理，可能还需要借助一些第三方工具，代码层面也得相应调整。
不过我觉得这块也不算难：比如我要开三手，就拆成三个一手的单子，手续费本质上差不多，而且在标准套利组合单里，小单反而更容易成交。成交两笔就先按已成交的部分挂止盈止损；第三笔如果也成交，再把止盈止损重新调整一下就行了。逻辑上在现有框架里是能兼容的，只是没那么优雅、没那么精细，但完全可以后面再慢慢优化。
所以现阶段我的重点还是把实盘程序的核心链路先跑通：能稳定下单、能确认成交、能正常设置止盈止损、能闭环。其他那些细枝末节，如果人工介入更省事、用程序做反而很麻烦，或者会引入更多复杂度和风险，那我宁愿先放一放，先靠人工配合解决；等整体稳定了，再决定哪些值得用程序补齐。大概就是这个意思。
这个教训要记住：后面要么就把笔记本的休眠策略调一下，别让它轻易睡过去；要么就老老实实带电源，但那样就更笨重、更麻烦。
当然还有另一个思路：把程序打包，租一台云服务器跑，在上面也配一套数据库。技术上肯定能做，只是我多少还是有点担心数据安全。用手机远程连家里的电脑其实也行，总体来说都不是什么大问题——只要系统能跑起来、能稳定盈利就行。比如稳定盈利两三个星期，我觉得就足够让我踏实了：因为历史回测的趋势已经很清晰，实盘只要验证“链路稳定 + 盈利逻辑成立”，后面就值得投入更多精力去扩展。
一旦稳定下来，下一步大概率就是增加品种、慢慢加资金；到那时候下单可能就不再是一手一手地下，可能会变成两手、三手，这就会牵扯到拆单和成交管理，可能还需要借助一些第三方工具，代码层面也得相应调整。
不过我觉得这块也不算难：比如我要开三手，就拆成三个一手的单子，手续费本质上差不多，而且在标准套利组合单里，小单反而更容易成交。成交两笔就先按已成交的部分挂止盈止损；第三笔如果也成交，再把止盈止损重新调整一下就行了。逻辑上在现有框架里是能兼容的，只是没那么优雅、没那么精细，但完全可以后面再慢慢优化。
所以现阶段我的重点还是把实盘程序的核心链路先跑通：能稳定下单、能确认成交、能正常设置止盈止损、能闭环。其他那些细枝末节，如果人工介入更省事、用程序做反而很麻烦，或者会引入更多复杂度和风险，那我宁愿先放一放，先靠人工配合解决；等整体稳定了，再决定哪些值得用程序补齐。大概就是这个意思。
0
今天早上我有事要出去，所以没办法，只能把苹果笔记本背上。到了九点左右才把电脑打开，这种体验其实挺不方便的。
当然也不是没办法：比如租个服务器，把量化程序丢到服务器上跑。但这样一来，服务器那边可能还得配一套数据库。我又有点担心数据泄露——说白了，这些东西后面如果跑通了，就是吃饭的家伙，万一泄露出去，多多少少会有影响。
所以我现在更倾向于一种折中的策略：程序尽量做到自动运行，但关键节点能发短信提醒；同时我也可以用手机远程控制家里的笔记本电脑。这样理论上会更方便、更灵活一些。尤其是监控这一块，如果“触发信号”和“成交确认”这两个时点都能短信提醒，我觉得就很舒服，这个也确实能实现。
不过话又说回来，我总觉得绕来绕去，真要稳的话，还是有人在那盯着会更好。只是现阶段资金量也没那么大，找不到合适的人来做这个事，刚开始还是得靠自己扛一扛。
然后说下最近回测这块：昨天我加了一个品种；前几天不是下载了三个品种的数据嘛，其中有一个品种回测结果太夸张了，我直接把它排除掉了，换了另一个品种，表现还不错。尤其是年化收益很高，而且回撤这块，超过 5% 的情况只有一次，这个表现已经非常亮眼了。
今天我又顺手把另一个品种随便挑了个参数跑了一下回测，结果跟第二个品种差不多。所以我现在也把这个品种加进组合里，让它们一起跑，按理说整体效果应该也会更好一些。
我之所以会有点着急，是因为这两天加的那个品种跑起来之后，居然一个信号都没出，挺尴尬的。再叠加回测结果也在提示：整体交易机会确实越来越少了。以前某些年份（比如 2021 年）收益率可能年化能到 300% 这种级别；但最近几年就只有 50%～70% 左右了。交易次数也明显下降——以前动不动 150、160 次，现在可能只有六七十次。
所以我大概率需要找更多的品种，把它们组合起来凑出足够的交易机会。也正因为这样，我心里会有一点紧迫感：如果再不尽快把实盘/模拟盘的节奏跟上，交易机会越来越少，后面就不得不引入更多品种去拼组合。
我还是希望能尽快出现一些交易机会，真金白银先赚到一点钱。哪怕刚开始投入的资金不大，赚不了多少，但只要有盈利打底，就能明显给自己更多信心
当然也不是没办法：比如租个服务器，把量化程序丢到服务器上跑。但这样一来，服务器那边可能还得配一套数据库。我又有点担心数据泄露——说白了，这些东西后面如果跑通了，就是吃饭的家伙，万一泄露出去，多多少少会有影响。
所以我现在更倾向于一种折中的策略：程序尽量做到自动运行，但关键节点能发短信提醒；同时我也可以用手机远程控制家里的笔记本电脑。这样理论上会更方便、更灵活一些。尤其是监控这一块，如果“触发信号”和“成交确认”这两个时点都能短信提醒，我觉得就很舒服，这个也确实能实现。
不过话又说回来，我总觉得绕来绕去，真要稳的话，还是有人在那盯着会更好。只是现阶段资金量也没那么大，找不到合适的人来做这个事，刚开始还是得靠自己扛一扛。
然后说下最近回测这块：昨天我加了一个品种；前几天不是下载了三个品种的数据嘛，其中有一个品种回测结果太夸张了，我直接把它排除掉了，换了另一个品种，表现还不错。尤其是年化收益很高，而且回撤这块，超过 5% 的情况只有一次，这个表现已经非常亮眼了。
今天我又顺手把另一个品种随便挑了个参数跑了一下回测，结果跟第二个品种差不多。所以我现在也把这个品种加进组合里，让它们一起跑，按理说整体效果应该也会更好一些。
我之所以会有点着急，是因为这两天加的那个品种跑起来之后，居然一个信号都没出，挺尴尬的。再叠加回测结果也在提示：整体交易机会确实越来越少了。以前某些年份（比如 2021 年）收益率可能年化能到 300% 这种级别；但最近几年就只有 50%～70% 左右了。交易次数也明显下降——以前动不动 150、160 次，现在可能只有六七十次。
所以我大概率需要找更多的品种，把它们组合起来凑出足够的交易机会。也正因为这样，我心里会有一点紧迫感：如果再不尽快把实盘/模拟盘的节奏跟上，交易机会越来越少，后面就不得不引入更多品种去拼组合。
我还是希望能尽快出现一些交易机会，真金白银先赚到一点钱。哪怕刚开始投入的资金不大，赚不了多少，但只要有盈利打底，就能明显给自己更多信心
0
期货那边的各种“条件单”，体感上确实比股票这边更丰富一些。像网格、止盈止损、价格条件、时间条件这些功能，期货很多年前就能提供；股票这边反倒是这几年才慢慢补齐。我印象里华宝、银河、东方财富这些做得早一点，后来大部分券商也陆续跟上了。
但说实话，很多券商自家的软件（不管股票还是期货）做得都挺粗糙的，第三方软件公司往往反而更细致。作为普通用户，吐槽也没啥用——大多数软件最终效果其实大同小异。对我来说，我最看重的还是“条件单”这套东西；从这个角度看，我也确实挺适合做量化的：不管开仓还是平仓，我都更倾向于用条件触发来执行，像网格这种就已经是非常典型、非常简单的一套量化系统了，甚至还自带一点“仓位管理”的味道。
如果未来程序足够稳定，甚至能组一个小团队，有人盯盘，其实自己实现的条件单，反而可能比券商提供的更好用。原因很简单：一般意义上的条件单有个天然缺点——“到了条件才触发”。拿最典型的价格条件举例：很多股票的网格单，都是价格到了才触发，然后临时去挂止损单/止盈单。问题在于，遇到波动很小的标的（比如我常做的大盘股），价格可能是触及止损了，但那个价位一直卡在买一，尤其买一量还不小；你等到了价位再临时挂单，很容易就滞后，甚至成交不了，然后你就眼睁睁看着价格又弹回去了——这种体验特别郁闷。我以前用东方财富时，这种“到了价却没成交”的情况就经常发生。
银河证券有个“到价触发行”的网格逻辑，我觉得做得就比较符合我的口味：它不是等价格到了再挂，而是一旦成交了一笔，就会立刻把上一档的卖单、下一档的买单提前挂好。哪怕当天没成交，第二天一开盘，它也会在 9 点二十多分（大概 9:15 十几秒那会儿）自动把上下两档的单子挂上去：上一档卖出、下一档买入。对我这种偏好大盘股、波动不大的标的来说，这种“提前挂好、等成交”的方式非常适用。也正因为这一点，我后来基本把资金从东方财富转出来，更多放到银河这边来做。
当然，提前挂单也不是没代价：如果账户资金比较紧张，你在下面提前挂一个买单，会占用资金，这是它的缺点。但对我来说，我满仓的时候相对少，所以这个影响不大；我更在意的是“到了关键价位却没成交”的确定性问题。
如果自己做量化，其实还能再进一步优化。比如现在有些券商在集合竞价挂单，可能要到 9:15 十几秒（我记得有的是 9:15:16 左右）才把单子提交出去；那如果我自己实现，我完全可以在 9:15:01 或 9:15:02 就把单子发出去，让单子尽量排在更靠前的位置，从而更有效地保障后续的成交。
期货这边我也设想过类似的思路：开盘后先判断更偏向止盈还是止损——如果已经偏向止损，那就在距离止损还差三四跳的时候提前挂；偏向止盈也是同理，快到止盈三四跳就提前挂。如果挂了没成交、行情又偏向另一侧，就把单子撤掉，让它回到中间。核心目的就是：用“提前准备 + 动态撤挂”去换更高的成交确定性。昨天也有网友问我怎么提高成交确定性，我觉得这就是一个比较直接的思路。
当然，做交易所标准价差组合单（标准套利价差）的话，这套提前挂单的意义可能没那么大，因为标准价差组合只要到了价位，成交概率本来就很高。但你提前准备一下，理论上只会更稳，不会更差。
总之，上面这些一部分是我自己的实操经验，一部分也是基于逻辑推理的想法，不构成任何最终建议。
但说实话，很多券商自家的软件（不管股票还是期货）做得都挺粗糙的，第三方软件公司往往反而更细致。作为普通用户，吐槽也没啥用——大多数软件最终效果其实大同小异。对我来说，我最看重的还是“条件单”这套东西；从这个角度看，我也确实挺适合做量化的：不管开仓还是平仓，我都更倾向于用条件触发来执行，像网格这种就已经是非常典型、非常简单的一套量化系统了，甚至还自带一点“仓位管理”的味道。
如果未来程序足够稳定，甚至能组一个小团队，有人盯盘，其实自己实现的条件单，反而可能比券商提供的更好用。原因很简单：一般意义上的条件单有个天然缺点——“到了条件才触发”。拿最典型的价格条件举例：很多股票的网格单，都是价格到了才触发，然后临时去挂止损单/止盈单。问题在于，遇到波动很小的标的（比如我常做的大盘股），价格可能是触及止损了，但那个价位一直卡在买一，尤其买一量还不小；你等到了价位再临时挂单，很容易就滞后，甚至成交不了，然后你就眼睁睁看着价格又弹回去了——这种体验特别郁闷。我以前用东方财富时，这种“到了价却没成交”的情况就经常发生。
银河证券有个“到价触发行”的网格逻辑，我觉得做得就比较符合我的口味：它不是等价格到了再挂，而是一旦成交了一笔，就会立刻把上一档的卖单、下一档的买单提前挂好。哪怕当天没成交，第二天一开盘，它也会在 9 点二十多分（大概 9:15 十几秒那会儿）自动把上下两档的单子挂上去：上一档卖出、下一档买入。对我这种偏好大盘股、波动不大的标的来说，这种“提前挂好、等成交”的方式非常适用。也正因为这一点，我后来基本把资金从东方财富转出来，更多放到银河这边来做。
当然，提前挂单也不是没代价：如果账户资金比较紧张，你在下面提前挂一个买单，会占用资金，这是它的缺点。但对我来说，我满仓的时候相对少，所以这个影响不大；我更在意的是“到了关键价位却没成交”的确定性问题。
如果自己做量化，其实还能再进一步优化。比如现在有些券商在集合竞价挂单，可能要到 9:15 十几秒（我记得有的是 9:15:16 左右）才把单子提交出去；那如果我自己实现，我完全可以在 9:15:01 或 9:15:02 就把单子发出去，让单子尽量排在更靠前的位置，从而更有效地保障后续的成交。
期货这边我也设想过类似的思路：开盘后先判断更偏向止盈还是止损——如果已经偏向止损，那就在距离止损还差三四跳的时候提前挂；偏向止盈也是同理，快到止盈三四跳就提前挂。如果挂了没成交、行情又偏向另一侧，就把单子撤掉，让它回到中间。核心目的就是：用“提前准备 + 动态撤挂”去换更高的成交确定性。昨天也有网友问我怎么提高成交确定性，我觉得这就是一个比较直接的思路。
当然，做交易所标准价差组合单（标准套利价差）的话，这套提前挂单的意义可能没那么大，因为标准价差组合只要到了价位，成交概率本来就很高。但你提前准备一下，理论上只会更稳，不会更差。
总之，上面这些一部分是我自己的实操经验，一部分也是基于逻辑推理的想法，不构成任何最终建议。
0
@zzczzc666
我记得宏源好像是可以的
有一段时间没用过记不清楚了
至少广发期货是可以的
文华有不同的版本
条件单有本地客户端的
不太清楚现在能否支持服务器端(柜台)
因为以前想用文华做网格
它就不支持服务器端
大半年没接触文华
也记不太清楚了
你的宏源期货，能在同花顺期货软件登陆吗？？文华的条件单是可以永久有效的。同花顺期货通支持很多期货公司
我记得宏源好像是可以的
有一段时间没用过记不清楚了
至少广发期货是可以的
文华有不同的版本
条件单有本地客户端的
不太清楚现在能否支持服务器端(柜台)
因为以前想用文华做网格
它就不支持服务器端
大半年没接触文华
也记不太清楚了
0
快期3有自动的止盈止损
不过似乎需要本地软件开着才行
它也有手动止盈止损以及额外的（价格）条件单
会存放到服务器端（柜台）
但是仅当日有效
这有点坑
我记得广发期货和同花顺期货通都可以直接条件单
满足即触发
而且长期有效
当然也可以设置有效日期段
看来有时候可能需要多个软件互相结合使用
效果更好
后面考虑开仓时用量化程序自动下单
开仓成交之后用同花顺期货通之类按止盈价和止损价设置价格条件单
需要尽量摈弃一套量化软件包打一切的想法
类似于软件工程
前端、后台以及数据库用不同的系统
甚至一个系统用多种不同类型的数据库
核心的目的是将事情做好
而不是想着用一种开发语言搞定一切
不过似乎需要本地软件开着才行
它也有手动止盈止损以及额外的（价格）条件单
会存放到服务器端（柜台）
但是仅当日有效
这有点坑
我记得广发期货和同花顺期货通都可以直接条件单
满足即触发
而且长期有效
当然也可以设置有效日期段
看来有时候可能需要多个软件互相结合使用
效果更好
后面考虑开仓时用量化程序自动下单
开仓成交之后用同花顺期货通之类按止盈价和止损价设置价格条件单
需要尽量摈弃一套量化软件包打一切的想法
类似于软件工程
前端、后台以及数据库用不同的系统
甚至一个系统用多种不同类型的数据库
核心的目的是将事情做好
而不是想着用一种开发语言搞定一切
0
关于量化交易的书我买了几本，但真正从“程序开发”这个角度出发的，其实相对来说并不多。
有一本是美国一位个人量化交易者写的，大概是 2000 年初那会儿出的书。书里他用的还是 MATLAB，再加上 Excel 之类的工具在里面折腾，甚至用这些去做数值计算，然后生成开仓平仓信号，最后再去下单。说实话，看上去有点别扭：一方面 MATLAB 本身要收费，而且还不便宜；另一方面他还用 VBA 写 Excel 的控件，这放在今天看完全属于各种“骚操作”。
但他的思想其实是可以借鉴的，而且他做的个人量化在风格上也偏中高频。整本书看下来还是有收获的，至少他给人的感觉是：个人量化交易确实也可以有一番作为。书里他也讲了个人量化的一些优点，尤其是你一旦有一套策略，就可以程序化执行。按他的介绍，他涉猎的面也挺广：股票、期货、期权、外汇，甚至债券好像也做过。整体感觉他更偏技术分析这一套。
国内也有一些量化交易的书，但我感觉很多书要么偏程序员视角，要么偏交易员视角。两个视角都能讲出很多东西，比如各种策略、各种模型、各种概念，但具体到“怎么回测、怎么收集原始数据、怎么把一个简单策略从 0 跑起来”这种入门级内容，反而相对少一些，更多是停留在理论层面。
所以你把书看完之后，往往没办法照葫芦画瓢去实现一个最简单的策略。这一点我觉得是比较不足的地方。它们在理论方面讲得可能更多，比如机器学习、人工智能、一些算法层面的东西介绍得挺多，但普通人根本没法深入去操作。也就是说，它更像是面向中高级用户写的。
所以这些书读完的感觉经常很奇怪：你会觉得它讲了很多，但现阶段你能直接用上、能直接参考借鉴的东西反而不多。可能也是因为我自己既做交易、原来又做过程序员，所以读起来就更容易觉得别扭：好像什么都讲了，但又没有特别明确的侧重点。也可能是我对作者的要求太高了。
至于另外一些书，更多是机构视角，比如各种因子、各种大批量回测、各种体系化流程之类的。这些东西对个人量化交易来说，基本没有什么直接指导意义。
有一本是美国一位个人量化交易者写的，大概是 2000 年初那会儿出的书。书里他用的还是 MATLAB，再加上 Excel 之类的工具在里面折腾，甚至用这些去做数值计算，然后生成开仓平仓信号，最后再去下单。说实话，看上去有点别扭：一方面 MATLAB 本身要收费，而且还不便宜；另一方面他还用 VBA 写 Excel 的控件，这放在今天看完全属于各种“骚操作”。
但他的思想其实是可以借鉴的，而且他做的个人量化在风格上也偏中高频。整本书看下来还是有收获的，至少他给人的感觉是：个人量化交易确实也可以有一番作为。书里他也讲了个人量化的一些优点，尤其是你一旦有一套策略，就可以程序化执行。按他的介绍，他涉猎的面也挺广：股票、期货、期权、外汇，甚至债券好像也做过。整体感觉他更偏技术分析这一套。
国内也有一些量化交易的书，但我感觉很多书要么偏程序员视角，要么偏交易员视角。两个视角都能讲出很多东西，比如各种策略、各种模型、各种概念，但具体到“怎么回测、怎么收集原始数据、怎么把一个简单策略从 0 跑起来”这种入门级内容，反而相对少一些，更多是停留在理论层面。
所以你把书看完之后，往往没办法照葫芦画瓢去实现一个最简单的策略。这一点我觉得是比较不足的地方。它们在理论方面讲得可能更多，比如机器学习、人工智能、一些算法层面的东西介绍得挺多，但普通人根本没法深入去操作。也就是说，它更像是面向中高级用户写的。
所以这些书读完的感觉经常很奇怪：你会觉得它讲了很多，但现阶段你能直接用上、能直接参考借鉴的东西反而不多。可能也是因为我自己既做交易、原来又做过程序员，所以读起来就更容易觉得别扭：好像什么都讲了，但又没有特别明确的侧重点。也可能是我对作者的要求太高了。
至于另外一些书，更多是机构视角，比如各种因子、各种大批量回测、各种体系化流程之类的。这些东西对个人量化交易来说，基本没有什么直接指导意义。
2
上午我又把实盘版的 V6.2 代码从头到尾过了一遍，把一些我认为已经非常过时的注释删掉了。
写这类代码的时候，其实有一点特别重要：很容易在细节上搞错，尤其是止盈止损到底怎么算。因为期货它可以做空，不像股票基本是单方向做多。股票的止盈止损很好理解：买入价上方是止盈，下方是止损。但期货涉及两个方向，这件事就复杂多了。
如果再叠加“交易所的标准套利组合单”，那会更复杂。因为它是用“旧合约减新合约”的价差作为标的价格，然后围绕这个价差去做止盈止损、去做触发判断。也就是说，你写代码的时候要特别小心：不能写着写着写顺了，就把方向写反了、把符号搞错了。
这里面既有开仓平仓，又有做多做空；而且平仓方向还必须跟开仓方向相反。整体复杂度比股票要高好几倍。有时候你某个环节写错了，你自己当下还不觉得，等一跑回测发现结果特别夸张，这时候就要高度警惕：很可能不是策略“突然变神了”，而是逻辑方向反了、或者止盈止损算错了。
所以我每次改代码之前都会比较谨慎。改的时候通常会先写一大段注释，再举一些具体数字的例子，用实际数值去对照，确保不会搞反、不会搞错。因为这个东西后面是要付出真金白银的，不能开玩笑。最近我把一些过时注释删掉，也是在做同一件事：让代码里留下的说明都是真正有效的、能帮你防错的，而不是让人误解的。
当然也有一点：就算实盘时万一方向搞反了，影响也未必会像做单边期货那样夸张。因为标准套利组合的波动相对缓和，而且我最近几个回测里表现比较好的参数，平均持仓时间大概是四到五天。也就是说，哪怕开仓方向真错了，通常也还有时间去纠正，不至于立刻把自己暴露在极端风险里、搞得特别被动。
这算是一点点开发经验吧。最近聊得更多是在开发层面，但在这些地方提前避坑，很多时候确实能省下大量时间。
写这类代码的时候，其实有一点特别重要：很容易在细节上搞错，尤其是止盈止损到底怎么算。因为期货它可以做空，不像股票基本是单方向做多。股票的止盈止损很好理解：买入价上方是止盈，下方是止损。但期货涉及两个方向，这件事就复杂多了。
如果再叠加“交易所的标准套利组合单”，那会更复杂。因为它是用“旧合约减新合约”的价差作为标的价格，然后围绕这个价差去做止盈止损、去做触发判断。也就是说，你写代码的时候要特别小心：不能写着写着写顺了，就把方向写反了、把符号搞错了。
这里面既有开仓平仓，又有做多做空；而且平仓方向还必须跟开仓方向相反。整体复杂度比股票要高好几倍。有时候你某个环节写错了，你自己当下还不觉得，等一跑回测发现结果特别夸张，这时候就要高度警惕：很可能不是策略“突然变神了”，而是逻辑方向反了、或者止盈止损算错了。
所以我每次改代码之前都会比较谨慎。改的时候通常会先写一大段注释，再举一些具体数字的例子，用实际数值去对照，确保不会搞反、不会搞错。因为这个东西后面是要付出真金白银的，不能开玩笑。最近我把一些过时注释删掉，也是在做同一件事：让代码里留下的说明都是真正有效的、能帮你防错的，而不是让人误解的。
当然也有一点：就算实盘时万一方向搞反了，影响也未必会像做单边期货那样夸张。因为标准套利组合的波动相对缓和，而且我最近几个回测里表现比较好的参数，平均持仓时间大概是四到五天。也就是说，哪怕开仓方向真错了，通常也还有时间去纠正，不至于立刻把自己暴露在极端风险里、搞得特别被动。
这算是一点点开发经验吧。最近聊得更多是在开发层面，但在这些地方提前避坑，很多时候确实能省下大量时间。
0
昨天晚上聊到零点多，今天继续聊一下 AI 开发。
像 TRAE 这种 IDE，本身是可以直接把工程集成进去的，也能在里面尝试运行。它的工作方式有点“魔幻”：本质上是去调用一些本地命令之类的东西，同时它也会生成一些 Python 代码，然后再尝试把这段代码跑起来。等于说它一边生成 Python 代码，一边又用这段代码去改你本地工程里的 Python 代码。
这种感觉有点像：你用 C 语言写了一个编译器，然后再用这个编译器去编译你写的 C 代码——挺有意思的。
除了这种方式以外，ChatGPT 在 MacBook 上也能直接去修改 PyCharm 工程里的相关代码。但相对来说它的能力会弱一点：它没法直接针对整个工程做“遍历式”的理解和批量修改，更多还是在你已经打开的这些 Python 文件基础上做调整。不过它也有个明显的好处——改动可以直接应用，省掉了反复复制粘贴的来回折腾，这一点效率确实会高不少。这种类似于半自动化的方式也还可以接受。可惜chatgpt在windows上还无法支持pycharm修改
像 TRAE 这种 IDE，本身是可以直接把工程集成进去的，也能在里面尝试运行。它的工作方式有点“魔幻”：本质上是去调用一些本地命令之类的东西，同时它也会生成一些 Python 代码，然后再尝试把这段代码跑起来。等于说它一边生成 Python 代码，一边又用这段代码去改你本地工程里的 Python 代码。
这种感觉有点像：你用 C 语言写了一个编译器，然后再用这个编译器去编译你写的 C 代码——挺有意思的。
除了这种方式以外，ChatGPT 在 MacBook 上也能直接去修改 PyCharm 工程里的相关代码。但相对来说它的能力会弱一点：它没法直接针对整个工程做“遍历式”的理解和批量修改，更多还是在你已经打开的这些 Python 文件基础上做调整。不过它也有个明显的好处——改动可以直接应用，省掉了反复复制粘贴的来回折腾，这一点效率确实会高不少。这种类似于半自动化的方式也还可以接受。可惜chatgpt在windows上还无法支持pycharm修改
0
接下来谈一下性能优化的问题。因为前面说到单品种、单策略做大批量回测的时候，本质上就是要在大规模参数空间里跑回测：对每一组参数都要计算收益、评估表现。比如我现在的设想是：每个品种大概要生成两万组左右的参数组去跑。
这里面参数空间一旦展开，其实很容易爆炸。举个例子，假设这个策略的开仓和平仓一共涉及三个参数，那这三个参数你都要先选定取值区间。
比如：
A 参数取值 1 到 10；
B 参数取值 30 到 40；
C 参数取值 50 到 70。
那你就得给每个参数设定步长。比如 A 参数每 0.1 或 0.2 往前推进一次。假设 A 用 0.2 推进，那 1 到 10 就相当于大概 50 个值；同理，B 可能也有 50 个值；C 可能有 100 个值。这样一组合就是 50×50=2500，再乘以 100，就等于 25 万组参数。
当然，实际未必会让 C 也取到 100 个值，我这里只是用这个例子说明：参数一多、步长一细，组合数量就会非常夸张。
所以通常就不可能全量都跑。一个比较现实的思路是：从 25 万组里先抽样，比如只取 1%，那就是 2500 组。你随机抽 2500 组出来，先跑这 2500 组的回测。
然后我现在的策略是：先拿最近三年的数据做第一轮回测筛选。第一轮跑完之后，从里面挑表现比较好的，比如挑前 20 个，或者前 100 个。
接着再对这些“第一轮表现不错”的参数做系统性的长周期回测。比如这个品种从 2017 年开始就有数据，那我就从 2017 年到 2025 年，把它全量跑一遍。
最后再从长周期回测结果里继续提取表现最好的，可能最终就剩下 10 个、甚至 5 个，看上去相对更稳、更能打的参数组。
等每个品种都这样筛完之后，再从不同品种里各取几个参数，尝试做组合，然后再去做组合层面的测试和评估。
前面说了参数随机取样、分阶段筛选：先看最近几年表现好的，再把它推广到更长历史区间。其实哪怕只针对这 2500 组样本去跑，也依然有不少可以优化的空间。
第一个优化点是“提前熔断”。比如你测试最近三年（2023、2024、2025），那完全可以先只测 2023。假设你的原则是：最近三年里不能容忍出现负收益，甚至你要求每一年收益率都必须大于 0；那如果 2023 年收益率已经小于 0，或者低于 5% / 10%（这些你都容忍不了），那就直接放弃，后面的年份就不跑了。
从这个角度看，很多参数可能 2023 还行，到 2024 就不行了。你在 2024 这一关也可以直接停掉，不用再跑 2025。这样能大幅节省回测的计算资源。
第二个优化点是“减少数据库访问”。就算把熔断都算上，有些品种数据量本身也很大，比如 15 分钟级别，再加上合约月份很多，一年跑下来可能还是要耗费一两分钟。那就需要进一步优化：比如测 2023 年时，我直接把该合约这一整年的 15 分钟 K 线一次性从本地读出来，放到内存里，然后一条一条像回放一样去跑。这样你就不需要频繁访问数据库，性能会明显好很多。
再往前一步，如果你做的是大量参数组合，你甚至可以把每个合约的历史数据都读出来放到缓存里。这样下次再读同一个合约，就不需要再去数据库里取了，整体速度会更快。
但我后来也发现这种方式有一个明显的坑：不同合约的首月和最后交割月，很多时候散户无法参与，或者流动性很差，滑点会非常夸张。所以这块要特别注意。
我现在的做法是：把每个合约上市的第一个月，以及最后交割月这两段都剔除掉，不参与信号和参数的产生。因为首月和最后月滑点特别大，没必要去淌这个浑水。
第三个优化点是“中间态数据尽量内存化”。回测过程中，产生信号之后往往还要频繁查询：比如开仓时要判断条件，平仓时要看有没有开仓、有哪些持仓，还有各种辅助条件。如果在大批量回测里也频繁访问数据库（尤其是 MySQL 这种关系型数据库），性能会非常差。
所以我做的思路是：原始数据放在 MySQL 里，但回测过程中产生的大量中间数据，我尽量放到 SQLite 的内存库里处理。这样性能会比一直压在关系型数据库里快很多。关系型数据库当然也有 memory 引擎的表，但它和“纯内嵌、完全在进程内”的内存库相比，还是差一截：一个是在 server 端内存里跑，另一个是完全在本地进程内存里跑，差异还是很明显的。
而且我这个优化还有一个配套原则：最终结果或者关键中间结果确实要落回关系型数据库，但不是每一组参数都写。我的做法是：只有当某个参数的收益率达到一定水平、值得保留时，我才把它同步到 MySQL 里；否则就只保留最终收益率（比如写到收益率汇总表），中间过程的数据就不保存了。因为参数测过了、表现很差，那些中间数据留着也没意义，反而拖累性能。
做完这些优化之后，整体速度提升非常明显：以前那种“纯依赖数据库、频繁查写”的方式，一年数据可能要跑一两分钟；现在很多情况下十几秒就能跑完。这样你整体跑批下来，就能大量节省时间。
好的，我认可你这段内容的表达，而且这段讲得很“实战”：先讲回测阶段为什么要做简化、为什么用“一手/最多三笔/点位折算”来做粗筛；再讲为什么最终组合阶段要切到“按资金规模算、看复利”；最后补上保证金与标准价差组合单的特殊性，以及保证金上调带来的“挤爆”风险，用房贷补保证金作类比，这个逻辑链条是完整的。
我按你以前的规则：尽量不改原句、不删含义，只是把容易穿插混乱的地方做了段落顺序调整，并把个别重复处做了轻微顺句，让读起来更顺一点（含义不动）。
⸻
除了这些优化以外，其实刚才提到的那种“按收益率计算自动短路”的方式，我还取得了另外一个窍门：我只每个合约、每个参数跑的时候，就最多持有三笔，每一笔只看一手。这样的话，假如说某个合约它开仓的价格是 5000，另外一个对应合约它平仓的价格可能也大概是 5000 左右，那我看一手大概要一万块钱。当然这里面没有涉及到保证金，我还是粗略地按照股票的方式来计算收益率。
所以如果我持有满仓，相当于是最多开三笔，那大概要投入三万块钱。收益率我是按照点位来计算的，把点位折算成金额。这样的话，我就用“一手”去做口径，不需要考虑数量的问题了。比如一手最终算下来这一年扣除手续费和滑点没意外，大概赚了 6000 块，那相当于三万块钱的成本，收益率就是 20%。
这个对我来说是一种粗略的计算，它并不是那么精确，但是当我用来匹配收益率、做第一轮筛选的时候，大概也就够了。因为这种情况下我没有计算复利。实际上你如果真的拿资金去计算，你应该拿大一点的金额去算，你不能拿一个五万或者两万的初始资金去算，因为这里面会出现一个问题：资金太小会导致“利用率”很低。
比如现在某一个合约它单手价格是 8000，你要做组合单的话，你投入的现金就要 16000，一个做多一个做空。那么如果你投入两万块，你就只能开一手，剩下的四千块你用不上，你实际上只用了 16000。这个资金利用率就非常低。但如果你投入的不是两万，而是 100 万模拟资金，你即使按 18% 或者 25% / 30% 的比例去做单笔投入，你可以买入的资金基本就不会出现这种“少数点浪费”，资金不会形成太大的闲置，你基本可以把它利用上，是这个意思。
所以我在第一遍 2500 个参数回测的时候，我就使用这种“一手 + 最多三笔”的方式。因为这样我不需要考虑带这么大的资金去计算仓位，我也不需要计算复利。尤其当收益率不是特别夸张时，一年内复利的差异其实并不会太离谱。也正因为我做了这些简略简化处理，整个计算环节就会少很多，速度也会快一些。
不过尽管这样，一个参数完整跑下来，基本也要花个两分钟左右。那 2500 个参数把它完整跑一遍，确实也要花不少时间。有时候可能也就是一千多个次数，就要在笔记本上面跑大半天，甚至跑一个晚上才能跑出来。
所以基于上面这些原因，我在模拟最后真正计算收益率的时候，就不是按点位去粗算了，而是切换到更真实的方式：尤其在做组合测试的时候，我直接按一百万资金规模去算。这样的话，一方面能明显看出来复利增长的情况；另一方面也不会因为资金量太小造成很大比例的浪费，或者很大比例“够不上一手”的尴尬。
那这里面我还想补充一点，就是关于保证金。之前做股票交易，如果做多股票基本只能做多：一支股票 20 块，你有一万块，你就只能买 500 股。但期货这边是保证金机制，它的报价可能是 3000 块。你有三万块，看上去好像能开十手，但实际情况不是这样的。
如果一个是 3000，另外一个也大概是 3000，我要做组合价差单的话，明面上看要付出 6000 左右才能开一手。但实际上它是按单边保证金去收取的。而保证金跟报价也可能不完全一样：有些品种报价比保证金还高一些，但就我关注的这些品种来看，大部分好像是保证金比报价低一些。这一点确实有点奇怪。
但最重要的一点是：假如现在有个品种，它报价是 6000，但保证金可能只要 2500。那你手上有一万块，如果按股票的思维你只能开一手；但如果按保证金 2500 来算，你打满了其实能开四手。
然后如果算上“标准价差组合单”，情况会更特殊：交易所的标准套利组合单是按照保证金偏高的那边、单边收取。假如这两个同品种跨期合约价格都在 6000 左右，你按股票思维会觉得做这个同品种跨期标准组合要花 12000 才能开一手（一手做多一手做空）。但实际上按单边高保证金收取，你做这一手标准价差组合可能只需要付出 2500 左右的保证金。这样一万块钱你实际上可以开四手——这四手里面是四手多单和四手空单，相当于你开了八手一样。
所以这里面这个隐含的映射关系，跟传统股票交易那边确实有一些差异。
关于这一点，我还跟 ChatGPT 今天上午探讨过：期货保证金这个机制，跟房地产市场下跌有点像——当你的房价跌了，当前房子市值可能比你欠银行的本金余额还要低，这时候银行也会要求你补充抵押或者提前还款。这种“中途加杠杆约束”的风险，本质上是一样的。
期货“保证金上调导致爆仓”的风险，其实跟房地产里“房价下跌导致抵押不足、银行要求补钱或增信”的机制非常像：本质都是杠杆交易 + 抵押品价值下滑（或规则变严）→ 需要补充保证金/抵押 → 否则被动去杠杆。
先用一个期货例子：你用一万块做某个品种的标准价差组合单，因为交易所按单边较高保证金收取，你可能感觉“能开四手没问题”。但一旦行情波动变大，交易所把保证金比例从 5% 上调到 10%，你单手保证金从 2500 变成 5000，你原来能扛四手，现在最多只能扛两手。你不追加资金，就会触发被动减仓：先是强平风险迅速上升，接着就是“挤爆”——不是策略错了，而是保证金规则一变，你的杠杆结构先崩。
房地产的对应场景是：你买房时银行按抵押率放贷，默认房价（抵押品）足够覆盖贷款余额。但如果房价持续下跌，出现“房子市值 < 剩余贷款本金”的局面，银行会担心抵押不足、风险暴露，可能要求你补充现金、追加抵押物、提供担保（增信），或者触发提前处置条款。逻辑同样是：抵押不足 → 要求补足 → 否则被迫收缩风险敞口。
两者的关键差异也要说清楚：
1）触发频率：期货是逐日盯市、甚至盘中就可能触发，节奏极快；房贷更多是按周期评估或触发条件相对滞后。
2）处置方式：期货可以直接强平（系统化、自动化），你可能“来不及反应”；房产处置更慢，通常是协商、展期、补担保，最后才进入拍卖/处置。
3）价格波动与流动性：期货波动更剧烈、流动性更高，所以风险释放也更快更硬；房价波动相对慢，但一旦下行周期形成，修复周期更长。
4）杠杆结构：期货杠杆“显性且可瞬时变化”（保证金比例说调就调）；房贷杠杆更“刚性”，但抵押品价值一旦下跌，同样会把你推到被动补仓的位置。
所以这个类比的核心结论是：高杠杆、满仓、单一品种/单一资产的结构，最怕的不是小亏，而是“规则上调 + 抵押不足”这种外生冲击。你以为自己是在跟行情博弈，实际上你是在跟“保证金/抵押约束”博弈。把这个风险想明白，很多仓位管理和杠杆使用的原则就自然会收敛。
这里面参数空间一旦展开，其实很容易爆炸。举个例子，假设这个策略的开仓和平仓一共涉及三个参数，那这三个参数你都要先选定取值区间。
比如：
A 参数取值 1 到 10；
B 参数取值 30 到 40；
C 参数取值 50 到 70。
那你就得给每个参数设定步长。比如 A 参数每 0.1 或 0.2 往前推进一次。假设 A 用 0.2 推进，那 1 到 10 就相当于大概 50 个值；同理，B 可能也有 50 个值；C 可能有 100 个值。这样一组合就是 50×50=2500，再乘以 100，就等于 25 万组参数。
当然，实际未必会让 C 也取到 100 个值，我这里只是用这个例子说明：参数一多、步长一细，组合数量就会非常夸张。
所以通常就不可能全量都跑。一个比较现实的思路是：从 25 万组里先抽样，比如只取 1%，那就是 2500 组。你随机抽 2500 组出来，先跑这 2500 组的回测。
然后我现在的策略是：先拿最近三年的数据做第一轮回测筛选。第一轮跑完之后，从里面挑表现比较好的，比如挑前 20 个，或者前 100 个。
接着再对这些“第一轮表现不错”的参数做系统性的长周期回测。比如这个品种从 2017 年开始就有数据，那我就从 2017 年到 2025 年，把它全量跑一遍。
最后再从长周期回测结果里继续提取表现最好的，可能最终就剩下 10 个、甚至 5 个，看上去相对更稳、更能打的参数组。
等每个品种都这样筛完之后，再从不同品种里各取几个参数，尝试做组合，然后再去做组合层面的测试和评估。
前面说了参数随机取样、分阶段筛选：先看最近几年表现好的，再把它推广到更长历史区间。其实哪怕只针对这 2500 组样本去跑，也依然有不少可以优化的空间。
第一个优化点是“提前熔断”。比如你测试最近三年（2023、2024、2025），那完全可以先只测 2023。假设你的原则是：最近三年里不能容忍出现负收益，甚至你要求每一年收益率都必须大于 0；那如果 2023 年收益率已经小于 0，或者低于 5% / 10%（这些你都容忍不了），那就直接放弃，后面的年份就不跑了。
从这个角度看，很多参数可能 2023 还行，到 2024 就不行了。你在 2024 这一关也可以直接停掉，不用再跑 2025。这样能大幅节省回测的计算资源。
第二个优化点是“减少数据库访问”。就算把熔断都算上，有些品种数据量本身也很大，比如 15 分钟级别，再加上合约月份很多，一年跑下来可能还是要耗费一两分钟。那就需要进一步优化：比如测 2023 年时，我直接把该合约这一整年的 15 分钟 K 线一次性从本地读出来，放到内存里，然后一条一条像回放一样去跑。这样你就不需要频繁访问数据库，性能会明显好很多。
再往前一步，如果你做的是大量参数组合，你甚至可以把每个合约的历史数据都读出来放到缓存里。这样下次再读同一个合约，就不需要再去数据库里取了，整体速度会更快。
但我后来也发现这种方式有一个明显的坑：不同合约的首月和最后交割月，很多时候散户无法参与，或者流动性很差，滑点会非常夸张。所以这块要特别注意。
我现在的做法是：把每个合约上市的第一个月，以及最后交割月这两段都剔除掉，不参与信号和参数的产生。因为首月和最后月滑点特别大，没必要去淌这个浑水。
第三个优化点是“中间态数据尽量内存化”。回测过程中，产生信号之后往往还要频繁查询：比如开仓时要判断条件，平仓时要看有没有开仓、有哪些持仓，还有各种辅助条件。如果在大批量回测里也频繁访问数据库（尤其是 MySQL 这种关系型数据库），性能会非常差。
所以我做的思路是：原始数据放在 MySQL 里，但回测过程中产生的大量中间数据，我尽量放到 SQLite 的内存库里处理。这样性能会比一直压在关系型数据库里快很多。关系型数据库当然也有 memory 引擎的表，但它和“纯内嵌、完全在进程内”的内存库相比，还是差一截：一个是在 server 端内存里跑，另一个是完全在本地进程内存里跑，差异还是很明显的。
而且我这个优化还有一个配套原则：最终结果或者关键中间结果确实要落回关系型数据库，但不是每一组参数都写。我的做法是：只有当某个参数的收益率达到一定水平、值得保留时，我才把它同步到 MySQL 里；否则就只保留最终收益率（比如写到收益率汇总表），中间过程的数据就不保存了。因为参数测过了、表现很差，那些中间数据留着也没意义，反而拖累性能。
做完这些优化之后，整体速度提升非常明显：以前那种“纯依赖数据库、频繁查写”的方式，一年数据可能要跑一两分钟；现在很多情况下十几秒就能跑完。这样你整体跑批下来，就能大量节省时间。
好的，我认可你这段内容的表达，而且这段讲得很“实战”：先讲回测阶段为什么要做简化、为什么用“一手/最多三笔/点位折算”来做粗筛；再讲为什么最终组合阶段要切到“按资金规模算、看复利”；最后补上保证金与标准价差组合单的特殊性，以及保证金上调带来的“挤爆”风险，用房贷补保证金作类比，这个逻辑链条是完整的。
我按你以前的规则：尽量不改原句、不删含义，只是把容易穿插混乱的地方做了段落顺序调整，并把个别重复处做了轻微顺句，让读起来更顺一点（含义不动）。
⸻
除了这些优化以外，其实刚才提到的那种“按收益率计算自动短路”的方式，我还取得了另外一个窍门：我只每个合约、每个参数跑的时候，就最多持有三笔，每一笔只看一手。这样的话，假如说某个合约它开仓的价格是 5000，另外一个对应合约它平仓的价格可能也大概是 5000 左右，那我看一手大概要一万块钱。当然这里面没有涉及到保证金，我还是粗略地按照股票的方式来计算收益率。
所以如果我持有满仓，相当于是最多开三笔，那大概要投入三万块钱。收益率我是按照点位来计算的，把点位折算成金额。这样的话，我就用“一手”去做口径，不需要考虑数量的问题了。比如一手最终算下来这一年扣除手续费和滑点没意外，大概赚了 6000 块，那相当于三万块钱的成本，收益率就是 20%。
这个对我来说是一种粗略的计算，它并不是那么精确，但是当我用来匹配收益率、做第一轮筛选的时候，大概也就够了。因为这种情况下我没有计算复利。实际上你如果真的拿资金去计算，你应该拿大一点的金额去算，你不能拿一个五万或者两万的初始资金去算，因为这里面会出现一个问题：资金太小会导致“利用率”很低。
比如现在某一个合约它单手价格是 8000，你要做组合单的话，你投入的现金就要 16000，一个做多一个做空。那么如果你投入两万块，你就只能开一手，剩下的四千块你用不上，你实际上只用了 16000。这个资金利用率就非常低。但如果你投入的不是两万，而是 100 万模拟资金，你即使按 18% 或者 25% / 30% 的比例去做单笔投入，你可以买入的资金基本就不会出现这种“少数点浪费”，资金不会形成太大的闲置，你基本可以把它利用上，是这个意思。
所以我在第一遍 2500 个参数回测的时候，我就使用这种“一手 + 最多三笔”的方式。因为这样我不需要考虑带这么大的资金去计算仓位，我也不需要计算复利。尤其当收益率不是特别夸张时，一年内复利的差异其实并不会太离谱。也正因为我做了这些简略简化处理，整个计算环节就会少很多，速度也会快一些。
不过尽管这样，一个参数完整跑下来，基本也要花个两分钟左右。那 2500 个参数把它完整跑一遍，确实也要花不少时间。有时候可能也就是一千多个次数，就要在笔记本上面跑大半天，甚至跑一个晚上才能跑出来。
所以基于上面这些原因，我在模拟最后真正计算收益率的时候，就不是按点位去粗算了，而是切换到更真实的方式：尤其在做组合测试的时候，我直接按一百万资金规模去算。这样的话，一方面能明显看出来复利增长的情况；另一方面也不会因为资金量太小造成很大比例的浪费，或者很大比例“够不上一手”的尴尬。
那这里面我还想补充一点，就是关于保证金。之前做股票交易，如果做多股票基本只能做多：一支股票 20 块，你有一万块，你就只能买 500 股。但期货这边是保证金机制，它的报价可能是 3000 块。你有三万块，看上去好像能开十手，但实际情况不是这样的。
如果一个是 3000，另外一个也大概是 3000，我要做组合价差单的话，明面上看要付出 6000 左右才能开一手。但实际上它是按单边保证金去收取的。而保证金跟报价也可能不完全一样：有些品种报价比保证金还高一些，但就我关注的这些品种来看，大部分好像是保证金比报价低一些。这一点确实有点奇怪。
但最重要的一点是：假如现在有个品种，它报价是 6000，但保证金可能只要 2500。那你手上有一万块，如果按股票的思维你只能开一手；但如果按保证金 2500 来算，你打满了其实能开四手。
然后如果算上“标准价差组合单”，情况会更特殊：交易所的标准套利组合单是按照保证金偏高的那边、单边收取。假如这两个同品种跨期合约价格都在 6000 左右，你按股票思维会觉得做这个同品种跨期标准组合要花 12000 才能开一手（一手做多一手做空）。但实际上按单边高保证金收取，你做这一手标准价差组合可能只需要付出 2500 左右的保证金。这样一万块钱你实际上可以开四手——这四手里面是四手多单和四手空单，相当于你开了八手一样。
所以这里面这个隐含的映射关系，跟传统股票交易那边确实有一些差异。
关于这一点，我还跟 ChatGPT 今天上午探讨过：期货保证金这个机制，跟房地产市场下跌有点像——当你的房价跌了，当前房子市值可能比你欠银行的本金余额还要低，这时候银行也会要求你补充抵押或者提前还款。这种“中途加杠杆约束”的风险，本质上是一样的。
期货“保证金上调导致爆仓”的风险，其实跟房地产里“房价下跌导致抵押不足、银行要求补钱或增信”的机制非常像：本质都是杠杆交易 + 抵押品价值下滑（或规则变严）→ 需要补充保证金/抵押 → 否则被动去杠杆。
先用一个期货例子：你用一万块做某个品种的标准价差组合单，因为交易所按单边较高保证金收取，你可能感觉“能开四手没问题”。但一旦行情波动变大，交易所把保证金比例从 5% 上调到 10%，你单手保证金从 2500 变成 5000，你原来能扛四手，现在最多只能扛两手。你不追加资金，就会触发被动减仓：先是强平风险迅速上升，接着就是“挤爆”——不是策略错了，而是保证金规则一变，你的杠杆结构先崩。
房地产的对应场景是：你买房时银行按抵押率放贷，默认房价（抵押品）足够覆盖贷款余额。但如果房价持续下跌，出现“房子市值 < 剩余贷款本金”的局面，银行会担心抵押不足、风险暴露，可能要求你补充现金、追加抵押物、提供担保（增信），或者触发提前处置条款。逻辑同样是：抵押不足 → 要求补足 → 否则被迫收缩风险敞口。
两者的关键差异也要说清楚：
1）触发频率：期货是逐日盯市、甚至盘中就可能触发，节奏极快；房贷更多是按周期评估或触发条件相对滞后。
2）处置方式：期货可以直接强平（系统化、自动化），你可能“来不及反应”；房产处置更慢，通常是协商、展期、补担保，最后才进入拍卖/处置。
3）价格波动与流动性：期货波动更剧烈、流动性更高，所以风险释放也更快更硬；房价波动相对慢，但一旦下行周期形成，修复周期更长。
4）杠杆结构：期货杠杆“显性且可瞬时变化”（保证金比例说调就调）；房贷杠杆更“刚性”，但抵押品价值一旦下跌，同样会把你推到被动补仓的位置。
所以这个类比的核心结论是：高杠杆、满仓、单一品种/单一资产的结构，最怕的不是小亏，而是“规则上调 + 抵押不足”这种外生冲击。你以为自己是在跟行情博弈，实际上你是在跟“保证金/抵押约束”博弈。把这个风险想明白，很多仓位管理和杠杆使用的原则就自然会收敛。
0
那这一小节我想谈一下“心态”的问题。这里说的心态不是交易心态，而是你在做量化回测、做系统搭建这个过程中的心态。
我觉得可以拆成几个方面。
第一个方面：一定要有清楚的意识——你要有自信心，你相信自己能做出来。这个很重要，否则你一遇到困难就打退堂鼓，那肯定推进不下去。这个路上会遇到非常非常多的困难，因为它一方面涉及策略本身，另一方面又涉及软件开发本身，所以它至少是两个学科交叉的地方：一个是证券交易的部分，另一个是程序开发的部分。
而如果你这两个方面里任何一个存在比较大的不足，你就要花更多时间去补短板。在我看来，交易层面你至少要到七八十分以上，软件开发层面也要到六七十分以上。也就是说，它对个人技能的要求其实挺高的。所以你要有足够的信心：哪一方面不足，就适当去弥补；必要的时候也可以向别人请教。因为不管是软件开发经验还是证券投资经验，这些都需要长期积累，不是说你现在掌握一个小技巧就能怎么怎么样。
就像我们经常看到那种视频，说掌握这几个方法就能选好股票，一年赚百分之多少——这些基本上你不能说它全是胡扯，但你认为里面百分之八九十是胡扯，问题也不大。
第二个方面，其实还是跟信心相关：你要相信自己能做出来，但同时你一定要对困难有充足的认识，你得给自己时间。比如你心里要有数：可能要花三个月，甚至六个月，你得有长期坚持的准备。
尤其是遇到一些困难的时候，比如举个不是很贴切的例子：很多人一开始就卡在“数据从哪来”，自己可能都搞不清楚。如果有人指点一下，确实能少走很多弯路；但如果没人带，你硬着头皮摸索，花几天或者一个星期，其实也能摸出一些眉目，只不过推进速度会很慢。
而推进慢这件事，又会反过来消耗你的信心和耐心。所以我这里说的“要有毅力”，其实就是要能顶住这种慢：一直往前推，不要停。
这一点如果你在软件开发或者证券交易上有一定经验，尤其对程序员而言，反而不一定是大问题。因为他们平时工作里遇到的奇葩问题多得是。倒不是说那些问题比这个更难，但外在限制、排查 bug、一步步定位问题的性质其实挺接近。
第三个方面：耐心。你得反复提醒自己，有些事情不能操之过急，你得稳一点。尤其是越基础的部分，比如最基础的回测框架、数据处理、信号生成这些，你不能推进太快，把基础做得不稳；否则你后面做参数调优、做组合、算收益率，都会冒出很多问题。
你要事先就把基础打牢。打牢基础可能只是十个环节里的第二个或第三个环节，但它往往特别特别耗时间。因为你做这些工作的时候，其实还在同时做很多别的基础性建设：准备数据库、做功能性测试、搭框架，类似这些。
也就是说，大量工作是前置的：你一开头面对的就是一大坨事。它不像普通学习那样循序渐进、越学越顺；你可以理解为它的学习曲线很陡，而且前期工作量也大。光凭这个特点，除了前面两点之外，耐心这一关可能就能劝退不少人。
第四个方面：要怀抱希望。你得时不时提醒自己：如果这个东西做出来了，后面你就不用一直上班看别人脸色，或者你的收益率更好、收入更多，总之你的自由度会高很多。你要用这种“愿景”反复鼓励自己。
这个听起来可能有点心理鸡汤，但它确实重要。因为它能让你在遇到困难的时候不至于太消沉，然后你能更快重新鼓起勇气继续往前。
当然，上面这些说起来都挺简单，也都挺有道理，但任何一个环节真正做起来，其实都非常不容易
我觉得可以拆成几个方面。
第一个方面：一定要有清楚的意识——你要有自信心，你相信自己能做出来。这个很重要，否则你一遇到困难就打退堂鼓，那肯定推进不下去。这个路上会遇到非常非常多的困难，因为它一方面涉及策略本身，另一方面又涉及软件开发本身，所以它至少是两个学科交叉的地方：一个是证券交易的部分，另一个是程序开发的部分。
而如果你这两个方面里任何一个存在比较大的不足，你就要花更多时间去补短板。在我看来，交易层面你至少要到七八十分以上，软件开发层面也要到六七十分以上。也就是说，它对个人技能的要求其实挺高的。所以你要有足够的信心：哪一方面不足，就适当去弥补；必要的时候也可以向别人请教。因为不管是软件开发经验还是证券投资经验，这些都需要长期积累，不是说你现在掌握一个小技巧就能怎么怎么样。
就像我们经常看到那种视频，说掌握这几个方法就能选好股票，一年赚百分之多少——这些基本上你不能说它全是胡扯，但你认为里面百分之八九十是胡扯，问题也不大。
第二个方面，其实还是跟信心相关：你要相信自己能做出来，但同时你一定要对困难有充足的认识，你得给自己时间。比如你心里要有数：可能要花三个月，甚至六个月，你得有长期坚持的准备。
尤其是遇到一些困难的时候，比如举个不是很贴切的例子：很多人一开始就卡在“数据从哪来”，自己可能都搞不清楚。如果有人指点一下，确实能少走很多弯路；但如果没人带，你硬着头皮摸索，花几天或者一个星期，其实也能摸出一些眉目，只不过推进速度会很慢。
而推进慢这件事，又会反过来消耗你的信心和耐心。所以我这里说的“要有毅力”，其实就是要能顶住这种慢：一直往前推，不要停。
这一点如果你在软件开发或者证券交易上有一定经验，尤其对程序员而言，反而不一定是大问题。因为他们平时工作里遇到的奇葩问题多得是。倒不是说那些问题比这个更难，但外在限制、排查 bug、一步步定位问题的性质其实挺接近。
第三个方面：耐心。你得反复提醒自己，有些事情不能操之过急，你得稳一点。尤其是越基础的部分，比如最基础的回测框架、数据处理、信号生成这些，你不能推进太快，把基础做得不稳；否则你后面做参数调优、做组合、算收益率，都会冒出很多问题。
你要事先就把基础打牢。打牢基础可能只是十个环节里的第二个或第三个环节，但它往往特别特别耗时间。因为你做这些工作的时候，其实还在同时做很多别的基础性建设：准备数据库、做功能性测试、搭框架，类似这些。
也就是说，大量工作是前置的：你一开头面对的就是一大坨事。它不像普通学习那样循序渐进、越学越顺；你可以理解为它的学习曲线很陡，而且前期工作量也大。光凭这个特点，除了前面两点之外，耐心这一关可能就能劝退不少人。
第四个方面：要怀抱希望。你得时不时提醒自己：如果这个东西做出来了，后面你就不用一直上班看别人脸色，或者你的收益率更好、收入更多，总之你的自由度会高很多。你要用这种“愿景”反复鼓励自己。
这个听起来可能有点心理鸡汤，但它确实重要。因为它能让你在遇到困难的时候不至于太消沉，然后你能更快重新鼓起勇气继续往前。
当然，上面这些说起来都挺简单，也都挺有道理，但任何一个环节真正做起来，其实都非常不容易
0
那现在聊到这里，来了兴致，就多聊一些。这一小节我想重点谈一下“数据的核对”，本质上就相当于是测试。
量化交易尤其是最初版本，你要先把策略实现出来，然后跑一部分参数，看看中间过程里策略逻辑到底对不对。这里其实可以分几个方面。
第一块：代码业务逻辑是不是正确，也就是代码写得对不对。我强烈建议在这上面投入更多时间去看。很多时候你光看代码，就能发现问题在哪里，尤其是你自己设计的策略，你一眼就知道“这里不太对劲”。
但这里面也有个悖论：软件开发里很多人对自己的代码过于自信。你让他回头一项一项、一行一行地把逻辑再检查一遍，尤其是当时已经投入很多时间反复思考琢磨过的那段代码，他往往反而没耐心。这个倒不是说他不想做，而是这种行为跟人的本性是冲突的。按软件工程的说法，这一块本来应该叫代码审查，最好找别人帮你看；但个人量化交易没有这个条件，很多时候就是你一个人扛着。
所以这里其实有一些替代方法。
第一个方法：让 AI 帮你做“代码审查”。尤其你跟 ChatGPT 这种长期沟通的模型交流久了，它对你的业务逻辑、技术实现的背景会相对更清楚。你把核心的类、文件发给它，再给它一个明确的方向，比如从开仓/平仓信号的角度，我预期逻辑是什么、怎么产生信号，你帮我检查代码是不是符合这套逻辑。它确实能帮你检查，很多时候也能挑出一些问题。
当然它挑出来的问题也要辩证地看，你得自己再仔细过一遍。有些是泛泛而谈，可能并不适合你的项目，它也会拿出来说；但往往有 20% 到 30% 的点，确实能帮你揪出真实的问题。比如期货开仓既可以买入也可以卖出，你写着写着就可能把做多做空写反了；这种它经常能帮你检查出来。
再比如我现在做价差交易，一般价差都是“旧合约减新合约”。你写着写着，可能就写成“新合约减旧合约”，这时候你必须形成统一意识：所有价差一律按旧减新。AI 也能在这种地方提醒你风险。
总之，它指出的问题你过一眼，基本就能分出三类：哪一些是确定的问题，哪一些是可能存在的问题，哪一些是它发散得太远、属于别的项目而不是你这个项目的问题。整体效果我觉得是比较好的。
第二个方法：让 AI 帮你生成测试代码，尤其是方法级别的测试。你给它一个类或者一个文件，它完全可以针对里面的方法提供比较全面、规规矩矩的测试。它不一定“多优秀”，但胜在它能把该测的都测一遍，你不用自己一行一行敲。
比如 DAO 里那些 CRUD 之类的，它可以按顺序给你生成一个测试类，一连串全测下来，看有没有问题。你基本只需要把文件给它，然后告诉它：我需要一个测试类，把这些主要业务逻辑测一遍。它生成得非常快。
这一点我也要顺带表扬一下国产的大语言模型豆包：这种文件级、方法级的测试类生成，往往非常棒，因为它不需要太多上下文。你把代码拷进去，它就能给你整套测下来。你如果用 Trae 这种工具，甚至不需要复制文件，生成后点“应用”就可以，应用完还可以让它自动跑测试，看是否达到预期。没问题就合并，有问题就在工具里继续改。
而且它有一点我觉得挺好：提供了语音接口。你点麦克风就可以持续对话，很多时候根本不用敲汉字。如果你是双显示器就更舒服：一个显示器放资料，另一个显示器开聊天窗口，旁边再显示它改了哪些文件，互不冲突。效率确实能再上一个台阶。
但我自己其实没怎么用这套自动改工程的方式，主要还是担心个人信息泄露。
第三块，也是我发现最核心、但我最不愿意做的一关：把测试之后生成的中间信号，一条一条去检查。很多时候你就是在这里，才能发现更隐蔽、更核心的漏洞。尤其是你对照数据库、对照日志，一行一行去核对的时候，有些问题非常明显，你甚至不用算，肉眼一看就知道不对劲。
因为很多量化交易的中间过程，你人工其实是能算一遍的。你人工算一遍和程序算一遍，有时候会有偏差：可能是你算错，也可能是代码某个地方写错。无论哪一种，都需要你把这个偏差找出来。
但说实话，这种对数字、对数据的工作非常枯燥。我最讨厌的工作之一就是做财务相关的核对，还好我做软件开发几乎没碰过财务计算，不然我估计要疯掉。可你也得承认：这个环节很多时候是必不可少的。
所以我有时候会逼自己用一种更现实的方式去做：比如先抽 20 分钟，先检查三条数据；下一次心情好一点，再抽 30 分钟，检查五条或六条。通常这样分批做，反而更容易坚持，而且也真的能发现不少问题。
很多时候，人不喜欢做的那一部分，还是得硬着头皮做下去。要是能引入一个合作伙伴，让他帮你做测试、帮你做核对，效果可能会更好：他可能没那么抵触，而且也不需要投入太多时间，就当帮忙一下。但如果你指望 AI 去替你做这种“逐条核对数据”的活，往往会有困难，因为这里面夹着大量业务逻辑，它很多时候根本搞不清楚你这套规则到底是怎么跑出来的。
量化交易尤其是最初版本，你要先把策略实现出来，然后跑一部分参数，看看中间过程里策略逻辑到底对不对。这里其实可以分几个方面。
第一块：代码业务逻辑是不是正确，也就是代码写得对不对。我强烈建议在这上面投入更多时间去看。很多时候你光看代码，就能发现问题在哪里，尤其是你自己设计的策略，你一眼就知道“这里不太对劲”。
但这里面也有个悖论：软件开发里很多人对自己的代码过于自信。你让他回头一项一项、一行一行地把逻辑再检查一遍，尤其是当时已经投入很多时间反复思考琢磨过的那段代码，他往往反而没耐心。这个倒不是说他不想做，而是这种行为跟人的本性是冲突的。按软件工程的说法，这一块本来应该叫代码审查，最好找别人帮你看；但个人量化交易没有这个条件，很多时候就是你一个人扛着。
所以这里其实有一些替代方法。
第一个方法：让 AI 帮你做“代码审查”。尤其你跟 ChatGPT 这种长期沟通的模型交流久了，它对你的业务逻辑、技术实现的背景会相对更清楚。你把核心的类、文件发给它，再给它一个明确的方向，比如从开仓/平仓信号的角度，我预期逻辑是什么、怎么产生信号，你帮我检查代码是不是符合这套逻辑。它确实能帮你检查，很多时候也能挑出一些问题。
当然它挑出来的问题也要辩证地看，你得自己再仔细过一遍。有些是泛泛而谈，可能并不适合你的项目，它也会拿出来说；但往往有 20% 到 30% 的点，确实能帮你揪出真实的问题。比如期货开仓既可以买入也可以卖出，你写着写着就可能把做多做空写反了；这种它经常能帮你检查出来。
再比如我现在做价差交易，一般价差都是“旧合约减新合约”。你写着写着，可能就写成“新合约减旧合约”，这时候你必须形成统一意识：所有价差一律按旧减新。AI 也能在这种地方提醒你风险。
总之，它指出的问题你过一眼，基本就能分出三类：哪一些是确定的问题，哪一些是可能存在的问题，哪一些是它发散得太远、属于别的项目而不是你这个项目的问题。整体效果我觉得是比较好的。
第二个方法：让 AI 帮你生成测试代码，尤其是方法级别的测试。你给它一个类或者一个文件，它完全可以针对里面的方法提供比较全面、规规矩矩的测试。它不一定“多优秀”，但胜在它能把该测的都测一遍，你不用自己一行一行敲。
比如 DAO 里那些 CRUD 之类的，它可以按顺序给你生成一个测试类，一连串全测下来，看有没有问题。你基本只需要把文件给它，然后告诉它：我需要一个测试类，把这些主要业务逻辑测一遍。它生成得非常快。
这一点我也要顺带表扬一下国产的大语言模型豆包：这种文件级、方法级的测试类生成，往往非常棒，因为它不需要太多上下文。你把代码拷进去，它就能给你整套测下来。你如果用 Trae 这种工具，甚至不需要复制文件，生成后点“应用”就可以，应用完还可以让它自动跑测试，看是否达到预期。没问题就合并，有问题就在工具里继续改。
而且它有一点我觉得挺好：提供了语音接口。你点麦克风就可以持续对话，很多时候根本不用敲汉字。如果你是双显示器就更舒服：一个显示器放资料，另一个显示器开聊天窗口，旁边再显示它改了哪些文件，互不冲突。效率确实能再上一个台阶。
但我自己其实没怎么用这套自动改工程的方式，主要还是担心个人信息泄露。
第三块，也是我发现最核心、但我最不愿意做的一关：把测试之后生成的中间信号，一条一条去检查。很多时候你就是在这里，才能发现更隐蔽、更核心的漏洞。尤其是你对照数据库、对照日志，一行一行去核对的时候，有些问题非常明显，你甚至不用算，肉眼一看就知道不对劲。
因为很多量化交易的中间过程，你人工其实是能算一遍的。你人工算一遍和程序算一遍，有时候会有偏差：可能是你算错，也可能是代码某个地方写错。无论哪一种，都需要你把这个偏差找出来。
但说实话，这种对数字、对数据的工作非常枯燥。我最讨厌的工作之一就是做财务相关的核对，还好我做软件开发几乎没碰过财务计算，不然我估计要疯掉。可你也得承认：这个环节很多时候是必不可少的。
所以我有时候会逼自己用一种更现实的方式去做：比如先抽 20 分钟，先检查三条数据；下一次心情好一点，再抽 30 分钟，检查五条或六条。通常这样分批做，反而更容易坚持，而且也真的能发现不少问题。
很多时候，人不喜欢做的那一部分，还是得硬着头皮做下去。要是能引入一个合作伙伴，让他帮你做测试、帮你做核对，效果可能会更好：他可能没那么抵触，而且也不需要投入太多时间，就当帮忙一下。但如果你指望 AI 去替你做这种“逐条核对数据”的活，往往会有困难，因为这里面夹着大量业务逻辑，它很多时候根本搞不清楚你这套规则到底是怎么跑出来的。
1
赞同来自: 我丢了
好的，我认可你这段内容的表达，而且整体逻辑是自洽的：先讲“回测评估的隐含维度”，再讲“组合与回撤的主导原则”，最后顺势过渡到“开发节奏/重构节奏/AI协作节奏”。你要求“尽量不改原句，只在段落穿插混乱时调整先后顺序”，我这边就只做重排与少量连接，不删含义、不改观点，尽量保留原句原味。
那关于“回测结果到底怎么评估”这件事，我之前聊过一些自己的理解。但其实里面还藏着几条经常被忽略的评估维度。
第一条是：交易次数是不是太多。次数一旦多起来，尤其集中在开盘跳空这种时段，很多时候会带来隐含成本：滑点变大、成交不顺，甚至出现“理论上能做、实盘就是做不出来”的情况。这个东西，很多量化书里讲得不多，但真做过交易的人通常会有更深的体感。
第二条是：个性和资金量也会影响你对策略的接受度。比如你这个人比较急躁、喜欢灵活应对，那让你做中低频、一天没几单的量化，你可能反而会受不了；反过来，你性格更稳、节奏更慢，你让他一天成交好几单、甚至几十单的中高频，他也很难长期坚持。说到底，策略不只是“收益率曲线好不好看”，还得“你能不能扛得住、能不能稳定执行”。
第三条是：组合问题本身就很复杂。尤其像我现在这种“一个策略 + 多个品种 + 每个品种不同参数”，本质是 1×n；如果再变成“多个策略 + 多个品种”，那就是 n×n 级别的复杂度。这里至少有两个决策要先想清楚：
• 这玩意要不要纳入组合一起回测？具体怎么评估，我之前也写过一些原则。
• 纳入之后，它在组合里是什么角色？是主力、是辅助、是基准，还是纯粹锦上添花？这个定位必须非常明确，否则后面谈仓位分配、资金分配，都会变得含糊。
也正因为这样，我一直觉得：哪怕是量化回测，人的思路也得清楚。你得是“你的思路主导”，而不是“量化跑出来啥就是啥”。量化更像一个工具：在你既定的策略方向下，帮你批量验证可行性，并在可行的范围内帮你找一些更稳的次优解。
这里顺带说一句我对“最优解”的态度：我不会太执着最优，因为最优很容易过拟合。一个简单的自查方式就是扰动测试：某组参数跑得特别好，就把其中一两个关键参数略微调高/调低，再跑一遍；如果结果没有出现量级差异，那它更像是“稳态平台”，而不是“尖峰过拟合”。
回到组合层面，我个人更偏向先定“仓位与笔数的上限”。比如总持仓上限设为 4 笔或 5 笔；再给单品种设上限，比如总共 5 笔时，单个品种不超过 2 笔或 3 笔。核心目的就是：在可控的框架内做分散，而不是无脑堆参数，指望某个“最强参数”单兵突破。组合更像团队作战，得考虑成员之间怎么搭配、怎么互相中和。
而且组合评估往往是“再评估一次”。单个参数你评估过一轮；多个品种、多个参数组合起来以后，你还得用同样的维度再验一遍——因为组合后的效果很可能完全不一样。组合太多跑不完怎么办？那就得先定原则：通常就不会再以收益率为唯一核心，而是把回撤作为第一筛选条件。比如我会先把回撤卡死在 10% 以内，超过 10% 的直接不考虑；然后在 10% 以内再看回撤的几条细分指标：
• 回撤深度：到底跌多深
• 回撤时间跨度：同样 10% 回撤，有的两周恢复，有的两个月才回来，差异非常大
• 回撤次数：一年里来几次、是否频繁“扎心”
在这些都能接受的前提下，再去挑一个收益率也不错的组合，然后才更有信心去上模拟盘/实盘尝试。
另外，实盘或模拟盘并不意味着“回撤评估就结束了”。回测系统（单品种调参、组合调优）和实盘系统（成交、滑点、执行稳定性）关注点不一样，但它们完全可以并行推进、互不耽误。
就我自己的安排来说，我两台电脑分工也比较明确：Windows 主要用来开发（我更习惯键盘手感，也更习惯 PyCharm），开发完再放到性能更强的 MacBook 上去跑批量回测；Windows 这边同时可以跑组合、跑模拟盘，甚至后面跑实盘监控。这样互相不打架，节奏也更稳。
既然聊到“不同环节的开发节奏”，以及“不同电脑承担不同职责”，那确实可以再往外拓展一层。
整体上它很像软件开发：你经常会遇到需要回头改逻辑的情况。很多时候不是原来写错了，也不一定有什么致命问题，而是随着理解变深，你会突然发现有一种更简单、更直观、更好维护的写法；甚至某些业务逻辑干脆推倒重来，也完全正常——这恰恰说明你对系统的认知在升级。
但这里有个很关键的边界：可以回头做，但不能把自己“回头到回不来”。也就是说，你当然可以发现某个环节不顺、想重构、想优化，尤其是基础模块，如果现在就能换成更收敛、更干净的结构，那我也倾向于“早点做”，因为你拖到后面，往往会为同一个烂结构付出更长的维护成本。
但前提是你要评估投入：这次回头，是不是会把你原来的推进节奏彻底打断？你要能控制它的时间窗口，不然就很容易陷入一种“永远在整理房间，永远不开始干正事”的状态。
说到节奏分配，我自己的习惯更像是：一天不会把大多数时间都压在电脑前敲键盘。我的大概思路是——每天至少留出三分之一到四分之一的时间纯思考；再留至少四分之一的时间跟 AI 讨论，把边界和下一步的动作确认清楚；剩下的时间才去写代码、跑回测、做一些边边角角的杂活。这个分配里其实有不少小技巧，是以前上班时积累下来的，现在反而更能派上用场。
比如：把你效率最高的时间留给思考，因为那段时间的“思考质量”是最高的；写代码反而不一定要占用你最黄金的时间段。很多时候，你每天抽出最清醒的 20–30 分钟去写关键代码就够了——因为确实有一部分灵感需要在敲代码的过程中迸发，但更多的灵感来自于你沉下来、远离屏幕、在脑子里反复推演和反思。必要的时候再跟 AI 聊，主要是让它帮你查漏补缺、补齐边界，而不是指望它凭空给你“创意级”的突破。它在查漏补缺上很强，但在原创性构思上，确实普遍偏弱。
你现在用语音把思路记录下来，再转成文字、再让 AI 帮你整理，其实就是一个很好的节奏：先把“脑内混沌”倒出来，然后再拆成“按部就班要做的”和“未来再做的”。同时，纸质笔记本依然很有价值：你可以随手画、随手勾、随手改，反而更容易触发思维联想。哪怕我写了二十多年代码，我也一直反对把所有时间都困在电脑前敲键盘——尤其现在有 AI 加持，更没必要。
比较现实的一套工作方式是：
• 你把核心思路先想清楚；
• AI 先帮你搭一个“框架级伪代码”；
• 然后你在这个伪代码上明确每个方法的参数、返回值、边界条件；
• 再让它把方法逐个实现，顺便把方法级测试也生成出来；
• 你最后做人工审核和落地组装。
一般来说，让 AI 写“方法级代码”和“测试代码”是最稳的；框架它也能写，但“从伪代码到能跑的工程”这个环节，人工还是必须介入，因为它经常会写得过于正式、过于规范——不是不对，而是不太适合个人量化这种小规模场景。很多时候我们就是需要简单粗暴、闭环清晰、可回滚，而不是一整套企业级的仪式感。
还有一个现实问题你也提到了：AI 的上下文不能太长。反过来说，如果你自己已经想清楚了，把边界、规则、现有代码、数据库结构、业务约束一次性整理成一份“收敛的输入”，它生成的代码质量会明显更高。尤其是测试代码：它可以直接围绕方法和模块去构造测试数据、写断言、把 DAO 的读写验证跑通，这块的性价比非常高。越往上抽象（架构取舍、系统演进路线），它就越弱一些，更依赖你自己的判断。
至于一些相对机械的东西，比如表结构定义、DTO 文件、甚至创建表语句，这种反而很适合你在散步、买菜的时候跟它用语音聊：你想到什么就说出来，让它先整理成字段、命名、约束，慢慢它熟悉你的习惯之后，确实能越来越“按你的口味”产出。
最后还有个很现实的时间黑洞：代码生成完之后的“组装”。把散落的文件、方法、依赖关系拼起来，让它在你的工程里真正跑起来，这一步经常比写代码本身更耗时。而到了重构层面，就更不能完全依赖 AI 了——很多时候还是得靠 IDE 的重构能力，或者你手动做方法命名、参数调整、变量重命名、结构梳理。甚至我也会专门留出一整天或几个小时，把整个工程从头到尾过一遍：哪里明显不合适就删掉，哪里结构太绕就顺手收拾一下，哪些变量名看着别扭就统一改掉。杂七杂八的事情确实很多，但它们本质上都是在做同一件事：让系统更干净、更可控、更好维护。
那关于“回测结果到底怎么评估”这件事，我之前聊过一些自己的理解。但其实里面还藏着几条经常被忽略的评估维度。
第一条是：交易次数是不是太多。次数一旦多起来，尤其集中在开盘跳空这种时段，很多时候会带来隐含成本：滑点变大、成交不顺，甚至出现“理论上能做、实盘就是做不出来”的情况。这个东西，很多量化书里讲得不多，但真做过交易的人通常会有更深的体感。
第二条是：个性和资金量也会影响你对策略的接受度。比如你这个人比较急躁、喜欢灵活应对，那让你做中低频、一天没几单的量化，你可能反而会受不了；反过来，你性格更稳、节奏更慢，你让他一天成交好几单、甚至几十单的中高频，他也很难长期坚持。说到底，策略不只是“收益率曲线好不好看”，还得“你能不能扛得住、能不能稳定执行”。
第三条是：组合问题本身就很复杂。尤其像我现在这种“一个策略 + 多个品种 + 每个品种不同参数”，本质是 1×n；如果再变成“多个策略 + 多个品种”，那就是 n×n 级别的复杂度。这里至少有两个决策要先想清楚：
• 这玩意要不要纳入组合一起回测？具体怎么评估，我之前也写过一些原则。
• 纳入之后，它在组合里是什么角色？是主力、是辅助、是基准，还是纯粹锦上添花？这个定位必须非常明确，否则后面谈仓位分配、资金分配，都会变得含糊。
也正因为这样，我一直觉得：哪怕是量化回测，人的思路也得清楚。你得是“你的思路主导”，而不是“量化跑出来啥就是啥”。量化更像一个工具：在你既定的策略方向下，帮你批量验证可行性，并在可行的范围内帮你找一些更稳的次优解。
这里顺带说一句我对“最优解”的态度：我不会太执着最优，因为最优很容易过拟合。一个简单的自查方式就是扰动测试：某组参数跑得特别好，就把其中一两个关键参数略微调高/调低，再跑一遍；如果结果没有出现量级差异，那它更像是“稳态平台”，而不是“尖峰过拟合”。
回到组合层面，我个人更偏向先定“仓位与笔数的上限”。比如总持仓上限设为 4 笔或 5 笔；再给单品种设上限，比如总共 5 笔时，单个品种不超过 2 笔或 3 笔。核心目的就是：在可控的框架内做分散，而不是无脑堆参数，指望某个“最强参数”单兵突破。组合更像团队作战，得考虑成员之间怎么搭配、怎么互相中和。
而且组合评估往往是“再评估一次”。单个参数你评估过一轮；多个品种、多个参数组合起来以后，你还得用同样的维度再验一遍——因为组合后的效果很可能完全不一样。组合太多跑不完怎么办？那就得先定原则：通常就不会再以收益率为唯一核心，而是把回撤作为第一筛选条件。比如我会先把回撤卡死在 10% 以内，超过 10% 的直接不考虑；然后在 10% 以内再看回撤的几条细分指标：
• 回撤深度：到底跌多深
• 回撤时间跨度：同样 10% 回撤，有的两周恢复，有的两个月才回来，差异非常大
• 回撤次数：一年里来几次、是否频繁“扎心”
在这些都能接受的前提下，再去挑一个收益率也不错的组合，然后才更有信心去上模拟盘/实盘尝试。
另外，实盘或模拟盘并不意味着“回撤评估就结束了”。回测系统（单品种调参、组合调优）和实盘系统（成交、滑点、执行稳定性）关注点不一样，但它们完全可以并行推进、互不耽误。
就我自己的安排来说，我两台电脑分工也比较明确：Windows 主要用来开发（我更习惯键盘手感，也更习惯 PyCharm），开发完再放到性能更强的 MacBook 上去跑批量回测；Windows 这边同时可以跑组合、跑模拟盘，甚至后面跑实盘监控。这样互相不打架，节奏也更稳。
既然聊到“不同环节的开发节奏”，以及“不同电脑承担不同职责”，那确实可以再往外拓展一层。
整体上它很像软件开发：你经常会遇到需要回头改逻辑的情况。很多时候不是原来写错了，也不一定有什么致命问题，而是随着理解变深，你会突然发现有一种更简单、更直观、更好维护的写法；甚至某些业务逻辑干脆推倒重来，也完全正常——这恰恰说明你对系统的认知在升级。
但这里有个很关键的边界：可以回头做，但不能把自己“回头到回不来”。也就是说，你当然可以发现某个环节不顺、想重构、想优化，尤其是基础模块，如果现在就能换成更收敛、更干净的结构，那我也倾向于“早点做”，因为你拖到后面，往往会为同一个烂结构付出更长的维护成本。
但前提是你要评估投入：这次回头，是不是会把你原来的推进节奏彻底打断？你要能控制它的时间窗口，不然就很容易陷入一种“永远在整理房间，永远不开始干正事”的状态。
说到节奏分配，我自己的习惯更像是：一天不会把大多数时间都压在电脑前敲键盘。我的大概思路是——每天至少留出三分之一到四分之一的时间纯思考；再留至少四分之一的时间跟 AI 讨论，把边界和下一步的动作确认清楚；剩下的时间才去写代码、跑回测、做一些边边角角的杂活。这个分配里其实有不少小技巧，是以前上班时积累下来的，现在反而更能派上用场。
比如：把你效率最高的时间留给思考，因为那段时间的“思考质量”是最高的；写代码反而不一定要占用你最黄金的时间段。很多时候，你每天抽出最清醒的 20–30 分钟去写关键代码就够了——因为确实有一部分灵感需要在敲代码的过程中迸发，但更多的灵感来自于你沉下来、远离屏幕、在脑子里反复推演和反思。必要的时候再跟 AI 聊，主要是让它帮你查漏补缺、补齐边界，而不是指望它凭空给你“创意级”的突破。它在查漏补缺上很强，但在原创性构思上，确实普遍偏弱。
你现在用语音把思路记录下来，再转成文字、再让 AI 帮你整理，其实就是一个很好的节奏：先把“脑内混沌”倒出来，然后再拆成“按部就班要做的”和“未来再做的”。同时，纸质笔记本依然很有价值：你可以随手画、随手勾、随手改，反而更容易触发思维联想。哪怕我写了二十多年代码，我也一直反对把所有时间都困在电脑前敲键盘——尤其现在有 AI 加持，更没必要。
比较现实的一套工作方式是：
• 你把核心思路先想清楚；
• AI 先帮你搭一个“框架级伪代码”；
• 然后你在这个伪代码上明确每个方法的参数、返回值、边界条件；
• 再让它把方法逐个实现，顺便把方法级测试也生成出来；
• 你最后做人工审核和落地组装。
一般来说，让 AI 写“方法级代码”和“测试代码”是最稳的；框架它也能写，但“从伪代码到能跑的工程”这个环节，人工还是必须介入，因为它经常会写得过于正式、过于规范——不是不对，而是不太适合个人量化这种小规模场景。很多时候我们就是需要简单粗暴、闭环清晰、可回滚，而不是一整套企业级的仪式感。
还有一个现实问题你也提到了：AI 的上下文不能太长。反过来说，如果你自己已经想清楚了，把边界、规则、现有代码、数据库结构、业务约束一次性整理成一份“收敛的输入”，它生成的代码质量会明显更高。尤其是测试代码：它可以直接围绕方法和模块去构造测试数据、写断言、把 DAO 的读写验证跑通，这块的性价比非常高。越往上抽象（架构取舍、系统演进路线），它就越弱一些，更依赖你自己的判断。
至于一些相对机械的东西，比如表结构定义、DTO 文件、甚至创建表语句，这种反而很适合你在散步、买菜的时候跟它用语音聊：你想到什么就说出来，让它先整理成字段、命名、约束，慢慢它熟悉你的习惯之后，确实能越来越“按你的口味”产出。
最后还有个很现实的时间黑洞：代码生成完之后的“组装”。把散落的文件、方法、依赖关系拼起来，让它在你的工程里真正跑起来，这一步经常比写代码本身更耗时。而到了重构层面，就更不能完全依赖 AI 了——很多时候还是得靠 IDE 的重构能力，或者你手动做方法命名、参数调整、变量重命名、结构梳理。甚至我也会专门留出一整天或几个小时，把整个工程从头到尾过一遍：哪里明显不合适就删掉，哪里结构太绕就顺手收拾一下，哪些变量名看着别扭就统一改掉。杂七杂八的事情确实很多，但它们本质上都是在做同一件事：让系统更干净、更可控、更好维护。
1
赞同来自: lwhsq88
其实我觉得这里面非常重要的一点，就是跟 AI 的交流。很多东西如果完全靠自己摸索，确实会非常耗时间，而且不少典型的坑，你在没踩之前根本意识不到。
但在跟 AI 交流的过程中，尤其是 ChatGPT，它确实能提供非常多的思路。这一点对我来说，帮助主要体现在设计层面、理念层面，以及具体的代码开发，甚至测试层面。很多在一开始就容易走偏、或者后面才发现代价很高的地方，通过和 AI 反复讨论，其实可以提前规避掉。
有时候我也会半开玩笑地跟朋友说，这三个月下来，我跟 AI 在量化开发和回测这件事情上的反复交流，不光是技术层面，连整体认知好像都“上了一个小台阶”。虽然不夸张，但确实能明显感觉到，看问题的角度变了。
也正因为这样，现在再回头去看一些所谓的量化书籍或者论坛，会发现很多内容其实讲得都比较“表面”。比如它很少会告诉你：开发是基于什么平台做的，用了哪些具体工具；虽然大家都知道大部分是 Python，但常见的开发模式、踩过的坑，基本不会系统讲清楚。
相对来说，这些资料更多是在讲结果评估，比如怎么去看回测结果好不好。其实这一点，当你真正跑出来一堆结果之后，心里大概也会有数：无非是从几个核心维度去看。
正好借这个地方，简单说一下我目前的理解。假设你已经有了一个策略，在某一个品种上跑过回测，而且已经考虑了手续费和一定程度的滑点，最终得到了大量参数结果。那接下来，你到底怎么评估哪些参数相对更好？
第一个维度，当然是收益率，这个不用多说，大家都很清楚。
第二个就是回撤。从几个方面展开谈：
1、1 回撤的深度。这个最直观，比如回撤 10% 和回撤 20%，在心理承受和资金管理上的感受是完全不一样的。
1、2 回撤的时间跨度。同样是 10% 的回撤，有的可能两周就修复回来了，有的却要拖两个月甚至更久，这两种对人的影响差异其实非常大。时间一拉长，心态、执行力都会受到考验。
1、3 是回撤出现的次数。有的策略回撤不深，但次数很多；有的回撤次数不多，但一来就是一次比较大的。这三点加在一起，其实才是一个更完整的回撤画像。
总的来说，每个人对回撤的承受能力都是不一样的，这一定要结合你自己对收益率的预期来一起看。如果你追求的是超高收益率，那通常就要接受更极端的回撤深度；反过来，如果你更追求平稳，那就需要在仓位和组合结构上做一些取舍。
比如说，不要轻易满仓，或者引入更多的标的，尤其是那些相关性比较低，甚至是负相关的标的，让它们在组合里相互中和。这样在出现回撤的时候，账户曲线不至于过于夸张，整体体验也会好很多。
再往下一个层面，就是概率相关的指标。
这一块主要就两个：一个是胜率，另一个是盈亏比。由这两项，其实就可以推算出第三项，也就是常说的期望值。
当然，这里说的期望值是比较传统意义上的期望值。在我自己的理解里，我还额外加了一个维度，就是单笔收益率的期望值。这一点我在之前的帖子里其实也提到过。
核心原因在于，不同品种、不同策略，它的资金利用效率是不一样的。比如同样是赚一千块钱，品种 A 可能只需要投入一万块钱，而品种 B 可能需要投入五万块钱。如果在同一时间，A 和 B 都出现了交易机会，那理论上你更应该优先选择 A，因为它的预期收益率更高，资金效率也更好。
而这些东西，其实在回测阶段基本都是可以算出来的，只是看你有没有把它们纳入到评估体系里。
但在跟 AI 交流的过程中，尤其是 ChatGPT，它确实能提供非常多的思路。这一点对我来说，帮助主要体现在设计层面、理念层面，以及具体的代码开发，甚至测试层面。很多在一开始就容易走偏、或者后面才发现代价很高的地方，通过和 AI 反复讨论，其实可以提前规避掉。
有时候我也会半开玩笑地跟朋友说，这三个月下来，我跟 AI 在量化开发和回测这件事情上的反复交流，不光是技术层面，连整体认知好像都“上了一个小台阶”。虽然不夸张，但确实能明显感觉到，看问题的角度变了。
也正因为这样，现在再回头去看一些所谓的量化书籍或者论坛，会发现很多内容其实讲得都比较“表面”。比如它很少会告诉你：开发是基于什么平台做的，用了哪些具体工具；虽然大家都知道大部分是 Python，但常见的开发模式、踩过的坑，基本不会系统讲清楚。
相对来说，这些资料更多是在讲结果评估，比如怎么去看回测结果好不好。其实这一点，当你真正跑出来一堆结果之后，心里大概也会有数：无非是从几个核心维度去看。
正好借这个地方，简单说一下我目前的理解。假设你已经有了一个策略，在某一个品种上跑过回测，而且已经考虑了手续费和一定程度的滑点，最终得到了大量参数结果。那接下来，你到底怎么评估哪些参数相对更好？
第一个维度，当然是收益率，这个不用多说，大家都很清楚。
第二个就是回撤。从几个方面展开谈：
1、1 回撤的深度。这个最直观，比如回撤 10% 和回撤 20%，在心理承受和资金管理上的感受是完全不一样的。
1、2 回撤的时间跨度。同样是 10% 的回撤，有的可能两周就修复回来了，有的却要拖两个月甚至更久，这两种对人的影响差异其实非常大。时间一拉长，心态、执行力都会受到考验。
1、3 是回撤出现的次数。有的策略回撤不深，但次数很多；有的回撤次数不多，但一来就是一次比较大的。这三点加在一起，其实才是一个更完整的回撤画像。
总的来说，每个人对回撤的承受能力都是不一样的，这一定要结合你自己对收益率的预期来一起看。如果你追求的是超高收益率，那通常就要接受更极端的回撤深度；反过来，如果你更追求平稳，那就需要在仓位和组合结构上做一些取舍。
比如说，不要轻易满仓，或者引入更多的标的，尤其是那些相关性比较低，甚至是负相关的标的，让它们在组合里相互中和。这样在出现回撤的时候，账户曲线不至于过于夸张，整体体验也会好很多。
再往下一个层面，就是概率相关的指标。
这一块主要就两个：一个是胜率，另一个是盈亏比。由这两项，其实就可以推算出第三项，也就是常说的期望值。
当然，这里说的期望值是比较传统意义上的期望值。在我自己的理解里，我还额外加了一个维度，就是单笔收益率的期望值。这一点我在之前的帖子里其实也提到过。
核心原因在于，不同品种、不同策略，它的资金利用效率是不一样的。比如同样是赚一千块钱，品种 A 可能只需要投入一万块钱，而品种 B 可能需要投入五万块钱。如果在同一时间，A 和 B 都出现了交易机会，那理论上你更应该优先选择 A，因为它的预期收益率更高，资金效率也更好。
而这些东西，其实在回测阶段基本都是可以算出来的，只是看你有没有把它们纳入到评估体系里。
1
赞同来自: 我丢了
@大力飞砖
我目前能想到的、相对最简单的一点，就是能不能提前挂单。尤其是在你已经开仓成交、接下来要平仓的情况下，很多量化策略其实在开仓那一刻，止盈止损点位就已经是确定的。既然如此，那么在开仓完成之后，理论上是完全可以提前把平仓的止盈、止损单一起挂好的。
也正是基于这个想法，我今天还专门和 ChatGPT 讨论过。我个人是觉得，如果期货公司本身，或者它合作的第三方，提供了更专业的条件单、止盈止损功能，那其实可以直接用他们的系统来做这件事情。因为这种方式不依赖你本地程序是否在线、是否卡顿，它是直接在柜台或者服务器端执行的，只要价格触达，对应的平仓单就会自动成交。
当然，我也知道有些人可能不太认同这种方式，会更倾向于“所有逻辑都掌握在自己程序里”。但就平仓这件事来说，我个人更倾向于交给这些更专业、延迟更低的系统去做，比起本地程序识别到信号之后再临时下单，成功率和确定性都要高不少。
这是第一种思路。
第二种思路就比较直接了：因为我做的是中低频量化，一旦出现交易机会，不管是开仓还是平仓，我本身就愿意主动让点。比如原本目标是赚 10 个点，开仓让 1 个点，平仓再让 1 个点，最终可能只赚 8 个点。但由于我回测里不管是胜率、盈亏比，还是最终算出来的期望值都相对较高，所以我是可以接受这种“用收益换成交确定性”的。
尤其是在开盘阶段，如果出现跳空的情况，我反而更倾向于多让一点。不管是直接跳过止盈点，还是直接打到止损附近，这个时候如果能尽快平掉单子，我觉得比让仓位继续暴露在不确定性里要更有意义，特别是平仓单。
最后还是要再强调一下，上面这些都不是我在实盘中已经充分验证过的结论。因为我实盘才刚起步，这些更多是我在开发和思考过程中总结出来的一些想法，仅代表个人理解，不构成任何投资建议。
我刚开始学习量化，也编码写了一些策略简单入门。请教楼主，你有什么方法提高委托成功率的？关于委托成功率这一块，因为我现在实盘才刚刚开始跑，所以这里只能谈一下我目前的思路，更多还是偏理论层面，不一定成熟，也不一定适合所有人。
我目前能想到的、相对最简单的一点，就是能不能提前挂单。尤其是在你已经开仓成交、接下来要平仓的情况下，很多量化策略其实在开仓那一刻，止盈止损点位就已经是确定的。既然如此，那么在开仓完成之后，理论上是完全可以提前把平仓的止盈、止损单一起挂好的。
也正是基于这个想法，我今天还专门和 ChatGPT 讨论过。我个人是觉得，如果期货公司本身，或者它合作的第三方，提供了更专业的条件单、止盈止损功能，那其实可以直接用他们的系统来做这件事情。因为这种方式不依赖你本地程序是否在线、是否卡顿，它是直接在柜台或者服务器端执行的，只要价格触达，对应的平仓单就会自动成交。
当然，我也知道有些人可能不太认同这种方式，会更倾向于“所有逻辑都掌握在自己程序里”。但就平仓这件事来说，我个人更倾向于交给这些更专业、延迟更低的系统去做，比起本地程序识别到信号之后再临时下单，成功率和确定性都要高不少。
这是第一种思路。
第二种思路就比较直接了：因为我做的是中低频量化，一旦出现交易机会，不管是开仓还是平仓，我本身就愿意主动让点。比如原本目标是赚 10 个点，开仓让 1 个点，平仓再让 1 个点，最终可能只赚 8 个点。但由于我回测里不管是胜率、盈亏比，还是最终算出来的期望值都相对较高，所以我是可以接受这种“用收益换成交确定性”的。
尤其是在开盘阶段，如果出现跳空的情况，我反而更倾向于多让一点。不管是直接跳过止盈点，还是直接打到止损附近，这个时候如果能尽快平掉单子，我觉得比让仓位继续暴露在不确定性里要更有意义，特别是平仓单。
最后还是要再强调一下，上面这些都不是我在实盘中已经充分验证过的结论。因为我实盘才刚起步，这些更多是我在开发和思考过程中总结出来的一些想法，仅代表个人理解，不构成任何投资建议。
0
@zoetina52
如果用邮件的方式，其实有点大材小用。邮件可以承载很多内容，但对我来说并不需要那么多。我只要能收到一个提醒，知道“有事发生了”，然后我自己及时打开程序去看就可以了。
从这个角度看，如果有一个助手，或者说一个很轻量的提醒机制，其实就已经能满足需求了。今天我也试了一种比较“土但可行”的办法，理论上是完全跑得通的。
就是我用苹果手机和苹果笔记本登录同一套系统，在手机上打开短信转发功能。然后在 Mac 上运行量化程序，同时把 Messages 的窗口也打开。一旦程序检测到开仓信号，或者收到了成交回报，就生成一段简单的文字，通过 Python 的 UI 自动化方式，把内容复制到 Messages 窗口里，直接给指定号码发一条短信。
这样的话，我另一部手机就能实时收到短信提醒。实际上也可以接第三方短信服务，这个技术上并不复杂，做个个人认证就行了。但这种方式有一个问题，就是短信内容会经过第三方，我个人的信息、策略或者参数，安全性上会差一点。
综合下来，我反而觉得用短信这种方式在稳定性和及时性上都挺合适的，而且已经完全够我用了。唯一需要额外处理的，就是手机号的问题。我今天测试发现，用同一个手机号给自己发短信，手机端是不会弹通知的。
不过这个也不难解决，现在苹果手机可以插两张卡，再单独办一张卡用来接收提示信息就行了。这样一来，一旦有信号或者成交，我就能第一时间收到提醒，然后再手动去查看程序里的详细情况，整体流程是闭环的。
简短点评：
这个思路本质上还是那句话：不追求“看起来很高级”，而是优先解决“及时知道发生了什么”。在量化实盘里，这种克制反而更稳。
python不会发就用java发 通信写数据库也好监听端口也好url也好 反正你自己用能跑历来不报错就行嫌微信提示不明显就装专门的收件app 专门收监控邮箱的邮件 只要app提示一来点开来看就行邮件和别的东西比入短信相比有巨大优势就是容量大 邮件正文能装茫茫多的信息 而最核心的操作或者摘要写在邮件名称里就行 详略得当原则上你又不是多实时的操作 还得人工来判断 远期合约个把小时成交不了也不差这一分...非常感谢详细回复。其实我给自己的定位并不是要搞一个像期货结算单那样、信息非常全面复杂的系统。我真正需要的，只是一个提示：比如现在是哪一个品种已经出现开仓信号了，哪一笔已经成交了，有这些信息就够了。
如果用邮件的方式，其实有点大材小用。邮件可以承载很多内容，但对我来说并不需要那么多。我只要能收到一个提醒，知道“有事发生了”，然后我自己及时打开程序去看就可以了。
从这个角度看，如果有一个助手，或者说一个很轻量的提醒机制，其实就已经能满足需求了。今天我也试了一种比较“土但可行”的办法，理论上是完全跑得通的。
就是我用苹果手机和苹果笔记本登录同一套系统，在手机上打开短信转发功能。然后在 Mac 上运行量化程序，同时把 Messages 的窗口也打开。一旦程序检测到开仓信号，或者收到了成交回报，就生成一段简单的文字，通过 Python 的 UI 自动化方式，把内容复制到 Messages 窗口里，直接给指定号码发一条短信。
这样的话，我另一部手机就能实时收到短信提醒。实际上也可以接第三方短信服务，这个技术上并不复杂，做个个人认证就行了。但这种方式有一个问题，就是短信内容会经过第三方，我个人的信息、策略或者参数，安全性上会差一点。
综合下来，我反而觉得用短信这种方式在稳定性和及时性上都挺合适的，而且已经完全够我用了。唯一需要额外处理的，就是手机号的问题。我今天测试发现，用同一个手机号给自己发短信，手机端是不会弹通知的。
不过这个也不难解决，现在苹果手机可以插两张卡，再单独办一张卡用来接收提示信息就行了。这样一来，一旦有信号或者成交，我就能第一时间收到提醒，然后再手动去查看程序里的详细情况，整体流程是闭环的。
简短点评：
这个思路本质上还是那句话：不追求“看起来很高级”，而是优先解决“及时知道发生了什么”。在量化实盘里，这种克制反而更稳。
0
其实除了代码开发本身，在回测过程中还会遇到一些比较典型、但一开始不太容易意识到的问题。
第一个就是策略和数据颗粒度是否匹配。一开始为了简化，我很明确自己做的是中低频交易，所以直接选择了日 K 线数据。当时的想法也很简单：不想一上来就搞 15 分钟、60 分钟这种更细粒度的数据，担心噪音太多，反而对策略不友好。
但真正开发推进下去之后就发现，日 K 线的问题也很明显——颗粒度太粗了。在程序里反复琢磨怎么判断开仓、平仓信号时，会发现很多细节根本看不出来。后来就转而尝试 15 分钟 K 线，这一步反而一下子顺了很多：数据量不算夸张，但已经足够产生比较清晰的开平仓信号。
再加上我做的是标准的价差组合，交易所那边本身会尝试撮合两条腿的价差，所以我并不需要做到特别精细。在这种情况下，15 分钟级别对我来说已经完全够用。
这里其实就引出一个很重要的点：你在做开发或回测的时候，需要对交易本身、盘口、流动性、单腿成交风险有一个基本的认识，而不是认准一个方向就一条路走到底。很多时候，适当转个弯，反而会更顺。当然，这个说起来有点抽象，具体例子也不太好一一展开。
再往下就是设计层面的问题。严格来说，开发之前是应该先做框架设计的，但我一开始也没有那么强的设计意识，更多是先把数据拿到手，用策略把整条逻辑跑通。跑通之后，再批量生成参数，用历史数据筛选表现较好的参数，最后再考虑放到实盘里。
当时我也有一个比较明确的想法：最开始先只做一个品种，把程序跑稳，后面再逐步扩展到其他品种。这样实盘时可以分仓多个品种，一方面降低风险，另一方面也能让整体收益更稳定一些。尤其是当某一个品种的参数慢慢失效时，其他品种还能顶住，不至于收益率一下子掉到零，甚至直接转亏。
所以从软件生命周期的角度来看，有比较丰富的后台开发经验的人，确实会更有优势一些。
另外还有一些量化本身常见的坑。比如手续费，这是很多人都会踩的一个点；再比如滑点，我一开始其实并没有意识到标准组合单的存在，最早是尝试用两条腿自己去撮合成交，这里也算是走了一点弯路。
后来慢慢发现，对交易标的本身多了解一点，真的会省很多事。有时候跟朋友交流一下，或者和 AI 聊一聊，对方一句话就能点醒你：比如“这个其实可以直接用组合单，不需要自己去模拟两腿成交”。标准套利组合单这件事，其实也是我在和 ChatGPT、豆包这些工具聊天时被提醒到的，后来一查，国内还真有，而且我关注的品种正好也支持。
当然，组合单更多还是在模拟盘或实盘阶段发挥作用。回测阶段，我一直都是用两条腿直接计算价差，判断是否满足开平仓条件，这完全是可行的。
但组合单也带来了新的问题：回测时用两条腿，模拟时可以监控组合价格，却没法真正模拟成交。为了解决这个问题，我又额外花了一些精力，做了一套“特殊的模拟逻辑”，用两条腿来统计价差触达和超额的次数，从而评估下单后大概多久能成交、成交的概率大概有多高。
这一块我其实也单独做过比较完整的验证。
第一个就是策略和数据颗粒度是否匹配。一开始为了简化，我很明确自己做的是中低频交易，所以直接选择了日 K 线数据。当时的想法也很简单：不想一上来就搞 15 分钟、60 分钟这种更细粒度的数据，担心噪音太多，反而对策略不友好。
但真正开发推进下去之后就发现，日 K 线的问题也很明显——颗粒度太粗了。在程序里反复琢磨怎么判断开仓、平仓信号时，会发现很多细节根本看不出来。后来就转而尝试 15 分钟 K 线，这一步反而一下子顺了很多：数据量不算夸张，但已经足够产生比较清晰的开平仓信号。
再加上我做的是标准的价差组合，交易所那边本身会尝试撮合两条腿的价差，所以我并不需要做到特别精细。在这种情况下，15 分钟级别对我来说已经完全够用。
这里其实就引出一个很重要的点：你在做开发或回测的时候，需要对交易本身、盘口、流动性、单腿成交风险有一个基本的认识，而不是认准一个方向就一条路走到底。很多时候，适当转个弯，反而会更顺。当然，这个说起来有点抽象，具体例子也不太好一一展开。
再往下就是设计层面的问题。严格来说，开发之前是应该先做框架设计的，但我一开始也没有那么强的设计意识，更多是先把数据拿到手，用策略把整条逻辑跑通。跑通之后，再批量生成参数，用历史数据筛选表现较好的参数，最后再考虑放到实盘里。
当时我也有一个比较明确的想法：最开始先只做一个品种，把程序跑稳，后面再逐步扩展到其他品种。这样实盘时可以分仓多个品种，一方面降低风险，另一方面也能让整体收益更稳定一些。尤其是当某一个品种的参数慢慢失效时，其他品种还能顶住，不至于收益率一下子掉到零，甚至直接转亏。
所以从软件生命周期的角度来看，有比较丰富的后台开发经验的人，确实会更有优势一些。
另外还有一些量化本身常见的坑。比如手续费，这是很多人都会踩的一个点；再比如滑点，我一开始其实并没有意识到标准组合单的存在，最早是尝试用两条腿自己去撮合成交，这里也算是走了一点弯路。
后来慢慢发现，对交易标的本身多了解一点，真的会省很多事。有时候跟朋友交流一下，或者和 AI 聊一聊，对方一句话就能点醒你：比如“这个其实可以直接用组合单，不需要自己去模拟两腿成交”。标准套利组合单这件事，其实也是我在和 ChatGPT、豆包这些工具聊天时被提醒到的，后来一查，国内还真有，而且我关注的品种正好也支持。
当然，组合单更多还是在模拟盘或实盘阶段发挥作用。回测阶段，我一直都是用两条腿直接计算价差，判断是否满足开平仓条件，这完全是可行的。
但组合单也带来了新的问题：回测时用两条腿，模拟时可以监控组合价格，却没法真正模拟成交。为了解决这个问题，我又额外花了一些精力，做了一套“特殊的模拟逻辑”，用两条腿来统计价差触达和超额的次数，从而评估下单后大概多久能成交、成交的概率大概有多高。
这一块我其实也单独做过比较完整的验证。
0
zoetina52
- 以前什么都不懂，日子过得好好的。后来我学习了些理财知识，家里的钱越理越少。
@谋城2021
嫌微信提示不明显就装专门的收件app 专门收监控邮箱的邮件 只要app提示一来点开来看就行
邮件和别的东西比入短信相比有巨大优势就是容量大 邮件正文能装茫茫多的信息 而最核心的操作或者摘要写在邮件名称里就行 详略得当
原则上你又不是多实时的操作 还得人工来判断 远期合约个把小时成交不了也不差这一分钟时间差
大家都是码农 别将就那么多 写代码能用就行 一上来就要求这要求那的没意义 先跑起来能赚钱后面慢慢优化慢慢改（然而并不会）
谢谢你这个思路也不错但是有2个问题，程序里面调用邮件接口似乎也不太好做另外手机端收到邮件还是有一些滞后的最关键的手机邮件似乎都是一个红点提示不是那种弹窗之类提示python不会发就用java发 通信写数据库也好监听端口也好url也好 反正你自己用能跑历来不报错就行
嫌微信提示不明显就装专门的收件app 专门收监控邮箱的邮件 只要app提示一来点开来看就行
邮件和别的东西比入短信相比有巨大优势就是容量大 邮件正文能装茫茫多的信息 而最核心的操作或者摘要写在邮件名称里就行 详略得当
原则上你又不是多实时的操作 还得人工来判断 远期合约个把小时成交不了也不差这一分钟时间差
大家都是码农 别将就那么多 写代码能用就行 一上来就要求这要求那的没意义 先跑起来能赚钱后面慢慢优化慢慢改（然而并不会）
0
接下来再简单聊一下回测过程中涉及到的开发问题，主要还是后台这一块。
其实回测本身牵扯的东西非常多，第一步绕不开的就是基础数据从哪里来。这个问题我在前面的帖子里也提过，方式其实不少，比如可以在淘宝、闲鱼上直接买数据，也可以去注册一些专业软件，它们往往提供历史数据的下载功能。另外，还有一些“间接”的办法，比如通过天勤 SDK 之类的工具，也能想办法把数据拉下来。
但说实话，一开始是挺迷茫的。你在网上搜，很难看到一套真正系统、从头到尾讲清楚的流程。反而是在淘宝、闲鱼这些地方，更容易找到“现成”的数据资源。当然，买数据也有一个很现实的问题：通常只截止到当前，如果你后面还要继续回测，就得自己想办法把新数据补上。
不过很多事情都是这样，当你真正走过一遍、把路走通之后，会发现其实也没那么难；但在没走出来之前，真的会觉得完全没路可走。这一点，不管是以前做股票，还是后来接触期货量化，对新手来说，几乎都是一个必经阶段。
数据搞定之后，下一步就是策略和标的的选择。这两者之间其实也有“先有谁”的问题。我自己在这方面经验也谈不上多，就是某一次灵光一闪想到一个策略，然后再反过来，根据这个策略去匹配合适的标的。
比如我个人不太想晚上还盯着盘折腾，所以那些夜盘交易、受国际盘影响比较大的品种，我暂时就不参与了。一方面是精力有限，另一方面是晚上交易会带来跨日处理的问题，对程序来说也会增加额外复杂度。当然，这些并不是解决不了，只是我在一开始并不想把系统复杂度拉得太高。
因此我的程序整体设计得相对简洁，也没有刻意去覆盖太多极端情况。毕竟我做的是价差交易，本身只要不是出现极端收敛或极端扩散，大多数时候两条腿都是同向运动的，天然就过滤掉了不少单边敞口风险。
再往下就是开发本身的问题。说实话，如果对程序开发完全没有概念，就直接上手做量化开发，我个人觉得风险是非常大的。哪怕你是前端工程师，但几乎没有后端经验，贸然来做量化，也会比较吃力。因为前端和后端在软件设计思维上，差异其实非常大。
相对来说，做过 C++、Java、Python 这类偏后端或中间层开发的人，会更适合一些；纯数据库方向也可以，但 SQL、统计分析和完整应用程序之间，还是有差别的，只是比前端要小一点。当然，这并不是说做 Java、C++ 的就不能转 Python，这个问题不大，业务逻辑和思维方式本身是相通的。
我自己其实几年前也动过做量化的念头，但当时发现主流接口基本都是 Python，就被语言成本挡了一下，再加上当时动力也没那么强，就搁置了。现在有 AI 加持之后，这一块的门槛确实低了很多。你只要有后端经验，把“如果用 Java 我会怎么做”描述清楚，让 AI 帮你用 Python 实现，基本是可行的。
当然，过程中我也是一边学 Python，一边推进开发。有些很细碎的点，比如 list 排序、dict 取值，方括号和 get 的区别，key 不存在会不会抛异常，这种我到现在也还是经常直接问 AI。但我觉得这不是什么大问题，关键是你有这个意识：key 不存在时，是拿到一个空值，还是直接抛异常，这两种性质完全不同。
再补充一点，像 ChatGPT 在后台开发这块确实很强，只是使用成本稍微高一点，网络环境也比较折腾。等你后面需要把市值曲线、回测结果、仓位情况这些东西展示出来时，就会涉及前端。这一块我用的是豆包，整体体验还不错，前端生成能力挺强的。
当然，不管是豆包还是 ChatGPT，在连续、长上下文的讨论中都会有一定局限，尤其是聊天记录一多，上下文衔接能力就会下降，其中豆包这一点相对更明显一些，这里就不展开说了。
另外顺带一提，字节跳动出的 TRaa 这个 AI IDE，其实也挺有意思的。我之前还让它尝试去分析天勤 SDK 在 GitHub 上的源码，整体能力还是可以的，只是适合在特定场景下使用。主要还是对某些公司会不会泄漏我的代码或尝试获取我的核心策略的担忧
其实回测本身牵扯的东西非常多，第一步绕不开的就是基础数据从哪里来。这个问题我在前面的帖子里也提过，方式其实不少，比如可以在淘宝、闲鱼上直接买数据，也可以去注册一些专业软件，它们往往提供历史数据的下载功能。另外，还有一些“间接”的办法，比如通过天勤 SDK 之类的工具，也能想办法把数据拉下来。
但说实话，一开始是挺迷茫的。你在网上搜，很难看到一套真正系统、从头到尾讲清楚的流程。反而是在淘宝、闲鱼这些地方，更容易找到“现成”的数据资源。当然，买数据也有一个很现实的问题：通常只截止到当前，如果你后面还要继续回测，就得自己想办法把新数据补上。
不过很多事情都是这样，当你真正走过一遍、把路走通之后，会发现其实也没那么难；但在没走出来之前，真的会觉得完全没路可走。这一点，不管是以前做股票，还是后来接触期货量化，对新手来说，几乎都是一个必经阶段。
数据搞定之后，下一步就是策略和标的的选择。这两者之间其实也有“先有谁”的问题。我自己在这方面经验也谈不上多，就是某一次灵光一闪想到一个策略，然后再反过来，根据这个策略去匹配合适的标的。
比如我个人不太想晚上还盯着盘折腾，所以那些夜盘交易、受国际盘影响比较大的品种，我暂时就不参与了。一方面是精力有限，另一方面是晚上交易会带来跨日处理的问题，对程序来说也会增加额外复杂度。当然，这些并不是解决不了，只是我在一开始并不想把系统复杂度拉得太高。
因此我的程序整体设计得相对简洁，也没有刻意去覆盖太多极端情况。毕竟我做的是价差交易，本身只要不是出现极端收敛或极端扩散，大多数时候两条腿都是同向运动的，天然就过滤掉了不少单边敞口风险。
再往下就是开发本身的问题。说实话，如果对程序开发完全没有概念，就直接上手做量化开发，我个人觉得风险是非常大的。哪怕你是前端工程师，但几乎没有后端经验，贸然来做量化，也会比较吃力。因为前端和后端在软件设计思维上，差异其实非常大。
相对来说，做过 C++、Java、Python 这类偏后端或中间层开发的人，会更适合一些；纯数据库方向也可以，但 SQL、统计分析和完整应用程序之间，还是有差别的，只是比前端要小一点。当然，这并不是说做 Java、C++ 的就不能转 Python，这个问题不大，业务逻辑和思维方式本身是相通的。
我自己其实几年前也动过做量化的念头，但当时发现主流接口基本都是 Python，就被语言成本挡了一下，再加上当时动力也没那么强，就搁置了。现在有 AI 加持之后，这一块的门槛确实低了很多。你只要有后端经验，把“如果用 Java 我会怎么做”描述清楚，让 AI 帮你用 Python 实现，基本是可行的。
当然，过程中我也是一边学 Python，一边推进开发。有些很细碎的点，比如 list 排序、dict 取值，方括号和 get 的区别，key 不存在会不会抛异常，这种我到现在也还是经常直接问 AI。但我觉得这不是什么大问题，关键是你有这个意识：key 不存在时，是拿到一个空值，还是直接抛异常，这两种性质完全不同。
再补充一点，像 ChatGPT 在后台开发这块确实很强，只是使用成本稍微高一点，网络环境也比较折腾。等你后面需要把市值曲线、回测结果、仓位情况这些东西展示出来时，就会涉及前端。这一块我用的是豆包，整体体验还不错，前端生成能力挺强的。
当然，不管是豆包还是 ChatGPT，在连续、长上下文的讨论中都会有一定局限，尤其是聊天记录一多，上下文衔接能力就会下降，其中豆包这一点相对更明显一些，这里就不展开说了。
另外顺带一提，字节跳动出的 TRaa 这个 AI IDE，其实也挺有意思的。我之前还让它尝试去分析天勤 SDK 在 GitHub 上的源码，整体能力还是可以的，只是适合在特定场景下使用。主要还是对某些公司会不会泄漏我的代码或尝试获取我的核心策略的担忧
0
在价差交易中，尤其是跨期或非主力合约组合时，经常会遇到单腿合约流动性偏弱的问题，典型表现是买一卖一价差较大、last price 跳变不稳定。可能开盘不久有成交价格3600，过了几个小时一直不再有成交，而买一卖一价格可能都滚落到3560到3570这一带。如果仍然直接使用 last price 来做信号判断，容易出现信号滞后、抖动或与真实可成交价格偏离的情况。
最初我考虑过更精细的做法：根据做多或做空方向，分别取买一或卖一价格来判断和下单。但在实际推进到实盘时发现，这种方式虽然看起来更“精确”，却显著增加了复杂度和测试成本，尤其是在模拟盘和回放环境无法完整支持标准价差组合单的前提下，反而存在“精确但难以验证”的风险。
最终采用的方案是：不再使用 last price，而是统一使用买一和卖一的中间价（(bid1 + ask1) / 2）作为价格输入，用于价差信号的判断。这种方式在流动性较差的合约上可以有效平滑盘口噪声，而在流动性良好的合约上，其结果与精细化处理并无本质差异。
由于价差交易本身是双腿结构，单边价格的小误差在另一条腿同步变化时往往可以相互抵消。因此，这种“略微模糊但整体正确”的处理方式，在实盘可行性、系统稳定性和工程复杂度之间取得了更好的平衡，也更符合“宁可模糊的正确，不要精确的错误”的原则。
最初我考虑过更精细的做法：根据做多或做空方向，分别取买一或卖一价格来判断和下单。但在实际推进到实盘时发现，这种方式虽然看起来更“精确”，却显著增加了复杂度和测试成本，尤其是在模拟盘和回放环境无法完整支持标准价差组合单的前提下，反而存在“精确但难以验证”的风险。
最终采用的方案是：不再使用 last price，而是统一使用买一和卖一的中间价（(bid1 + ask1) / 2）作为价格输入，用于价差信号的判断。这种方式在流动性较差的合约上可以有效平滑盘口噪声，而在流动性良好的合约上，其结果与精细化处理并无本质差异。
由于价差交易本身是双腿结构，单边价格的小误差在另一条腿同步变化时往往可以相互抵消。因此，这种“略微模糊但整体正确”的处理方式，在实盘可行性、系统稳定性和工程复杂度之间取得了更好的平衡，也更符合“宁可模糊的正确，不要精确的错误”的原则。
0
@zoetina52
你这个思路也不错
但是有2个问题，
程序里面调用邮件接口似乎也不太好做
另外手机端收到邮件还是有一些滞后的
最关键的手机邮件似乎都是一个红点提示
不是那种弹窗之类提示
如果不是实时性要求很高的谢谢
微信关注下qq邮箱或者 189 邮箱之类的 然后自己给自己发邮件 微信就能弹提示 一般半分钟不到就弹出来了
你这个思路也不错
但是有2个问题，
程序里面调用邮件接口似乎也不太好做
另外手机端收到邮件还是有一些滞后的
最关键的手机邮件似乎都是一个红点提示
不是那种弹窗之类提示
0
zoetina52
- 以前什么都不懂，日子过得好好的。后来我学习了些理财知识，家里的钱越理越少。
@谋城2021
微信关注下qq邮箱或者 189 邮箱之类的 然后自己给自己发邮件 微信就能弹提示 一般半分钟不到就弹出来了
目前回测的交易还是中频量化如果不是实时性要求很高的
基本上两三天来回交易一次
所以量化信号+手工下单基本都来得及
不过现在已经实现了程序自动下单
但没有加入撤单或改单或追单的功能
并不是开发不了
而是为了保持业务逻辑的简单和清晰
特意去掉了这些辅助性但是会大大增加复杂性的功能项
回到助手方面
更多的还是做一些辅助性的事情
尤其是某些边边角角的杂项
比如也在考虑如何在不用盯盘的情况下及时收到提示信息
大概有以下几种思路：
...
微信关注下qq邮箱或者 189 邮箱之类的 然后自己给自己发邮件 微信就能弹提示 一般半分钟不到就弹出来了
0
目前回测的交易还是中频量化
基本上两三天来回交易一次
所以量化信号+手工下单基本都来得及
不过现在已经实现了程序自动下单
但没有加入撤单或改单或追单的功能
并不是开发不了
而是为了保持业务逻辑的简单和清晰
特意去掉了这些辅助性但是会大大增加复杂性的功能项
回到助手方面
更多的还是做一些辅助性的事情
尤其是某些边边角角的杂项
比如也在考虑如何在不用盯盘的情况下及时收到提示信息
大概有以下几种思路：
1、使用第三方短信发送
2、使用第三方绑定威信推送信息
3、使用macbook+iphone组合发送系统级提示
4、使用 macbook+iphone+iMessage发送
5、直接使用期货公司或者快期APP开启交易提醒之类
6、将信息推送到自己的服务器上，手机用浏览器访问服务器间接获取
一个问题
解决方案往往有很多种
不存在哪个最佳方案
只是在现有的条件限制下
哪个更适合
基本上两三天来回交易一次
所以量化信号+手工下单基本都来得及
不过现在已经实现了程序自动下单
但没有加入撤单或改单或追单的功能
并不是开发不了
而是为了保持业务逻辑的简单和清晰
特意去掉了这些辅助性但是会大大增加复杂性的功能项
回到助手方面
更多的还是做一些辅助性的事情
尤其是某些边边角角的杂项
比如也在考虑如何在不用盯盘的情况下及时收到提示信息
大概有以下几种思路：
1、使用第三方短信发送
2、使用第三方绑定威信推送信息
3、使用macbook+iphone组合发送系统级提示
4、使用 macbook+iphone+iMessage发送
5、直接使用期货公司或者快期APP开启交易提醒之类
6、将信息推送到自己的服务器上，手机用浏览器访问服务器间接获取
一个问题
解决方案往往有很多种
不存在哪个最佳方案
只是在现有的条件限制下
哪个更适合
1
赞同来自: 我丢了
虽然自己辞职已有两年半
但一直以来
都有找个助手或者凑个小团队的想法
但是没有实施
或许是远程交流不方便
或许是对方要上班
或许很多时候交流似乎没有太大必要
越来越觉得
谈得到一块的
基本认知的层级都差不多
更多的只是知识或见识方面存在差异
这时候互补的效应立即显现出来
但是这个可遇不可求
相对来说
jsl还是不错的
确实能学到不少东西
虽然我还是对于可转债摊大饼，小市值策略不太感兴趣
相对来说
我喜欢集中标的
而不是太过分散
这个无所谓好坏
个人性格或西行差异而已
找助理的想法更现实
深圳人很多
教学相长
很多东西可以教、可以带
但是个人财力并不允许长期找助理干杂货
所以
还是等实盘赚到更多收益
或者实盘收益率不那么经验
但是可以实现长期稳定盈利的话
也是非常不错的
届时真的要考虑找个帮手了
但一直以来
都有找个助手或者凑个小团队的想法
但是没有实施
或许是远程交流不方便
或许是对方要上班
或许很多时候交流似乎没有太大必要
越来越觉得
谈得到一块的
基本认知的层级都差不多
更多的只是知识或见识方面存在差异
这时候互补的效应立即显现出来
但是这个可遇不可求
相对来说
jsl还是不错的
确实能学到不少东西
虽然我还是对于可转债摊大饼，小市值策略不太感兴趣
相对来说
我喜欢集中标的
而不是太过分散
这个无所谓好坏
个人性格或西行差异而已
找助理的想法更现实
深圳人很多
教学相长
很多东西可以教、可以带
但是个人财力并不允许长期找助理干杂货
所以
还是等实盘赚到更多收益
或者实盘收益率不那么经验
但是可以实现长期稳定盈利的话
也是非常不错的
届时真的要考虑找个帮手了
0
前两天想着横向扩展品种
降低风险的同时
收益率可以走的更稳
也为后面真的资金做大后的容量考量
又花了大半天的时间弄了三个品种的15分钟K线数据
其实这些工作可以直接考虑找助理帮忙做
或者直接买数据，也就一两百块
当然也可以用天勤专业版（一年将近一万，一个月一千三左右）
但是现在不是还没正式盈利嘛
还是自己做吧
其中一个品种
回测收益率高的离谱
后来才发现并不是程序错误
而是这个品种报价低，但是保证金反而高不少
而我以前回测为了简单
都是按照股票开仓的思路去计算占用资金情况
另一方面是该品种的杠杆率非常高
还有更重要的是
它的交易机会特别多
三方面叠加
回测收益率简直报表
倒不是我的手续费计算有问题
而是它确实很高.....
后来为了避开这些麻烦
换了另一个品种
直接套用了一个感觉的参数
回测效果居然也不错
我甚至还没有系统回测这个品种
获取一个最优或者次优的参数
这个世界真神奇
降低风险的同时
收益率可以走的更稳
也为后面真的资金做大后的容量考量
又花了大半天的时间弄了三个品种的15分钟K线数据
其实这些工作可以直接考虑找助理帮忙做
或者直接买数据，也就一两百块
当然也可以用天勤专业版（一年将近一万，一个月一千三左右）
但是现在不是还没正式盈利嘛
还是自己做吧
其中一个品种
回测收益率高的离谱
后来才发现并不是程序错误
而是这个品种报价低，但是保证金反而高不少
而我以前回测为了简单
都是按照股票开仓的思路去计算占用资金情况
另一方面是该品种的杠杆率非常高
还有更重要的是
它的交易机会特别多
三方面叠加
回测收益率简直报表
倒不是我的手续费计算有问题
而是它确实很高.....
后来为了避开这些麻烦
换了另一个品种
直接套用了一个感觉的参数
回测效果居然也不错
我甚至还没有系统回测这个品种
获取一个最优或者次优的参数
这个世界真神奇
0
现在的策略偏向中低频
虽然配置了三个品种
但是一年下来平均交易次数也就120-150次
平均三天来回算一次
这两天盘中一直开着程序
但是没有开仓和平仓信号
耐心等吧
今天将实盘的代码又过了一遍
将那些属于回测部分的，或者虽然属于实盘但暂时不需要的代码都删掉了
回测与模拟盘以及实盘各有侧重
回测是提出策略、尽量使用历史数据甚至大批参数跑
验证策略的有效性
这里面要思考的东西最多
比如手续费、滑点、收益率、回撤
策略的交易次数，市场容量等
除了客观方面
甚至还要考虑该策略的交易方式是否与自己的性格、资金属性、资金大小匹配
模拟盘验证策略的成交的概率
实盘则真正关注盘口的成交
虽然配置了三个品种
但是一年下来平均交易次数也就120-150次
平均三天来回算一次
这两天盘中一直开着程序
但是没有开仓和平仓信号
耐心等吧
今天将实盘的代码又过了一遍
将那些属于回测部分的，或者虽然属于实盘但暂时不需要的代码都删掉了
回测与模拟盘以及实盘各有侧重
回测是提出策略、尽量使用历史数据甚至大批参数跑
验证策略的有效性
这里面要思考的东西最多
比如手续费、滑点、收益率、回撤
策略的交易次数，市场容量等
除了客观方面
甚至还要考虑该策略的交易方式是否与自己的性格、资金属性、资金大小匹配
模拟盘验证策略的成交的概率
实盘则真正关注盘口的成交
0
继续在优化实盘部分
现阶段不考虑撤单
主要是跑通核心链条
考虑到标准价差组合单的撮合逻辑比较奇特
要么都成交
要么都不成交
可以规避单腿成交的风险
类似于数据库的事务
但是它也存在一个弊端
就是如果你的某个单子较大时
可能两个单腿不足以撮合
这时候即使有价格优先时间优先也不够
其实隐含的就是数量（越小的越）优先
所以如果后续资金量大一些之后
为了成交
必须拆分成多个小单
现阶段不考虑撤单
主要是跑通核心链条
考虑到标准价差组合单的撮合逻辑比较奇特
要么都成交
要么都不成交
可以规避单腿成交的风险
类似于数据库的事务
但是它也存在一个弊端
就是如果你的某个单子较大时
可能两个单腿不足以撮合
这时候即使有价格优先时间优先也不够
其实隐含的就是数量（越小的越）优先
所以如果后续资金量大一些之后
为了成交
必须拆分成多个小单
0
这两天准备实盘部分
以前开发过
今天把它重新整合起来
软件开发就是这么奇怪
以前实现的时候为了加快速度
加入了各种缓存或者 map dict 之类
作为判断和开关
现在基本上都摈弃了
只保留最核心的部分
因为是中低频量化
每年交易次数在100次（开仓加平仓算一次）
所以完全不用追求性能
单线程跟踪价格变化足够了
以前开发过
今天把它重新整合起来
软件开发就是这么奇怪
以前实现的时候为了加快速度
加入了各种缓存或者 map dict 之类
作为判断和开关
现在基本上都摈弃了
只保留最核心的部分
因为是中低频量化
每年交易次数在100次（开仓加平仓算一次）
所以完全不用追求性能
单线程跟踪价格变化足够了
1
赞同来自: KevinLe
单策略多品种多参数有一个潜在的问题
就是思考的时候需要从资金管理（仓位管理）的视角去看
尤其是不能简单看收益率和传统概率与盈亏比计算出来的期望值
而应该看各品种的单笔交易期望收益率
比如同样是投入20万元，止盈止损额度相同，假如说平均每手盈利600点，每点10元
A品种因为单价高，只能开5手，累计盈利3000元，
B品种因为单价低一些，可以开10手，累计盈利就是6000元
那么针对投入的资金而言，单笔收益率差了1倍
从组合的视角看，
我们就应该以B品种为核心，挑选B品种里面单次收益率高（比如3%）且交易次数还可以的参数
A品种作为锦上添花型，挑选其单次收益率也还可以的（比如1.5%）且交易次数偏少一些的参数
让它们组合起来
总体的收益率会比直接拿最强收益率B+最强收益率A的更稳，回撤更低
很多策略都是以单策略或单参数自己玩
而这种类似于资金组合（组合搭配）的方式思考的维度完全不一样。
以上仅为个人肤浅的理解，不过呢也得到了回测组合测试的数据支持
就是思考的时候需要从资金管理（仓位管理）的视角去看
尤其是不能简单看收益率和传统概率与盈亏比计算出来的期望值
而应该看各品种的单笔交易期望收益率
比如同样是投入20万元，止盈止损额度相同，假如说平均每手盈利600点，每点10元
A品种因为单价高，只能开5手，累计盈利3000元，
B品种因为单价低一些，可以开10手，累计盈利就是6000元
那么针对投入的资金而言，单笔收益率差了1倍
从组合的视角看，
我们就应该以B品种为核心，挑选B品种里面单次收益率高（比如3%）且交易次数还可以的参数
A品种作为锦上添花型，挑选其单次收益率也还可以的（比如1.5%）且交易次数偏少一些的参数
让它们组合起来
总体的收益率会比直接拿最强收益率B+最强收益率A的更稳，回撤更低
很多策略都是以单策略或单参数自己玩
而这种类似于资金组合（组合搭配）的方式思考的维度完全不一样。
以上仅为个人肤浅的理解，不过呢也得到了回测组合测试的数据支持
京公网安备 11010802031449号