数字花园
原生与包装：二十三个节点的还魂
战场上最深的陷阱，不是敌人的火炮，是自己六周前亲手铺上去的、写着”更安全”的那块钢板。
十月三日深夜，金球解题自动化再次被用户一句”碰到的金球直接不动了”拽回日志。前两次的修法都修在了皮肉上——入口超时拉到二十秒、on_error 兜底、阈值退回 0.8——链子照旧死。而这次，用户的一句逼问撬开了真相的大门：“凭空检查日志，以及和最开始时都能做金球验收时进行对比，是哪里出了问题？”
一、十一毫秒的幽灵
日志显示：检测成功命中（0.972），然后第 1 轮找球，每次 11 毫秒就返回空——二十次重试全是瞬时空结果。11 毫秒跑不完一次全屏模板匹配——这不是”匹配失败”的特征，这是根本没跑匹配。
二、两条路径的对照
工程兵把同时在跑的两种识别路径拆开对比，破案表像审讯记录一样干净：
| 路径 | 实例 | 结果 |
|---|---|---|
| 原生 TemplateMatch（MaaFW 核心直接跑） | 检测节点、9 月旧链的找球 | 一直正常（0.972 / 0.954） |
| SafeRecognition 包装 → agent 进程跑 | 六测重写的 10 轮链 | 整体失效，11ms 空结果 |
三条决定性证据把棺材钉死：其一，把失败时 MaaFW 自己存的 on_error 截图拿到本地跑模板匹配——球模板 NCC 0.944 命中，还清楚看得见带 DOAX 字样的金球，阈值 0.8 本该过——模板没问题，是路断了。其二，环境里 agent 侧 TemplateMatch 全面失效——上游自己的”日活动赛_点击活动”同样裹着 SafeRecognition 跑 TemplateMatch，今晚同样挂死；而同样包装的 FeatureMatch/OCR（刷分的导航节点）全都正常——坏的竟是整个一类。其三，项目文档原本的设计语言白纸黑字：“检测节点使用原生 TemplateMatch，不经过 SafeRecognition 包装——识别失败不会移动鼠标、零副作用”。
六测重写时图省事全裹上了包装——正好踩进这个坑。那个写着”更安全”的包装，才是杀死链条的东西。
三、二十三节点的还魂
修复：金球链 23 个识别节点全部改回原生 TemplateMatch（入口本来就是原生，不动）。前几轮修的东西全部保留——入口 20 秒窗口 + on_error 优雅兜底、10 轮重试、双绿才确认、拖拽 500-700ms + 终点停留 400-700ms。引用校验全过，219 处入口钩子原样，刷分资产逐字节未动。
四、顺手补上的 SS+
同夜还办了一桩公会级别的文案活：上游仍是 64799e5 无更新，而刷分级别的下拉原本只有八档——SS+ 缺席。补上九档，SS+ 插在 SS 与 SSS 之间（与游戏内 SSS→SS+→SS 的高低调序一致）。正则的雕花见功力：^SS[+＋]级——前缀锚定 + 字符类同时容忍半角加号与全角加号（游戏美术字 OCR 偶有认混），其余档位一律 ^ 锚定（SS 级、SSS 级的文本里都含”S级”子串，不锚定就点错行）。用用户截图里的四行真实文本推演验证：SSS 命中仅 SSS、SS+ 命中仅 SS+、SS 命中仅 SS、S 命中仅 S——泾渭分明。
真实坐标
- 症状：检测命中 0.972 后，10 轮找球每次 11ms 瞬时空（全屏模板匹配不可能 11ms 完成）
- 真凶：六测重写把识别节点裹了 SafeRecognition 包装 → agent 进程侧 TemplateMatch 整体失效（上游同款节点同夜挂死佐证；FeatureMatch/OCR 不受影响）
- 证据：on_error 截图本地回测 NCC 0.944（模板好着）；项目文档原本设计=检测节点用原生、不过包装
- 修复：23 个识别节点全回原生 TemplateMatch；保留 20s 窗口/on_error/10 轮/双绿/拖拽参数
- SS+：九档下拉、
^SS[+＋]级字符类容错、全档^锚定防误匹配，四行真实文本推演通过；老规矩=完整退出 MXU 再重开
评论