有些用户已经写了自己的Python策略，能选股，能算指标，能生成买卖信号。以前可能通过miniQMT连接账户执行。现在外部直连交易这条路不能继续使用，就会出现一个问题：策略还能用吗？

答案是，策略本身可能还能用，但执行方式要改。你要先把Python策略分成两部分：一部分是研究和计算，一部分是交易接口。研究和计算包括数据清洗、指标计算、信号判断、仓位规则、日志记录。这些通常可以保留。交易接口包括账户查询、下单、撤单、成交回报，这些需要重新适配。

如果策略已经能稳定输出信号，那么它不一定要完全搬进QMT或PTrade。更合理的思路是：外部Python继续计算，生成标准信号；执行端读取信号，再完成账户检查和委托提交。

这时候QMT就有价值。它可以作为本地执行端，读取外部系统生成的文件或数据库记录，再根据账户状态决定是否执行。这样做的好处是，原来的策略核心不用完全重写，主要改造执行层。

但这件事不能简单理解成“QMT读取一个文件就下单”。真正重要的是信号要规范。比如信号什么时候生成，什么时候过期，交易什么标的，方向是什么，数量是多少，是否已经处理过。如果这些没有设计好，就容易重复下单或执行过期信号。

还有订单状态。外部Python发出信号以后，不能只知道“我发了”。它还要知道执行端有没有读取，有没有提交委托，订单是否成交，是否失败，是否撤销。没有状态反馈，系统跑久了就会乱。

如果策略频率不高，可以先用简单文件做验证。比如外部Python写出信号，QMT只读取并打印，不下单。确认读取逻辑稳定后，再进入模拟验证。不要一开始就直接实盘。

如果信号较多，需要长期追踪，就要考虑更稳定的记录方式，比如本地数据库。它可以保存信号状态、处理结果和订单反馈。但具体用什么方式，要看策略频率、数据量和运行环境。

另一种选择是PTrade。如果你的策略逻辑并不依赖本地系统，只是标准低频调仓，可以考虑把策略改写到PTrade框架里。这样维护成本可能更低。所以，有Python策略但不能直接交易，并不是策略作废，而是执行层需要重新设计。本文仅用于量化工具迁移交流，不构成投资建议。

迁移时还要控制预期。原来一段代码能直接查账户、下单，现在可能要拆成信号端和执行端。多了一层结构，开发工作会增加，但好处是系统边界更清楚，后续维护也更有弹性。

先保留能独立运行的研究部分，再重做执行层，是比较稳的迁移顺序。

执行层重做以后，原来的策略研究成果才有机会继续发挥作用。

先把这一步想清楚，再去看具体操作，会更稳。

实际使用前，还要把策略频率、数据来源、运行环境和订单处理方式写清楚。很多问题不是工具本身造成的，而是前面这些条件没有确认。先确认条件，再做测试，迁移和实盘都会更稳。

策略能继续用的前提，是把计算部分和交易部分拆清楚，不要混在一起判断。 这一步虽然简单，但能减少很多后续排查成本。

策略能继续用的前提，是把计算部分和交易部分拆清楚，不要混在一起判断。