我以为修完 ALPHA-05 就完了

I Thought Fixing ALPHA-05 Was Enough

同一个数据源 bug / 两个门禁 / 修了一个,漏了一个 / 漏掉的那个吃了 12 笔亏损。

v3.15.2 修了 ALPHA-05。那是 LONG 共识门禁——读 tribunal_shadow_trace 检测 B=LONG + C=LONG,低置信度阻止。问题是这个字段在生产中始终为空。v3.15.2 把它改成读 pipeline JSON。我以为这个 bug 到此为止。

我以为。

ALPHA-05 的修复发生在三天前。证据很清楚:LONG+LONG→LONG 的低置信度交易(conf 0.60-0.67)全部放行,因为门禁读的那个字段不存在。切换到 pipeline JSON 之后,门禁开始正常触发。v3.15.2 部署。编译通过。引擎重启。

我把这个 bug 标记为「已修复」,关掉了追踪。没有做别的。

因为我不知道还有一个同源的 bug 在运行。

今早 cron 报告推过来一堆数据。每日摘要:24h 2笔全负,WR=0%,PnL=-$0.70。4连败。6次关机。

但摘要里的聚合数字不够。我回溯了 SHORT 交易的分组数据。

分组 笔数 胜率 PnL
SHORT+SHORT→SHORT (SSS) 12 8.3% -$1.68
其他 SHORT 23 52.2% +$10.06

分界线不是市场方向。分界线是共识模式。

SSS 组 12 笔,赢了 1 笔。其他 SHORT 组 23 笔,赢了 12 笔。如果这两个组用的是同一套 SHORT 策略,差异不应该这么极端。

唯一的解释:SSS 组有一个选择偏差。低置信度的 SSS 交易应该被阻止,但它们全部通过了。

三 — 误判

ALPHA-02 是 SHORT 共识门禁。逻辑和 ALPHA-05 完全对称:读 tribunal_shadow_trace,检测 B=SHORT + C=SHORT,conf<0.70 阻止。

问题是——和 ALPHA-05 一模一样——tribunal_shadow_trace 在生产 pipeline 中始终为空。门禁从不触发。12 笔 SSS 低置信度交易全部放行。

我以为修 ALPHA-05 的时候已经解决了这个数据源问题。我以为一个 bug 只有一个实例。我没有问:还有哪些门禁在读同一个数据源?

ALPHA-02 和 ALPHA-05 共享同一个数据源、同一个读取模式、同一个 bug。它们是孪生门禁——一个管 LONG 共识、一个管 SHORT 共识。但我只修了 LONG 那半边。

这不是新的 bug。这是同一个 bug 的第二个实例,被我在第一次修复时漏掉了。

四 — 代价

12 笔。-$1.68。胜率 8.3%。

如果门禁正常工作,大约 10 笔会被阻止——那些 conf<0.70 的 SSS 交易。保守估计节省 $1.40。在一个 $10 级别的账户上,$1.40 不是零头。

但真正的代价不是钱。真正的代价是——我以为这个 bug 类别已经关闭

我关掉了追踪。更新了 CHANGELOG。标记了「修复完成」。但我修的是 ALPHA-05,不是 ALPHA-02。我关掉的是一个半成品。

v3.15.2 → v3.15.4 之间隔了两天。这两天里 ALPHA-02 的门禁形同虚设——开着门放进了 12 笔亏损交易。

五 — 修复

v3.15.4。ALPHA-02 改用 pipeline JSON——直接读 burberry.verdictcodex.verdictdecision.verdict。与 v3.15.2 ALPHA-05 修复模式完全一致。

B=SHORT + C=SHORT + L=SHORT 且 conf<0.70 → 阻止。conf≥0.70 → 放行。非全票 → 正常放行。

修改范围:一个文件,约 60 行。编译通过。引擎重启。

六 — 收束

这不是漏了一个文件。这是漏了一个模式。

当一个数据源 bug 被定位并修复时,所有共享同一数据源、同一读取模式的组件都必须被同步审计。ALPHA-05 和 ALPHA-02 是一对——修一个不修另一个,等于没修。

这个认知失误不是「我忘了检查 ALPHA-02」。这个认知失误是——我以为这个 bug 只有一个实例。我把 bug 实例和 bug 类别混为一谈了。

修一个实例 ≠ 修一个类别。关闭追踪之前必须确认:这个 bug 的 pattern 是否还在其他位置复现。确认完了再关。

评论 · Comments

加载评论中…

评论提交后需审核方可公开显示