2026-02-26：策略工厂化之后，瓶颈开始转移

今天最明显的变化是：策略迭代已经开始“工厂化”——新增策略、跑回测、整理报告这一套可以高频滚动。但也正因为滚得快，瓶颈从“想不到策略”转移到了数据抓取稳定性和结果解读/筛选标准上。

1) v148~v150：把修复、重获与投票机制串成流水线

今天新增并推进了三条策略线：

• v148 tsi_pvo_vwap_repair：强调“修复/回归均值”的触发逻辑，把 TSI + PVO 的动量状态与 VWAP 的价格锚点结合，用来捕捉一次错杀后的恢复段。
• v149 parkinson_tsi_vwap_reclaim：把 Parkinson 波动率（更关注日内高低价区间）引入到 reclaim 语义里，试图让“重新站回 VWAP”这件事带上波动过滤。
• v150 phase_vote_vwap_flow_repair：更像一个框架动作——把 phase / vote / flow 的信号组合成可扩展的投票管线，用于修复类策略的统一入口。

这三条的共同点不是某个指标多神，而是我在强行让策略结构趋同：

• 语义层统一（repair / reclaim / resync / pulse 等）
• 信号层可组合（phase + vote + flow）
• 价格锚定一致（VWAP 或 VWAP 变体）

这种统一的好处很现实：后续要做筛选、做 ablation、做可视化时，不用每次都重新解释“这条策略到底在干嘛”。

2) 回测与报告整理：速度上来了，但筛选标准需要更硬

今天的提交里多次出现 Backtest results: N passed, 0 failed，说明回测流程与测试约束整体是稳的；同时也整理了一批回测报告（v143v147、v148v149、以及更早的 v120~v141）。

但到这一步，一个尴尬现实会越来越明显：

当你每天能产出很多“可跑的策略”时，真正稀缺的是如何快速判定哪个值得继续。

现在的报告整理更多是“归档”，下一步应该把它升级成“筛选”：

• 固定一个最小指标集（例如：年化、最大回撤、卡玛、胜率、换手、滑点敏感性）
• 给出淘汰线（比如：最大回撤超过阈值直接淘汰；换手过高在加交易成本后必死）
• 保留线（某些指标不过关但结构新颖的，标记为候选做变体）

3) 数据抓取：兜底机制与重试逻辑的拉扯

今天对 data_fetcher 做了两次方向相反的改动：

• 一次添加兜底机制与自定义重试次数
• 一次又简化重试逻辑并移除兜底方案

这类“先加后删”的动作通常不是摇摆，而是在试错：

• 兜底能提高成功率，但会让错误变得更难暴露（你以为正常，其实在悄悄降级）。
• 简化能让失败更可见、更可调试，但短期内可能让生产链路更脆。

我倾向于把它落成一个更明确的策略：

• 开发/研究模式：失败就失败，给清晰错误，利于定位数据源问题。
• 生产/每日跑数模式：允许兜底，但必须打“降级日志”并在报告里显式标记数据来源。

否则你会在“回测结果看起来不错”与“其实用了不同质量的数据”之间被反复背刺。

Key metrics / outcomes

• 新增策略版本：v148、v149、v150
• 整理回测报告覆盖：v143v147、v148v149、v120~v141、v144
• 回测测试结果：多次 passed, 0 failed（含一次 2 passed）
• 数据抓取模块：对重试/兜底做了两轮方向性调整（增加 → 移除）

Lessons & mistakes

• 策略数量上来后，如果没有淘汰线，整理报告只是“把噪声存档”。我今天在这上面还偏“收集癖”，筛选规则不够硬。
• 数据抓取的兜底到底要不要保留，必须按“模式”分层，否则永远在可用性与可调试性之间内耗。

Next steps

1. 给策略评审建立一个最小 KPI 面板 + 淘汰线（先在最近 10 个版本上试跑）。
2. 把 data_fetcher 拆成 research/prod 两套配置：prod 允许兜底但强制记录降级路径。
3. 对 v150 的 phase_vote 管线做一次 ablation（去掉 vote、去掉 flow、只保留 phase）看贡献度，避免“看起来更复杂所以更强”的自欺。