第 18 课 · 盘中提醒闭环

异动 → 快报 → 送达 → 人工确认：给监控系统装上"最后一公里"，并学会不打扰自己

这节课你将得到什么

第 6 课的盘中监控 Agent 有一个尴尬的缺口：快报只打印在你电脑终端里——而异动发生时，你大概率不在终端前。这节课给它装上送达层：规则触发后，快报通过 Server酱或企业微信 webhook 推到你的手机上，你点开、判断、决定动不动手。至此，"异动 → 快报 → 送达 → 人工确认"的盘中闭环完整了。

但这节课真正想让你记住的不是"怎么发 webhook"（那是 20 行代码的事），而是两条工程纪律：第一，防骚扰是监控系统的生死线——没有冷却与上限的提醒系统，一周内就会被你自己静音；第二，webhook URL 即密钥——它泄露的后果和 API Key 泄露一模一样。

一、半自动闭环全图回顾

走到第 18 课，你的辅助决策系统每一环都对应着前面某节课的实战。把这盘棋完整看一遍：

脚本 scripts/alert_dispatcher.py 直接 import 第 6 课的 intraday_monitor（规则引擎、自选股原样复用，不重复造轮子），新增的只有两块：渠道抽象和防骚扰守卫。这就是"整合"的含义：每一课造的零件，拼成一台机器。

二、送达层：渠道抽象（控制台 / Server酱 / 企业微信）

送达层的核心是一个朴素的设计：所有渠道长得一样——都有 send(title, body) 方法，上层代码只管"发"，不关心发给谁。脚本里四个渠道类：

build_channels() 按 WEBHOOK_URL 的域名自动识别该用哪个真实渠道——你以后接钉钉、飞书、Bark，都只是再加一个同样形状的类，上层一行不用改。这就是渠道抽象的价值：提醒逻辑与送达方式解耦。

三、防骚扰：监控系统的生死线

先看一个必然发生的剧情：茅台 09:45 触发"涨速+量能"，提醒送达；09:50 它还在涨，同样的规则再次触发；09:55、10:00……一上午你能收到几十条内容几乎相同的提醒。第三天，你开始看到提醒就划掉。第七天，一条真正重要的提醒被你一起划掉了。这叫告警疲劳（alert fatigue）——运维领域的经典教训：淹没在噪音里的告警系统比没有告警更危险，因为它给了你"有人在盯"的错觉。

脚本里的 AlertGuard 用两条规则兜住这个问题：

• 冷却期：同一标的 + 同一规则，30 分钟内不重复提醒。注意粒度是"标的 × 规则"：茅台的"涨速"在冷却中，不影响它新触发的"逼近涨停"正常送达——新信息不该被旧信息连坐。
• 每日上限：全天提醒封顶 20 条。这是兜底条款：万一哪天阈值设错、规则集体失控（第 7 课你亲手见过参数怎么失控的），你的手机最多被打扰 20 次，而不是 200 次。

四、webhook 安全：URL 即密钥

Server酱的 webhook 形如 https://sctapi.ftqq.com/SCTxxxxx.send，企业微信机器人的形如 https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=xxxx。注意它们没有密码、没有签名——谁拿到这个 URL，谁就能往你的微信/群里发消息。它和 LLM_API_KEY 是同等级别的秘密：

• 脚本从环境变量 WEBHOOK_URL 读取，绝不写进代码——写进去就会被 git commit 带进代码库，推到 GitHub 后爬虫几分钟内就能扫到（Server酱官方文档也明确要求不要泄露 SendKEY）。
• 真泄露了怎么办：Server酱后台重置 SendKEY，企业微信群里移除该机器人再新建——旧 URL 立即作废。
• 警惕"提醒内容"本身：快报里有你的持仓信息，webhook 走的是第三方服务器，介意的可以把持仓明细留在控制台、推送只发简版。

五、动手：跑起来（无需网络、无需 Key）

