# 预测超跌反弹策略 · 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 注册新策略健康项

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

> 2026-08-12 更新：步骤 1 已完成 ✅（回测复现见下）

```
1. ✅ 本地同步 git + 研究侧注册 → 回测复现 18.57%（2026-08-12 完成）
   - strategy_lab.py 注册 v_oversold（mr引擎 config）+ v_weak（v_mr研发参数）
   - run_mr_backtest 扩展支持外部因子（mkt_rsi/mkt_dd60/mcap_q/pe_q/news3/sec_ret20）
   - step49_save_to_research.py 复现 v5 定稿：10y 年化 18.57%/回撤-32.4%/873信号 ✅
   - 研究Tab/组合Tab 展示真实回测（v_weak 10y cagr 11.7% / v_oversold 10y cagr 18.6%）
   - 性能修复：prepare_sector_context ADX O(N²)→O(N)、外部因子预加载（消除循环内查库）
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 七天重审）|

## 十、管道修复验证记录（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 内
- 一个脚本一个调度