一只 ST 股票卖不掉以后，我给 QMT 实盘系统补了 5 道风控
展开
自动化最危险的不是策略错，而是系统以为一切正常。
开头：自动化最怕的不是亏钱，而是假装一切正常
前面几篇一直在讲策略验证、候选池、执行画像和历史回测。到了实盘阶段，问题会变得更直接：系统不只是要判断方向，还要处理真实交易里的各种脏东西。
比如某只股票突然变成 ST，系统的本地快照没及时更新；卖单已经报到 QMT，但成交数量还是 0；行情 tick 已经有价格，5 分钟 K 线却还停在昨天，导致系统误以为今天还没到执行日。
这些问题听起来不像策略研究，甚至有点琐碎。但它们恰恰决定了自动化系统能不能长期跑。因为真实实盘里，最危险的不是某一次判断错了，而是系统错了以后还在页面上显示“一切正常”。
本文只讨论 QMT 实盘系统的风控、日志和监控设计，不构成任何具体标的建议，也不提供账户操作指令。
第一坑：本地数据说它不是 ST，真实行情已经戴帽了
实盘系统里，ST 过滤不能只靠一份本地缓存。原因很简单：股票名称和交易状态会变化，本地快照如果过期，就可能把已经戴帽的股票继续当成普通股票处理。
这次问题暴露得很直接：本地 ST 快照还是旧日期，候选生成时没有识别出新变化。到了 QMT 实盘端，实时名称里已经出现 ST，系统才发现它不应该进入正常展示和统计。
所以我给系统补了三层检查：盘后研究侧要刷新 ST 快照；实盘运行时要用 QMT 实时名称做最后防线；一旦发现名称包含 ST，就加入黑名单，后续禁止新买入。
这里有一个细节很重要：黑名单不能简单地让程序跳过这只股票。因为如果账户里已经持有它，跳过以后反而不会再处理卖出。正确做法是：禁止新买入，但已有持仓仍然允许后台尝试卖出。
第二坑：委托已报，不等于真实成交
很多自动化系统最容易犯的低级错误，是把“下单接口没有报错”当成“交易已经成交”。这在真实交易里是两件事。
QMT 接收了委托，只代表订单已经提交到交易端。它可能成交，也可能部分成交，也可能一直挂着，成交数量为 0。尤其遇到 ST、跌停、流动性差、没有买盘承接时，卖单已报并不代表卖得出去。
这次修复里，我把日志拆成两类：一类是 OrderSubmit，表示委托提交；另一类是 RealTrade，只有持仓数量真的变化以后才记录为真实成交。卖出也是一样，只有 QMT 持仓减少，才从本地持仓跟踪里移除。
这一步看起来只是日志命名，但意义很大。因为一旦系统把未成交订单记成已成交，后续页面、盈亏、仓位和重复下单保护都会被带偏。
第三坑：卖不掉不是程序没努力，而是市场没有承接
很多人看到自动化卖不掉，第一反应是程序是不是没发单。实际不一定。真实交易里，程序可以提交卖单，但不能强行让市场成交。
如果标的处在 ST 状态、跌停附近、买盘很薄，卖单可能一直排队。这个时候系统要做的不是把它从页面上假装删除，而是清楚地区分：订单已经提交，成交还没有发生，持仓仍然存在。
所以我不再用“日志里出现 SELL”来判断卖出完成，而是用账户持仓数量变化来确认成交。只要持仓还在，它就仍然是后台需要处理的风险资产。
对普通用户来说，这个认知也很重要。自动化可以减少重复操作，但它不能消灭市场流动性问题。卖不出去的时候，问题往往不在代码，而在盘口承接。
第四坑：实时价格有了，5 分钟 K 线还没跟上
实盘系统还有一个容易被忽略的问题：不同数据源不会永远同步。tick 实时价格可能已经更新，但 5 分钟 K 线接口还没有生成当天的新行。
这次就出现过这种情况。页面上能看到今天的实时价格，但建仓判断用的是 5 分钟 K 线最后一行日期。多数股票的 K 线还停在前一交易日，系统就误判为“还没到今天的执行日”，导致股票池无法正常建仓。
修复方式不是简单地关掉判断，而是在 5 分钟 K 线落后、实时 tick 已经有价格时，补一行当天的合成分钟数据，用来判断执行日和建仓窗口。
这不是为了让回测更好看，而是为了让实盘系统在数据延迟时仍然知道今天已经开盘了。真实系统必须能处理这种不完美的数据状态。
第五坑：页面展示不是美化，是风控的一部分
很多人把仪表盘当成展示层，觉得只要好看就行。我现在反而觉得，实盘仪表盘本身就是风控的一部分。
如果 ST 持仓继续显示在主界面里，并且继续计入持仓盈亏，用户很容易把它和正常策略持仓混在一起看。这样会让策略表现、持仓数量和风险状态都变得不清楚。
所以这次我把 ST 股票从网页主表、今日日志、持仓数量和浮动盈亏统计里排除。注意，不是从后台删除，也不是假装没有这只股票。它仍然保留在后台处置链路里，系统仍然可以继续尝试卖出。
前台用于观察策略是否正常，后台用于处理异常资产。两者要分开。这种区分比页面多一个颜色标签更重要。
我给 QMT 实盘系统补的 5 道风控
第一道，ST 快照不能长期复用。研究侧每天检查快照日期，过期就重新拉取，拉取失败也要留下状态。
第二道，实盘端用 QMT 实时名称做最后校验。只要名称里出现 ST，就自动加入黑名单，禁止后续新买入。
第三道，委托提交和真实成交分开记录。OrderSubmit 只说明单子报出，RealTrade 必须等账户持仓变化后才写入。
第四道，行情数据要有降级处理。5 分钟 K 线落后但 tick 有价格时，系统要能补当天实时判断行，避免错过建仓窗口。
第五道，仪表盘只展示正常策略状态。异常持仓不计入策略主表和盈亏统计，但后台保留卖出处理和审计记录。
结尾：实盘系统的价值，是把错误暴露出来
这次复盘以后，我对 QMT 自动化有一个更明确的看法：实盘系统不是为了让人相信策略永远正确，而是为了让错误尽早暴露。
一个系统如果只能在顺利时工作，那它还不够实盘。真正需要打磨的是这些不顺利的时刻：状态变了、订单没成交、数据延迟、页面统计失真、持仓和日志对不上。
所以我建议每个做 QMT 自动化的人，先别急着追求更复杂的策略。先检查五件事：能不能识别异常标的，能不能区分委托和成交，能不能确认真实持仓，能不能处理数据延迟，能不能留下完整复盘记录。
策略研究决定上限，执行风控决定你能不能活到下一轮迭代。
如果你也在做 QMT 自动化，可以先整理一份自己的实盘风控检查清单。不要只问策略赚不赚钱，先问系统出错时你能不能看见。
可放在文末的领取提示
如果你也在用 QMT 做自动化，可以先整理一份自己的实盘风控检查清单。重点不是证明某个策略未来一定有效，而是确认系统出错时你能不能看见。
本文只分享系统搭建和风控复盘思路，不荐股，不喊单，不构成投资建议。
开头：自动化最怕的不是亏钱，而是假装一切正常
前面几篇一直在讲策略验证、候选池、执行画像和历史回测。到了实盘阶段，问题会变得更直接：系统不只是要判断方向，还要处理真实交易里的各种脏东西。
比如某只股票突然变成 ST，系统的本地快照没及时更新；卖单已经报到 QMT，但成交数量还是 0；行情 tick 已经有价格，5 分钟 K 线却还停在昨天，导致系统误以为今天还没到执行日。
这些问题听起来不像策略研究，甚至有点琐碎。但它们恰恰决定了自动化系统能不能长期跑。因为真实实盘里，最危险的不是某一次判断错了，而是系统错了以后还在页面上显示“一切正常”。
本文只讨论 QMT 实盘系统的风控、日志和监控设计，不构成任何具体标的建议，也不提供账户操作指令。
第一坑：本地数据说它不是 ST，真实行情已经戴帽了
实盘系统里，ST 过滤不能只靠一份本地缓存。原因很简单：股票名称和交易状态会变化，本地快照如果过期，就可能把已经戴帽的股票继续当成普通股票处理。
这次问题暴露得很直接：本地 ST 快照还是旧日期，候选生成时没有识别出新变化。到了 QMT 实盘端，实时名称里已经出现 ST，系统才发现它不应该进入正常展示和统计。
所以我给系统补了三层检查：盘后研究侧要刷新 ST 快照；实盘运行时要用 QMT 实时名称做最后防线；一旦发现名称包含 ST，就加入黑名单，后续禁止新买入。
这里有一个细节很重要：黑名单不能简单地让程序跳过这只股票。因为如果账户里已经持有它，跳过以后反而不会再处理卖出。正确做法是：禁止新买入，但已有持仓仍然允许后台尝试卖出。
第二坑：委托已报，不等于真实成交
很多自动化系统最容易犯的低级错误，是把“下单接口没有报错”当成“交易已经成交”。这在真实交易里是两件事。
QMT 接收了委托，只代表订单已经提交到交易端。它可能成交，也可能部分成交，也可能一直挂着，成交数量为 0。尤其遇到 ST、跌停、流动性差、没有买盘承接时，卖单已报并不代表卖得出去。
这次修复里，我把日志拆成两类：一类是 OrderSubmit，表示委托提交；另一类是 RealTrade，只有持仓数量真的变化以后才记录为真实成交。卖出也是一样，只有 QMT 持仓减少，才从本地持仓跟踪里移除。
这一步看起来只是日志命名，但意义很大。因为一旦系统把未成交订单记成已成交，后续页面、盈亏、仓位和重复下单保护都会被带偏。
第三坑：卖不掉不是程序没努力，而是市场没有承接
很多人看到自动化卖不掉，第一反应是程序是不是没发单。实际不一定。真实交易里，程序可以提交卖单，但不能强行让市场成交。
如果标的处在 ST 状态、跌停附近、买盘很薄，卖单可能一直排队。这个时候系统要做的不是把它从页面上假装删除，而是清楚地区分：订单已经提交，成交还没有发生，持仓仍然存在。
所以我不再用“日志里出现 SELL”来判断卖出完成，而是用账户持仓数量变化来确认成交。只要持仓还在，它就仍然是后台需要处理的风险资产。
对普通用户来说，这个认知也很重要。自动化可以减少重复操作，但它不能消灭市场流动性问题。卖不出去的时候，问题往往不在代码，而在盘口承接。
第四坑：实时价格有了，5 分钟 K 线还没跟上
实盘系统还有一个容易被忽略的问题：不同数据源不会永远同步。tick 实时价格可能已经更新，但 5 分钟 K 线接口还没有生成当天的新行。
这次就出现过这种情况。页面上能看到今天的实时价格，但建仓判断用的是 5 分钟 K 线最后一行日期。多数股票的 K 线还停在前一交易日，系统就误判为“还没到今天的执行日”，导致股票池无法正常建仓。
修复方式不是简单地关掉判断，而是在 5 分钟 K 线落后、实时 tick 已经有价格时，补一行当天的合成分钟数据，用来判断执行日和建仓窗口。
这不是为了让回测更好看，而是为了让实盘系统在数据延迟时仍然知道今天已经开盘了。真实系统必须能处理这种不完美的数据状态。
第五坑：页面展示不是美化，是风控的一部分
很多人把仪表盘当成展示层，觉得只要好看就行。我现在反而觉得，实盘仪表盘本身就是风控的一部分。
如果 ST 持仓继续显示在主界面里，并且继续计入持仓盈亏，用户很容易把它和正常策略持仓混在一起看。这样会让策略表现、持仓数量和风险状态都变得不清楚。
所以这次我把 ST 股票从网页主表、今日日志、持仓数量和浮动盈亏统计里排除。注意，不是从后台删除，也不是假装没有这只股票。它仍然保留在后台处置链路里，系统仍然可以继续尝试卖出。
前台用于观察策略是否正常，后台用于处理异常资产。两者要分开。这种区分比页面多一个颜色标签更重要。
我给 QMT 实盘系统补的 5 道风控
第一道，ST 快照不能长期复用。研究侧每天检查快照日期，过期就重新拉取，拉取失败也要留下状态。
第二道，实盘端用 QMT 实时名称做最后校验。只要名称里出现 ST，就自动加入黑名单，禁止后续新买入。
第三道，委托提交和真实成交分开记录。OrderSubmit 只说明单子报出，RealTrade 必须等账户持仓变化后才写入。
第四道，行情数据要有降级处理。5 分钟 K 线落后但 tick 有价格时，系统要能补当天实时判断行，避免错过建仓窗口。
第五道，仪表盘只展示正常策略状态。异常持仓不计入策略主表和盈亏统计，但后台保留卖出处理和审计记录。
结尾：实盘系统的价值，是把错误暴露出来
这次复盘以后，我对 QMT 自动化有一个更明确的看法：实盘系统不是为了让人相信策略永远正确，而是为了让错误尽早暴露。
一个系统如果只能在顺利时工作，那它还不够实盘。真正需要打磨的是这些不顺利的时刻：状态变了、订单没成交、数据延迟、页面统计失真、持仓和日志对不上。
所以我建议每个做 QMT 自动化的人，先别急着追求更复杂的策略。先检查五件事：能不能识别异常标的，能不能区分委托和成交，能不能确认真实持仓，能不能处理数据延迟，能不能留下完整复盘记录。
策略研究决定上限，执行风控决定你能不能活到下一轮迭代。
如果你也在做 QMT 自动化，可以先整理一份自己的实盘风控检查清单。不要只问策略赚不赚钱，先问系统出错时你能不能看见。
可放在文末的领取提示
如果你也在用 QMT 做自动化，可以先整理一份自己的实盘风控检查清单。重点不是证明某个策略未来一定有效，而是确认系统出错时你能不能看见。
本文只分享系统搭建和风控复盘思路，不荐股，不喊单，不构成投资建议。
话题与分类：
主题股票：
主题概念：
声明：遵守相关法律法规，所发内容承担法律责任，倡导理性交流，远离非法证券活动，共建和谐交流环境！
