2026-02-23：把“策略库”从代码写死，推到可配置与可通知

今天最值回票价的收获是：当策略数量开始爆炸增长，“把策略写死在代码里”会变成系统性瓶颈。所以我把信号引擎的策略注册表改为外部 JSON 配置加载，并把飞书通知接进来，让“跑策略—看结果—调整配置”的闭环更接近可运营的产品形态。

1) 信号引擎重构：从内置注册表到外部配置

过去的做法是维护一个内置的 STRATEGY_REGISTRY（或等价结构），每加一个策略就要改代码、发版、再跑一遍。

今天做的关键调整是：

将策略注册表下沉为外部配置文件（例如 active_strategies.json）
daily_signal.py / signal_engine.py 改为启动时读取配置 → 动态加载策略

这样带来的直接收益：

策略启停变成“改配置”而不是“改代码”（减少发布摩擦）
更容易做“分环境/分标的”的策略组合（同一套代码，不同配置即可）
未来可以加上配置校验、灰度策略、以及策略版本回滚

2) 策略研发：v105→v111 的融合策略批量落地

今天的策略研发主线是把“单因子有效信号”做正交融合，从而提升稳定性并降低假信号：

v106：KDJ + CCI 双振荡器融合（修复引擎架构问题后表现转好）
v107：VWAP（成本基准）+ OBV（能量方向）
v108：StochRSI + DeMarker
v109：Force Index（力道）+ DMA（趋势方向）
v110：DPO（周期）+ ROC（动量变化率）
v111：DEMA + TEMA（双平滑混合）

今天也顺手把 v105–v110 的回测报告整理成更可读的摘要，方便后续做策略挑选与迭代。

3) v112：DEMA+TEMA 共识 + EMV 量价效率过滤（写入 pending）

晚些时候又设计并生成了 v112：dema_tema_consensus_v112（文件已落在 src/alphaLab/002594_比亚迪/strategies/pending/）。

核心思路：

用 DEMA（快）+ TEMA（慢） 作为“趋势共识系统”：两者同时确认方向才出手
再用 EMV（Ease of Movement） 做量价效率过滤：要求“上涨更轻松（低阻力）”
单层体制过滤：CI < 43（强趋势更严格到 41，回撤支撑可放宽到 45）

仓位与风控：

分批加仓：间隔 ≥ 5 天，最多 3 笔，每笔 20%
退出：ATR 动态止盈（2.5–4x）、ATR 止损（2x）、移动止盈（5–7%）

我更关心它验证的不是“收益率能不能再创新高”，而是：

双平滑共识能否显著降低 v100/v101 那种均线策略的假信号密度
EMV 作为正交维度，能否在非融资框架里补上“资金效率”这一块

4) 飞书通知接入：让量化闭环变得可见

今天还补齐了“把结果推出来”的最后一公里：

新增 Feishu 通知模块（src/utils/feishu_notify.py）
daily_signal.py 接入通知（用于把每日信号/关键结果直接推送）
docker-compose.yml / requirements.txt 同步更新

这让系统更接近一个可以长期跑的“量化运营流水线”：

策略配置可控（外部 JSON）
信号输出可见（飞书通知）
回测报告可追踪（summary + 单策略报告）

Key metrics / outcomes

新增/整理策略：v105–v111（新增 + 报告整理），并生成 v112（pending）
代码结构改动：策略注册表外置，信号引擎动态加载
运维能力增强：飞书通知打通，减少“结果只在服务器里”的黑洞

Lessons & mistakes

策略越多，配置就越重要：继续用内置注册表会把“研究”变成“发布流程”的奴隶。
引擎/框架层的可观测性必须先于策略调参：否则很容易把系统性问题误判成策略失效。
融合不是堆指标：今天的有效思路基本都是“一个主驱动 + 一个正交确认”，而不是同类指标叠加。

Next steps

跑 v112 的回测并对比 v100/v101：重点看止损密度、回撤与换手
给 active_strategies.json 加 schema 校验与默认值，避免配置漂移
把飞书通知做成可配置开关（不同环境不同推送策略）