youpaishidifu/msgbot
1
1
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
543 Commits 1 Branch 0 Tags
08d4bcaf7e5633c9b654de34e1ad4bb1488d9fed
Commit Graph
543 Commits
This Branch
This Branch
All Branches
Author SHA1 Message Date
youpaishidifu a858bbb9f6 fix(ocr): EasyOCR CUDA崩溃防护——健康检查+冻结隔离+自动降级 
问题：EasyOCR worker启动即崩溃（access violation in torch CUDA），
冻住整台电脑，用户需强制重启。

修复三层防护：
1. worker端：CUDA健康检查——启动时创建小张量测试CUDA可用性，
   失败则降级CPU，避免进入VGG模型加载的崩溃路径
2. 父进程端：CUDA_LAUNCH_BLOCKING=1——CUDA操作同步化，
   access violation时只杀子进程不冻整机（关键防冻结）
3. 父进程端：崩溃检测——读取崩溃日志，含access violation/torch
   则增加_easyocr_cuda_oom_count，第二次崩溃后强制CPU模式
   （_easyocr_cuda_oom_count>=2 → EASYOCR_FORCE_CPU=1）
 2026-08-02 21:22:59 +08:00
youpaishidifu b21e8f8cd4 feat(ocr): 引入消息历史数据库，改进无时间戳消息放行逻辑\n\n问题：\n1. OCR识别不到时间戳则直接丢弃，如'领地系统依托于哪个插件'因无可见时间戳被丢弃\n2. 微信/QQ同时进消息时，总有一方的消息会被丢弃（待进一步排查）\n\n修复：\n- 新增MessageHistory类，使用SQLite记录用户消息和bot回复\n- 在bot回复时记录到数据库（三处回复路径均已添加）\n- 在ocr_text_has_fresh_timestamp中，无时间戳时增加上下文判断：\n - 若最近30秒内有bot回复（用户消息挨着bot消息）：\n * 数据库无该用户消息记录 → 无条件放行\n * 数据库有记录 → 整段丢弃（防重复处理）\n - 否则保持原有逻辑（超短中文消息放行，其他丢弃）\n- 放行时记录用户消息到数据库，用于后续去重\n\n数据库：msg_history.db（SQLite），表message_history，字段：\n platform, sender_type(user/bot), content, content_hash(MD5), created_at\n\n验证：py_compile OK；数据库初始化自动创建表\n\n用户要求：'把用户消息、bot回复的消息做记录，如若用户的消息挨着bot的消息，且数据库无记录，无条件放行，如果用户的消息挨着bot的消息，无时间戳，数据库有记录，则整段丢弃。使用db保存。' 2026-08-02 21:01:33 +08:00
youpaishidifu e0e5e05b10 fix(ocr): 乱码过滤器放宽——正常英文名词不再误杀\n\n根因：游戏UI乱码过滤器 regex CJK+大写英文 匹配'如何通过Minecraft...'中的'Minecraft'，\n导致正常用户消息被误过滤。过滤器本意是捕获游戏UI公告/服务器列表中的乱码片段（如'玩家Ierite'），\n但无法区分正常英文名词。\n\n修复：在 CJK+大写英文过滤前增加中文字符占比检查——\n若中文字符数 >= 英文字母数，视为正常句子不过滤。\n三处过滤器均已修复：OCR(2183行)、剪贴板(2654行)、Poll(4328行)。\n\n示例：\n- '如何通过Minecraft的官网更新自己的皮肤?' → 中文10字母9，保留\n- '玩家Ierite' → 中文2字母6，过滤\n- '比武Mtp' → 中文2字母3，过滤 2026-08-02 19:49:15 +08:00
youpaishidifu 6f791622c9 fix(ocr): 引擎对比长度保护——Windows OCR截断丢消息 
根因：_pick_ocr_text() 用 score >= score 选引擎，Windows OCR
虽然行数少（8行 vs EasyOCR 19行），但因垃圾字符少、空格惩罚低，
分数可能略高或持平，导致完整 EasyOCR 文本被丢弃。

修复：
- 新增长度保护：当一方行数 >=1.5x 且字符数 >=1.3x 另一方时，
  分数差 <10 分则强制选更长文本
- 引擎对比日志增加行数/字符数/分数差，方便排查
- 不影响分数差距大时的正常选择逻辑
 2026-08-02 17:51:27 +08:00
