“都是Python，为什么不能直接复制？”这是量化新手非常容易产生的疑问。表面上看，QMT、miniQMT和PTrade里都能写if、for、函数和变量，甚至计算均线时都可能用到相似的Python语法，于是很多人把一段代码从一个平台粘贴到另一个平台，结果第一行接口调用就报错。

问题不在Python本身，而在平台提供的运行框架不同。可以把策略代码拆成三层来看：最里面是策略思想，中间是数据和账户处理，最外面是平台接口。真正容易复用的是最里面那层，越靠外越需要重新适配。

第一层是策略思想。例如“计算短期均线和长期均线，短期向上穿过长期时产生关注信号”，这种逻辑与平台无关。均线怎么算、什么条件算交叉、如何限制重复信号，这些规则可以保留。只要输入的数据结构一致，纯粹的数学计算函数也通常可以复用。

第二层是数据和状态。不同平台返回行情的形式可能不同。有的平台返回DataFrame，有的平台返回字典或按证券代码组织的数据对象；有的平台在handle_data中直接提供当前数据，有的平台需要主动调用历史行情接口。即使同样叫close，索引方式也可能完全不同。持仓、资金和委托对象同样如此，字段名称、返回类型和更新时间都可能不同。

第三层是平台接口，这部分通常不能直接复制。QMT内置Python常见的框架是init或handlebar配合ContextInfo，并使用平台提供的行情与下单函数；PTrade强调initialize、before_trading_start、handle_data和after_trading_end等事件，交易时使用order、order_target等接口；miniQMT则是普通本地Python程序，通过XtData读取行情，通过XtTrader连接账户、查询资产并提交委托。三者的启动方式、运行位置和订单回报机制都不同。

举个更直观的例子。假设策略每天计算一次五日均线。在PTrade中，可以在initialize里设置股票池，在handle_data中读取历史价格；如果选择日线频率，平台会按照日线策略的运行规则触发。在QMT中，策略可能依赖主图K线驱动handlebar，也可能使用定时任务。miniQMT没有平台自动替你组织整个策略生命周期，你需要自己决定程序什么时候运行、多久取一次数据、如何保持进程不退出。

因此，把PTrade中的handle_data整段复制到miniQMT，Python语法虽然没问题，但miniQMT根本不会自动调用这个函数；把QMT里的passorder复制到PTrade，PTrade也不认识这个接口。就像同样是汉语，火车站和医院的办事窗口规则并不一样，能说同一种语言，不代表拿同一张表就能办理。

代码迁移最稳妥的方法，不是边报错边替换函数名，而是先画出策略流程。第一步需要什么数据；第二步如何计算指标；第三步什么条件产生信号；第四步如何读取资金和持仓；第五步如何下单；第六步如何确认成交。流程明确后，再把每一步映射到新平台对应的接口。

还要特别注意两个容易被忽略的地方。其一是运行频率。原策略按分钟K线结束运行，迁移后如果变成每几秒触发，可能在同一分钟重复产生信号。其二是状态保存。PTrade对全局变量g有平台持久化机制，QMT和本地miniQMT的状态管理方式不同，直接复制变量写法，重启后可能出现完全不同的结果。

哪些代码最值得保留？通常是独立的指标函数、数据清洗函数、信号判断函数和风险计算函数。哪些代码应当重写？通常是初始化、行情获取、账户查询、下单撤单、回调处理、定时任务和持久化。把两类代码分开，是策略以后能在不同平台间迁移的关键。

新手还容易犯一个错误：代码在新平台“能运行”，就认为迁移完成。真正的验收至少包括数据时间是否一致、指标结果是否一致、信号触发次数是否一致、订单数量是否正确、程序重启后状态是否恢复。尤其涉及真实账户时，必须先在回测或模拟环境中核对。

如果你手里已经有一段QMT、PTrade或miniQMT策略，准备换到另一个环境，先不要急着整段复制。把代码分成“策略逻辑”和“平台接口”两部分，再逐项迁移，成功率会高很多。主页后续也会整理不同平台的接口对应关系，帮助新手判断哪些能复用、哪些必须重写。本文仅作量化软件知识交流，不构成投资建议。