youpaishidifu/msgbot
1
1
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
557 Commits 1 Branch 0 Tags
main
Commit Graph
456 Commits
Author SHA1 Message Date
youpaishidifu c06c7df065 fix(monitor): 修复群聊拆分正则误匹配邮箱导致消息丢失 
问题：OCR输出中包含邮箱地址如"youpaishidifu@qq.com"，原正则
 会匹配"youpaishidifu@"作为分隔符，
导致群聊拆分只保留"qq.com"，消息内容完全丢失。

根因：
1. \s不匹配换行符，导致含换行的匹配失败
2. 无邮箱格式排除机制，@后面有.时仍被误匹配

修复：
- 使用显式空白字符列表 (?=[\n|\t| |\t|，|：]) 替代 \s
- 添加负向前瞻 (?@(?![^@]*\.)) 排除@后面含.的邮箱格式
- 两条款分离：空白/标点匹配 + @非邮箱匹配

测试验证：
✓ 换行+@格式正确拆分
✓ 逗号/空格分隔正确拆分
✓ @直接粘连正确拆分
✓ 邮箱地址不被误匹配
✓ 最新消息内容完整保留
 2026-08-16 12:52:20 +08:00
youpaishidifu 2175400744 fix(monitor): 修复全局昵称匹配正则边界过严问题，改用简单子串匹配 
原正则要求前后必须是空格/标点/字符串边界，导致常见OCR格式无法匹配：
- "你好草原探险服务器备用号，我想问" → 未剥离（失败）
- "=>草原探险服务器备用号游戏专用有问题" → 未剥离（失败）

新方案：统一使用最长优先的子串匹配
- 按昵称长度降序排序，优先匹配长昵称（避免短前缀误匹配）
- 直接字符串查找并移除，简单高效
- 不会误删部分匹配的文本（如"服务器备用电源"不会误删"备用"）

测试验证：
✓ 纯昵称剥离
✓ 箭头前缀剥离
✓ 汉字前缀+逗号剥离
✓ 连续多个昵称剥离
✓ 短昵称剥离
✓ 防误删（部分匹配不误删）
 2026-08-16 12:12:09 +08:00
youpaishidifu 91c027f5a1 fix(monitor): 扩展昵称剥离为全局匹配，无论藏在何处都能识别 
【问题】当前 _strip_qq_nickname 只支持前缀匹配（startswith），
但 OCR 输出中昵称可能出现在文本的任何位置，导致部分昵称无法剥离。

【场景复现】
- 输入: '=>草原探险服务器备用号游戏专用有问题，他们常用的登录插件是在哪里下载的？'
- 期望: '有问题，他们常用的登录插件是在哪里下载的？'
- 实际（修复前）: 部分昵称残留，污染知识库检索

【修复方案】
在 _strip_qq_nickname 主循环中新增步骤5（全局匹配兜底）：
1. 前缀匹配优先处理常见粘连格式
2. 若前缀匹配无变化，启用全局正则匹配扫描文本中间
3. 使用前后边界检查避免误删正文中的正常文本
4. 限制最大迭代次数（20次）防止无限循环

【测试验证】
✓ '=>草原探险服务器备用号游戏专用有个问题...' → '有个问题...'
✓ '草原探险服务器备用号游戏专用有个问题...' → '有个问题...'
✓ '你好草原探险服务器备用号，我想问...' → '我想问...'
✓ '谢谢游戏专用，这个问题解决了' → '这个问题解决了'

【新增non_core_kw】口语填充词过滤（2026-08-16）
- '有个', '问题', '常用', '他们', '各位', '大家', '小伙伴'
- 防止口语填充虚增核心关键词数量导致误拒绝

【早期昵称剥离】（2026-08-16）
- 在_process_ocr_output开头调用_strip_qq_nickname
- 防止昵称污染时间戳检测和行合并逻辑
- 位置：垃圾检测之前（第3172行）
 2026-08-16 12:07:04 +08:00