youpaishidifu 3853804ca4 fix: 急停/停止即时生效+基线吞消息永久拦截破除 
问题1: 用户消息通过四层过滤器但不回复——根因基线轮吞消息后永久拦截:
- 基线轮 seen.add(item) 将历史消息永久加入 _seen_messages
- _last_sig 无条件更新 → 之后 OCR 每轮读到相同屏幕 sig 相同静默 return
- 双保险永久拦截: 用户重发相同内容永远等不到回复
修复: 基线轮 seen.discard(item) + 清空 _last_sig + 不 seen.add，
防重复改由 sig 静默跳过承担; sig 静默跳过加日志暴露(4131)

问题2: OCR 识别期间急停/手动停止不生效——主线程卡死在等待:
- _ocr_dual_engine join(timeout=10) 卡死
- _call_easyocr_safe queue.get(timeout=9) 卡死(EasyOCR子进程被杀后
  proc.poll()!=None → _read_worker 立即退出 → _q 永空 → 等满超时)
- _safe_screenshot join(timeout=3) 卡死
修复: 三处等待全部改 while self._running 轮询(50ms粒度),
急停瞬间丢弃未出结果的 OCR 折返; _safe_screenshot 去 @staticmethod

验证: py_compile OK; 隔离测试 test_baseline_fix.py 4组断言全过
(基线后 seen 不含 item、sig 清空、重发触发回复、回复后防重复)
 2026-08-02 16:44:00 +08:00
youpaishidifu 19c8817893 fix: 过滤器4 _is_reply_fragment 长度门槛6→4（≤4不参与匹配直接放行，≥4走完整匹配）；日志拆分避免'7<6'误导（实际为_replied_texts空） 2026-08-02 15:12:16 +08:00
youpaishidifu e9b9d6d92e fix: QQ截图cap_left右移至25%避开消息列表时间戳; 修复未来时间戳误判为新鲜(14:40不能匹配16:00); 修复跨午夜反向边界+1day误用; 修复_is_markdown_document日志插入导致长文本检测死代码; 四层过滤器加日志 2026-08-02 14:53:46 +08:00
youpaishidifu 22e781edac fix: 调整QQ截图裁剪参数cap_left=15%，添加噪声文本过滤 
- QQ截图裁剪cap_left从0.10调整到0.15，避免截到左侧会话列表
- 新增_is_noise_text函数，过滤HTML标签、图片路径、OCR噪声等
- 在stage splitting主循环、尾部处理、_ocr_text_has_fresh_timestamp三处调用噪声过滤
- 语法检查通过
 2026-08-02 12:34:32 +08:00
youpaishidifu ad7aef5747 修复微信不唤醒前台+QQ裁消息+截屏定时随机清理 
- 微信截图从不唤醒前台根因: _ensure_visible置前失败后'窗口可见即放行'
  (IsWindowVisible&&!IsIconic→True), 截图截到被其他窗口压着的遮挡内容
  (窗口停哪截哪, 用户实测原图证实)
- 修复: 微信分支改用_ensure_foreground(AttachThreadInput强置前),
  必须真正前台才截图; 微信原生窗口安全(2630搜索联系人已用同路径)
- QQ裁剪继续往左放宽: cap_left 0.15→0.10 (15%仍裁掉左侧用户消息气泡边缘)
- 截屏清理改为定时随机: 原_clean_old_ocr_debug每次保存即按数量删(keep模式),
  高频create+delete易触发360勒索误报; 新增_maybe_clean_ocr_dir()
  每30~60秒随机间隔清理, 删除mtime早于60s的全部截图(raw+processed都清),
  5处保存点去掉立即清理, 死函数已删, 挂载_run_loop主循环
 2026-08-01 23:50:04 +08:00
youpaishidifu 4428042703 修复OCR捕捉不可见旧消息+微信无图可查+急停/停止/启动计数器清零 
- 不可见消息被回复根因: stage splitting主循环+尾部处理中 last_ts=None 时
  buf无条件append(首行消息在时间戳之前=更早历史, 绕过全部新鲜性检查)
  → 22:35:33日志实锤: '单清效果是清理哪些效果?'(早已被覆盖)被OCR精准捕捉并回复
- 修复: ① 主循环 if not last_ts: 视为历史丢弃(首个时间戳之前的消息)
  ② 尾部处理 if not last_ts: 丢弃(整行无时间戳归属)
  ③ _ocr_text_has_fresh_timestamp 无时间戳不再无条件True, 仅≤4字中文超短消息放行
