10 KiB
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 | ⏳ 讨论中 |
| 2 | 候选管道适配方案 | cron-review#2 | ⏳ 待讨论 |
| 3 | 停 8 个冗余 cron | cron-review#1 | ⏳ 待讨论 |
| 4 | 健康监控注册 p_oversold | 部署步骤5 | ⏳ 待讨论（依赖 1/2 结论） |
| 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 待老莫确认
✅ 结论
【待定】
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 待老莫确认
✅ 结论
【待定】
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 分钟与午间任务重叠；若事项二走独立评估，此任务价值下降 |
需要你确认的点
- #2 市场精选推荐：7/31 已停摆，是彻底废弃还是修复重启？
- #8 自选12维补全：是否停？取决于事项二的结论（p_oversold 走独立评估则可停/降频）
- #1-7：直接停有没有顾虑？
💬 讨论记录
- 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
需要你确认的点
- v5 这套参数直接作为实盘参数，还是观察期先用更保守的（如单日限 3、仓位 10%）？
- 阴跌判定阈值（连跌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 分工，两策略并行时资金如何分配需定。
需要你确认的点
- p_oversold 实盘投入多少资金？（独立账户 or 与 v_weak 共享资金池按比例切）
- 观察期是否先用小资金（如 10 万）验证，达标后再放大？
我的建议
观察期小资金（10 万级）起步——验证实盘执行偏差（滑点/成交价 vs 信号日收盘假设）后，再按 regime 框架与 v_weak 分配。
💬 讨论记录
- 2026-08-12 待老莫确认
✅ 结论
【待定】
7️⃣ 事项七：观察期时长
背景
部署流程最后一步"观察期实盘验证"。文档未定义观察期时长和达标标准。
需要你确认的点
- 观察期多久？（建议至少覆盖一个弱市波段——超跌策略只在弱市出信号，强趋势市可能数周无信号）
- 观察期达标标准？（建议：实盘信号数/胜率与回测基线偏差 <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 件 |