MoFin/docs/deployment-plan-predictive-oversold.md

预测超跌反弹策略 · MoFin 整合部署计划（修订版）

状态：📋 计划（待老莫审阅批准后才实施） 创建：2026-08-10 ｜ 修订：2026-08-10（查清系统现状后修正） 策略：预测超跌反弹 v5（年化18.57%） 原则：先充分准备，明晰部署流程，再具体实施。未获批准不操作 MoFin 系统。

---

〇、真正目标（老莫确认）

把"预测超跌反弹"研究成果应用到实际，两条线并行：

1. MoFin 全方位体现和说明：

   • 注册进 strategy_lab.py 的 STRATEGIES → 研究Tab 展示策略版本、回测、分析
   • 策略文档进 docs/ → 知微/系统可读
   • 组合Tab/盯盘Tab 相关体现（含归档区 UI 需求）

2. 实际操作应用（246 cron 管道，MoFin 监控之下）：

   • 新增/接入扫描器 → candidates 表 → 现有候选管道（filter→promote→reassess）自动接管
   • 信号进盯盘/健康监控/知微简报

一、系统现状（2026-08-10 查实）

策略注册（研究Tab数据源）

• strategy_lab.py STRATEGIES：80 个版本（v1.0~v11.x + v_combo/v_next/h1.x + v_lurk_v1/v2/v3）
• STRATEGY_DESCRIPTIONS：123 个（title/algorithm/rationale/evidence）
• v_lurk_v1/v2/v3（潜伏型）是最近注册的（老莫指导的由果推因成果），研究Tab已反映
• ⚠️ v_mr 不在 STRATEGIES（只在 mr_engine_v2.py 研究引擎脚本里）——策略面板看不到
• ⚠️ S2 是过时概念（s2_scanner.py 存在但未在 STRATEGIES）

实盘管道（246 cron 63个任务，全部启用）

主力建仓扫描 accumulation_scanner (每15分) → candidates 表
候选股过滤管道 candidate_filter (每30分)
候选股自动提拔 promote_candidates (每30分)
盘前全量重评 premarket_full_review (08:10)
+ market_watch/market_screener/market_insight + 简报/健康/审计/监控

关键结论

• 新策略实盘接入 = 写一个扫描器（对齐 accumulation_scanner 模式：腾讯行情源+候选写入+幂等），候选管道 sector 无关自动接管
• 研究Tab接入 = 注册 STRATEGIES（title/algorithm/rationale/evidence）

二、研究侧接入（strategy_lab 注册）

注册条目（对齐 STRATEGY_DESCRIPTIONS 格式）：

"v_oversold_v1": {
  "title": "预测超跌反弹v1（弱市+小市值+低PE+新闻+行业弱+深跌）",
  "algorithm": "入场: mkt_rsi<50 + mcap_q<0.2 + pe_q<0.2 + news3>=1 + sec_ret20<0 + bias60<-20 + mkt_dd60<=-5。阴跌跳过: 连跌>=2+ADX<=55+RSI>=33。出场: 支撑下5%止损/压力位止盈/40日。仓位: 10槽15%+单日限5。",
  "rationale": "由果及因(30207大涨段)+12维预测因子扫描(887万样本)，预测力随因子叠加单调提升(3.52%→11.61%大涨率)。",
  "evidence": "统一资金模拟年化18.57%/回撤-32.4%/胜率~90%(2016-2026)。阴跌中段判定剔除大回撤源头(连跌+弱趋势+RSI偏高时信号avg-6.35%→保留+6.75%)。"
}

三、实盘扫描器（246 cron 接入）

新文件：deploy/profile-scripts/predictive_oversold_scanner.py

• 对齐 accumulation_scanner：腾讯行情源 / candidates 表写入 / 当日幂等
• 门控：大盘条件（mkt_rsi/mkt_dd60/mkt_adx/mkt_down_days）
• 候选 sector："p_oversold"
• 排序：按 bias60 深度

调度：market_watch.py 链式调用（追加）或独立 cron 条目（待定，老莫定）

四、Tab UI（老莫需求）