演示模式内置了一个三轮扫描的剧本，刻意构造"重复触发 → 被冷却拦截 → 新规则放行"的完整剧情：

cd "$HOME/AI Project/Quant Learning"
source .venv/bin/activate
python scripts/alert_dispatcher.py

你会看到（我已在你的环境实测通过，输出有删减）：

运行模式：预计算快报，全部渠道打印到控制台（不真发）
防骚扰：同一标的同一规则 30 分钟内不重复；每日上限 20 条

■ 扫描 09:45 —— 规则引擎先行，不触发不打扰

========================================================
异动提醒 ｜ 贵州茅台(600519) ｜ 触发：涨速、量能
--------------------------------------------------------
[送达·控制台] 异动提醒 ｜ 贵州茅台(600519) ｜ 触发：涨速、量能
  规则明细：5分钟涨速 +2.18%（阈值 ≥ +2.00%）
  规则明细：成交量为20日均量的 2.1 倍（阈值 ≥ 2.0 倍）
  规则明细：距涨停价 1628.00 元还有 5.37%（阈值 < 1.00%）
  快报：贵州茅台盘中异动：5分钟涨速超2%，资金脉冲式流入，急涨后回落风险同步放大。成交量已达20日均量2倍以上，放量异动需分辨是进攻还是出货。决策由人做出。
  持仓提示：sellable，是否行动由你判断，Agent 不替你下单。
[送达·Server酱·演示] 不真发；--send 模式此渠道将真实推送
[送达·企业微信·演示] 不真发；--send 模式此渠道将真实推送
========================================================
  - 平安银行(000001)：未触发，静默
  ……（宁德时代触发"逼近涨停"，同样送达一条）……

■ 扫描 09:50 —— 规则引擎先行，不触发不打扰
  - 贵州茅台(600519)：涨速（冷却中，约 30 分钟后解除） → 已抑制，不送达
  - 贵州茅台(600519)：量能（冷却中，约 30 分钟后解除） → 已抑制，不送达
  - 平安银行(000001)：未触发，静默
  - 宁德时代(300750)：逼近涨停（冷却中，约 30 分钟后解除） → 已抑制，不送达

■ 扫描 10:05 —— 规则引擎先行，不触发不打扰
  - 贵州茅台(600519)：量能（冷却中，约 30 分钟后解除） → 已抑制，不送达

========================================================
异动提醒 ｜ 贵州茅台(600519) ｜ 触发：逼近涨停
--------------------------------------------------------
[送达·控制台] 异动提醒 ｜ 贵州茅台(600519) ｜ 触发：逼近涨停
  规则明细：5分钟涨速 +0.25%（阈值 ≥ +2.00%）
  规则明细：成交量为20日均量的 2.3 倍（阈值 ≥ 2.0 倍）
  规则明细：距涨停价 1628.00 元还有 0.99%（阈值 < 1.00%）
  快报：贵州茅台盘中异动：距涨停不足1%，触板后流动性骤降，若封板失败回撤会很快。决策由人做出。
  持仓提示：sellable，是否行动由你判断，Agent 不替你下单。
========================================================
  - 平安银行(000001)：未触发，静默
  - 宁德时代(300750)：逼近涨停（冷却中，约 30 分钟后解除） → 已抑制，不送达

对照剧本读三处关键行为：第 2 轮，同样的规则还在触发，但全部进入冷却——你的手机保持安静，这就是防骚扰的价值；第 3 轮，茅台的"量能"仍在冷却（被拦截），但新触发的"逼近涨停"是新规则，正常送达——冷却粒度是"标的 × 规则"，新信息不被连坐；每条提醒末尾都带 T+1 持仓提示（sellable / frozen），这是第 1 课的分水岭在提醒里的落位：冻结持仓的异动，你只能看，不能动。

六、验证防骚扰：--test 自检

冷却和上限不能只靠"看代码觉得对"，脚本内置自检，用假时钟快进时间：