- 微信无图: 22:35:26 _ensure_hwnd超时(12s)整轮跳过无截图; 现在
  _ensure_visible失败时保存'窗口不可见现场截图'(尺寸过滤), 每次尝试都留图
- 计数器清零: start()/stop()缺_easyocr_consecutive_failures重置,
  _emergency_stop()急停完全不重置; 三处统一清零
  consecutive_failures/cuda_oom_count/call_count/retry_until/broken
  + OCR状态(截图hash/垃圾计数/引擎选择/回复冷却/上次文本)
  = 重启后CUDA降级/超时计数不残留, 从头评估GPU/CPU
 2026-08-01 22:57:54 +08:00
youpaishidifu 4ae189e82f 修复EasyOCR CUDA OOM冻结+时间戳day=0崩溃+OCR图片分目录img/raw+processed 
- 冻结根因: CUDA OOM后worker不退出, 损坏context持续占显存, 父进程不杀子进程
  反复发图→线程堆积+显存耗尽→桌面冻结
- worker: readtext CUDA/kernel错误→立即退出释放显存(faulerhandler已有兜底)
- 父进程: 收到CUDA错误→立即杀子进程+30s冷却; 连续2次CUDA错误→EASYOCR_FORCE_CPU=1
  强制CPU模式启动(显存不足降级防冻结)
- 时间戳day=0崩溃: _is_timestamp_old跨午夜用replace(day-1), 每月1号day=1→day=0
  抛ValueError day is out of range for month→微信OCR整轮失败; 改用timedelta(days=±1)
- OCR调试图片回源码目录: img/raw(原图PNG) + img/processed(处理后JPG) 分目录存储
- 崩溃日志回源码根 easyocr_crash.log (不写%LOCALAPPDATA%)
- _clean_old_ocr_debug 默认 keep=20 (回退上一轮激进keep=6)
- .gitignore: 忽略 img/ 与 worker_stderr/stdout.txt
 2026-08-01 22:23:55 +08:00
youpaishidifu 0405e42a90 修复OCR回复牛头不对马嘴+残留消息+EasyOCR崩溃捕获+360误报 
1. knowledge_base.py: 检索排序惩罚标题-only/短正文段，降低heading bonus，奖励正文命中，避免纯标题/免责声明段排第一
2. auto_reply.py: 动作类查询要求正文命中才放行；拒绝纯标题/免责声明答案
3. monitor.py: 调试截图改存%LOCALAPPDATA%/windowmsgbot/ocr_debug避开源码目录(360); 收紧残留消息fresh gate(600s硬门); 启动即崩溃/请求崩溃时读取easyocr_crash.log写入主日志
4. easyocr_worker.py: 加faulthandler+sys.excepthook全局捕获，崩溃traceback落盘%LOCALAPPDATA%/windowmsgbot/easyocr_crash.log
 2026-08-01 21:21:05 +08:00
youpaishidifu 9ff019df00 fix: EasyOCR inner timeout mismatch + fresh timestamp gate放宽 
1. EasyOCR inner timeout 30s→_OCR_TIMEOUT-1(9s)
   外层join 10s，inner必须<外层，否则线程永远alive跳过
2. _ocr_text_has_fresh_timestamp: 时间戳全过期但含新鲜内容特征时放行
   旧时间戳后紧跟新消息(无独立时间戳)不再被整批丢弃
 2026-08-01 18:09:26 +08:00
