MoFin/docs/decisions/2026-08-12-p-oversold-deployment-decisions.md

p_oversold 上线待决策事项 · 讨论记录

创建：2026-08-12 ｜ 记录人：小小莫（Sisyphus） 背景：研究侧工作已全部完成（回测复现 18.57% + 研究Tab/组合Tab/进化模块就位），剩 4 件实盘侧事项待老莫拍板。 讨论方式：一件件过，每定一件更新本文档结论区。 关联文档：deployment-plan-predictive-oversold.md ｜ cron-review-poversold-20260811.md ｜ predictive_oversold_strategy.md

---

📋 事项总览

#	事项	来源	状态
1	p_oversold 扫描器调度方式	cron-review#3 / 部署计划#3	⏳ 讨论中（实证：独立 cron 明显更优）
2	候选管道适配方案	cron-review#2	✅ 已实施（方案C，无需决策）
3	停 8 个冗余 cron	cron-review#1	⏳ 待讨论（#8 依赖已明朗：建议停）
4	健康监控注册 p_oversold	部署步骤5	⏳ 待讨论（依赖 1 结论）
5	策略参数定稿（v5 = 实盘参数？）	部署计划#1	⏳ 待讨论（建议最先讨论）
6	实盘资金规模	部署计划#2	⏳ 待讨论
7	观察期时长	部署计划#4	⏳ 待讨论
8	部署节奏（分步 or 一次到位）	部署计划#5	⏳ 待讨论

---

1️⃣ 事项一：p_oversold 扫描器调度方式

背景

predictive_oversold_scanner.py 已开发完毕（deploy/profile-scripts/），功能：大盘门控（mkt_rsi<50 + mkt_dd60≤-5% + 阴跌跳过）+ 12维信号 + 写 candidates（sector='p_oversold'）+ 当日幂等 + 单例守卫 + 600s 护栏。但尚未注册 cron，目前不自动跑。

选项对比

维度	A. 独立 cron（建议）	B. market_watch 链式
做法	新增 hermes cron 条目，对齐 mr_scanner 模式（35 9 * * 1-5）	塞进 market_watch.py 串行调用
优点	职责单一、独立监控/重启、失败不拖垮别的扫描器；与 v_weak/s2 现有模式一致	调度集中
缺点	多一条 cron 条目	market_watch 已耦合多任务，失败拖垮整链；其调度时机（371 行现有条目）不一定匹配开盘扫描需求
信号频率需求	盘前/开盘后一次即可（超跌信号不需要高频）	同左

我的建议

独立 cron（9:35 交易日）。超跌信号只需开盘后扫一次，独立运行最稳，符合"一个脚本一个调度"规范（DEVELOPMENT_STANDARDS 5.6）。

💬 讨论记录

• 2026-08-12 待老莫确认
• 2026-08-12 实证补充（小小莫查证）：
  • market_watch 实际调度 = */10 9-11,13-15 * * 1-5（每 10 分钟高频），职责是"市场数据采集 + market_regime 计算"，当前没有链式调用任何扫描器
  • 若 p_oversold 挂链式 → 每天会被连带跑 ~30 次（超跌信号日频足够，纯浪费资源）且混淆"采集 vs 策略扫描"职责
  • mr_scanner（v_weak）现有时段 = 35 9 * * 1-5（9:35 开盘后一次），p_oversold 与之同频最合理
  • 实证结论：独立 cron 明显更优（B 方案在高频采集任务上挂低频扫描是错配）

✅ 结论

【待定】

---

2️⃣ 事项二：候选管道适配方案

背景

p_oversold 扫描器写 candidates 表后，现有候选管道（candidate_filter 6 阶段评分 → promote_candidates RR>=2.0 提拔）是为 accumulation（主力建仓）设计的。超跌候选 RR 普遍<2（step39 数据验证），RR>=2 门槛会大量拒绝 p_oversold 候选——这正是 accumulation 现在 59 只全被拒的固有冲突，p_oversold 会重蹈覆辙。

选项对比

