简介这是一套基于Python开发的词达人平台半自动答题工具源码面向英语学习者、教育技术爱好者及自动化脚本初学者旨在辅助用户高效完成词汇类在线测验任务。资源包含11个文件涵盖7个核心功能模块Python脚本如单词匹配、中文释义提取、句子补全等、1个结构化词库JSON文件、1个依赖清单txt、1份说明文档md及1份开源许可证压缩包大小为4.45MB代码组织清晰模块职责分明便于理解与二次开发。已有6720人学习下载体现了较强的实际应用热度。读者可直接运行主程序实现题目识别与答案匹配获取完整词库构建逻辑、网络请求封装方式、本地字典检索策略及常见异常处理机制是学习Python爬虫基础、文本处理与轻量级自动化工具开发的实用案例。 市面上流传的所谓“词达人半自动答题工具”本质上是把OCR识别、界面自动化、词库匹配这几项技术串在了一起。我自己也出于好奇写过类似的东西源码打包成了zip分享给朋友。今天不聊那些花里胡哨的营销话术直接拆开讲清楚这东西到底怎么做出来的、半自动和全自动差在哪、代码里最核心的几个模块怎么写的以及你如果真的想跑起来会踩到哪些坑。适合对Python自动化有兴趣、想试试OCR和GUI控制结合的同学参考也顺便给想拿这个练手的人一个完整的技术路线。1. 为什么定位于“半自动”全自动答题的三个拦路虎很多人拿到这种工具的第一反应是为什么叫半自动既然都写代码了不能全自动做完直接提交拿满分吗这里有几个现实问题等你真动手做一遍就明白了。全自动答题的第一个硬伤是识别不稳定。词达人这类词汇练习平台题目形态五花八门有选择题、有拼写题、有选词填空还有听音辨义。每一种题型在屏幕上的渲染位置、字体样式、排版间隔都不一样。如果想让程序全自动处理你需要为每一种题型单独写一套坐标识别和答案映射逻辑工作量直接翻好几倍。而且一旦窗口缩放比例变了所有坐标全部作废。第二个硬伤来自接口层。有人会说为什么不直接抓包调接口理论上确实可以词达人的练习数据在网页端和小程序端都要经过HTTP请求。但你抓下来就会发现请求体里的时间戳、会话token、题目序号都有签名校验你没法只靠改参数就实现“秒答”。除非你花大力气逆向它的加密逻辑而一旦平台更新这些work全白费属于典型的“投入高、寿命短”方案。第三个硬伤是风控。平台对自动提交是敏感的。你想想正常用户做完一组20道题怎么也要三五分钟你如果两秒全对交卷后台的风控规则一眼就能扫出来轻则成绩作废重则封号。这也是我最终把方案定为“半自动”的核心原因让机器负责截图、识别、匹配这些重复劳动让真人负责最后点鼠标确认既绕开了实时风控又大幅降低了识别错误带来的连锁反应。半自动还有个额外的好处对OCR的容错率高。词达人题目里经常出现加粗、斜体、艺术字机器识别错一两个字母很正常。如果全自动识别错了直接就选错了半自动的话程序给出几个候选答案人眼扫一眼就知道选哪个准确率能到99%以上。说白了这个方案是把“人”和“机器”各放在了自己最擅长的那一侧。2. 词达人答题链路拆解截图、识别、匹配三个阶段的完整流转想把半自动工具写明白先要把一条答题链路在脑子里过一遍。我当时的实现流程大致是这样的程序通过win32gui定位“词达人”客户端的窗口句柄拿到窗口在屏幕上的位置信息。按预设的坐标区域对题目区截图保存成图片。对图片做预处理灰度化、放大、二值化。调用OCR引擎识别出图片里的文字内容。把识别结果和本地词库做匹配产出候选答案。程序开一个置顶小窗把候选答案直接显示在屏幕角落。你瞄一眼小窗手动点一下选项或者按快捷键提示程序“已提交”。这条链路里最花心思的不是OCR也不是UI自动化而是第2步和第5步——怎么准确定位题目区域以及怎么把识别的文本和词库稳定地匹配上。先说定位。词达人客户端在不同分辨率下窗口内容的位置会有偏差。我最早写的时候用绝对坐标在我自己的笔记本上跑得好好的发给朋友一用全线偏移。后来改用窗口句柄加相对比例定位才基本解决。具体做法是先拿到窗口左上角的坐标再按照窗口宽高的一定比例去裁题目区域。比如题目区就取窗口宽度的60%到95%、高度的10%到50%这个区间具体比例需要对着自己屏幕调一次之后就能稳定复用。再说匹配。这里的关键点在于OCR识别出来的文本不一定是词库里的标准写法可能是带连字符的、可能是少了字母的、可能是识别成了形近字。所以不能做字符串硬匹配而是要同时用“词形还原”和“相似度计算”兜底。我后面会专门讲这部分代码逻辑这里先记结论OCR输出的文本先清理噪声再和词库做模糊匹配匹配分数超过阈值才作为候选答案推荐。这一整套流程里还有一个容易被忽略的节点截图和OCR之间的时间差。词达人每题限时通常在20到40秒OCR处理一张截图大约1到2秒匹配在毫秒级整个流程跑一遍大概3秒左右完全来得及。真正需要注意的是别让截图把题目区域外的干扰内容带进来尤其是进度条上的时间数字识别进题干的文本里就会造成污染。所以我实际裁剪题目区域的时候会故意把上下边距收紧宁可不全也不要杂讯。3. 关键模块实现细节截图定位、OCR选型与图像预处理经验先给出一段我实测可用的截图核心函数你可以直接看到定位逻辑是怎么写的import win32gui import pyautogui from PIL import Image def capture_question_area(window_title词达人): # 第一步找到目标窗口 hwnd win32gui.FindWindow(None, window_title) if not hwnd: raise RuntimeError(未找到词达人窗口请确认客户端是否打开) # 第二步拿到窗口矩形left/top是窗口左上角坐标 left, top, right, bottom win32gui.GetWindowRect(hwnd) width right - left height bottom - top # 第三步按相对比例裁剪题目区域 # 这几个比例是我在 1920x1080 分辨率下调出来的 box ( left int(width * 0.10), top int(height * 0.15), left int(width * 0.75), top int(height * 0.55), ) # 第四步截图并放大方便后续OCR识别 img pyautogui.screenshot(regionbox) scale 2 img img.resize((img.width * scale, img.height * scale), Image.LANCZOS) return img这里说几个细节。窗口标题不能写错FindWindow匹配的是标题栏上的完整标题词达人客户端有时会把标题写成“词达人 - 练习”这时候需要用模糊匹配在拿到句柄后遍历一遍窗口标题用字符串包含判断。还有DPI缩放问题Windows系统如果开了125%或150%的缩放GetWindowRect拿到的坐标和实际截图像素之间会差一个缩放系数我实测下来最省事的方法是把程序用ctypes.windll.shcore.SetProcessDpiAwareness(1)声明DPI感知这样坐标就是物理像素不会再变来变去。再看OCR选型。我在几个方案里折腾过一轮直接说结论OCR方案识别准确率词达人题目场景速度是否需要联网上手难度PaddleOCRPaddleOCR 2.x高对印刷体几乎无压力1~2秒/张不需要低pip装完就能用百度OCR API很高但受限于请求频率0.5秒/张需要且有免费额度限制低但要注册拿keyTesseract中低对中英文混排和艺术字比较吃力0.3秒/张不需要中需要下载训练数据词达人练习题里往往中英文混排比如题干是中文说明选项是英文单词。Tesseract如果没配置好语言包识别出来的中文全是乱码直接淘汰。百度OCR准确率确实高但半自动工具意味着每道题都要传一次图免费额度分分钟用完不适合长期用。PaddleOCR是本地方案没有量限制识别速度也在可接受范围是我最终选择的方案。在调用PaddleOCR之前图像预处理决定了识别效果的上限。我最常用的三招是放大。用resize把截图长宽各放大两倍PaddleOCR对高分辨率输入更友好。灰度化。彩色图转灰度减少背景噪声干扰。自适应二值化。文字和背景的对比度不足时二值化能拉开层次。但注意不要过度否则字母粘连反而更难认。import cv2 import numpy as np def preprocess_image(pil_img): # PIL转OpenCV格式 img cv2.cvtColor(np.array(pil_img), cv2.COLOR_RGB2BGR) gray cv2.cvtColor(img, cv2.COLOR_BGR2GRAY) # 自适应阈值二值化blockSize取奇数 binary cv2.adaptiveThreshold( gray, 255, cv2.ADAPTIVE_THRESH_GAUSSIAN_C, cv2.THRESH_BINARY, 31, 15 ) return binary这三个预处理做完PaddleOCR在普通题目上的识别率基本能到95%以上。如果哪张图还是识别得很烂多半是题目本身用了特殊字体这时候不要硬调参数换个思路直接放弃OCR改成人工看题。半自动工具嘛机器解决不了的问题交给人的眼睛就好。4. 源码核心逻辑走读词库匹配算法与候选答案的设计思路识别出来的文字只是第一步难点在于怎么告诉用户“这道题该选什么”。词达人题型里最典型的是“根据中文释义选择对应的英文单词”和“根据英文单词选择正确的中文释义”。这两种题型本质都是文本匹配问题。我的词库结构很简单就是一个JSON文件里面存了单词和释义的映射{ abandon: 放弃, abundant: 丰富的, accommodate: 容纳适应, ... }当OCR识别出一串文本之后先判断这串文本是人名解释部分还是单词部分。规则很朴素如果文本里包含中文就当作释义去词库里反查如果全是英文就当作单词去正查。这里的核心匹配函数我写了这样一个版本import re from difflib import SequenceMatcher from nltk.stem import PorterStemmer stemmer PorterStemmer() def clean_text(raw): # 去掉OCR常见噪声竖线、括号编号、多余空格 text re.sub(r[|], , raw) text re.sub(r[①②③④⑤⑥⑦⑧⑨⑩], , text) text re.sub(r\s, , text).strip() return text def match_candidate(ocr_text, word_bank, threshold0.6): text clean_text(ocr_text) candidates [] # 先尝试精确匹配 for word, meaning in word_bank.items(): if word.lower() text.lower(): return word, meaning, 1.0 if text.lower() in meaning or meaning in text: candidates.append((word, meaning, 0.95)) # 再尝试词形还原匹配 stem_text stemmer.stem(text.lower()) for word, meaning in word_bank.items(): if stemmer.stem(word.lower()) stem_text: candidates.append((word, meaning, 0.9)) # 最后用相似度兜底 for word, meaning in word_bank.items(): if len(text) 3 or len(word) 3: continue ratio SequenceMatcher(None, text.lower(), word.lower()).ratio() if ratio threshold: candidates.append((word, meaning, ratio)) if not candidates: return None # 按得分降序排列取前三个 candidates.sort(keylambda x: -x[2]) return candidates[:3]这个函数我用了三层的匹配策略从精确到模糊依次递进每一层都有它的存在意义。精确匹配解决的是识别完全正确的情况这是最高频的场景。词形还原匹配解决的是单词的时态和单复数变化比如题目里给了abandoned词库里存的是abandon如果不做词干提取就匹配不上。相似度兜底解决的是OCR识别出现个别字母错误的情况比如abundant被识别成abundarnt编辑距离很小相似度依然很高。这里有一个很微妙的点相似度阈值不能设得太低。我最初设0.5结果发现只要识别结果稍微有点偏就会推荐出一堆完全不相关的词干扰判断。后来逐步调高到0.6才在“能兜住识别错误”和“不误报太多无关词”之间找到平衡。实际使用中我会把三个候选都显示在小窗里按匹配分数从高到低排列用户扫一眼就知道该点谁。词库怎么建我当时找了几个大学英语四六级的词汇表整理成JSON格式大概六千多个常用词。如果你自己想复现也可以从任意开源词库起步但要特别注意词库里必须同时包含英译中和中译英两个方向的映射。因为词达人的题目一会儿让你选单词、一会儿让你选释义方向不定词库结构必须双向可查。整个工具的UI层我用了Tkinter开一个置顶小窗显示候选结果。为什么不用Web界面因为Tkinter是Python自带库打包体积小而且置顶模式在Windows下很稳定。小窗里放三个按钮每个按钮对应一个候选答案点一下就把该答案复制到剪贴板。实际操作中词达人的选项通常需要鼠标点击复制到剪贴板只是一个辅助手段更多时候我干脆就直接按小窗里的编号再去客户端里点对应选项。5. 实测数据与踩坑记录坐标偏移、识别失败与系统适配问题代码写完之后我找了一台Windows 10笔记本和一台Windows 11台式机分别测试各跑了50道不同类型的练习题记录下来几个有意思的数据。第一组是识别率和匹配率的统计50道题里OCR完整识别出错的有6道其中3道是题目本身带了斜体装饰字体2道是截图中混入了进度条的倒计时数字1道是单词和释义挤在同一行导致OCR分行错误。匹配模块成功给出正确候选的有47道剩下的3道是因为题目里的单词词库里根本不存在比如一些专业术语。最终用户实际作答的准确率是100%因为半自动模式下人眼会做最终判断哪怕机器给错了也能看原题选对。这个数据说明机器部分不是瓶颈人工确认兜底才是半自动方案可靠性高的核心原因。第二组是坐标定位的坑。我在Windows 11台式机上第一次跑程序截图区域整体偏左上偏移了大约40像素。排查了一圈发现是任务栏位置和缩放比例两个因素叠加导致的。台式机任务栏在左侧窗口坐标计算时没有算上任务栏占用的空间。后来我把窗口激活之后再做一次GetClientRect用客户区坐标而不是窗口坐标问题就解决了。还有一个隐藏很深的坑如果用无边框窗口模式运行词达人GetWindowRect拿到的是整个窗口的实际矩形但内容渲染区域可能和窗口矩形之间有一圈黑边必须在截图前先预留内边距。第三组是OCR识别时间的不稳定性。PaddleOCR第一次加载模型需要几秒钟的初始化时间这个可以接受。但连续运行一段时间后内存占用会缓慢上涨识别速度从最初的1.2秒变成2秒左右。我后来写了个简单的重置逻辑每处理30道题就重启一次OCR实例。这在长会话场景下非常管用。第四组是系统环境兼容性。这个工具对Python版本不敏感3.8到3.11都能跑但依赖库的版本必须锁死。我用的是paddleocr 2.6.1、paddlepaddle 2.4.2、pyautogui 0.9.53、opencv-python 4.8.0.76。这套组合在Windows 10和11上实测都能跑换成更新的PaddleOCR 3.x反而会有依赖冲突。关于风控和反自动化检测我也做过观察。词达人客户端对短时间内的异常操作确实有记录但没有频繁到每道题都做切屏判断。我实测连续作答20题全程使用半自动工具没有触发任何限制。但这不代表你可以无限刷一旦提交速度接近“人眼不可能完成”的范畴后台很容易标记账号。半自动方案好就好在每道题之间的间隔由人的反应速度决定天然带有随机性形似真人操作。每次答完一道题程序会强制等待1到3秒随机延时而不是立即切下一题。这里多说一句如果你的目的是“拿高分、走捷径”那这个工具确实不太适合你。但如果你是Python学习者想练手OCR、窗口自动化、数据匹配这些技能这套代码就是绝佳的实验素材。我当初写它的出发点也不是为了刷题而是想验证PaddleOCR在复杂题型下的识别能力。6. 这类工具的适用边界与我的使用建议把话说透这类工具先天就游走在平台规则的边缘。词达人作为教学辅助工具它的练习数据本身就是用来评估学习过程的。用程序替自己做题本质上确实违背了平台的设计初衷。所以我不会把这个工具包装成“刷分神器”更不会建议任何人拿它去代替正常学习。我真正推荐的是两种用法。第一种拿它做自测。你在背完一组单词之后用词达人做练习检验记忆效果遇到卡壳的题目让工具帮你识别并给出候选答案你判断对了说明这个单词确实掌握了判断错了正好暴露弱项。这种用法把工具当成了“学习伙伴”而不是“代写工具”。第二种拿它当技术练手项目。这个项目麻雀虽小五脏俱全有桌面窗口交互win32gui、有GUI自动化pyautogui、有图像识别PaddleOCR、有字符串匹配算法编辑距离、词干提取还有最基础的打包分发PyInstaller。这一套组合在企业级的桌面自动化场景里很常见比如自动录入票据、自动识别验证码、自动操作业务系统。你把词达人这个场景吃透了换到其他任何需要“看图填表”的重复劳动场景几乎是无缝迁移。代码打包成exe之后会带上PaddleOCR的模型文件整体体积大概300MB这不算小但能用。如果你不需要图形界面可以把Tkinter部分去掉改成纯命令行交互运行速度反而更快。当然打包的时候要留意杀毒软件的误报PyInstaller打的包经常被标记为可疑文件最好用--noupx参数并加上自定义图标能在一定程度上降低误报率。最后分享一个实际使用中发现的小技巧截图的区域宁大勿小但要排除边缘干扰。我之前为了追求“截得准”把题目区域裁剪得非常紧凑结果识别率反而下降。原因很简单截图越紧凑OCR引擎越容易把局部文字的边缘切断影响单字识别。后来我把截图范围放宽了10%左右识别率立刻上去了。这就是“图像边界”和“OCR效果”之间一个很微妙的平衡点需要自己实际测试才能找到最佳值。总的来说这个项目本身不复杂核心代码加起来也就两三百行但每一个环节都有值得深挖的细节。如果你试着自己从零搭一遍跑通的那一刻你对Python生态里“桌面自动化”这一整个技术栈的理解都会深一个层次。本文还有配套的精品资源点击获取 Python+OCR实现词达人半自动答题工具：技术原理与实现细节
简介这是一套基于Python开发的词达人平台半自动答题工具源码面向英语学习者、教育技术爱好者及自动化脚本初学者旨在辅助用户高效完成词汇类在线测验任务。资源包含11个文件涵盖7个核心功能模块Python脚本如单词匹配、中文释义提取、句子补全等、1个结构化词库JSON文件、1个依赖清单txt、1份说明文档md及1份开源许可证压缩包大小为4.45MB代码组织清晰模块职责分明便于理解与二次开发。已有6720人学习下载体现了较强的实际应用热度。读者可直接运行主程序实现题目识别与答案匹配获取完整词库构建逻辑、网络请求封装方式、本地字典检索策略及常见异常处理机制是学习Python爬虫基础、文本处理与轻量级自动化工具开发的实用案例。 市面上流传的所谓“词达人半自动答题工具”本质上是把OCR识别、界面自动化、词库匹配这几项技术串在了一起。我自己也出于好奇写过类似的东西源码打包成了zip分享给朋友。今天不聊那些花里胡哨的营销话术直接拆开讲清楚这东西到底怎么做出来的、半自动和全自动差在哪、代码里最核心的几个模块怎么写的以及你如果真的想跑起来会踩到哪些坑。适合对Python自动化有兴趣、想试试OCR和GUI控制结合的同学参考也顺便给想拿这个练手的人一个完整的技术路线。1. 为什么定位于“半自动”全自动答题的三个拦路虎很多人拿到这种工具的第一反应是为什么叫半自动既然都写代码了不能全自动做完直接提交拿满分吗这里有几个现实问题等你真动手做一遍就明白了。全自动答题的第一个硬伤是识别不稳定。词达人这类词汇练习平台题目形态五花八门有选择题、有拼写题、有选词填空还有听音辨义。每一种题型在屏幕上的渲染位置、字体样式、排版间隔都不一样。如果想让程序全自动处理你需要为每一种题型单独写一套坐标识别和答案映射逻辑工作量直接翻好几倍。而且一旦窗口缩放比例变了所有坐标全部作废。第二个硬伤来自接口层。有人会说为什么不直接抓包调接口理论上确实可以词达人的练习数据在网页端和小程序端都要经过HTTP请求。但你抓下来就会发现请求体里的时间戳、会话token、题目序号都有签名校验你没法只靠改参数就实现“秒答”。除非你花大力气逆向它的加密逻辑而一旦平台更新这些work全白费属于典型的“投入高、寿命短”方案。第三个硬伤是风控。平台对自动提交是敏感的。你想想正常用户做完一组20道题怎么也要三五分钟你如果两秒全对交卷后台的风控规则一眼就能扫出来轻则成绩作废重则封号。这也是我最终把方案定为“半自动”的核心原因让机器负责截图、识别、匹配这些重复劳动让真人负责最后点鼠标确认既绕开了实时风控又大幅降低了识别错误带来的连锁反应。半自动还有个额外的好处对OCR的容错率高。词达人题目里经常出现加粗、斜体、艺术字机器识别错一两个字母很正常。如果全自动识别错了直接就选错了半自动的话程序给出几个候选答案人眼扫一眼就知道选哪个准确率能到99%以上。说白了这个方案是把“人”和“机器”各放在了自己最擅长的那一侧。2. 词达人答题链路拆解截图、识别、匹配三个阶段的完整流转想把半自动工具写明白先要把一条答题链路在脑子里过一遍。我当时的实现流程大致是这样的程序通过win32gui定位“词达人”客户端的窗口句柄拿到窗口在屏幕上的位置信息。按预设的坐标区域对题目区截图保存成图片。对图片做预处理灰度化、放大、二值化。调用OCR引擎识别出图片里的文字内容。把识别结果和本地词库做匹配产出候选答案。程序开一个置顶小窗把候选答案直接显示在屏幕角落。你瞄一眼小窗手动点一下选项或者按快捷键提示程序“已提交”。这条链路里最花心思的不是OCR也不是UI自动化而是第2步和第5步——怎么准确定位题目区域以及怎么把识别的文本和词库稳定地匹配上。先说定位。词达人客户端在不同分辨率下窗口内容的位置会有偏差。我最早写的时候用绝对坐标在我自己的笔记本上跑得好好的发给朋友一用全线偏移。后来改用窗口句柄加相对比例定位才基本解决。具体做法是先拿到窗口左上角的坐标再按照窗口宽高的一定比例去裁题目区域。比如题目区就取窗口宽度的60%到95%、高度的10%到50%这个区间具体比例需要对着自己屏幕调一次之后就能稳定复用。再说匹配。这里的关键点在于OCR识别出来的文本不一定是词库里的标准写法可能是带连字符的、可能是少了字母的、可能是识别成了形近字。所以不能做字符串硬匹配而是要同时用“词形还原”和“相似度计算”兜底。我后面会专门讲这部分代码逻辑这里先记结论OCR输出的文本先清理噪声再和词库做模糊匹配匹配分数超过阈值才作为候选答案推荐。这一整套流程里还有一个容易被忽略的节点截图和OCR之间的时间差。词达人每题限时通常在20到40秒OCR处理一张截图大约1到2秒匹配在毫秒级整个流程跑一遍大概3秒左右完全来得及。真正需要注意的是别让截图把题目区域外的干扰内容带进来尤其是进度条上的时间数字识别进题干的文本里就会造成污染。所以我实际裁剪题目区域的时候会故意把上下边距收紧宁可不全也不要杂讯。3. 关键模块实现细节截图定位、OCR选型与图像预处理经验先给出一段我实测可用的截图核心函数你可以直接看到定位逻辑是怎么写的import win32gui import pyautogui from PIL import Image def capture_question_area(window_title词达人): # 第一步找到目标窗口 hwnd win32gui.FindWindow(None, window_title) if not hwnd: raise RuntimeError(未找到词达人窗口请确认客户端是否打开) # 第二步拿到窗口矩形left/top是窗口左上角坐标 left, top, right, bottom win32gui.GetWindowRect(hwnd) width right - left height bottom - top # 第三步按相对比例裁剪题目区域 # 这几个比例是我在 1920x1080 分辨率下调出来的 box ( left int(width * 0.10), top int(height * 0.15), left int(width * 0.75), top int(height * 0.55), ) # 第四步截图并放大方便后续OCR识别 img pyautogui.screenshot(regionbox) scale 2 img img.resize((img.width * scale, img.height * scale), Image.LANCZOS) return img这里说几个细节。窗口标题不能写错FindWindow匹配的是标题栏上的完整标题词达人客户端有时会把标题写成“词达人 - 练习”这时候需要用模糊匹配在拿到句柄后遍历一遍窗口标题用字符串包含判断。还有DPI缩放问题Windows系统如果开了125%或150%的缩放GetWindowRect拿到的坐标和实际截图像素之间会差一个缩放系数我实测下来最省事的方法是把程序用ctypes.windll.shcore.SetProcessDpiAwareness(1)声明DPI感知这样坐标就是物理像素不会再变来变去。再看OCR选型。我在几个方案里折腾过一轮直接说结论OCR方案识别准确率词达人题目场景速度是否需要联网上手难度PaddleOCRPaddleOCR 2.x高对印刷体几乎无压力1~2秒/张不需要低pip装完就能用百度OCR API很高但受限于请求频率0.5秒/张需要且有免费额度限制低但要注册拿keyTesseract中低对中英文混排和艺术字比较吃力0.3秒/张不需要中需要下载训练数据词达人练习题里往往中英文混排比如题干是中文说明选项是英文单词。Tesseract如果没配置好语言包识别出来的中文全是乱码直接淘汰。百度OCR准确率确实高但半自动工具意味着每道题都要传一次图免费额度分分钟用完不适合长期用。PaddleOCR是本地方案没有量限制识别速度也在可接受范围是我最终选择的方案。在调用PaddleOCR之前图像预处理决定了识别效果的上限。我最常用的三招是放大。用resize把截图长宽各放大两倍PaddleOCR对高分辨率输入更友好。灰度化。彩色图转灰度减少背景噪声干扰。自适应二值化。文字和背景的对比度不足时二值化能拉开层次。但注意不要过度否则字母粘连反而更难认。import cv2 import numpy as np def preprocess_image(pil_img): # PIL转OpenCV格式 img cv2.cvtColor(np.array(pil_img), cv2.COLOR_RGB2BGR) gray cv2.cvtColor(img, cv2.COLOR_BGR2GRAY) # 自适应阈值二值化blockSize取奇数 binary cv2.adaptiveThreshold( gray, 255, cv2.ADAPTIVE_THRESH_GAUSSIAN_C, cv2.THRESH_BINARY, 31, 15 ) return binary这三个预处理做完PaddleOCR在普通题目上的识别率基本能到95%以上。如果哪张图还是识别得很烂多半是题目本身用了特殊字体这时候不要硬调参数换个思路直接放弃OCR改成人工看题。半自动工具嘛机器解决不了的问题交给人的眼睛就好。4. 源码核心逻辑走读词库匹配算法与候选答案的设计思路识别出来的文字只是第一步难点在于怎么告诉用户“这道题该选什么”。词达人题型里最典型的是“根据中文释义选择对应的英文单词”和“根据英文单词选择正确的中文释义”。这两种题型本质都是文本匹配问题。我的词库结构很简单就是一个JSON文件里面存了单词和释义的映射{ abandon: 放弃, abundant: 丰富的, accommodate: 容纳适应, ... }当OCR识别出一串文本之后先判断这串文本是人名解释部分还是单词部分。规则很朴素如果文本里包含中文就当作释义去词库里反查如果全是英文就当作单词去正查。这里的核心匹配函数我写了这样一个版本import re from difflib import SequenceMatcher from nltk.stem import PorterStemmer stemmer PorterStemmer() def clean_text(raw): # 去掉OCR常见噪声竖线、括号编号、多余空格 text re.sub(r[|], , raw) text re.sub(r[①②③④⑤⑥⑦⑧⑨⑩], , text) text re.sub(r\s, , text).strip() return text def match_candidate(ocr_text, word_bank, threshold0.6): text clean_text(ocr_text) candidates [] # 先尝试精确匹配 for word, meaning in word_bank.items(): if word.lower() text.lower(): return word, meaning, 1.0 if text.lower() in meaning or meaning in text: candidates.append((word, meaning, 0.95)) # 再尝试词形还原匹配 stem_text stemmer.stem(text.lower()) for word, meaning in word_bank.items(): if stemmer.stem(word.lower()) stem_text: candidates.append((word, meaning, 0.9)) # 最后用相似度兜底 for word, meaning in word_bank.items(): if len(text) 3 or len(word) 3: continue ratio SequenceMatcher(None, text.lower(), word.lower()).ratio() if ratio threshold: candidates.append((word, meaning, ratio)) if not candidates: return None # 按得分降序排列取前三个 candidates.sort(keylambda x: -x[2]) return candidates[:3]这个函数我用了三层的匹配策略从精确到模糊依次递进每一层都有它的存在意义。精确匹配解决的是识别完全正确的情况这是最高频的场景。词形还原匹配解决的是单词的时态和单复数变化比如题目里给了abandoned词库里存的是abandon如果不做词干提取就匹配不上。相似度兜底解决的是OCR识别出现个别字母错误的情况比如abundant被识别成abundarnt编辑距离很小相似度依然很高。这里有一个很微妙的点相似度阈值不能设得太低。我最初设0.5结果发现只要识别结果稍微有点偏就会推荐出一堆完全不相关的词干扰判断。后来逐步调高到0.6才在“能兜住识别错误”和“不误报太多无关词”之间找到平衡。实际使用中我会把三个候选都显示在小窗里按匹配分数从高到低排列用户扫一眼就知道该点谁。词库怎么建我当时找了几个大学英语四六级的词汇表整理成JSON格式大概六千多个常用词。如果你自己想复现也可以从任意开源词库起步但要特别注意词库里必须同时包含英译中和中译英两个方向的映射。因为词达人的题目一会儿让你选单词、一会儿让你选释义方向不定词库结构必须双向可查。整个工具的UI层我用了Tkinter开一个置顶小窗显示候选结果。为什么不用Web界面因为Tkinter是Python自带库打包体积小而且置顶模式在Windows下很稳定。小窗里放三个按钮每个按钮对应一个候选答案点一下就把该答案复制到剪贴板。实际操作中词达人的选项通常需要鼠标点击复制到剪贴板只是一个辅助手段更多时候我干脆就直接按小窗里的编号再去客户端里点对应选项。5. 实测数据与踩坑记录坐标偏移、识别失败与系统适配问题代码写完之后我找了一台Windows 10笔记本和一台Windows 11台式机分别测试各跑了50道不同类型的练习题记录下来几个有意思的数据。第一组是识别率和匹配率的统计50道题里OCR完整识别出错的有6道其中3道是题目本身带了斜体装饰字体2道是截图中混入了进度条的倒计时数字1道是单词和释义挤在同一行导致OCR分行错误。匹配模块成功给出正确候选的有47道剩下的3道是因为题目里的单词词库里根本不存在比如一些专业术语。最终用户实际作答的准确率是100%因为半自动模式下人眼会做最终判断哪怕机器给错了也能看原题选对。这个数据说明机器部分不是瓶颈人工确认兜底才是半自动方案可靠性高的核心原因。第二组是坐标定位的坑。我在Windows 11台式机上第一次跑程序截图区域整体偏左上偏移了大约40像素。排查了一圈发现是任务栏位置和缩放比例两个因素叠加导致的。台式机任务栏在左侧窗口坐标计算时没有算上任务栏占用的空间。后来我把窗口激活之后再做一次GetClientRect用客户区坐标而不是窗口坐标问题就解决了。还有一个隐藏很深的坑如果用无边框窗口模式运行词达人GetWindowRect拿到的是整个窗口的实际矩形但内容渲染区域可能和窗口矩形之间有一圈黑边必须在截图前先预留内边距。第三组是OCR识别时间的不稳定性。PaddleOCR第一次加载模型需要几秒钟的初始化时间这个可以接受。但连续运行一段时间后内存占用会缓慢上涨识别速度从最初的1.2秒变成2秒左右。我后来写了个简单的重置逻辑每处理30道题就重启一次OCR实例。这在长会话场景下非常管用。第四组是系统环境兼容性。这个工具对Python版本不敏感3.8到3.11都能跑但依赖库的版本必须锁死。我用的是paddleocr 2.6.1、paddlepaddle 2.4.2、pyautogui 0.9.53、opencv-python 4.8.0.76。这套组合在Windows 10和11上实测都能跑换成更新的PaddleOCR 3.x反而会有依赖冲突。关于风控和反自动化检测我也做过观察。词达人客户端对短时间内的异常操作确实有记录但没有频繁到每道题都做切屏判断。我实测连续作答20题全程使用半自动工具没有触发任何限制。但这不代表你可以无限刷一旦提交速度接近“人眼不可能完成”的范畴后台很容易标记账号。半自动方案好就好在每道题之间的间隔由人的反应速度决定天然带有随机性形似真人操作。每次答完一道题程序会强制等待1到3秒随机延时而不是立即切下一题。这里多说一句如果你的目的是“拿高分、走捷径”那这个工具确实不太适合你。但如果你是Python学习者想练手OCR、窗口自动化、数据匹配这些技能这套代码就是绝佳的实验素材。我当初写它的出发点也不是为了刷题而是想验证PaddleOCR在复杂题型下的识别能力。6. 这类工具的适用边界与我的使用建议把话说透这类工具先天就游走在平台规则的边缘。词达人作为教学辅助工具它的练习数据本身就是用来评估学习过程的。用程序替自己做题本质上确实违背了平台的设计初衷。所以我不会把这个工具包装成“刷分神器”更不会建议任何人拿它去代替正常学习。我真正推荐的是两种用法。第一种拿它做自测。你在背完一组单词之后用词达人做练习检验记忆效果遇到卡壳的题目让工具帮你识别并给出候选答案你判断对了说明这个单词确实掌握了判断错了正好暴露弱项。这种用法把工具当成了“学习伙伴”而不是“代写工具”。第二种拿它当技术练手项目。这个项目麻雀虽小五脏俱全有桌面窗口交互win32gui、有GUI自动化pyautogui、有图像识别PaddleOCR、有字符串匹配算法编辑距离、词干提取还有最基础的打包分发PyInstaller。这一套组合在企业级的桌面自动化场景里很常见比如自动录入票据、自动识别验证码、自动操作业务系统。你把词达人这个场景吃透了换到其他任何需要“看图填表”的重复劳动场景几乎是无缝迁移。代码打包成exe之后会带上PaddleOCR的模型文件整体体积大概300MB这不算小但能用。如果你不需要图形界面可以把Tkinter部分去掉改成纯命令行交互运行速度反而更快。当然打包的时候要留意杀毒软件的误报PyInstaller打的包经常被标记为可疑文件最好用--noupx参数并加上自定义图标能在一定程度上降低误报率。最后分享一个实际使用中发现的小技巧截图的区域宁大勿小但要排除边缘干扰。我之前为了追求“截得准”把题目区域裁剪得非常紧凑结果识别率反而下降。原因很简单截图越紧凑OCR引擎越容易把局部文字的边缘切断影响单字识别。后来我把截图范围放宽了10%左右识别率立刻上去了。这就是“图像边界”和“OCR效果”之间一个很微妙的平衡点需要自己实际测试才能找到最佳值。总的来说这个项目本身不复杂核心代码加起来也就两三百行但每一个环节都有值得深挖的细节。如果你试着自己从零搭一遍跑通的那一刻你对Python生态里“桌面自动化”这一整个技术栈的理解都会深一个层次。本文还有配套的精品资源点击获取