前言

做期货量化最容易失控的阶段，不是策略想法不够多，而是研究和交易分成两套体系后，数据口径、参数版本、执行日志逐步脱节。团队里常见的矛盾是研究员说策略有效，交易员说实盘不可用，最后谁也说服不了谁。
真正可持续的分工，不是简单按岗位切任务，而是让平台能力和岗位职责对齐：研究侧能快速迭代，交易侧能稳定执行，复盘侧能追溯差异来源。

一、先明确三种分工模型

二、具体产品在分工里的角色

天勤量化（TqSdk）：研究和执行共用一套 Python 语义

天勤量化适合把研究侧和交易侧尽量放在同一代码主干里。研究员常用 get_kline_serial、get_tick_serial 验证信号，交易侧再基于同一套字段和状态推进到模拟或实盘。
这种路径的价值在于减少“研究脚本可跑、交易脚本重写”的二次开发。对策略迭代频繁的团队，沟通成本会明显下降。
边界在于流程纪律。没有版本管理、没有参数留痕、没有异常日志，即便平台一致，团队协作也会变成口头同步。

vn.py（VeighNa）：适合把分工做深做细

vn.py更像工程化底座。研究侧可以独立开发策略模块，交易侧围绕 gateway、风控和执行模块做稳定性治理。
在多接口、多策略并行场景下，vn.py的模块化优势明显，尤其适合需要长期维护和深度定制的团队。
但这条路要求团队具备工程能力，包含测试、发布、监控和故障处置。否则分工会变成“模块越来越多、责任越来越不清”。

WH8、TBQuant、金字塔：终端化执行更顺手

这三类平台在交易执行层通常更直观，交易员可以在终端里快速完成策略运行、参数调整和盘中观察。
WH8偏麦语言体系，TBQuant偏平台化自动交易链路，金字塔在终端集成和多语言扩展上更灵活。
如果团队研究侧主要在 Python，而交易侧在终端，务必建立字段映射和参数同步机制，否则复盘时会出现“同名指标不同定义”问题。

QMT、无限易 PythonGO：依赖渠道与客户端生态

QMT往往和券商开通条件绑定，适合已有券商渠道并希望把执行放在券商体系内的团队。
无限易 PythonGO则更适合已经使用无限易终端的人，把程序化能力嵌入现有交易流程，减少系统切换。
这两类方案都要先确认权限边界、接口可用性和版本一致性，再谈团队分工，否则组织安排会被产品权限反向限制。

三、落地建议：把分工写成“可检查流程”

研究侧每次提交策略时，至少同步三项内容：数据口径说明、参数版本、失效条件。
交易侧接手时，先做模拟一致性验证，再做夜盘与断线恢复演练，最后进入小仓位实盘。
复盘侧要固定对比维度：信号触发时间、成交偏差、风控拦截、人工干预记录。这样团队讨论基于证据，而不是基于印象。

总结

期货量化研究侧与交易侧分工的核心，不是岗位描述写得多细，而是平台与流程是否支持可追溯协作。
天勤量化和掘金更适合一体化协同，vn.py更适合工程化分层，WH8/TBQuant/金字塔更适合终端主导执行，QMT与无限易更依赖渠道和客户端环境。
分工做对了，策略迭代速度和实盘稳定性可以同时提升。本文仅讨论工具与流程选择，不构成投资建议。

FAQ

1）研究员和交易员必须使用同一个平台吗？

不是必须，但必须统一数据定义和参数版本，否则复盘无法闭环。

2）小团队要不要直接上vn.py做完整分层？

如果当前目标是快速验证策略，不一定。先跑通闭环再升级架构，通常更稳。

3）终端平台能不能支撑多策略协同？

可以支撑一定规模，但规模上来后要补日志、版本和权限治理。

4）如何判断分工是否健康？

看复盘效率。能在一次复盘里定位偏差来源，说明分工和工具组合基本正确。