本文面向梦幻西游手游时空客户端相关的桌面自动化开发与使用场景。金手指的判断依赖当前窗口截图、窗口矩形、模板文件和可复核日志,具体表现会受到客户端画面、Windows 缩放、窗口位置及运行权限影响。下面只讨论当前项目代码中已经存在的结构和排查方法,不把示意图冒充软件截图,也不虚构用户案例、排名、收录量或效果数据。关键内容即使不加载图片也能通过正文理解。

把任务拆成可观察状态

把任务拆成可观察状态

捉鬼任务的自动化流程不应写成一串无条件点击,而应拆成入口、准备、执行中、结果确认和结束或异常等状态。每个状态都要有可观察的画面条件,例如按钮、提示文字、任务面板或窗口层级。状态名称写入日志后,才能知道程序是在入口没有找到,还是已经进入任务却没有完成确认。

入口识别不等于任务已开始

识别到入口按钮只能说明当前画面存在候选目标,不能直接推出任务已经开始。点击前要确认窗口仍是目标窗口,点击后要重新截图,检查入口是否消失、任务面板是否变化或新的提示是否出现。若画面没有变化,应记录未推进原因并重新观察,而不是连续发送同一动作。

执行中要等待画面变化

执行中通常会经历等待、移动、弹窗或短暂菜单等变化。等待函数应允许停止事件打断,并在关键节点重新采集画面。短暂界面不宜无限重复扫描,因为重复采集可能错过出现窗口;更稳妥的做法是保留一次同帧截图,先比较候选状态,再点击第一个可靠命中。

结果确认要有明确证据

结果确认需要来自明确的画面证据,例如完成文字、下一阶段入口或任务面板状态改变。内部变量被设置为完成,只代表代码路径走到某个位置,不能替代外部画面确认。若结果文字识别存在空格、换行或颜色差异,应先做文本归一化,再把原始识别结果和归一化结果同时写入日志。

异常分支要回到可判断状态

遇到窗口遮挡、识别为空、任务中断或结果不明确时,先退回到可观察状态:重新确认前台窗口、保存截图、读取矩形和检查停止事件。异常处理的目标是恢复判断条件,而不是盲目扩大搜索区域或降低阈值。每个异常分支都应有明确的下一次观察点。

捉鬼任务从入口识别到结果确认和异常分支的状态图
捉鬼任务从入口识别到结果确认和异常分支的状态图

排查时建议一次只改变一个条件,并保留窗口矩形、截图时间、识别框、匹配分数和最终动作。若要了解窗口移动后的相对识别,可阅读窗口相对识别说明;需要了解多尺度模板时,可参考多尺度模板匹配实践

复核记录怎么写

状态机的边界应写清楚进入条件、成功条件、超时条件和停止条件。进入条件来自当前画面,成功条件来自下一张验证图,超时条件负责留下证据,停止条件优先于后续动作。这样任务衔接时不会因为一个内部标志而跳过结果确认。

如果同一任务出现多种合法画面,应把它们归入同一状态而不是复制整段动作。模板、文字和窗口状态可以组成多个证据来源,但必须说明最少满足哪些条件。异常重试也要限制在当前状态,避免重试动作越过菜单或重复消耗任务次数。

在任务组合中,上一阶段的完成证据应成为下一阶段的输入条件。若只依靠计数器推进,重启或异常后容易从错误位置继续;保存阶段、最近截图和结束原因,恢复时先重新观察再决定动作。\n\n本节内容应与实际运行日志一起核对,页面文字用于说明方法,具体结果以当前环境中的截图、窗口信息和代码行为为准。\n\n排查结束后再恢复完整任务链,先确认当前窗口、当前阶段与当前模板条件没有变化。\n\n实际发布前还要检查标题、摘要、canonical、封面图、图注、站内链接、移动端换行和页面 HTTP 状态,发布后的 URL 以站点返回结果为准。