12 KiB
12 KiB
预测超跌反弹策略 · MoFin 整合部署计划（修订版）
状态：📋 计划（待老莫审阅批准后才实施） 创建：2026-08-10 ｜ 修订：2026-08-10（查清系统现状后修正） 策略：预测超跌反弹 v5（年化18.57%） 原则：先充分准备，明晰部署流程，再具体实施。未获批准不操作 MoFin 系统。
〇、真正目标（老莫确认）
把"预测超跌反弹"研究成果应用到实际，两条线并行：
-
MoFin 全方位体现和说明：
- 注册进
strategy_lab.py的 STRATEGIES → 研究Tab 展示策略版本、回测、分析 - 策略文档进 docs/ → 知微/系统可读
- 组合Tab/盯盘Tab 相关体现（含归档区 UI 需求）
- 注册进
-
实际操作应用（246 cron 管道，MoFin 监控之下）：
- 新增/接入扫描器 → candidates 表 → 现有候选管道（filter→promote→reassess）自动接管
- 信号进盯盘/健康监控/知微简报
一、系统现状（2026-08-10 查实）
策略注册（研究Tab数据源）
strategy_lab.pySTRATEGIES：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. 观察期实盘验证
七、待老莫确认
- 策略参数定稿：v5（阴跌判定+限流5+10槽15%）= 实盘参数？
- 实盘资金规模？
- 调度方式：market_watch 链式 还是 独立 cron？
- 观察期时长？
- 部署节奏：分步？
修订说明：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 重要发现（新策略接入参考）
- candidate_filter 只支持 A 股（fetch_daily_klines 只处理 sh/sz 前缀）——HK 股（5位代码）全被拒（S2/S3/S4 无数据）
- 我的 p_oversold 策略专注 A 股超跌，不受影响 ✅
- promote_candidates 的 RR>=2.0 门槛是为强势突破设计——accumulation 候选（建仓期低位股）RR 天然 <2（40+/57 被拒）
- 我的策略接入时，RR 门槛按我的选股设计调整（老莫指导）
- 定时脚本普遍缺单例守卫（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 七天重审） |
十、管道修复验证记录（2026-08-10，全部通过）
| 验证 | 结果 |
|---|---|
| candidate_filter 完整跑通 | ✅ 84只重审，无报错无锁冲突 |
| promote_candidates 完整跑通 | ✅ 59只处理完，无超时（限批+护栏生效） |
| 行为回归（RR门槛/ST排除） | ✅ 59只全RR<2+3只ST拒 → 0提拔合理 |
| 守卫不回滚（已入库） | ✅ 两个修复 commit 后保留 |
关键确认：accumulation 候选 RR 普遍<2（本次59只0通过）是扫描器与门槛的固有冲突，非bug。我的 p_oversold 策略接入时用专属评估规避。
十一、部署新策略前的完整准备（2026-08-10 最终版）
11.1 系统检修已完成（修复项）
| 修复 | commit | 验证 |
|---|---|---|
| promote_candidates 超时（限批+守卫+护栏） | 9f82a9b1 |
✅ 57候选60s跑完 |
| candidate_filter pass_final 死角（7天重审） | 79980ce9 |
✅ 0→84只重审 |
| candidate_filter 单例守卫（规范5.3） | 4e10ca9a |
✅ 正常执行 |
| 小果残留清理（health_checklist） | 运行时文件 | ✅ 体检无小果误报 |
| 规范修正（DEVELOPMENT_STANDARDS v1.1） | 待提交 | ✅ 5.3-5.6+部署规范 |
11.2 已知未修问题（记录，不影响新策略）
- 策略评估-每日 Connection error（8/6起）
- 市场精选推荐 7/31后停摆
- 收盘简报 8/7 RuntimeError
- LLM API 不稳定导致简报静默失败（需监控）
- refresh_mtf_cache 等其他定时脚本缺守卫（系统性）
11.3 新策略部署 checklist（p_oversold）
□ 1. 研究侧：strategy_lab.py 注册 v_oversold_v1（title/algorithm/rationale/evidence）
□ 2. 扫描器：predictive_oversold_scanner.py
- 腾讯行情源（对齐 accumulation_scanner）
- 大盘门控（mkt_rsi<50 + mkt_dd60<=-5 + 阴跌跳过）
- 写 candidates 表 sector='p_oversold' + 当日幂等
- 单例守卫（规范5.3）+ 限批/护栏（规范5.4）
□ 3. 候选评估：按我的选股逻辑（不复用 accumulation 的 RR>=2）
- 方案A：独立评估（推荐）
- 方案B：复用管道但改门槛
□ 4. 调度：market_watch 链式 或 独立 cron（规范5.6 调度单一）
□ 5. 验证：python3 -u xxx.py 实测（规范D4）
□ 6. 入库：GIT_ALLOW_COMMIT=1 commit + hmo push（规范D1-D3）
□ 7. 健康监控：morning_health_check 注册 p_oversold 项
□ 8. 知微交接：简报模板 + 策略文档 + 观察期
□ 9. Tab UI：策略/组合Tab 归档区（折叠+延迟加载）
□ 10. 观察期：实盘小资金验证
11.4 部署红线（规范强约束）
- 改动必须 commit 入库（deploy_guard 回滚机制）
- push 必须 hmo 身份
- 定时脚本必须单例守卫
- 重型脚本必须控制 600s 内
- 一个脚本一个调度