youpaishidifu 8cf28d11bc EasyOCR容错: 连续3次超时才杀进程, 前2次保留子进程预留初始化时间, 单次OCR超时保持10s 2026-08-01 17:15:57 +08:00
youpaishidifu ae145c0d2d EasyOCR修复: 1)总超时10s→60s(首次加载~28s) 2)时间戳正则兼容EasyOCR的16.47/15;39/16:03.41格式 → 标准化为HH:MM:SS 2026-08-01 17:07:30 +08:00
youpaishidifu 749d14ab91 修复: 1)OCR时间戳跨行继承(消息无时间戳时继承前行时间戳) 2)QQ UI黑名单添加窗口抖动 2026-08-01 16:16:17 +08:00
youpaishidifu 16fdfb0620 EasyOCR修复: 1)worker加顶层异常捕获确保stderr可见 2)竞态保护:stdin写入前检查proc非None 3)增加处理日志 4)超时改30s 2026-08-01 15:58:58 +08:00
youpaishidifu 8ccad84986 OCR历史消息过滤: 若文本有可见时间戳但全部过期(>300s)直接丢弃, 防止混入旧消息误触发回复 2026-08-01 14:58:41 +08:00
youpaishidifu 733f12c45b 偏旁过滤改md库驱动: bot只查Unicode列码点, md缺失才回退硬编码范围, 维护只改md不改代码 2026-08-01 13:22:24 +08:00
youpaishidifu ba0e6e2450 修复3个OCR问题: easyocr子进程ready握手+60s初始化预算, 偏旁过滤改Unicode范围判断, 新旧消息按新鲜特征放行 
- easyocr_worker.py: 初始化完成后输出{"ready":true}握手, 父进程不再把3-10s初始化计入10s请求超时
- monitor.py: _ensure_easyocr_subprocess重写 - 60s握手预算(daemon线程+Queue), stderr PIPE捕获崩溃原因, 崩溃/超时改30s冷却自动重试(不再永久broken)
- monitor.py: 删除markdown表格字符key偏旁库, 改U+2E80-U+2FDF码位范围判断, 修复"地图"/"太"等正常汉字被误判为偏旁丢弃
- monitor.py: _looks_fresh_content新鲜特征判断 - 旧时间戳但含疑问词/问句/句尾标点的消息放行, 不再整块丢弃
- 新增test_easyocr_handshake.py: 子进程握手+OCR往返回归测试(实测通过: 28s含初始化, 识别'你好世界测试123')
 2026-08-01 13:00:57 +08:00
youpaishidifu d2389ec3e1 fix: 微信裁切参数调整 + 气泡上下文验证 + EasyOCR重启修复 
- 微信裁切参数：cap_left从0.34减至0.30，cap_right改为跳过滚动条+右边框(2%宽度)
- 微信气泡上下文验证：OCR后处理增加气泡消息上下文检查
  - 消息必须包含时间戳、冒号分隔符或标点结尾
  - 短中文消息(≤8字)和含问词/感叹词的消息放行
  - 过滤Windows弹窗/通知/非聊天内容
- EasyOCR重启修复：stop()和start()中重置_easyocr_broken标志
  - 确保停止/急停后双引擎仍能搭档作业
 2026-07-31 22:29:14 +08:00
youpaishidifu f9c4b161f3 fix: 偏旁替换改为偏旁丢弃 + 英文配置乱码过滤 
- 偏旁过滤逻辑：从'替换为补充字符'改为'包含偏旁字符就丢弃'
  修复'法'被OCR拆成'氵去'后替换为'河去'的问题
- 新增英文配置格式+乱码过滤：拦截 key=value 后跟乱码的模式
  如 'invite referral bonus=5a激<5'
- OCR级和Poll级同步更新偏旁过滤和乱码过滤规则
 2026-07-31 21:20:07 +08:00
youpaishidifu fe83f1035a feat: 补全所有偏旁的补充字符（200个偏旁，0空值） 
1. 为200个CJK偏旁全部填写补充字符（正确汉字）
2. 修正U+2E8E：氵→冫（两点水，之前误标为三点水）
3. 删除重复条目：广(U+2EA4)与尸(U+2EA4)重复，删除广
4. 修正文件头描述：从"≥3丢弃"改为"替换/丢弃"

维护方式：编辑unicode_radicals.md的补充字符列，重启bot生效
 2026-07-31 19:47:48 +08:00
youpaishidifu 18742065a7 feat: 偏旁库逻辑重构 — 替换偏旁为正确汉字\n\n1. 修改unicode_radicals.md格式，新增补充字符列\n2. 新增_load_radicals()加载偏旁→补充字符映射（字典）\n3. 新增_replace_radicals()函数：遍历偏旁，有补充字符则替换，无补充字符则整段丢弃\n4. OCR级和Poll级偏旁过滤逻辑同步更新\n5. 降级逻辑：默认范围U+2E80-U+2FDF，补充字符为空\n\n维护方式：编辑unicode_radicals.md填写补充字符，重启bot生效 2026-07-31 18:30:33 +08:00
youpaishidifu 9163f12fcb fix: OCR吞字纠错 + 拉黑'拍了拍'系统通知 
1. OCR吞字纠错：在_normalize_ocr_text中添加词级纠错字典，
   修复Windows OCR常见汉字误识别（手髓→手续、β余→多余、
   早原→草原、届件→插件、文|牛→文件、日何→如何）