维度	A. 独立评估（建议）	B. 复用管道改门槛
做法	candidates 写 score_final 高分 + pass_final=1，绕过 candidate_filter 6 阶段评分，直接进 promote；promote 加 sector='p_oversold' RR 例外	修改 candidate_filter/promote 公共门槛，让 p_oversold 候选能过
优点	不污染 accumulation 管道；超跌策略的完整验证逻辑（12维+阴跌判定已在扫描器内做过）不被公共评分削足适履	管道统一
缺点	需改 promote_candidates（加 sector 例外）	改公共管道有回归风险；accumulation 的 RR 冲突问题被放大
代码改动量	小（promote 加一个例外分支）	大（公共逻辑分支化）

我的建议

方案A（独立评估）。超跌策略有自己完整的验证体系，套 accumulation 的评分+RR 是削足适履。

💬 讨论记录

• 2026-08-12 待老莫确认
• 2026-08-12 实证发现（小小莫查证）：方案C 已完整实施，无需再决策 ✅
  • 扫描器写入端（predictive_oversold_scanner.py 176-193）：score_final=8 + pass_final=1 直接标记绕过 candidate_filter，sector='p_oversold'，ON CONFLICT 当日幂等
  • promote 端（promote_candidates.py 132-137）：if _rr < 2.0 and cand_sector != "p_oversold" → p_oversold 候选跳过 RR>=2.0 门槛（commit 1f77f577，2026-08-11）
  • 两端配套，方案C 全链路就绪。文档选项 A/B 讨论已过时

✅ 结论

【已实施，无需决策】方案C（独立评估 + RR 例外）——扫描器写 candidates 直接标记 pass_final=1 绕过 6 阶段评分；promote_candidates 对 sector='p_oversold' 跳过 RR>=2.0 门槛。两端已于 2026-08-11 落地。

---

3️⃣ 事项三：停 8 个冗余 cron

背景

cron-review-poversold-20260811.md §四 梳理出 8 个重复/停摆/冗余的定时任务。停掉可减轻 246 负载（当前 66 个调度脚本）。

明细

#	cron	调度	现状	停的理由
1	策略评估-每日	0 21 * * 1-5	❌ 8/6 起 error	与"策略评估-每周"重复，每日版是早期半成品
2	市场精选推荐-每日	0 16 * * 1-5	❌ 7/31 起停摆	部署计划已明确废弃；新策略有专属扫描器
3	跨市场背离检测-周末	30 8-16/2 * * 0,6	重复	与工作日版（*/30 8-15）完全同脚本
4	宏观风险扫描-午间	30 11 * * 1-5	重复	与 8:30 版重复度 80%
5	宏观风险扫描-周末	0 10 * * 0,6	重复	与 8:30 版同脚本
6	行业富集-cninfo-午间	45 12 * * 1-5	重复	早间（7:50）已覆盖全部 active 策略
7	基本面刷新-午间	47 12 * * 1-5	冗余	PE/PB 一天变一次，早晚两次够
8	自选12维分析补全-每日午间	30 12 * * 1-5	⚠️ 待定	调度约 80 分钟与午间任务重叠；事项二已确认走方案C（独立评估），此通用补全对 p_oversold 价值下降

需要你确认的点

1. #2 市场精选推荐：7/31 已停摆，是彻底废弃还是修复重启？
2. #8 自选12维补全：事项二已定方案C（独立评估），#8 可停/降频——同意吗？
3. #1-7：直接停有没有顾虑？

💬 讨论记录

• 2026-08-12 待老莫确认
• 2026-08-12 事项二已定（方案C 已实施）→ #8 依赖条件已满足：通用 12 维补全对 p_oversold 无价值，建议停或降频

💬 讨论记录

• 2026-08-12 待老莫确认

✅ 结论

【待定】

---

4️⃣ 事项四：健康监控注册 p_oversold

背景

morning_health_check 当前没有 p_oversold 检查项；strategy_health 表只有 v_next4 一条（8/1）。扫描器上线后需要把 p_oversold 纳入每日健康监控（实盘 trades 数/胜率/回测偏差追踪）。

说明

• 不着急：等事项一（调度）和事项二（候选适配）定了、扫描器实际跑起来后再做
• 工作量小：morning_health_check 注册一个检查项 + strategy_health 表按日写入
• 健康度口径：实盘 trades vs 回测基线（10y 年化 18.57%）的偏差监控

💬 讨论记录

• 2026-08-12 待老莫确认（可后置到扫描器上线后）

