全键盘版猫咪代打：基于SendInput的稳定按键自动化脚本-北京尧图网络

简介《超萌猫咪代打全键盘版》是一份基于 GitHub 开源项目 Bongocat-osu 改造的趣味桌面程序源码与素材沿用开源思路把猫咪敲击动画同键盘输入绑定适合想边玩边练打字、对游戏开发或开源二次改造有兴趣的玩家和学习者使用。压缩包内共 352 个文件以 283 张 png 图像素材为主体搭配 28 个 json 配置、21 个 flac 音效、13 个 dll 运行库、3 个 moc3 动画模型与 2 个 exe 主程序整体约 14.46MB结构精简便于按图像、音频、配置和运行库分目录查看。项目已吸引 1859 人学习/下载。除可直接双击运行的客户端外包内还保留了完整的多媒体资源和关键依赖既能让普通用户快速体验全键盘版猫咪代打节奏交互也可供开发者参考 SFML 与 WPF 混用下的图形音频调度、键盘事件监听以及猫咪动作同步方式作为轻量级开源游戏改版的练手样本。1. 超萌猫咪代打全键盘版把重复按键交出去脚本只做一件事猫咪代打全键盘版不是一只猫在替你玩游戏而是一套纯键盘事件驱动的自动化脚本专门负责游戏签到、领体力、批量表单这类机械重复操作。它和鼠标宏、图像识别脚本最大的区别在于不依赖屏幕坐标不做像素匹配只向操作系统发送按键事件窗口移动了、分辨率变了序列照样跑。适合两类人一类每天被重复按键消耗时间的玩家或办公党另一类是刚接触 Windows 键鼠自动化、想用最小成本跑通一个完整方案的开发者。“全键盘版”的核心约束是只靠键盘完成触发、循环和急停这让它的状态逻辑比图像方案简单得多也比鼠标宏更抗环境变化。命令行里你能看到日志但多数时候它安静地挂在那里等热键按下。2. 全键盘代打的底层逻辑为什么按键事件比坐标和像素更靠谱2.1 三种自动化方案的取舍鼠标宏、图像识别、全键盘脚本先说结论方案没有绝对好坏只有“和环境是否匹配”。自动化的三条常见路线我拆开讲。鼠标宏是最常见的入门玩法。它把鼠标移动轨迹、点击坐标和延时原样记录然后回放。优点是实现极简单录一遍就能用缺点是坐标是死的窗口一挪、分辨率一变宏就打在空白处这在游戏窗口化切换时特别致命。图像识别方案是截屏后做模板匹配或 OCR能反查按钮位置适应性最强但代价是截屏和处理都得吃 CPU/GPU识别一帧上百毫秒很正常而且画面一有光影变化匹配就会出“玄学”结果调阈值能调一晚上。全键盘脚本走的是第三条路不管屏幕上画的是什么只向系统发送按键事件。它没有坐标不需要截图整个逻辑就是一条按键序列流。优势非常直接轻量、稳定、环境无关。代价是它完全没有视觉反馈——不知道按钮有没有弹出来不知道页面加载完没有只能靠固定延迟和节奏来推进。所以全键盘脚本适合“流程固定、不需要观察画面”的任务比如每日签到、连点对话框、批量录入表单不适合“走到岔路口需要判断往哪走”的流程。什么时候不要选全键盘如果任务中间有“看到某按钮变亮再点”这类需要看画面的判断全键盘就直接出局。这时候老老实实上图像识别或者干脆人肉盯着别让方案迁就想法。三类方案我一般这样选要判断画面选图像识别要无脑连点选鼠标宏要长流程、要跨窗口稳定选全键盘。2.2 虚拟键码与扫描码按键到事件要过两道闸Windows 里一个物理按键被按下去系统会生成两层标识虚拟键码Virtual-Key CodeVK描述“按的是哪个键”扫描码Scan Code描述“物理键盘上哪个位置的键被按下”。我们平时写的按键常量比如VK_RETURN0x0D指回车VK_SPACE0x20指空格这些都是 VK 码。到了应用层键盘事件在多数情况下走消息队列WM_KEYDOWN/WM_KEYUP普通窗口只要收到消息就能响应。但有些目标程序不走寻常路要么直接调用GetKeyState实时轮询按键状态要么用 Raw Input 读原始输入要么对扫描码做校验。这时只发 VK 码会翻车——程序根本没反应或者行为异常。我在 Windows 上做按键注入时默认用SendInput而不是keybd_event并且同时填 VK 码和扫描码。原因有两层第一keybd_event是旧接口对扩展键和扫描码的支持不完整第二SendInput可以带KEYEVENTF_SCANCODE和KEYEVENTF_EXTENDEDKEY标志把一条按键消息补全成和真实键盘几乎一致的输入。关键参数如下按键VK 码扫描码扩展键A0x410x1E否空格0x200x39否回车0x0D0x1C否右方向键0x270x4B是需 0xE0 前缀扩展键的标志很容易被忽略。方向键、Home/End、小键盘区这些键的扫描码都需要加KEYEVENTF_EXTENDEDKEY前缀漏掉之后某些框架会把一次“右方向键”识别成其他键表现就是脚本执行的每一步都和预期差一位。按键事件从系统到应用的完整链条是SendInput→ 系统输入队列 → 当前焦点窗口的消息队列 → 应用处理。任何一环丢消息按键就无声无息地没了。常见丢消息场景有两个窗口没焦点、输入法还在中间拦了一道。前者看 3.4 的焦点管理后者是 5.1 的输入法坑。脚本开发者唯一能控制的是注入端所以注入端越接近真实硬件事件越好。SendInput能同时携带 VK、扫描码、扩展键标志已经是用户态能给出的上限再往底走就是驱动级方案那属于另一个风险等级日常脚本不需要碰。2.3 事件驱动与状态机猫咪脚本不容易跑飞的原因全键盘脚本没有画面反馈如果从头到尾是一条长按键序列中间任何一步卡住后面全部连锁错位。所以我把脚本设计成状态机每个状态维护自己的按键序列状态之间靠延时和计数推进。以游戏日常任务为例我会拆成五个状态启动定位激活窗口、确认焦点、进场准备按空格跳过开场、按回车确认、核心循环签到/领奖/送好友循环 N 轮、收尾等待结算、返回主界面、退出把焦点还给用户、记录日志。每个状态对应一组按键序列状态之间用固定延时推进。状态内再做冗余设计——比如送好友前先按 ESC 关闭可能的弹窗保证下一个按键一定落在预期界面上。关键设计细节是“幂等”。围绕“领奖”这个动作真实玩家可能遇到两种情况奖励已领取没有弹窗、待领取有弹窗。脚本不判断画面所以设计序列时要让“多按一下”尽量无害——比如进入状态后先执行一次“关闭弹窗”的组合键再做领取动作这样无论弹窗存不存在状态都不会跑飞。这种靠冗余按键换稳定性的做法是猫咪类代打脚本和直给式宏最大的不同。2.4 全键盘脚本的四个边界什么场景不硬撑全键盘方案虽然稳定但边界也很清楚。我做技术方案时用四条标准快速过滤条件适用不适用画面判断流程固定不需要识别弹窗需要根据画面做分支跳转频率要求慢节奏每秒一两次高频连点按毫秒计窗口结构单窗口、标题稳定多窗口跳转、无标题弹窗权限环境普通用户权限一致目标程序高权限运行全键盘脚本的价值在于“流程的确定性”不在于“环境的适应性”。确定性强参数就少脚本就稳环境适应诉求多就应该换方案而不是在一个不合适的方案上咬牙打补丁。这个判断在项目启动前做能省掉后面一半的排障时间。3. 跑通最小猫咪代打环境、代码、配置、焦点四步走3.1 环境准备Python keyboard 库一条命令进场我建议 Windows 上先用 Python。原因一是生态成熟二是调试直观——脚本出问题可以直接看堆栈不用在编译环节折腾。核心依赖只有一个keyboard库它负责全局热键监听和按键模拟安装命令pip install keyboard如果目标程序对按键有严格校验我会再补一个pywin32用来拿窗口句柄和做焦点切换pip install pywin32 pyperclipkeyboard库的press_and_release底层走的是SendInput日常场景够用一旦发现按下去的键没反应再换成自己包装的SendInput调用。为什么不直接上 pyautoguipyautogui 的强项在屏幕坐标和截图全键盘场景用不上它的定位部分还多了一层坐标纠偏的代码负担没必要。安装后先做一个冒烟测试按一下 F9脚本输出一句日志并模拟按一次空格再按 F11 退出确认库的权限和热键都没问题。3.2 最小骨架热键启动、循环执行、热键急停import time import random import threading import keyboard # 全局开关 RUNNING False def send_key(key: str): # 统一的按键出口以后要换底层注入只改这里 keyboard.press_and_release(key) def task_once(): # 模拟一次“跳过对话确认”任务 send_key(space) time.sleep(random.uniform(0.2, 0.5)) send_key(enter) time.sleep(random.uniform(0.3, 0.6)) def worker(): global RUNNING while RUNNING: task_once() def start(): global RUNNING if not RUNNING: RUNNING True threading.Thread(targetworker, daemonTrue).start() def stop(): global RUNNING RUNNING False if __name__ __main__: keyboard.add_hotkey(f9, start) keyboard.add_hotkey(f11, stop) print(F9 启动F11 停止脚本挂起中...) keyboard.wait()这段代码的关键点是热键回调只改RUNNING标志不直接开线程避免热键被按住时重复启动。worker是单一循环线程顺序执行任务keyboard.wait()让主线程常驻。整体很小但“启动——执行——急停”三个能力都有了。task_once()里故意用了random.uniform而不是固定延时这是后面要重点讲的人类节奏模拟这里先埋个点。如果需要更严格的防重入给start()加一把threading.Lock()在RUNNING判断之外再锁一层防止极端情况下两个线程同时进入工作循环。日常单用户脚本不加也能跑但加上更稳妥。3.3 把按键序列抽成配置表任务内容不写死在代码里固定任务的脚本最容易犯的错是把按键序列写死在代码里。换一个任务就要改代码改完还可能引入语法错误。我用一个 JSON 配置来存任务步骤代码只负责解析和顺序执行{ loop: 3, steps: [ { key: space, delay: 0.3, comment: 跳过开场对话 }, { key: enter, delay: 0.5, comment: 确认进入 }, { key: tab, delay: 0.2, comment: 焦点移到领取按钮 }, { key: enter, delay: 0.6, comment: 点击领取 } ] }对应执行端import json import time import random import keyboard def run_config(path: str): with open(path, r, encodingutf-8) as f: cfg json.load(f) for i in range(cfg.get(loop, 1)): for step in cfg[steps]: keyboard.press_and_release(step[key]) time.sleep(random.uniform(step[delay] * 0.8, step[delay] * 1.2)) def validate_steps(steps): for s in steps: if key not in s or delay not in s: raise ValueError(每个步骤必须有 key 和 delay 字段)配置表里每一行的key用keyboard库的键名delay是基准延时实际执行时乘以 0.8 到 1.2 的随机系数让节奏不固定。comment字段不参与执行但排查问题时日志里能直接看到当前步骤是“跳过开场对话”还是“点击领取”少猜很多。validate_steps在加载配置后立刻执行配置写错字段时提前报错而不是跑了一半才停下来。3.4 焦点管理按键发到正确的窗口keyboard.press_and_release发的是全局按键事件焦点在哪就打到哪。如果脚本执行途中用户切去聊天窗口后面所有按键都会打错地方。所以我在每个状态开始前做一次焦点确认import time import win32gui import win32con import keyboard def focus_window_by_title(title: str): hwnd win32gui.FindWindow(None, title) if not hwnd: raise RuntimeError(f没有找到窗口: {title}) # 用 Alt 键绕过 Windows 的前台窗口锁定限制 keyboard.press(alt) win32gui.SetForegroundWindow(hwnd) keyboard.release(alt) time.sleep(0.2)Windows 对SetForegroundWindow有前台锁限制非前台进程可能调用失败先按住 Alt 再把窗口拉到前台是绕过这个限制的常见做法稳定性和直接调用不在一个量级。使用时标题必须和任务窗口完全一致中文标题建议用完整匹配别用模糊匹配不然容易落到标题相近的无关窗口上。焦点确认还有一个作用窗口标题变化时立刻抛错而不是带着错位状态继续跑。这一步是脚本的“安全带”。4. 参数调校把脚本调得又稳又像人4.1 间隔时间快不是本事稳才是刚写完脚本的人普遍会调小延时见过有人把每步间隔压到 0.05 秒觉得快就是效率。结果目标程序处理不过来弹窗没出来就按了下一步整个序列错位返工时间远超省下的那几秒。我一般把基准间隔定在 0.2 到 0.5 秒之间这是正常人手操作键盘的自然节奏也是目标程序能稳定响应的安全区间。确定间隔的原则是“每步后留出一个观察窗”。比如点击领取后页面如果切到下一个界面需要留出至少 0.6 秒的动画时间。这个时间不能省省了后面每一步都在补救。遇到网络请求、界面切换间隔按秒记都不夸张。先测目标程序的响应延迟手动操作一次观察从按键到界面变化所需时间再把这个时间乘以 1.5 作为基准间隔八成不会翻车。4.2 随机抖动让按键节奏接近真人操作固定间隔的脚本有个明显特征每一步都像节拍器一样精准。这在人类看来很反常目标程序如果把行为数据上传做分析也是最容易被标记的点。我用的是给每步延时加一个随机系数的办法前面配置表已经写了time.sleep(random.uniform(base_delay * 0.8, base_delay * 1.2))系数范围不要拉得太大0.8 到 1.2 已经能破坏节奏上的机械感拉大到 0.5 到 2.0 会让每一步都忽快忽慢反而像网络卡顿也拖慢整体进度。另一个容易被忽略的随机点是循环间隔——两轮任务之间加一个 1 到 3 秒的随机等待效果比每步抖动更接近真人。我通常在 JSON 配置里加一个loop_delay字段执行完一轮后统一休眠而不是在每一步都加随机量。4.3 热键三件套启动、暂停、急停热键设计我固定用三件套启动、暂停、急停。启动键负责开始执行序列暂停键在状态中途停下但不退出急停键立刻清空所有状态让脚本回到起点。keyboard.add_hotkey(f9, start_worker) # 启动 keyboard.add_hotkey(f10, pause_worker) # 暂停 keyboard.add_hotkey(f11, emergency_stop) # 急停 def pause_worker(): global PAUSED PAUSED not PAUSED def emergency_stop(): global RUNNING, PAUSED, STEP_INDEX RUNNING False PAUSED False STEP_INDEX 0暂停和急停的区别很多人分不清暂停是把RUNNING置为 False 但保留当前进度下次启动从断点继续急停是把所有状态全部复位回到零点。实际使用中暂停用在临时离开急停用在发现情况不对需要重来的瞬间。热键被占用的问题很常见F9 可能被别的常驻软件截走或者目标程序自己监听 F9。我一般回避单纯的 F 区键改用组合键比如ctrlf10虽然按起来多一个键但很难撞车。4.4 日志与断点脚本出问题时能看现场没有日志的自动化脚本是个黑匣子出问题只能重跑一遍再看。我在脚本里固定加两行输出每步开始前打时间戳和步骤名每轮结束时打循环计数。日志写到文件而不是只打到控制台因为脚本挂在后台时控制台可能被系统锁屏挡住。import logging logging.basicConfig( filenamecat_bot.log, levellogging.INFO, format%(asctime)s %(levelname)s: %(message)s ) logging.info(step%s key%s, step[comment], step[key])日志的关键价值在于回放。急停之后翻日志能看到最后一步是哪一步就能判断序列是停在哪个位置。日志级别建议用 INFO不开 DEBUG因为键盘事件每步都会打一条DEBUG 会把文件刷得很大文件按天滚动保留最近三天就够。这个信息比任何调试器都好用也是后面空跑验证的基础。5. 猫咪代打常见问题排查五条踩坑记录5.1 输入法抢键按下去的字母变成了中文候选词现象脚本模拟按字母或数字时屏幕出现中文输入法的候选框按键没有送到目标程序目标窗口完全没有反应。原因系统当前输入法处于中文模式按键事件进入输入法管线后被打断或改道字母没能穿透到应用层。这个问题只在脚本输入字母/字符时出现纯方向键和回车不受影响所以很多人一开始很难发现。解决脚本启动前先切换输入法到英文模式。做法是执行序列的第一行固定加一步keyboard.press_and_release(ctrlspace)再开始主任务。另一个更彻底的办法是任务序列尽量用控制键不用字母——方向键、回车、空格、Tab 都避开输入法管道。调试时如果发现候选框弹出先手动确认当前输入法状态再检查脚本有没有在头部做切换。5.2 目标程序以管理员身份运行时按键送不进去现象脚本在普通窗口上跑得好好的切到目标程序后按键没反应目标程序界面能正常操作但脚本发的事件像被吞掉。原因目标程序以管理员权限运行权限级别高于脚本进程普通权限的进程无法向高权限窗口注入输入事件。这是 Windows 用户账户控制UAC的隔离机制不是脚本 bug。解决以管理员身份运行脚本解释器。右键“以管理员身份运行”打开命令行再启动脚本。注意这样会让脚本对其他窗口也有更高权限调试时别开着不相关的敏感窗口万一热键误触事件打在哪个窗口你控制不了。在脚本里加一个启动时权限自检尝试ctypes.windll.shell32.IsUserAnAdmin()返回值不是 1 就直接退出并提示。5.3 热键被系统或后台程序占用现象按下 F9 没有任何反应或者弹出了其他软件的功能面板脚本完全没被执行。原因后台程序录屏、输入法工具、截图软件注册了相同的全局热键热键冲突时系统可能只通知其中一个另一个静默失效。解决先用keyboard.unhook_all()清掉自己注册的回调确认不是自己的重复注册再用资源监视器或类似工具查一下后台有哪些进程在监听快捷键。排查完把热键改成组合键比如ctrlf10、ctrlaltf10。改完后做一次冒烟测试按热键看日志有没有输出。如果按下去弹出了另一个程序的面板而不是脚本日志说明那个软件抢先注册了同一个键换键是唯一出路。5.4 遇到反自动化检测脚本被冻结或失效现象脚本连续运行一段时间后按键不再生效目标程序表现异常甚至直接提示“检测到异常操作”并冻结窗口。原因部分应用对按键频率、间隔模式或全局热键注入事件做了检测固定节奏高频按键是最容易触发的模式。漫无目的的乱点不会触发但一周七天、每天同样时间、同样节奏的脚本行为在行为统计里非常显眼。解决先降低整体频率把每步间隔收到 0.3 秒以上再检查随机系数是否生效确认日志里的时间戳没有均匀间隔。脚本用于自动化日常操作时要先确认用户协议允许不然初始化阶段的一切调参都没意义这个红线不能碰。我的原则是合规场景才做自动化协议明确禁止的脚本写得再好也不上。5.5 按键按下没抬起卡键与连发问题现象脚本结束后目标窗口像被一直按住某个键比如持续输出一串“aaaa”直到手动按一次该键才恢复。原因进程被强制终止比如急停时直接退出keydown事件发出但keyup没补上系统认为键还处于按下状态。这在脚本里写入长按键组合键时尤其常见。解决急停逻辑里不要直接sys.exit()先把当前按住的键发一次keyboard.release(key)再做清理。另外给脚本加try/finally在finally里释放所有已按下的键再用atexit注册进程退出时的兜底释放import atexit atexit.register(lambda: [keyboard.release(k) for k in held_keys])held_keys列表由send_key统一记录按下时把键名加进列表释放时移出。这样无论脚本是正常退出还是被强杀最后都能把键盘状态还原。这条血泪经验值不少钱我第一次写长按键脚本时就被“卡住的方向键”坑掉了一整个上午。6. 进阶验证先空跑、再看日志、最后才上实战6.1 对记事本空跑验证序列本身没问题第一次跑通不要直接上目标程序。我的习惯是打开记事本让脚本对记事本执行任务序列然后肉眼确认输出内容。记事本不会吞按键也不会弹窗干扰是纯键盘脚本最好的测试沙箱。序列跑完检查光标位置和输出字符是否符合预期如果这一步就乱了说明键名配置或扩展键标志有误先在这里修正别把问题带到目标程序里。6.2 用日志回放判断脚本卡在哪一步空跑通过后记录一份完整日志然后切到目标程序跑第一轮。如果中途停下来翻日志看最后一条step是哪个动作。配合 5.1 到 5.5 的排查思路大部分问题能定位到“输入法没切”“焦点被抢”“间隔太短”这三类原因。日志是脚本最诚实的反馈也是调试效率最高的入口。出问题不要改一个参数就跑一遍全流程先看日志确定卡点再针对性调整那一个参数效率会高一截。6.3 急停和状态恢复给自己留后悔药脚本跑起来之后总有意外——一个弹窗、一次误触、一次网络卡顿。我的习惯是永远保留急停键并且在急停后支持从断点继续急停前记录当前执行到的步骤索引下次启动时从该索引开始而不是从头重跑。这样既避免浪费时间又避免从头执行导致状态叠加混乱。设计上步骤索引和循环计数都要写进日志下次启动脚本时读取日志最后一行自动续跑。这套状态恢复逻辑我实测能省掉 80% 的重复排障时间。我的习惯是任何自动化脚本的第一版本都先花半小时把空跑、日志、急停三条通道打通再谈效率和频率。这三样是脚本的保命线比任何花哨的参数都重要。把基础做扎实猫咪代打才能在电脑前安静地替你按下每一个键而不是在关键时刻把键盘按飞。希望帮到你。本文还有配套的精品资源点击获取

全键盘版猫咪代打：基于SendInput的稳定按键自动化脚本

相关推荐

HDR视频技术：原理、制作与未来趋势

GitLab环境搭建与高效配置实战指南

数据中心接入交换机架构：TOR、MOR与EOR详解

更多资讯

（论文速读）谱峭度 + 齿轮残差：如何识别早期点蚀的微弱冲击？

Vibe Coding 实战：两周、104 次提交，我做了一款背单词的爬塔小程序

【CMake】第1期从 CMake 初识到库的构建

C# .NET Core 微信小程序商城实战：支付库存订单闭环

SkyWalking 8.5 ES7发行包部署实战：配置、调优与避坑指南

超级具身智能“感知-决策中枢”研究（12）：基于FRA架构的语义总线与动态适配层

今日更新

AI智能体开发实战：从技术原理到商业落地

OpenShell 完全定制指南：从安装到深度配置，打造高效 Windows 开始菜单

Superpowers技能体系全解析：从Skills引入到安装的完整指南

本周精选

防幻觉智能体架构：电源硬件设计中的大模型编排与工具化实践

OpenGL面试核心考点：渲染管线、矩阵变换与性能排查全解析

全国计算机二级C语言真题PDF高效刷题指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？