2. 拉黑'拍了拍'：加入_UI_SUBSTR_BLOCKLIST，过滤微信/QQ
   '拍了拍'系统通知（UI按钮触发，非用户消息）
 2026-07-31 17:40:44 +08:00
youpaishidifu 9d30943a84 fix: QQ截图cap_left从20%减至15%，修复时间戳被截断（15:54→0:54）\n\n根因：cap_left=20%仍截掉了消息面板左侧的时间戳数字，\n导致OCR识别到的时间戳丢失前导数字（15→0），被补0后\n判定为旧消息跳过。减至15%确保时间戳完整。 2026-07-31 17:13:03 +08:00
youpaishidifu 0f5be72af0 feat: 保存OCR处理后图片到根目录（JPG格式）用于肉眼对比 
1. QQ和微信轮询方法中，图像预处理（resize+sharpen+contrast）后
   保存一份JPG格式的图片到windowmsgbot根目录
2. 文件名格式：ocr_processed_qq_时间戳.jpg / ocr_processed_wx_时间戳.jpg
3. 与原图（ocr_debug_*.png）对比，判断是OCR识别问题还是美化过度
4. 修改_clean_old_ocr_debug函数支持清理.jpg文件
 2026-07-31 16:44:04 +08:00
youpaishidifu 7812f3cc63 fix: 放宽bot配置说明过滤规则 — 三重匹配防误过滤用户消息 
原规则：只要包含配置短语或英文关键词就过滤，导致用户讨论配置的消息
如'invite referral bonus=5afi配置此处的文件'被误过滤。

修复：改为三重匹配——必须同时满足：
1. 包含配置短语（如'配置此处的文件'）
2. 包含英文关键词（如invite/referral）
3. 包含配置格式（=或:后跟非空白字符）

只有三者都满足才判定为bot旧回复，避免误过滤用户消息。
 2026-07-31 16:13:27 +08:00
youpaishidifu 7012eaa7ed fix: OCR时间戳截断修复 — 裁切左移 + 时间戳OCR误读兜底 
1. QQ截图cap_left从25%减至20%，减少时间戳左侧数字被截断概率
2. _is_timestamp_old新增OCR误读兜底：h<12时尝试h+10/h+12取diff最小者
   若<max_age则放行（OCR把15→5时h+10=15=正确值）
 2026-07-31 15:57:08 +08:00
youpaishidifu ce74fc762a fix: 用户操作不再打断bot唤醒截图 — 窗口可见即可截图，不要求前台 
根因：_ensure_visible 强制要求窗口在前台（_check_foreground），
用户操作鼠标/键盘会瞬间抢走前台焦点 → 3次重试全部失败 →
"唤醒失败"跳过本轮。但 ImageGrab.grab 只需要窗口在屏幕上可见，
不要求前台，用户操作≠窗口被遮挡。

修复：
- _ensure_visible：前台校验失败后，若窗口仍然可见(!IsIconic && IsWindowVisible)，
  仍返回True继续截图。仅窗口真的不可见时返回False
- QQ/微信轮询：窗口不可见时退避5秒（每0.1秒检查急停），
  给用户接管时间，同时不阻塞急停操作
 2026-07-31 14:44:12 +08:00
youpaishidifu 3a4fecbc03 fix: 用 daemon 线程替代 ThreadPoolExecutor，防止 Windows OCR 卡死冻结电脑 
根因：_ocr_dual_engine 用 ThreadPoolExecutor with 块，__exit__ 调
shutdown(wait=True)，当 Windows OCR 引擎卡死时永久阻塞主线程 → 电脑冻结。

修复：改用 daemon 线程 + join(timeout=10s)，超时后线程丢弃不阻塞。
daemon 线程随进程退出自动回收，不会泄漏。
 2026-07-31 14:13:51 +08:00
youpaishidifu 435f729589 fix: 降低OCR预处理锐化/对比度，增强偏旁碎片检测 2026-07-31 12:45:48 +08:00
youpaishidifu b065f8d707 fix: 时间戳分割支持中文日期前缀（昨天、前天、星期X等） 2026-07-31 10:19:01 +08:00
youpaishidifu e91fc20523 fix: 修复偏旁库加载失败 — 改用更健壮的markdown表格解析 2026-07-31 09:57:32 +08:00
youpaishidifu bd5ec8cbd8 fix: md格式直接砍掉 — 删除用户文本提取，统一过滤逻辑 
问题：OCR截屏截到bot旧回复（md格式文档内容），时间戳分割后
调用 _extract_user_text_from_md_fragment 尝试从混合文本中提取
'用户文本'，导致md内容中的非md部分绕过过滤→触发查库→错误回复。