• 策略Tab/组合Tab 加已归档区域（历史策略/组合）
• 默认折叠 + 点击展开 + 延迟加载（不展开不读数据）
• 涉及：static/index.html + server.py /api/research/* 加 archived 参数

五、知微交接 + 健康监控

• 策略文档 docs/（知微可读）+ 简报模板提及新策略
• morning_health_check 注册新策略健康项

六、部署流程（每步验证门禁）

1. 本地同步 git（246 领先，先 pull）+ 研究侧注册 → 回测复现 18.57%
2. 服务器 dry-run：scanner 独立跑（写 candidates 不提拔）
3. 候选管道验证（小样本 filter→promote）
4. 全链路开通（market_watch 链式 + cron 注册）
5. 健康监控 + 知微交接
6. 观察期实盘验证

七、待老莫确认

1. 策略参数定稿：v5（阴跌判定+限流5+10槽15%）= 实盘参数？
2. 实盘资金规模？
3. 调度方式：market_watch 链式 还是 独立 cron？
4. 观察期时长？
5. 部署节奏：分步？

---

修订说明：2026-08-10 查清系统现状后修正——移除过时的 v_mr/S2 引用，明确研究侧=STRATEGIES注册、实盘侧=扫描器接入。

八、管道修复实践记录（2026-08-10，部署参考）

8.1 已修复的问题

问题	根因	修复	验证
promote_candidates 超时600s	240候选×18s/个 >> 600s（hermes child_timeout）	加单例守卫 + 每批限10新提拔 + 重评子进程480→120s + 总时长护栏500s	✅ 57候选60s处理完
candidate_filter "待处理0只"	pass_final=1 不管分数，低分候选永不重审	加重审窗口：score_final<7 且 created_at>7天 → 重置重审	✅ 0→152只重审
db locked（SQLite并发）	多脚本并发写 mofin.db（WAL模式），refresh_mtf_cache 重复实例长锁	已杀重复实例；根因是定时脚本缺单例守卫（系统性）	⚠️ 待评估

8.2 重要发现（新策略接入参考）

1. candidate_filter 只支持 A 股（fetch_daily_klines 只处理 sh/sz 前缀）——HK 股（5位代码）全被拒（S2/S3/S4 无数据）
   • 我的 p_oversold 策略专注 A 股超跌，不受影响 ✅
2. promote_candidates 的 RR>=2.0 门槛是为强势突破设计——accumulation 候选（建仓期低位股）RR 天然 <2（40+/57 被拒）
   • 我的策略接入时，RR 门槛按我的选股设计调整（老莫指导）
3. 定时脚本普遍缺单例守卫（refresh_mtf_cache 重复实例 → 长锁）——系统性铁律问题，待评估

8.3 新策略接入候选管道的具体方式

候选管道架构（现状）：

accumulation_scanner → candidates(sector='accumulation') 
  → candidate_filter(6阶段评分: S2量价/S3技术/S4资金/S5基本面/S6消息)
  → promote_candidates(score>=7 + ST排除 + RR>=2 + 容量60)
  → per_stock_reassess(12维重评) → holding_strategies

我的策略接入点分析：

• candidate_filter / promote_candidates 无 sector 过滤 → p_oversold 候选会被现有管道消费
• 但 6 阶段评分是为 accumulation 设计（量价放大/中低位），超跌候选评分不适配
• RR>=2 门槛（promote 内）会大量拒绝超跌候选（同 accumulation 问题）

接入决策（待实施时定）：

• 方案A：复用现有管道（写 candidates + sector='p_oversold'）——但需调整 RR 门槛/评分适配
• 方案B：专属扫描器 + 专属评估（p_oversold 有自己的选股条件，不需要 accumulation 的 6 阶段+RR>=2）
• 方案C：A 变体——扫描器写 candidates 直接标记 score_final 高分 + pass_final=1，绕过 candidate_filter，直接进 promote（需确认 promote 逻辑）

8.4 部署操作清单（实施时对照）

1. 研究侧：strategy_lab.py 注册 v_oversold_v1（title/algorithm/rationale/evidence）
2. 扫描器：predictive_oversold_scanner.py（腾讯行情源 + 大盘门控 + candidates 写入 sector='p_oversold'）
3. 候选评估：按我的选股逻辑（不套 accumulation 的 RR>=2；或专属评估）
4. 调度：market_watch 链式 或 独立 cron（待定）
5. 健康监控：morning_health_check 注册 p_oversold 检查项
6. 知微交接：简报模板 + 策略文档
7. Tab UI：策略/组合Tab 归档区（折叠+延迟加载）
8. 观察期：实盘小资金验证

8.5 待处理（本次未做，记录）

• refresh_mtf_cache 等定时脚本加单例守卫（系统性）
• SQLite 并发写锁架构评估（WAL + busy_timeout 是否够）
• HK 股在候选管道中的处理（accumulation 侧，非我策略）
• accumulate 候选 RR 门槛适配（老莫决策）

九、deploy_guard 机制与正确修改流程（2026-08-10 实战教训）

9.1 deploy_guard 机制

• 监控 CODE_PATHS（deploy/profile-scripts, deploy/bot, prompt_manager, scripts, server.py, mofin_db.py 等）
• 发现 CODE_PATHS 内有未入库改动（git status M）→ git checkout 回滚到 HEAD + 硬链接同步 + XMPP 告警
• 目的：保护"已入库代码"不被现场改动污染（防知微两次 stale 提交事故）
• 未跟踪文件（??）不删，只告警

9.2 正确修改流程（实战验证）

1. 改 /home/hmo/MoFin/deploy/profile-scripts/xxx.py（或 .hermes 硬链接）
2. 立即 commit：GIT_ALLOW_COMMIT=1 git commit -m '说明'
   - pre-commit 白名单：只有 GIT_ALLOW_COMMIT=1 才放行（知微无此令牌）
   - 小小莫本人操作显式携带该令牌 = 我有权限
3. push：git push https://hmo@git.yoin.fun/hmo/MoFin.git master
   - 必须用 hmo 身份（store 凭据），不能改 user.name 为 xxm/mohe
   - 之前被拒根因：git config user.name 被改，凭据匹配到错误身份
4. 守卫下次运行看到 CODE_PATHS 干净 → 不回滚

9.3 本次管道修复（已入库）

commit	修复
9f82a9b1	promote_candidates 超时（限批10+单例守卫+重评120s+护栏500s）
79980ce9	candidate_filter pass_final 死角（低分<7 七天重审）