✅ 结论

【待定，可后置】

---

5️⃣ 事项五：策略参数定稿（v5 = 实盘参数？）

背景

predictive_oversold_strategy.md 定稿 v5 参数（数据扫描验证，非拍脑袋）：

• 信号：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
• 入场：信号日收盘价买入
• 止损：科学支撑位（枢轴S2/筹码密集区）下方 5% 缓冲
• 止盈：科学压力位（枢轴R2/筹码阻力）分批卖
• 兜底：40 交易日强平
• 仓位：10 槽 × 每票 15% + 单日限 5

需要你确认的点

1. v5 这套参数直接作为实盘参数，还是观察期先用更保守的（如单日限 3、仓位 10%）？
2. 阴跌判定阈值（连跌2/ADX55/RSI33）文档已标注"需实盘持续监控有效性"——观察期是否加严（如 ADX≤50）？

我的建议

直接用 v5 实盘——全部阈值经 step27-49 数据扫描，回测复现 18.57% 已验证。观察期的意义是验证"实盘执行 vs 回测假设"的偏差（滑点/流动性），不是改参数。

💬 讨论记录

• 2026-08-12 待老莫确认

✅ 结论

【待定】

---

6️⃣ 事项六：实盘资金规模

背景

v5 回测口径：初始资金 100 万，10 槽 × 每票 15%（≈15 万/票），单日限 5 票。 组合 Tab 显示 v_weak 与 p_oversold 按 regime 分工，两策略并行时资金如何分配需定。

需要你确认的点

1. p_oversold 实盘投入多少资金？（独立账户 or 与 v_weak 共享资金池按比例切）
2. 观察期是否先用小资金（如 10 万）验证，达标后再放大？

我的建议

观察期小资金（10 万级）起步——验证实盘执行偏差（滑点/成交价 vs 信号日收盘假设）后，再按 regime 框架与 v_weak 分配。

💬 讨论记录

• 2026-08-12 待老莫确认

✅ 结论

【待定】

---

7️⃣ 事项七：观察期时长

背景

部署流程最后一步"观察期实盘验证"。文档未定义观察期时长和达标标准。

需要你确认的点

1. 观察期多久？（建议至少覆盖一个弱市波段——超跌策略只在弱市出信号，强趋势市可能数周无信号）
2. 观察期达标标准？（建议：实盘信号数/胜率与回测基线偏差 <20%）

我的建议

至少 1 个月，且期间需出现 ≥3 次信号（月均 7.3 信号/10 年基线）——若 1 个月无信号属正常（策略稀缺性），顺延至信号样本足够再评估。

💬 讨论记录

• 2026-08-12 待老莫确认

✅ 结论

【待定】

---

8️⃣ 事项八：部署节奏（分步 or 一次到位）

背景

部署流程 6 步：①研究侧注册（已完成）→ ②scanner dry-run → ③候选管道小样本验证 → ④全链路开通 → ⑤健康监控+知微交接 → ⑥观察期实盘验证。

选项对比

维度	A. 严格分步（每步验证后推进）	B. 合并推进（dry-run 过了直接全链路）
优点	风险最小，每步可回退	快（超跌信号稀缺，等信号验证可能要数周）
缺点	慢，窗口期可能错过行情	出问题影响面大
适用	生产系统谨慎原则	扫描器有幂等+守卫+护栏兜底，风险可控

我的建议

②③合并（dry-run 直接带小样本管道验证），④⑤合并，⑥独立——扫描器本身风险低（只写 candidates 不交易），不需要过度分步。

💬 讨论记录

• 2026-08-12 待老莫确认

✅ 结论

【待定】

---

📌 讨论进度日志

时间	事项	结论
2026-08-12	（文档创建，4 件事）	全部待讨论
2026-08-12	（补充 5-8 战略级事项）	事项一已摆出待老莫决策；补全后共 8 件
2026-08-12	事项一：补 market_watch 实证	挂链式=每天连带跑~30次错配，独立 cron 明显更优（待老莫最终确认）
2026-08-12	事项二：发现已实施	✅ 方案C（独立评估+RR例外）2026-08-11 已落地，无需决策
2026-08-12	事项三：#8 依赖明朗	事项二定方案C → #8 通用补全建议停/降频（待老莫确认）