修复：
1. 时间戳分割逻辑（两处）：md格式直接跳过，不再提取用户文本
2. 删除 _extract_user_text_from_md_fragment 方法（约100行）
3. 统一过滤逻辑：只要匹配 _is_markdown_document → 直接continue

原理：正常用户聊天不用 #标题、[链接](url)、-列表等md语法，
只要出现就是bot旧回复被OCR读回。不需要尝试提取'用户部分'。
 2026-07-31 00:32:22 +08:00
youpaishidifu 567924a2e4 fix: 加强bot自身回复过滤 — 5层防护拦截OCR读回bot旧回复 
问题：OCR截屏截到bot之前发的回复内容（如'奖励:邀请人可获得该新用户首充金额的30%'、
'invite referral bonus=5afii'、'配置此处的文件，负责展示...'），
这些内容逃过了颜色检测（左确有白色气泡）、时间戳检测、偏旁检测，
流入KB匹配→触发错误回复。

修复（OCR级+Poll级双层，共5类新过滤器）：
1. 英文key=value配置格式：invite referral bonus=5afii
2. 配置文件描述片段：配置此处的文件、负责展示、对应一个商品等
3. 英文奖励关键词：invite/referral/reward/bonus
4. KB内容回读：奖励:、规则:、配置:等KB段落标记
5. 百分比+金额描述：30%+金额/奖励/积分等

原理：正常用户对话不含这些模式，只要出现就是bot旧回复被OCR读回
 2026-07-31 00:17:00 +08:00