youpaishidifu dec97d1687 修复：口语填充词导致关键词覆盖率误判 + OCR早期昵称剥离 
【问题1】关键词覆盖率虚高
查询"有个问题。他们常用的登录插件是在哪里下载的？"：
- 修复前：core_kw含{'有个','问题','常用','登录','下载'}共5词
- sdf1_login heading"### 2.1 下载"仅命中1词
- 阈值=max(1,(5+1)//2)=3 → 1<3 → 误拒绝

- 修复后：'有个','问题','常用'加入non_core_kw
- core_kw只剩{'登录','下载'}共2词，阈值=1
- heading含"下载" → 1/2 ≥ 1 → 通过 ✓

【问题2】昵称污染早期处理链路
昵称"草原探险服务器备用号"在OCR原始文本中会污染：
- _ocr_text_has_fresh_timestamp时间戳检测
- 行合并逻辑
- _split_and_denoise_segments分段

修复：在_process_ocr_output开头（垃圾检测之前）调用_strip_qq_nickname
确保所有后续步骤都不受昵称字符干扰

新增non_core_kw词条：'有个','问题','常用','他们','各位','大家','小伙伴'
 2026-08-16 11:35:21 +08:00
youpaishidifu 077ad4a893 @fix(monitor): 新增箭头分隔符=>拆分，解决Windows OCR合并多条消息问题 2026-08-16 11:14:19 +08:00
youpaishidifu abfc080283 @fix(monitor): 修复OCR碎片语义重复导致多条回复问题 
问题：同一条用户消息被OCR拆成3条文本变体（如"问一嘴...下载"
vs "在哪能下载" vs "能不能下载"），因文本差异未被seen/_replied_texts
拦截，导致同一意图触发3次回复。

修复：在_process_ocr_output返回前增加语义去重层：
- 提取CJK bigram集合（去停用词）
- 计算Jaccard相似度，>=0.3视为语义重复
- 30秒内保留第一条，后续相似消息跳过

验证：测试消息指纹相似度36-44%，阈值0.3可正确拦截。
@
 2026-08-16 10:31:23 +08:00
youpaishidifu a4d39a3aa1 修复YAML过滤器正则：允许gitcode:等域名格式 
- 修正正则：从'^(github|gitee|gitcode|git)\.ypshidifu'改为'^(github|gitee|gitcode|git)[:\.\s]'
- 修复：gitcode: gitypshidifu...开头的混合消息不再被误杀为YAML行
- 公告查询得以正常进入知识库搜索
 2026-08-15 23:38:42 +08:00
youpaishidifu 1e3bc9325f 修复YAML误杀+核心词优化 
1. YAML过滤器放宽：允许gitcode:等域名格式的消息
   - 添加正则排除gitcode:ypshidifu等已知域名
   - 修复公告查询被误杀问题

2. 核心词提取优化：
   - 将'相关联','相关','有关'加入non_core_kw
   - 添加'那么'到_STOPWORDS
   - 正确识别查询['公告', '消息']为核心词

3. 保持重复回复检测逻辑不变
 2026-08-15 23:35:53 +08:00
youpaishidifu 64be271f7f 修复病句过滤器：>=6而非>6 
- 确保'问插件怎么用'等6字查询正常放行
- 保持对所有缺主语碎片的严格过滤
 2026-08-15 23:01:20 +08:00
youpaishidifu b2e0c6fe87 放宽病句过滤器长度阈值：从>8改为>6 
- 修复'问插件怎么用'等短查询被误杀
- 保持对其他缺主语碎片的严格过滤
 2026-08-15 23:00:13 +08:00
youpaishidifu 5b88ea509f 优化病句过滤器：放行包含核心动作词的'问'开头消息 
- 扩大例外规则：不仅检查疑问词，还检测下载/地址/查询等核心动作词
- 修复'问一下登录插件下载地址'等不含疑问词的正常查询被误杀
- 保持对其他缺主语碎片（其/将/把/被/认/帮/想/试开头）的严格过滤
 2026-08-15 22:59:10 +08:00
youpaishidifu e456320deb 修复病句过滤器误杀正常查询消息 
- 分离'问'开头的消息处理逻辑
- '问一嘴'、'问一下'等正常查询消息不再被误判为病句
- 包含疑问词且长度>8的消息放行
- 保留其他缺主语碎片的过滤（其/将/把/被/认/帮/想/试开头）
 2026-08-15 22:56:24 +08:00
youpaishidifu fcc873626a fix(monitor): 修复nicknames变量未定义导致的OCR崩溃 
问题: 调用方使用未定义的nicknames变量导致NameError崩溃
日志: 'OCR失败: name 'nicknames' is not defined'

修复: 改用本地变量_has_nick_marker检测@或逗号标记，不再依赖外部变量
 2026-08-15 21:23:37 +08:00
youpaishidifu e01249dcc1 fix(monitor): 扩展联系方式匹配规则 
修复_sanatize_message中的手机号匹配遗漏：
1. 固话：以0开头的区号+号码（如010-12345678、07311234567）
2. 400电话：以400开头的7-8位数字
3. 急救电话：110、119、120、122

确保所有联系方式都能被正确识别和剥离，防止误触回复。
 2026-08-15 21:06:50 +08:00
youpaishidifu 79b1beabef fix(monitor): 修复OCR合并消息导致公告问题丢失 
当OCR将多条消息合并成一行时（如公告信息呀@游戏专用，草原探险服务器备用号，嘿啊），
_strip_qq_nickname只保留最后一个分隔符后的内容，导致前面的消息被丢弃。

新增_split_by_nick_sep方法，按昵称分隔符拆分所有消息段，确保：
1. 公告问题那个服务器最近有哪些那个公告信息呀能被提取
2. 服务器地址问题那个服务器的地址是多少啊也能被提取
3. 每条消息都进入处理队列，而不是只取最后一段
 2026-08-15 20:43:27 +08:00
youpaishidifu 98ecf96714 fix(monitor): 修复OCR重复识别导致的连续回复问题 
- 添加文本归一化：全角→半角标点转换
- 使用归一化文本进行查重比较，防止OCR标点差异导致查重失效
- 基线轮处理后，后续轮询仍能正确识别相同消息
- 修复连续回复2条的问题
 2026-08-15 18:51:59 +08:00
youpaishidifu 24a7b51660 fix(monitor): 修复OCR重复识别导致的连续回复问题 
- 添加文本归一化：全角→半角标点转换
- 防止OCR对同一消息的不同识别结果（如？ vs ?）导致查重失效
- 基线轮处理后，后续轮询仍能正确识别相同消息
- 修复连续回复2条的问题
 2026-08-15 18:49:37 +08:00
youpaishidifu ae27ee91cd fix: 修复KB搜索回复内容不对和历史消息重复处理问题 
问题1：回复内容不对
- protect.md的section heading包含整个section内容（含<br>和列表标记），导致下载意图加权检查误匹配
- 修复：增加检查，如果heading含<br>或列表标记，说明是复合标题，需检查下载是否出现在标题主体部分

问题2：历史消息重复处理
- 基线轮处理后seen.discard(item)从持久化集合中移除，但未重新加入_seen_messages
- 修复：基线轮处理后增加self._seen_messages.add(item)，确保下次轮询不再处理此消息
 2026-08-15 10:13:55 +08:00
youpaishidifu ad9b1dc59b fix(monitor): 修正日期检查逻辑 - 不阻塞新鲜消息 
问题：公告表格包含历史日期（2026/8/14昨天），但用户最新提问是今天的
      原逻辑检查所有日期非今日就直接拒绝，误杀了新鲜消息

根因：
1. 日志显示提取到日期: ['2026/8/14', '2026/8/3']（都是历史日期）
2. 用户消息 9:28:27 是新的，时间戳9:06在今天内
3. 原逻辑：所有日期非今日 → 拒绝 ❌

修复：
- 日期检查改为警告，不阻塞处理
- 优先检查时间戳新鲜度（第二道关卡）
- 如果时间戳≤300s → 放行 ✅
- 如果时间戳>300s → 丢弃 ✅

效果：
- 公告表格+新消息 → 放行 ✅
- 过期消息（时间戳>300s）→ 丢弃 ✅
 2026-08-15 09:32:08 +08:00
youpaishidifu 02702415a0 fix(monitor): 强化时间戳过滤 - 两道关卡检查 
问题：公告表格包含历史日期（如2026年8月3日），时间戳9:06在今天内
      导致过期22小时的历史消息被误认为新消息处理

根因：
1. OCR提取日期正则不匹配中文格式'2026年8月3日'
   - 原正则只匹配 YYYY/M/D 或 YYYY-M-D 格式
   - 公告使用中文日期格式，导致raw_dates为空
2. has_past_date=False → 跳过日期检查
3. 只检查时间戳9:06（在今天内）→ 放行

修复：
1. 扩展正则支持中文日期格式：\d{4}年\d{1,2}月\d{1,2}日
2. 新增第一道关卡：日期新鲜度检查
   - 如果文本包含日期信息，必须至少有一个日期是今天
   - 否则直接拒绝，不让进入后续队列
3. 保留第二道关卡：时间戳检查（现有逻辑）
   - 时间戳必须在300秒内

效果：
- 公告表格（含历史日期）→ 拒绝 ✅
- 新消息（无日期+新鲜时间戳）→ 放行 ✅
- 用户消息（无日期+无时间戳）→ 交给DB查重 ✅
 2026-08-15 09:15:23 +08:00
youpaishidifu 268301c60d fix(monitor): 过滤单字符映射避免误还原 
问题：
- '儿' → '凵' 单字符映射导致误还原
- 输入 '亻尔个事儿' 被错误还原成 '亻凵个事儿'

修复：
- _restore_radical_text() 只匹配长度 ≥ 2 的偏旁组合
- 避免单字符误匹配导致的错误还原

效果：
- '亻尔个事儿' → '你个事儿' ✅
- '儿' 不再被还原成 '凵' ✅
 2026-08-14 10:26:28 +08:00
youpaishidifu 7932617d0a feat(monitor): 补充常用OCR错误映射 
问题：
- '亻尔' 不在映射表中，导致无法还原成 '你'
- '讠人' 不在映射表中，导致无法还原成 '认'

修复：
- 添加 common_ocr_errors 字典
- 补充常见 OCR 错误映射：
  * '亻尔' → '你'
  * '讠人' → '认'
  * '讠我' → '认'（方言口音）

效果：
- '亻尔个事儿' → '你个事儿'（放行）
- '默讠人登录密码' → '默认人登录密码'（若添加 '讠人' 映射）
 2026-08-14 10:24:23 +08:00
youpaishidifu c992586f05 fix(monitor): 修正偏旁合体映射方向 
问题：映射方向错误，导致还原逻辑反向

原因分析：
- unicode_radicals.md 示例列格式：'件→亻牛'
- 意思是：正确汉字='件'，OCR错误='亻牛'
- 合体映射应为：'亻牛' → '件'（OCR错误→正确）

修复：
- 正确解析示例列：left='件', right='亻牛'
- 建立映射：radical_map['亻牛'] = '件'

验证：
- '讠吾' → '语'（正确）
- '彳亍' → '行'（正确）
- '亻尔' → '你'（新增支持）
 2026-08-14 10:21:59 +08:00
youpaishidifu 0c974d05a9 fix(monitor): 修正偏旁合体映射解析逻辑 
问题：解析 unicode_radicals.md 时列索引错误，导致映射表为空

修复：
- 正确提取第5列（索引5）作为补充字符
- 修正 parts 数组索引：parts[4]=示例, parts[5]=补充字符

验证：
- 构建 45 条合体映射（如 '讠吾'→'语', '亻尔'→'你'）
- 测试还原：'默讠人'→'默认人', '亻尔'→'你'
 2026-08-14 10:19:32 +08:00
youpaishidifu 8b4542d2f9 feat(monitor): 添加偏旁合体还原功能 
1. 新增 _load_radical_mapping() 函数
   - 解析 unicode_radicals.md 构建偏旁组合→完整汉字映射表
   - 例如: '讠吾'→'语', '亻尔'→'你', '彳亍'→'行'

2. 新增 _restore_radical_text() 函数
   - 按长度降序匹配，避免短模式误匹配
   - 将 OCR 拆分的偏旁组合还原为完整汉字

3. 改造偏旁过滤逻辑（OCR阶段 + Poll阶段）
   - 先尝试合体还原，再统计偏旁占比
   - 还原后偏旁占比>10%才丢弃
   - 修复 OCR 误识别（默讠/亻尔）导致有效消息被丢弃的问题

示例：
  输入: '默讠人登录密码'
  还原: '默认人登录密码'
  结果: 放行
 2026-08-14 10:17:29 +08:00
youpaishidifu b08363551a fix(monitor): Poll阶段也放宽偏旁过滤 
与OCR阶段保持一致，从"包含偏旁字符就丢弃"改为"偏旁字符占比>10%才丢弃"
防止OCR误识别（默讠/亻尔）导致有效消息被丢弃
 2026-08-14 10:10:16 +08:00
youpaishidifu 3e416c024b fix(monitor): 放宽偏旁过滤 + 修复表格提取逻辑 
1. 偏旁字符过滤放宽（monitor.py）
   - 从"包含偏旁字符就丢弃"改为"偏旁字符占比>10%才丢弃"
   - 修复 OCR 误识别（默讠/亻尔）导致有效消息被丢弃的问题
   - 纯偏旁碎片（如⺀⺁⺂⺃⺄⺅⺆⺇⺈⺉⺊）仍会被丢弃

2. 表格提取逻辑修复（auto_reply.py）
   - 放宽表格行检测：不要求行尾必须有|
   - 原因：Markdown表格可能未闭合或OCR识别不完整
   - 修复公告表格只显示第一行的问题
 2026-08-14 10:08:41 +08:00
youpaishidifu 7eaca50a71 fix(monitor): 修复消息分割和昵称剥离问题 
1. 句尾标点拆分优化（不再因句号/问号强制拆分）
   - 仅在检测到【新昵称/头衔】出现在标点后时才拆分
   - 增加续接代词检查（那/这/我/你/他/最/刚等）
   - 减少到最多拆1次，防止过度拆分

2. 群聊多消息拆分逻辑增强
   - mid-text 昵称分隔符扩展 @ 匹配（支持昵称@昵称格式）
   - mid-text 剥离后循环剥除残留开头的已知昵称
   - 修复 草原探险服务器备用号@游戏专用 格式中第二个昵称残留问题
 2026-08-13 23:47:45 +08:00
youpaishidifu 2a5f16ae1f fix(kb+filter): 修复管理员密码查询返回玩家端问题 + 问句豁免公共子串跳过 
1. auto_reply.py: 管理员密码查询(含php)要求heading含"管理员"，防止php.md玩家端被误选
2. monitor.py: Poll阶段回复公共子串跳过增加问句豁免，含疑问词的消息不再被误判为旧回复片段
 2026-08-13 17:17:28 +08:00
youpaishidifu 93c50ecef3 fix(ocr): 预分割阶段先剥离bot旧回复再检测噪声 
问题：OCR混合文本（用户提问+bot旧回复）被 _is_noise_text 误判为噪声丢弃。
例：'运营方有权...@游戏专用服务器近期有哪些公告...' → 含'运营方有权'触发协议噪声检测→整段丢弃。

修复：在 _pre_split_noise_filter 中先调用 _strip_bot_reply_fragments 剥离bot旧回复，
再对剥离后的文本做 _is_noise_text 检测。
剥离后为空→丢弃；剥离后仍有噪声→丢弃；否则保留。
 2026-08-13 14:26:33 +08:00
youpaishidifu 43fcb87238 fix(ocr): 修复过滤器1中未定义变量stripped导致新鲜时间戳消息被误丢 
问题：_ocr_text_has_fresh_timestamp在发现新鲜时间戳后调用record_user_message
时使用了未定义的stripped变量，触发NameError，被except捕获后继续执行
最终返回False，导致消息被丢弃。

修复：在函数开头提前定义stripped = text.strip()
 2026-08-12 21:38:15 +08:00
youpaishidifu d661b7c208 fix(repeat): 修复重启后已处理消息被重复处理 
问题：有新鲜时间戳(≤300s)的用户消息在过滤器1放行时，未调用
record_user_message()记录到DB。重启后：
- _seen_messages被清空
- DB只有bot回复记录，无用户消息记录
- is_user_message_replied()返回False（骨架匹配也失败）
→ 同一用户消息被当作新消息重新处理

修复：在"发现新鲜时间戳{ts}（≤300s），放行"时同步记录用户消息到DB

注意：无时间戳消息已在原代码中记录(record_user_message)
本次仅补充有时间戳消息的记录
 2026-08-12 18:20:16 +08:00
youpaishidifu d043da57e3 fix(ocr): 修复多时间戳场景下用户提问被误丢 (#1531 #1532) 
1. stage splitting 时间戳规整：第二段分隔符由 \2(同分隔符) 放宽为 [.;:]，
   使 15;27.05 这类 EasyOCR 混合分隔读法被正确识别为 15:27:05，
   修复 _inherited_ts 不更新导致下方消息继承陈旧时间戳被'尾部较老'误杀。
2. 过滤器层调整顺序：先剥 bot 旧回复片段，再剥 md 尾巴。OCR 把
   '用户新消息+bot旧回复'拼行时，md 尾巴剥离会在 bot 回复的 '::|::'
   残片处切断、误删用户提问，导致 filter4 整体丢弃。
3. _is_qq_ui_element 规则6：日志措辞修正(跳过->豁免/放行)，并新增
   含@+疑问词直接放行的纵深防御，避免用户提问被 UI 规则误杀。
 2026-08-12 16:48:26 +08:00
youpaishidifu 9d44b8b1d1 修复过滤器4误判用户名@提及为回复残片：公共子串为用户名时豁免 2026-08-12 14:57:22 +08:00
youpaishidifu b74fd5deb0 修复OCR拉丁混淆(php↔4p)导致去重失效引发的重复回复：新增中文骨架匹配兜底 2026-08-12 14:42:01 +08:00
youpaishidifu c0025a6f12 修复OCR重复回复+KB后台密码匹配+QQ UI过滤'有人@我' 2026-08-12 12:39:44 +08:00
youpaishidifu 1738daffec 修复短句碎片和模糊重复跳过的误报：允许包含括号的短消息，问句不视为模糊重复 2026-08-12 11:45:50 +08:00
youpaishidifu 7e3b3141b4 修复 Task #1516：移除 stage 级 bot 菜单过滤器，避免误杀用户消息 2026-08-12 09:45:10 +08:00
youpaishidifu 9080a4db0c fix: OCR捕获bot自身回复菜单触发重复查库(Task #1515) 
_is_noise_text(stage级)+逐行过滤新增bot回复菜单模式检测：
- 版本标签：(稳定版)(最新开发版)(官方版)等
- checkbox标记：[√][⚠][✗]
- md链接格式：[text](url)
防止OCR把屏幕上的bot回复菜单重新识别为新消息触发KB搜索。
 2026-08-11 22:07:15 +08:00
youpaishidifu 92568c249f fix: OCR病句乱码检测——数字混杂中文间(如游0由)触发_is_noise_text拦截 
Task #1514: 在_is_noise_text中新增规则，检测CJK+单个数字+CJK模式
(如'游0由去哪下载登陆插件啊')，排除合法组合(序号/数量/版本号等)。
 2026-08-11 17:02:46 +08:00
youpaishidifu 95d1514324 fix: 增强过滤器拦截纯@username消息触发查库回复 
新增规则6：匹配中文前缀+@+用户名+空格+用户名的纯@提及消息，
排除含疑问词的消息（如请问、怎么等）。长度限制放宽至50字符。
修复单独@username消息（如'有人@拜 youpaishidifu'）无实质内容
触发知识库搜索回复的问题。同步dist副本。
 2026-08-11 15:23:35 +08:00
youpaishidifu 41e5ee83c8 恢复_is_markdown_document的@staticmethod装饰器，修复OCR处理链崩溃 2026-08-11 14:52:56 +08:00
youpaishidifu 80ebe8e642 新增 _strip_markdown_tail: md 尾巴切掉保留用户提问, md 大头整段丢弃; stage/逐行/入库前 4 处接入 2026-08-11 14:20:51 +08:00
youpaishidifu 1752c055e0 修复 _is_markdown_document 中 #\s*# 规则误用 re.search 导致 QQ 标签触发 md 文档丢弃 2026-08-11 13:17:14 +08:00
youpaishidifu 290daf2d9e 修复回复片段过滤器双阈值误杀：用户消息带昵称时被当bot旧回复跳过 
- 11:14:39日志：'youpaishidifu关于我们，[潜水] BXZYAE'(用户youpaishidifu消息'关于我们'+群状态侧栏UI拼成一行)被'回复内容片段'丢弃，1 raw 0 filtered
- 根因：_process_ocr_output逐行过滤处的回复片段检测用size>=6无条件匹配，而stage级filter4已用'大部分才算'(lm>=15或lm>=8且>=60%)——历史回复含'youpaishidifu'(@提及旧回复)时与用户消息共享13字符公共子串(占比仅45%)，filter4正确放行后被宽松阈值抓回
- 修复1：3648行逐行检测阈值对齐filter4标准(大部分才算)
- 修复2：问句豁免——短问句与bot旧回复共享长短语时(如'登录插件下载地址是啥啊'vs下载地址回复共享8字占80%)60%标准仍会误杀；line含疑问词且非任何replied的完全子串→视为用户提问放行。真回声(line整段≈bot回复)仍拦
- filter4同步加问句豁免，两处标准统一
- 验证7/7：本次bug放行、短问句变体放行、真回声整段/带@/回复前缀整段读出均拦
 2026-08-11 11:33:27 +08:00
youpaishidifu 19da7e5fa5 放宽OCR时间戳提取：混合分隔符+独立6位裸数字，带合法性鉴权 
- 混合分隔符(10;20.48)：OCR把冒号读成不同符号，原正则要求同分隔符漏提最新时间戳，导致整批消息被'无新鲜时间戳'丢弃（10:21:54日志中10;14;21被提取但10;20.48丢失→454s超窗→连队列日志都没有）
- 独立6位裸数字(102048)也当HHMMSS时间戳：OCR无法保证格式但能保证读出数字，前后顾挡数字/字母/中文/下划线/分隔符/%，防版本号、日期、URL、小数串取段
- 鉴权：只收合法HH/MM/SS(hh<=23, mm<=59, ss<=59)，235959上限；016060/240000/520131等非法直接扔——_is_timestamp_old对非法返回False会被误判'新鲜'整批放行
- filter1(_ocr_text_has_fresh_timestamp)与_line_has_fresh_ts两处同步放宽
- 防回归：abc0.50;57(URL残片带前缀)/版本3.2.1/3.141592/0.50;57带URL上下文仍正确拒绝
 2026-08-11 11:04:08 +08:00
youpaishidifu 4173f28009 修复QQ UI过滤器误杀用户消息：')昵称 内容'带空格格式被当UI跳过 
- _is_qq_ui_element规则4原正则^\)[\w\u4e00-\u9fff]{2,}\S有回溯bug：\S回溯吃掉username末尾字符，导致')youpaishidifu 关于我们'（用户youpaishidifu发的真实消息'关于我们'，OCR把@/冒号误读为)）整行被误判UI丢弃
- 规则4改为分步判断：)username后剩余为空或首字符非空白（粘连UI）→跳过；剩余首字符是空白→疑似用户消息放行
- 放行后剥离')昵称 '前缀（OCR误读的)会挡在_strip_qq_nickname裸昵称剥离前）
- 剥离的短文本（'关于我们'4字）记入_ui_prefix_stripped，在短句碎片(≤8字无问词)检查处豁免——规则4放行贯穿到底，避免白修
- 验证：')C418minecraft'仍跳过（真UI），')youpaishidifu 关于我们'→'关于我们'到达消息流，'有人@拜'(UI提示)仍正确丢弃
 2026-08-11 10:07:05 +08:00