python scripts/alert_dispatcher.py --test

实测输出：

防骚扰自检（假时钟快进，无需等待）：
  自检 1：同一标的同一规则 30 分钟内第二次触发 → 抑制 …… 通过
  自检 2：冷却期内触发另一条不同规则 → 放行 …… 通过
  自检 3：冷却 30 分钟过后同规则再触发 → 放行 …… 通过
  自检 4：当日第 21 条起被每日上限拦截（放行 20 条） …… 通过
  自检 5：跨天后每日计数清零 → 放行 …… 通过
结果：5/5 通过

五条全过，进程返回码 0；任何一条失败会以非零码退出——这意味着你可以把它挂进 crontab 或 CI，规则改坏了立刻知道。监控系统的每一条"保护你的规则"，本身都要有测试保护。

七、接入真实渠道与真实模型（可选，课后完成）

真实送达：去 Server酱官网 微信扫码登录拿 SendKEY（免费版每天 5 条，够演示；付费版无此限），或在企业微信群里添加机器人拿 webhook，然后：

export WEBHOOK_URL="https://sctapi.ftqq.com/你的SendKEY.send"
python scripts/alert_dispatcher.py --send

真实 LLM 快报则沿用前几课的约定（OpenAI 兼容接口，默认 DeepSeek）：

export LLM_API_KEY="sk-你的key"
python scripts/alert_dispatcher.py --live

两个开关互相独立：--send 只管送达层、--live 只管快报生成，可以单独开也可以一起开。WEBHOOK_URL 域名不在支持列表里时，脚本会直接报错退出而不是静默丢弃。

--send 与 --live 两条代码路径均已写好但尚未实测（你机器上还没有 webhook 和 Key）：webhook 的请求格式按 Server酱与企业微信的官方文档实现，拿到 URL/Key 后各跑一次，有报错直接贴给我。真实送达的单请求超时设为 10 秒，webhook 挂了只影响送达、不会让监控崩溃（异常会沿调用栈抛出，实盘部署时应再包一层 try/except——留个心眼）。

八、批判性思考：提醒发到你手机上之后呢

闭环的最后一环是人，而人是这个系统里最不稳定的组件。三条清醒剂：

• 提醒会制造行动冲动。手机一震、快报一推，"做点什么"的冲动随之而来——但大部分异动的正确应对是"知道了，不动"。T+1 制度下你的反应天然慢半拍，冲动追进去当天还无法纠错。提醒的价值是"不错过"，不是"必须动"。
• 20 条上限同时也是预算。如果冷却和上限天天被打满，说明阈值设得太松，该回去调规则（复习第 7 课：别盘中凭感觉调，盘后拿历史数据验证）。好的监控系统日常应该是安静的。
• 送达依赖第三方。Server酱免费版每天限 5 条、企业微信机器人每分钟限 20 条，且都是别人的服务器。关键决策不能只押一条推送通道——这也是控制台渠道永远保留本地留痕的原因。免费服务的不稳定性，和第 2 课免费行情接口是同一个教训。

自测

凭记忆作答，答错会显示解析。

延伸阅读

• 主读：vn.py 仓库——国内最成熟的开源量化交易框架。不用读懂代码，重点看两件事：一是它的事件引擎如何把"行情 → 策略 → 风控 → 委托"串成一条事件流（对照本课的"异动 → 快报 → 送达"管道，工业界答案是同一个：事件驱动、逐层过滤）；二是它的风控模块——你会发现"频率限制、总量上限"在工业级系统里同样是硬性组件，防骚扰不是我们的土办法，是通行做法。
• Server酱文档与企业微信机器人文档——把 --send 跑通，顺便看官方对 SendKEY 保密的要求。
• 复习：第 6 课 · 盘中异动监控——本课的规则引擎与三层架构都从这里来。

有任何不清楚的地方（比如渠道抽象、AlertGuard 的假时钟、webhook 的申请流程），直接问我——我是你的老师。