youpaishidifu 348e40a995 fix: 病句过滤增强(特殊符号开头) + 急停多阶段中断检查 
1. 病句过滤增强：
   - 新增OCR级+Poll级特殊符号开头碎片过滤：^[~`～]
   - 拦截OCR把'一键'识别为'~键'导致的病句碎片（如'~键导出全服流水'）

2. 急停多阶段中断检查（6处）：
   - _poll函数入口：急停后下一轮立即折返
   - _ocr_read_qq截屏前：防止截屏+OCR继续执行
   - _ocr_read_wechat截屏前：同上
   - _process_ocr_output入口：防止文本处理继续
   - 回复发送前：防止急停后仍发送回复
   - 原有2处：OCR返回后 + 文本过滤后

3. 修复原理：原急停只在while循环开头检查_running，
   线程已深入_poll内部时无法中断同步阻塞的OCR操作。
   现在在每个耗时操作前检查，急停后立即丢弃当前结果。
 2026-07-30 23:39:54 +08:00
youpaishidifu 664d02ac55 fix: 尾部内容也检查时间戳过期 — 修复OCR拼凑历史消息触发查库 
问题：OCR读屏文本含多个时间戳(17:49:58, 8:33:06, 21:56:17)，
中间碎片因last_ts过期被正确跳过，但尾部(最后时间戳之后的内容)
被无条件放行→历史消息内容绕过时间戳过滤→触发查库→自动回复。

根因：尾部逻辑注释说'可能来自新消息'无条件放行，
但21:56:17清晰可见且已过期(差47min=2820s≥300s)，
尾部内容也是历史消息。

修复：尾部增加 last_ts 年龄检查，若最后可见时间戳已过期(≥300s)，
尾部内容也跳过不处理。
 2026-07-30 22:50:33 +08:00
youpaishidifu 5e86ef3c67 fix: 加强病句过滤 — 纯问句碎片、问句+乱码拼接、中段斜线命令 
问题：OCR捕捉到残余病句'怎么办？/printer...'触发查库，
回复了一串配置文件值（printer相关配置参数）。

根因：
1. '怎么办？'单独出现时无实质内容，但含问词被放行
2. '/printer玩家名'是指令帮助碎片，在消息中段未被拦截
3. 两者拼接后绕过了现有过滤器

修复（OCR级+Poll级双层）：
- 新增中段斜线命令碎片过滤：(?<=[\s？?。！,，])/[A-Za-z]{2,}
  拦截'怎么办？/printer玩家名'这种混合碎片
- 新增纯问句碎片过滤：只含疑问词+标点的短句直接丢弃
- 新增问句+乱码拼接过滤：问词开头+斜线/英文乱码特征→丢弃
 2026-07-30 22:36:15 +08:00
youpaishidifu 2a181ab34a fix: 偏旁过滤还原≥1丢弃 + OCR过滤bot自身pipe表格回复 
1. 偏旁碎片过滤还原：≥3→≥1，只要包含CJK偏旁就丢弃
   - 原因：OCR拆字碎片如'亻牛''彡'只要出现就说明是碎片
2. OCR/Poll级新增bot自身回复过滤：
   - pipe表格格式（|参数1|参数2|参数3|结果|）是bot回复格式
   - OCR截屏截到旧的bot回复不该进入KB匹配
   - pipe≥3且长度>30 → 过滤丢弃
 2026-07-30 20:01:47 +08:00
youpaishidifu 2a655e56ac feat: 偏旁Unicode库 + 偏旁数≥3才丢弃 
根因：OCR把'件'拆成'亻牛'，偏旁碎片触发查库。原逻辑只要包含CJK偏旁就过滤，
但正常用户消息也可能偶尔包含偏旁字符。

修复：
1. 新增 unicode_radicals.md 偏旁库文件（225个偏旁+Unicode码表）
2. bot启动时读取md文件构建偏旁字符集 _RADICAL_CHARS
3. 偏旁过滤改为计数：偏旁出现次数≥3才整段丢弃
4. 维护方式：编辑 md 文件添加/删除偏旁，重启 bot 生效

覆盖场景：
- '亻牛'（'件'被拆碎）
- '彳亍'（'行'被拆碎）
- OCR把多个汉字拆成偏旁碎片（≥3个偏旁）
 2026-07-30 18:55:55 +08:00
youpaishidifu 2b03ca1a7d fix: 简化偏旁碎片过滤逻辑，只要包含CJK偏旁就过滤 
- 原逻辑：偏旁数>=CJK完整字数才过滤，但长文本中CJK字数多，偏旁数少，条件不成立
- 新逻辑：只要包含CJK偏旁(U+2E80-U+2FDF)就直接过滤
- 原理：正常用户消息几乎不含这些偏旁字符，只要出现就是OCR把汉字拆碎了
- 覆盖'亻牛'、'彳亍'等OCR拆字碎片
 2026-07-30 18:06:48 +08:00
youpaishidifu 41f55fe9ed fix: 清理HTML标签 + 降低绿色像素阈值 + 增强乱码过滤 
1. HTML标签清理：
   - 在_normalize_ocr_text中清理<br>、<div>等HTML标签
   - OCR截到网页/终端时常带HTML标签，影响文本处理

2. 绿色像素检测阈值降低：
   - 从>=5改为>=3，更敏感地检测微信窗口
   - 防止QQ轮询截到微信内容被误处理

3. 乱码过滤增强：
   - CJK+拉丁混合乱码检测（如'默i'、'鼍'）
   - 生僻字/罕见字检测（CJK扩展区）
   - 系统配置内容过滤（概览、数据看板、在线玩家等）

4. 解决'牛头不对马嘴'问题：
   - OCR截到Wiki/终端内容被当用户消息处理
   - 知识库匹配到错误的section（Wiki标题而非具体内容）
 2026-07-30 17:44:49 +08:00
youpaishidifu 405191bab3 fix: 增强偏旁碎片过滤 + 系统配置内容过滤 
1. 偏旁碎片过滤增强：
   - 去掉长度限制（原≤20字），只要包含CJK偏旁(U+2E80-U+2FDF)且偏旁数>=CJK完整字数就过滤
   - 覆盖OCR把'件'拆成'亻牛'等更长碎片的情况

2. 系统配置内容过滤（新增）：
   - 检测包含@example、smtp、.py/.bat/.sh等特征的行，判定为系统配置内容
   - 检测邮件地址格式（user@domain.tld），判定为SMTP配置片段
   - 防止OCR截屏截到代码编辑器/终端内容被当用户消息处理

3. 同步更新OCR级和Poll级过滤逻辑
 2026-07-30 17:17:30 +08:00
youpaishidifu e42f56dc8f fix: 加强病句过滤 + QQ跨窗口污染检测 
1. 病句过滤增强：
   - 病句6：包含时间戳格式（16：29, 2026/7/29）的句子跳过
   - 病句7：以数字开头且包含问号的句子跳过（如'1屏蔽？不想要的后缀。'）
   - 病句8：包含引号包裹时间戳的句子跳过（如'"2026/7/29"'）

2. QQ跨窗口污染检测：
   - 检测微信绿色像素（R:135-180, G:205-250, B:75-125）
   - 若QQ轮询截图中检测到大量绿色像素，判定为微信窗口，跳过本轮
   - 防止QQ轮询截到微信内容被误处理

3. 像素检测优化：
   - QQ轮询增加绿色像素检测，避免截到微信窗口
   - 微信轮询已有类似逻辑（绿色=自身消息）
 2026-07-30 17:02:46 +08:00
youpaishidifu 52fd2cbd03 fix: 加强病句过滤 + QQ颜色检测逻辑简化 
1. 病句过滤增强：
   - 病句3扩展匹配范围：'^[其将把被]' → '^[其将把被认查问帮试想]'
   - 覆盖OCR常丢失前缀的情况：'默认管理员密码多少' → '认管理员密码多少'
   - 句子以动词开头、缺主语、无标点 → 判定为病句跳过

2. QQ颜色检测简化：
   - 核心原则：只要左半区无白色气泡 → 无用户消息 → 跳过
   - 删除冗余条件分支（仅bot回复、气泡柱检测等）
   - 避免'拿不准保守处理返回True'导致bot自身消息被处理
 2026-07-30 16:48:45 +08:00
youpaishidifu dadbcebe7f fix: EasyOCR GPU OOM 冻结 — 每3次主动重启子进程 + 用原图降显存压力 
根因：EasyOCR reader.readtext() 每次调用后 PyTorch CUDA 内存缓存不释放，
几轮后 VRAM 满 → Allocation Fail(27MB) → 显存错误 → 系统冻结。

修复：
- _easyocr_call_count 计数，达到 3 后 kill 子进程（下次自动重启）
- EasyOCR 用 im_original（1x）代替 im_processed（2x），降单次显存 4x
- _ensure_easyocr_subprocess 遇空 _easyocr_proc 自动重启
 2026-07-30 14:49:43 +08:00
youpaishidifu b382520093 fix: QQ OCR 截图前检查 _ensure_visible 返回值，失败跳过避免截到微信内容 
- _ocr_read_qq 中 _ensure_visible(hwnd) 返回值被丢弃，
  唤醒失败时 ImageGrab.grab 拿到微信窗口内容被当QQ消息处理
- 微信路径已正确检查返回值，QQ路径补齐
 2026-07-30 14:22:01 +08:00
youpaishidifu b55fff8cbb 修复2个bug: 急停后OCR残留 + 知识库奖励配置匹配错误 
Bug1 - 急停(ESC×2)后Windows OCR仍在运行输出日志：
  _emergency_stop设_running=False+杀EasyOCR子进程，但Windows OCR
  (RecognizeAsync)是同步阻塞调用，无法被中断。OCR完成后_poll继续
  处理文本→触发回复。
  修复：_poll中在_read_messages返回后+文本过滤后各增加self._running
  检查，OCR完成或文本处理中如已急停则立即return，不再触发回复。

Bug2 - 用户问寻宝奖励配置，bot返回指令参数表格(匹配度15.38)：
  知识库sdf1_game.md中'## 寻宝玩法介绍'命令表含'寻宝'高频词，
  TF-IDF得分远高于'## 奖励配置：'段。heading bonus仅2.0/词，
  不足以翻转15分的TF-IDF差距。
  修复：heading bonus从2.0/词提升至5.0/词；新增heading连续短语
  匹配bonus(+8.0)，如查询含'奖励配置'且heading含'奖励配置'则
  大幅boost，确保语义匹配的section排到最前。
 2026-07-30 13:49:58 +08:00
youpaishidifu e9bccb688b 修复2个bug: 同poll取最新消息(末条) + 斜线I变形(Iskin)过滤 
Bug1 - 用户问寻宝奖励，bot回复sdf1导入错误：
  OCR从上到下读屏，旧消息排前面新消息排后面。
  原逻辑'只处理第一条'把旧历史消息当新消息处理，
  真正的用户新消息被'同poll第条跳过'挡掉。
  修复：改为取new_items[-1](最后一条=屏幕最下方=最新消息)，
  其余加入seen防重复。

Bug2 - /skin OCR变形为Iskin在消息中后段未被过滤：
  /skin→OCR→Iskin(I替代/)。原过滤器要求^[A-Za-z]开头
  且len>10，但'使用指令Iskin'=9字符→漏网。
  修复：新增CJK+I+小写字母变形过滤器[\u4e00-\u9fff]I[a-z]{2,}，
  拦截所有CJK上下文中的斜线I变形命令。
 2026-07-30 13:04:30 +08:00