youpaishidifu b4b3da2633 修复OCR过滤器误杀：进程名检测撞上'服务器'子串 
- 服务器近期公告有哪些？被误判为Windows进程名丢弃（'服务'子串命中词表）
- 加负向前瞻(?!中文)：命中词后紧跟中文字符视为普通文本，不丢弃
- 窗口标题带ASCII后缀(记事本.txt/文件资源管理器 - 此电脑)仍正常命中
- 命中日志升级为WARNING并爆出具体命中词和全文，不再装哑巴
 2026-08-10 23:48:49 +08:00
youpaishidifu 18347a9f7d 修复OCR新旧消息同屏时新鲜消息被旧继承时间戳误杀(Task #1510) 
三层修复：
1. 表情包碎片过滤器不再误杀纯时间戳行(15;35;38等双分号时间戳)
   - 修复前：EasyOCR时间戳含两个分号被当碎片丢弃，新鲜时间戳丢失
   - 修复后：纯时间戳行(\d{1,2}[:;.]\d{1,2}...)直接放行
2. _SENT_END补ASCII问号(?)，问句行不再与下一行合并
   - 修复前：'游戏专用PHP有哪两种登录模式?'以半角?结尾被合并
   - 修复后：问句行独立，多条用户消息不会被,黏成一行
3. stage splitting新增_stage_fresh_hint前向peek
   - QQ时间戳渲染在消息下方，消息行继承的是上一行(可能陈旧)时间戳
   - 本行或下一行含新鲜时间戳(≤300s)时，继承时间戳较老不丢弃，交过滤器+DB查重
   - 新增_line_has_fresh_ts辅助方法
 2026-08-10 16:13:56 +08:00
youpaishidifu efdbec381b fix: QQ昵称剥离将正常消息吞空——污染昵称+@贪婪匹配+前导垃圾吞问号 
Task #1508: 消息'@游戏专用PHP有哪两种登录模式?'被_strip_qq_nickname剥离成空串,
空消息被当作消息进expanded查库。

三层根因:
1. 自动入库逻辑把'@游戏专用PHP有哪两种登录模式'整段(昵称+正文贪婪匹配)写进
   config.json qq_nicknames, 污染昵称后续先命中, 正确正文被当昵称剥掉
2. _leading_junk前导垃圾字符类含!！?？, 剥离残留的'?'被吞掉→消息变空
3. 调用点无空消息守卫, 空串照样expanded.append

修复:
1. 自动入库前校验: 匹配后紧贴正文(rest非分隔符开头)或长度>12的不入库
2. _leading_junk不再吞句末标点!！?？, 只清空格/逗号/句号/冒号/分号
3. _strip_qq_nickname剥离后为空回退原文(防御兜底)
4. 两处调用点加if msg守卫, 空串不进查库/回复
 2026-08-10 14:40:29 +08:00