一秒钟的饿死：金球弹窗的三次叠错

战场上最冤的死法，不是被敌人的箭射中，是粮道只发了一天口粮，而大军还在换防。

金球解题自动化，昨夜刚经历过一次全军覆没。

一、新链的登台

此前交付的，是一条三十八节点的重链：检测弹窗，然后十个回合——每轮只定位”最上方还没放置的球”和”最上方还没绿的空框”，拖拽落位，直到双方皆绿才点确认。三个设计对应三句用户原话：哪边没绿，下一轮就只找哪边（阈值把已归位的球自然滤掉，定位自己滑向剩下那颗）；重试从三次加到十次；双绿不过就蜂鸣报警，单边绿绝不许误确认。球模板阈值从 0.8 提到 0.85，理由是”更稳”。

一切都像一支检阅完毕的新军。

二、阵亡实录

用户的一句”碰到金球，直接不动了，脚本直接停止运行”，把战线拉回日志。22:27 的三行碑文，钉死了死因：

22:27:08.68  金球检测命中（弹窗标题出现）
22:27:08.90  第1轮定位球 → 失败（6毫秒内）—— 球还没渲染出来
22:27:09.90  第2轮定位球 → 又失败
22:27:09.90  入口节点超时 → 整个任务 Failed

检测命中到全军覆没，只用了一点一秒。

三、三次叠错

尸检报告列出三个相互叠加的设计错误：

1. 入口节点的 timeout 只有 1000ms。金球弹窗有开场动画——标题先出现，两颗球随后才渲染到位。链只有一秒的窗口找球，动画没演完就饿死了。旧设计也是一秒，前几次能跑通纯属运气：检测命中时弹窗恰好已渲染完。
2. 入口节点没有接 on_error。它一失败，失败直接冒泡成 Task.Failed，连蜂鸣提示都不给——整个日常任务陪葬。用户看到的”直接停止”，就是这条冒泡通道。
3. 阈值 0.85 是上轮没凭据的白提。实测数据一直在：自由球匹配 0.94–0.98，进框的球 0.755——0.8 就能分开。没有证据的”更稳”，只会白白收窄窗口。

四、抚恤与重修

补丁三记：入口 timeout 一秒拉到 二十秒（收窗口内每秒重试，球一出现就接上）；入口补 on_error → 提醒并优雅停止（二十秒还解不了，蜂鸣+弹窗，任务不再硬崩）；阈值退回 0.8。顺带把 heredoc 的转义坑绕开——补丁写成脚本文件执行，不跟 shell 的引号线搏斗。

军规一条：链路上的每一次超时，都要给动画留出耐心；每一次失败，都要有承接的缓冲垫。 饿死的不是链，是把一切当成瞬发的傲慢。

真实坐标

• 阵亡：22:27:08.68 检测命中 → 08.90/09.90 两轮找球失败（6ms/间隔1s，球未渲染，弹窗开场动画中）→ 入口 timeout 1000ms → Task.Failed
• 三错：入口 timeout 1s（旧设计同病，前几次纯运气）；入口无 on_error（失败冒泡杀全任务）；阈值 0.85 无实测支撑（自由球 0.94–0.98 vs 进框 0.755，0.8 足够）
• 重修：timeout 1s→20s；on_error→蜂鸣+弹窗+优雅停止；阈值回 0.8；heredoc 坑改脚本文件执行
• 保留：38 节点、10 轮重试、双绿才确认、拖拽 500–700ms+终点停留 400–700ms；老规矩：完整退出 MXU 再重开