录制脚本与回放环境的差异
录制的脚本在执行时出错，超过七成的问题出在录制环境和回放环境不一致。录制时游戏窗口的大小、分辨率、UI布局被固定下来了，脚本记录的是这个特定状态下每个点击位置的屏幕坐标。回放时如果窗口被拖动、分辨率改变或者UI缩放比例不一样，脚本点击的还是原来的坐标点，但那个位置对应的按钮已经挪走了，自然就点不中。
游戏画面更新也是同样的道理。录制的脚本依赖画面中的颜色特征或图像特征来识别目标位置，版本更新后按钮颜色换了、图标改了、甚至按钮位置微调了几个像素，脚本的特征匹配就会失败，要么点错要么直接卡住不动。
不同网络延迟下脚本节奏错乱
录脚本的时候网速好，每个操作之间的间隔很短，脚本记录下来的就是这种快节奏。回放时网络波动大或者服务器负载高，前一个动作还没返回结果，脚本已经执行下一步了。比如录的时候一刀砍出去怪物立刻掉血，脚本接着放下一刀；回放时延迟高了，上一刀的伤害结果还没回来，脚本认为打完了继续执行后续操作，实际游戏画面还停在原地，后续所有动作全部错位。
这是录制脚本最隐蔽的坑，看起来脚本在正常跑，实际上每一拍都比游戏画面快半拍，几轮操作下来整个流程全乱。
游戏内随机因素的干扰
传奇这类游戏里大量存在随机判定。怪物刷新位置不固定，录制时怪物在坐标(100,200)刷出来，脚本记录的是跑向这个坐标然后施法。回放时怪物刷在了(150,180)，脚本还是跑向(100,200)，到地方发现什么都没有，脚本就卡住了。BOSS技能触发时机也是随机的，录制的时候BOSS在第5秒放了一个技能，脚本记录了这个时间点做躲避操作，回放时BOSS第3秒就放了技能，脚本的躲避操作完全对不上时机。
这类随机性靠单纯的录制功能无法解决，脚本需要加入动态识别和逻辑判断能力。
图片和文字识别的参数设置不当
如果用到了图片识别功能来找目标，相似度阈值设置太严会导致稍微有点变化就认不出来，设置太松又会把背景当作目标。识别区域设置过大，画面里干扰元素多匹配速度慢还可能误识别；设置过小，目标稍微偏一点就超出识别范围。
文字识别受字体和背景颜色的影响很大。游戏内聊天框里不同玩家说话颜色不一样，怪物名字颜色也五花八门，脚本如果只识别一种固定颜色的文字，其他颜色的同样文字就会漏掉。识别范围的背景变化也会干扰结果，背景从草地变成石板路面，文字识别的准确率就会明显下降。
脚本编写阶段的处理方式
录制功能只能记录固定坐标和固定时间间隔的操作序列，任何偏离录制条件的情况都会导致错误。真正稳定的脚本需要手写或者修改录制生成的代码，加入等待条件判断、图像匹配循环、异常恢复路径等机制。
每个操作之间留动态等待时间，不要用固定延迟。比如点击攻击按钮后，用循环检测战斗状态或者怪物血量变化来判断攻击是否真的执行了，而不是硬等1.5秒。找怪物的逻辑从固定坐标改成全屏扫描加特征匹配，先截取屏幕图像，用模板匹配或特征点识别找到目标位置再操作。自动补血功能监测角色血量数值变化而不是固定的时间间隔。遇到脚本卡住的情况加上超时重置机制，连续三次操作失败就重新初始化当前任务状态。
测试与调试流程
写好的脚本先在单机版或者测试服务器上跑几轮，把每一步执行日志记录下来，截图保存每轮的关键状态。出错的时候对照日志和截图看哪一步的实际画面和预期不符。调整参数后重新测试，直到稳定运行多轮没有报错再放到正式环境使用。正式环境跑的时候保持画面设置和测试环境一致，窗口大小、分辨率、画质选项全部固定下来不要改动。
录制的脚本在执行时出错，超过七成的问题出在录制环境和回放环境不一致。录制时游戏窗口的大小、分辨率、UI布局被固定下来了，脚本记录的是这个特定状态下每个点击位置的屏幕坐标。回放时如果窗口被拖动、分辨率改变或者UI缩放比例不一样，脚本点击的还是原来的坐标点，但那个位置对应的按钮已经挪走了，自然就点不中。
游戏画面更新也是同样的道理。录制的脚本依赖画面中的颜色特征或图像特征来识别目标位置，版本更新后按钮颜色换了、图标改了、甚至按钮位置微调了几个像素，脚本的特征匹配就会失败，要么点错要么直接卡住不动。
不同网络延迟下脚本节奏错乱
录脚本的时候网速好，每个操作之间的间隔很短，脚本记录下来的就是这种快节奏。回放时网络波动大或者服务器负载高，前一个动作还没返回结果，脚本已经执行下一步了。比如录的时候一刀砍出去怪物立刻掉血，脚本接着放下一刀；回放时延迟高了，上一刀的伤害结果还没回来，脚本认为打完了继续执行后续操作，实际游戏画面还停在原地，后续所有动作全部错位。
这是录制脚本最隐蔽的坑，看起来脚本在正常跑，实际上每一拍都比游戏画面快半拍，几轮操作下来整个流程全乱。
游戏内随机因素的干扰
传奇这类游戏里大量存在随机判定。怪物刷新位置不固定，录制时怪物在坐标(100,200)刷出来，脚本记录的是跑向这个坐标然后施法。回放时怪物刷在了(150,180)，脚本还是跑向(100,200)，到地方发现什么都没有，脚本就卡住了。BOSS技能触发时机也是随机的，录制的时候BOSS在第5秒放了一个技能，脚本记录了这个时间点做躲避操作，回放时BOSS第3秒就放了技能，脚本的躲避操作完全对不上时机。
这类随机性靠单纯的录制功能无法解决，脚本需要加入动态识别和逻辑判断能力。
图片和文字识别的参数设置不当
如果用到了图片识别功能来找目标，相似度阈值设置太严会导致稍微有点变化就认不出来，设置太松又会把背景当作目标。识别区域设置过大，画面里干扰元素多匹配速度慢还可能误识别；设置过小，目标稍微偏一点就超出识别范围。
文字识别受字体和背景颜色的影响很大。游戏内聊天框里不同玩家说话颜色不一样，怪物名字颜色也五花八门，脚本如果只识别一种固定颜色的文字，其他颜色的同样文字就会漏掉。识别范围的背景变化也会干扰结果，背景从草地变成石板路面，文字识别的准确率就会明显下降。
脚本编写阶段的处理方式
录制功能只能记录固定坐标和固定时间间隔的操作序列，任何偏离录制条件的情况都会导致错误。真正稳定的脚本需要手写或者修改录制生成的代码，加入等待条件判断、图像匹配循环、异常恢复路径等机制。
每个操作之间留动态等待时间，不要用固定延迟。比如点击攻击按钮后，用循环检测战斗状态或者怪物血量变化来判断攻击是否真的执行了，而不是硬等1.5秒。找怪物的逻辑从固定坐标改成全屏扫描加特征匹配，先截取屏幕图像，用模板匹配或特征点识别找到目标位置再操作。自动补血功能监测角色血量数值变化而不是固定的时间间隔。遇到脚本卡住的情况加上超时重置机制，连续三次操作失败就重新初始化当前任务状态。
测试与调试流程
写好的脚本先在单机版或者测试服务器上跑几轮，把每一步执行日志记录下来，截图保存每轮的关键状态。出错的时候对照日志和截图看哪一步的实际画面和预期不符。调整参数后重新测试，直到稳定运行多轮没有报错再放到正式环境使用。正式环境跑的时候保持画面设置和测试环境一致，窗口大小、分辨率、画质选项全部固定下来不要改动。