youpaishidifu/msgbot
1
1
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
486 Commits 1 Branch 0 Tags
c55c382358a9b4be03cbbb58280d4bd9de3fc20a
Commit Graph
486 Commits
This Branch
This Branch
All Branches
Author SHA1 Message Date
youpaishidifu c55c382358 fix(msgbot): re.search()返回值缺bool()包装导致|=类型错误 
- 第7863行/7875行：`'@' in text and re.search(...)` 赋值为 re.Match 而非 bool
- 后续 `|= any(...)` 触发 re.Match |= bool → TypeError
- 修复：两处均加 bool() 包裹，与第7819行一致
 2026-08-29 17:46:24 +08:00
youpaishidifu 19019f80d3 fix(msgbot): 描述性碎片拦截——以"拥有/提供/支持"等动词开头+无主语+无问词→碎片 
- 新增 _descriptive_verbs 检查（len<=10 短文本分支内，核心名词豁免之前）
- 例："拥有完善的领地系统"→描述性动词开头+无主语→碎片丢弃，不再触发错误 KB 回复
- "领地系统"、"登录配置"等无描述性动词前缀的合法短查询不受影响
 2026-08-29 16:16:50 +08:00
youpaishidifu e0da52ead8 fix(msgbot): 修复历史消息漏放导致自言自语 + user_messages未入库 
- 修复 _ocr_text_has_fresh_timestamp：无日期+时间戳全部过期(>300s) 时由误放行改为丢弃。
  原"OCR时间戳不准确"假设会让QQ窗口中12:08/12:24等历史老消息被当作新消息，触发自言自语。
- 在"无日期+新鲜时间戳"与"无日期+无时间戳中文"两条放行路径补上 record_user_message，
  修复 user_messages 表长期为空、跨轮去重失效的问题。
 2026-08-29 15:09:33 +08:00
youpaishidifu c3f0fa0882 feat: 停止信号优先 + DB环形缓冲区 (Task #1617 + #1618) 
Task #1617 停止信号优先机制:
- 新增 threading.Event (_stop_event) 作为主停止信号
- 新增 _interruptible_sleep() 包装 Event.wait(timeout)
- 所有关键 time.sleep() 替换为 _interruptible_sleep()
- _poll 检查点同时检测 _stop_event.is_set() 和 _running
- stop()/_emergency_stop() 先 set() 唤醒阻塞线程
- start() 清除残留 stop_event

Task #1618 DB落库修复 + 环形缓冲区:
- user_messages/bot_messages 每平台最多10条 FIFO
- 物理重启时不清空这两张表(仅清空 ocr_staging/keyword_scores)
- 新增 SQLite 临时文件到 .gitignore

其他:
- 删除 _ocr_blue_test.py / _ocr_crop_test.py 调试文件
 2026-08-29 13:17:58 +08:00
youpaishidifu 96388d18f9 修复Bot自言自语拦截：不再仅依赖recent_replies，同时检查_replied_texts 
根因：Bot自言自语拦截条件为recent_replies不为空，但物理重启后
DB被清空→recent_replies为空→拦截逻辑完全不执行。

修复：构建_self_check_sources列表，合并recent_replies和_replied_texts。
_replied_texts在物理重启时保留（Task #1616），确保拦截逻辑始终有效。
 2026-08-29 12:20:07 +08:00
youpaishidifu f0f2c39d71 修复重启后Bot自言自语：物理重启时不清空_replied_texts去重集 
根因：_force_clear_all_residual_data(clear_db=True)在物理重启时
同时清空_replied_texts和DB，导致QQ窗口中旧bot回复的OCR捕获
无法被任何查重机制拦截。

修复：_replied_texts代表QQ窗口中可能仍可见的bot历史回复，
物理重启时保留该集合，仅清空_seen_messages和其他状态。
_replied_texts在__init__阶段从DB加载后跨重启持久。
 2026-08-29 10:21:08 +08:00
youpaishidifu c34ed371eb 修订时间戳新鲜度评分逻辑：≥5分直接放行，<5分查DB决定是否补分到5 2026-08-28 20:10:16 +08:00
youpaishidifu cb48663d87 Task #1611 v2: 修复过去日期分支pass导致return False的bug 2026-08-28 18:07:40 +08:00
youpaishidifu 279370271c Task #1611: 修复过去日期+未来时间戳被误丢弃 
问题：OCR识别到过去日期(2026/8/25)，但时间戳是今天的(17:45:35, 18:17:27)，
被误判为未来时间戳丢弃，导致用户新消息丢失。

根因：过去日期分支调用_is_timestamp_old时未传skip_future_check=True，
导致时间戳比系统时间晚时被拦截。

修复：过去日期分支增加skip_future_check=True参数，
当日期识别错误但时间戳正确时，信任时间戳判断新鲜度。

场景：OCR把今天日期误读成过去日期，但时间戳正确
例：2026/8/28 → 误读成 2026/8/25，但时间戳17:45:35正确
 2026-08-28 17:32:36 +08:00
youpaishidifu 9093458f9c Task #1610 修复：未来时间戳容忍偏差扩大到300s 
根因：_TS_FUTURE_TOLERANCE_S=15秒太严格，OCR读到16:18:39的消息在16:18:58被处理时，
被误判为"未来时间戳"（差19s），导致消息被丢弃。

修复：将容忍偏差从15秒扩大到300秒（与max_age持平）
- 300秒以内的时间戳偏差全部视为有效（含OCR延迟/队列积压）
- 300秒以外的才判定为"未来时间"直接丢弃

效果：16:18:39的消息在16:18:58被正常识别为新鲜时间戳（19s<300s）
 2026-08-28 16:54:45 +08:00
youpaishidifu 4404fb40f7 Task #1609 修复：同轮择优逻辑优先处理最新消息而非最旧消息 
根因：OCR读到两条消息（17:45和18:17），质量分评估未考虑时间戳新鲜度，
导致旧消息因关键词'插件'加分更高被选中

修复：在质量分评估中加入时间戳新鲜度奖励（≤300秒+5分，≤600秒+3分，≤1800秒+1分），
并修改排序逻辑：先按质量分降序，再按时间戳差值升序（越新鲜越好）

效果：当多条消息质量分相近时，优先处理最新消息
 2026-08-25 18:27:52 +08:00
youpaishidifu 2726863405 Task #1608 修复：过去日期文本中含新鲜时间戳时被误丢弃 
根因：OCR一次读到的文本同时含历史内容（公告表格）和新消息
例：'2026年8月3日 | 升级服务器...' + '17:45:35 登录插件在哪儿下载'
当前逻辑有过去日期→全量丢弃，误伤新消息

修复：检查是否有新鲜时间戳(≤300s)，有则放行（新消息特征），无则丢弃（纯历史消息）

触发场景：用户在新消息中@bot时，OCR同时读到了上一条bot回复的历史公告表格
 2026-08-25 17:55:03 +08:00
youpaishidifu c78c5a1636 Task #1607 修复：纯下载意图匹配错误 + OCR错误年份降级 
1. auto_reply.py: '哪儿下载?'等无核心词查询不应直接放行，
   改为全文回退检查（beibao.md全文不含'登录'等插件词→拒绝）
   修复 '在哪儿下载?' 误答背包插件问题

2. monitor.py: OCR错误年份(12026年)时增加本地时间戳辅助判断，
   时间戳新鲜(≤300s)则放行，否则丢弃
   修复历史消息中带今天时间戳时因OCR年份错误被全量丢弃
 2026-08-25 17:41:32 +08:00
youpaishidifu eac9ece77f Task #1606 修复：OCR识别错误日期（如12026年8月38日）导致查重失效 
Bug: EasyOCR把2026年8月3日识别成12026年8月38日→年份12026超范围被跳过→dates=[]→
过滤器1放行给下游→基线轮次选中近期公告触发二次回复，无查重日志。

Fix:
1. 年份解析前增加1900~2100范围检查，异常年份直接跳过不加入dates
2. 新增_ocr_fakedate_detected标志：无有效日期但检测到OCR年份异常（如12026）→丢弃
   防止历史消息特征被漏过无日期放行路径
3. 防御场景：未来日期（如2030年）、过去日期OCR噪声（年份畸形的历史记录)
 2026-08-25 16:40:20 +08:00
youpaishidifu 12f269acaf 修复下载类查询匹配错误：相关性检查阶段应用同义词映射（Task #1604） 2026-08-25 15:44:48 +08:00
youpaishidifu 35171d193b 修复OCR噪声过滤器误丢合法简短查询（Task #1603） 2026-08-25 11:55:28 +08:00
youpaishidifu ce6ff1a830 fix(Task#1602): 过去日期时间戳放行bug导致md表格残留漏网 
- _ocr_text_has_fresh_timestamp 中 has_past=True 时不应放行
- 根因：OCR抓取历史md表格（含旧时间戳如10:20:26），'新鲜时间戳'检查误放行
- 修复：有过去日期→直接丢弃（与has_today逻辑一致），不检查时间戳
- 前置修复：Task#1601 CUDA子进程探针（gui.py _probe_cuda_safety）
- commit eef3e08 已推 git.ypshidifu.cn
 2026-08-25 10:42:15 +08:00
youpaishidifu eef3e08f8f fix(Task#1601): gui.py CUDA子进程安全探针，防止access violation崩溃 
- 新增_probe_cuda_safety()静态方法：子进程做CUDA显存分配(torch.zeros(1,device='cuda'))
- 子进程崩溃(returncode=0xC0000005 ACCESS_VIOLATION)只杀子进程，主进程存活
- _check_memory_for_gpu()内存检查通过后调用探针，探针失败→降级CPU模式
- 验证：本机GTX1650+torch2.5.1+cu121探针returncode=3221225477，探针正确拦截
- monitor.py已有子进程隔离(_ensure_easyocr_subprocess)，无需修改
 2026-08-25 10:12:41 +08:00
youpaishidifu bdb4e5c168 fix(Task#1600): _is_noise_text新增Markdown表格管道残留检测 
QQ渲染的md表格(|日期|内容|...)被OCR抓取后，管道符结构未被is_noise_text识别，
导致表格碎片通过预分割管道进入KB搜索触发误回复。

修复：在过滤器2中新增管道残留检测：
- 模式A: 以|开头 + 2+管道符 → 整行表格片段
- 模式B: 3+管道符 + 含CJK → 截断表格片段
- 豁免: 含疑问词(?) → 可能是用户讨论表格语法
 2026-08-24 22:54:59 +08:00
youpaishidifu 5952b8672c 修复_is_noise_text中|运算符类型错误 
re.search返回re.Match|None与bool的|=报unsupported operand type(s)，
三处_has_user_msg_feature赋值处re.search外加bool()包装。
 2026-08-24 22:32:20 +08:00
youpaishidifu 08ddc5a89a 修复预分割配置碎片漏网导致用户消息被丢弃 
新增_is_config_fragment检测bot配置面板碎片（≥2配置键或空值截断标签），
在_split_and_denoise_segments逐段循环接入拦截，并对合并结果做二次净化逐行
恢复用户消息，解决单key碎片合并后凑够阈值被整体判噪声丢弃的问题（如"近期公告"）。
 2026-08-24 22:16:36 +08:00
youpaishidifu 1b36d92909 fix: Task #1595 修复UI时间戳误检导致消息误丢弃 
问题：OCR抓取配置面板+用户消息+UI时间戳时，_is_noise_text因检测到多条key:value而丢弃整段文本，包括其中的用户消息

修复：在噪声检测中添加用户消息特征豁免
- 包含@提及（如@利）→ 不丢弃
- 包含疑问词（吗呢多少怎么如何哪什么几）→ 不丢弃
- 包含明确查询意图（查/问/看+插件/功能/命令等）→ 不丢弃

应用场景：
- 配置面板显示+用户提问混排
- UI时间戳被OCR抓取粘连到文本末尾
- 避免误杀真实用户消息
 2026-08-24 18:03:09 +08:00
youpaishidifu ab598087ad Task #1592: 粗暴检测配置文件格式并丢弃 
- 在_is_noise_text方法开头实现配置文件格式检测
- 支持JSON格式、key:value对、等号分隔键值对、YAML/INI格式
- 无问号/疑问词时直接丢弃，不进入后续KB搜索
- 移除Task #1591在len<=10分支内的重复检测逻辑
 2026-08-24 17:29:04 +08:00
youpaishidifu 5e1ece6076 扩展配置文件格式检测，支持多条key:value拼接格式（如'图标: potato 标题:自杀'），忽略大小写/标点差异 2026-08-24 16:40:56 +08:00
youpaishidifu 3c118d3665 fix: 手动停止卡死+配置文件内容误触发自动回复 
问题1（Task #1590）：手动停止导致GUI卡死
- 根因：gui.py line 791 self.monitor.stop()在GUI主线程执行，线程join卡住时GUI冻结
- 修复：改为后台线程执行（复用_stop_monitor_async）

问题2（Task #1591）：配置文件内容"图标: shield"误触发自动回复
- 根因：_core_nouns含"图标"→残片过滤器放行→KB搜索命中sdf1_login→触发回复
- 修复：在_is_noise_text中增加配置文件格式检测（key: value格式，无问号/疑问词时拦截）

验证：正则^[\u4e00-\u9fff]{2,10}\s*[:：]\s*\S+$正确匹配配置文件格式，
正常查询（如"图标怎么设置"）不会被误拦。

Closes #1590 #1591
 2026-08-24 16:26:29 +08:00
youpaishidifu 06d58ee1c1 fix: 基线消息不再写入跨轮去重记录，消除自我阻塞 
根因：基线处理调用_add_to_recent_user_queries(item)将消息写入跨轮去重记录，
导致后续每轮OCR检测到相同消息时被自身匹配（100% Jaccard相似度）跳过。

修复：
- 移除基线处理中的_add_to_recent_user_queries调用（line 9321）
- if ts in seen: continue 处增加debug日志便于排查静默跳过

验证：剩余_add_to_recent_user_queries调用仅在消息被实际回复后触发，
不影响Task #1581双回复防护。

Closes #1589
 2026-08-24 15:36:06 +08:00
youpaishidifu f1fa31b3bb OCR残片过滤器放行核心名词查询：防止'近期公告'等被误丢 2026-08-24 14:39:48 +08:00
youpaishidifu a32400223a OCR时间戳拼接预处理：拆分日期+时间粘连，防止污染 2026-08-24 14:21:18 +08:00
youpaishidifu f74e59845e 修复OCR时间戳拼接污染：过去日期+新鲜时间戳放行给DB查重 2026-08-24 13:48:09 +08:00
youpaishidifu b83556f37f 修复OCR时间戳丢弃策略：无年月日消息放行给DB查重 
根因：QQ当天消息不显示日期，历史消息才显示"年/月/日 时:分"。
原逻辑对无时间戳消息放行，但对有时间戳无日期的消息过期就丢弃，
导致当天消息"12:36:05"被错误丢弃。

修复：_ocr_text_has_fresh_timestamp方法重写日期检查逻辑：
1. 有清晰年月日（四位年+月+日）→ 丢弃历史消息
2. 有不清晰年月日 → 用本地时间辅助判断时间戳是否过期
3. 无年月日 → 放行给下游DB查重（当天消息不带日期）

调用方简化：_ocr_text_has_fresh_timestamp返回False时直接丢弃。
 2026-08-24 12:59:42 +08:00
youpaishidifu 99d0e92e57 修复时间戳新鲜性检查日期误判：过去日期(昨天)的时间戳不再误判为≤300s新鲜 
根因：_is_timestamp_old只比较HH:MM:SS时间部分，不比较日期。
当OCR抓到昨天21:55:31的时间戳，当前系统22:00时，
时间差仅269s<300s→误判为'新鲜'→放行→触发KB搜索→答非所问。

修复：_ocr_text_has_fresh_timestamp中has_past_date分支，
检测到过去日期(昨天或更早)时直接返回False丢弃整段文本，
不再进入时间戳时间部分比较流程。

同时修复第二个问题：过去日期被误放行后触发KB查库但拒绝回复。
 2026-08-24 10:43:41 +08:00
youpaishidifu 0af8c68a73 修复两个OCR过滤bug 
1. auto_reply.py: has_meaningful_hit子串回退永远拒绝
   - 根因：q_mean是多字符token集合，set(heading_clean)是单字符集合
   - q_mean & set(heading_clean) 永远为空 → 子串回退永远拒绝
   - 修复：改为 any(kw in full for kw in q_mean) 子串匹配
   - 影响：sdf1_login下载查询(22.18分)被误拒

2. monitor.py: 过去日期时间戳过期整段丢弃
   - 根因：_ocr_text_has_fresh_timestamp返回False时（过期时间戳）
   - 调用方对含中文文本无条件放行 → 昨日旧消息被当作新消息
   - 修复：新增_has_past_date_timestamp方法检测过去日期
   - 调用方：过去日期+时间戳过期 → 整段丢弃
   - 场景：OCR抓到昨天(2026/8/23)的整屏内容被错误放行
 2026-08-24 10:16:40 +08:00
youpaishidifu 434a9609bf 修复下载类查询牛头不对马嘴复发：文档无下载token时拒绝 
问题：用户问在哪儿能下到那个登录插件，bot回复了protect文档的操作方式表格，
因为该文档heading含登录插件但body是操作方式，与下载无关。

修复：在_has_content_relevance方法中新增下载类查询额外防御——
当查询含下载意图词（下载/下到/哪下/在哪下/怎么下）时，
若文档全文（heading+title+body前800字）不含下载token，
直接拒绝该文档，防止牛头不对马嘴。

同时保留原有下载意图检查（heading含下载时放行），确保sdf1_login等下载文档正常匹配。

Task #1582
 2026-08-23 22:39:18 +08:00
youpaishidifu e826fbe0f0 修复基线消息不加跨轮去重记录导致重复回复 
问题：基线消息（首次成功轮询时标记的第一条消息）未加入 _recent_user_queries，
导致下一轮轮询时跨轮语义去重无法拦截100%相同的消息，触发二次回复。

修复：基线处理时调用 _add_to_recent_user_queries(item)，5分钟TTL内跨轮去重可拦截，
过期后用户重发仍可处理。

Task #1581
 2026-08-23 22:10:45 +08:00
youpaishidifu 7460d40940 fix: 修复启动时清空数据库逻辑，适配新表结构 2026-08-23 21:52:55 +08:00
youpaishidifu 2a3ecdba14 修复bot自言自语大小写不敏感问题 + 退出时后台内存回收不阻塞 
- monitor.py: 去重管道所有比较改为大小写不敏感（recent_replies时间窗口、_replied_texts、_fuzzy_duplicate、子串包含、长公共子串、_last_bot_reply_content）
- main.py: CTRL+C信号处理将内存回收放到后台线程，不阻塞退出
- gui.py: 无实质修改（仅格式）
 2026-08-23 21:30:05 +08:00
youpaishidifu 25b844098f fix(#1574): Bot自言自语拦截v2——拆行比对修复多行回复漏过 
根因：bot回复是多行（含表格），OCR只读首行（如'php有2种登陆模式:'）。
原比对把整个多行回复当一个字符串比较，CJK骨架/Jaccard被表格行稀释→漏过。

修复三处拆行：
1. recent_replies精确匹配：逐行 strip== 比对
2. Bot自言自语拦截(8928)：拆行做骨架/Jaccard/子串三策略
3. _last_bot_reply_content检查(9222)：拆行做SequenceMatcher/骨架/子串

新增策略3：CJK子串包含——OCR文本的CJK骨架是bot行CJK骨架的子串即拦截
（覆盖OCR截断场景：'有2种登陆模式'是'有2种登陆模式模式输入密码直登'的子串）
 2026-08-23 19:11:25 +08:00
youpaishidifu 308bae1fa5 fix: 修复OCR自言自语循环 - Bot回复归一化去重拦截 
根因：OCR读取bot自己回复时，文本格式差异（时间戳前缀、标点全/半角、空格）
导致精确/模糊匹配全部失效，bot反复回复自己的旧回复。

修复（Task #1574）：
1. 去重管道最前端新增「Bot自言自语拦截」：
   - 归一化OCR文本（去时间戳、去标点空格、只保留CJK）
   - CJK骨架完全相同 → 直接拦截
   - 归一化Jaccard相似度>=0.60 → 拦截
2. _last_bot_reply_content检查：
   - 相似度阈值从0.9降至0.65
   - CJK骨架长度要求从6降至4，覆盖短回复场景
 2026-08-23 17:59:59 +08:00
youpaishidifu 32f36dc5fd 任务#1570+#1572: 重构消息历史数据库为3表结构，改善OCR查重逻辑 
1. 数据库重构为3张表：
   - user_messages: 用户消息原文
   - bot_messages: bot消息原文
   - ocr_staging: OCR暂存（重启清空防自言自语）

2. 新增数据迁移：自动将旧表数据迁移到新表

3. 改善OCR查重逻辑：
   - 得分≥2时：检查与bot消息和用户原始消息的重合率
   - 重合率≥50%时丢弃（防bot自言自语和OCR残留）
   - 得分<2时：重合率≥70%丢弃

4. 新增OCR暂存记录功能：
   - 记录通过所有过滤器的OCR消息
   - 用于后续查重和审计

5. 新增get_recent_user_messages方法：
   - 获取最近的用户原始消息
   - 用于查重逻辑
 2026-08-23 16:41:53 +08:00
youpaishidifu 9152c3529f 任务#1441: 修复bot自言自语和双重回复问题 
**问题1: 自言自语**
- OCR把bot自己的回复再读一遍，当成新消息触发二次回复
- 修复: 查库对比bot历史回复，重合率≥50%（高分消息）或≥70%（普通消息）则丢弃

**问题2: 双重回复**
- 用户操作电脑打断bot回复发送时，_last_hash_replied标志被重置，下次轮询重复触发
- 修复: 新增_reply_in_progress标志，回复进行中时跳过所有轮询处理

**修改文件:**
- monitor.py: 添加_reply_in_progress状态追踪+动态阈值bot消息过滤
- gui.py: 在回复执行前后设置/清除_reply_in_progress标志
- _keyword_scorer.py: 新增get_last_score()方法用于查询得分而不记录
 2026-08-22 10:50:56 +08:00
youpaishidifu 1ab422cfd5 修复闲聊消息过滤：拦截'有时间吗'等无主题查询 2026-08-22 10:17:54 +08:00
youpaishidifu 05e7722816 修复Markdown标题过滤：支持无空格格式#xxx 2026-08-22 09:55:56 +08:00
youpaishidifu 7257bfb028 修复玩家昵称过滤：添加标准化匹配，忽略空格和括号差异 2026-08-21 13:04:15 +08:00
youpaishidifu dac243dcc0 新增编程格式块剥离函数，头部整段跳过，尾部切掉（含兼容格式匹配） 
- 新增 _strip_programming_format_blocks 函数，检测消息头部/尾部的JSON、YAML、Markdown表格等编程格式块
- 头部检测：JSON对象、Markdown表格、YAML块 → 整段丢弃
- 尾部检测：JSON对象、Markdown表格、YAML块 → 切掉尾部保留前段
- 兼容格式匹配：检测不完整JSON片段（中英文双引号包裹键值对，以逗号/括号结尾），即使OCR识别不完整也能拦截
- 在过滤管道中位于 _strip_json_yaml_blocks 之后调用
- 修复Markdown表格和JSON配置通过过滤器触发自动回复的问题
 2026-08-21 12:34:45 +08:00
youpaishidifu f337ad1df5 新增编程格式块剥离函数，头部整段跳过，尾部切掉 
- 新增 _strip_programming_format_blocks 函数，检测消息头部/尾部的JSON、YAML、Markdown表格等编程格式块
- 头部检测：JSON对象、Markdown表格、YAML块 → 整段丢弃
- 尾部检测：JSON对象、Markdown表格、YAML块 → 切掉尾部保留前段
- 在过滤管道中位于 _strip_json_yaml_blocks 之后调用
- 修复Markdown表格和JSON配置通过过滤器触发自动回复的问题
 2026-08-21 12:03:49 +08:00
youpaishidifu 04328d7022 新增bot回复格式说明碎片拦截（格式X: json格式等） 2026-08-21 11:44:25 +08:00
youpaishidifu 093ddb77d2 fix: _is_markdown_document增强，拦截含'第X步'的bot回复碎片 
问题：OCR把bot回复碎片'cdkl 1分 cdkz 2分 第三步:文件写好以后 游戏内/控制台执行/imp'
重新识别后进入队列，触发自动回复。_is_markdown_document漏检。

根因：
1. 第X步/步骤X检测用re.match行首匹配，碎片中'第三步'不在行首→漏网
2. 代码关键词列表缺少游戏服管理术语，只有1个命中(import不完整)不够阈值

修复：
1. 第X步/步骤X检测改为re.search全文匹配（用户日常不打'第X步'，全文命中即判定bot回复）
2. 代码关键词列表增加：控制台/执行/导入/插件（游戏服管理术语，用户日常不打）

commit: fcc2e51后同分支
 2026-08-21 11:33:05 +08:00
youpaishidifu fcc2e51777 fix: 修复中部孤立*导致用户查询被_is_noise_text误杀的问题 
问题：OCR把bot的**小姐姐**识别成小姐姐*，单个*粘在昵称后，
导致'小姐姐*, 关于我们'(len≤10)被_is_noise_text判为残片丢弃，用户查询丢失。

根因：
1. _is_noise_text的逗号分段放行逻辑在elif分支，len≤10时永远不走逗号分段
2. 过滤管道无清理中部孤立*的机制（_strip_markdown_head只剥开头，_strip_markdown_tail只匹配**）

修复：
1. _is_noise_text：在len≤10分支的return True前增加逗号分段放行检查
   - 短文本含逗号时，检查逗号后半部分是否含有效查询词（疑问词/动词/主语）
   - 后半部分有效→不丢弃，保留用户真实查询
2. 过滤管道增加孤立*清理步骤（正则: ([\u4e00-\u9fff])\*(?!\*)）
   - 清除中文字符旁的单个*（bot markdown加粗残留），不匹配**，不匹配英文场景
   - 覆盖4个调用点：for循环管道、尾部过滤、逐行过滤、去重后过滤
3. 预分割噪声检测也增加*清理

commit: 4个过滤管道+预分割+2个辅助方法，共73行变更
 2026-08-21 11:18:51 +08:00
youpaishidifu 3e1e8cb700 fix(ocr): 新增 _strip_markdown_head 剥离拼在用户消息【前面】的 md 列表标记 
根因：OCR 把 bot 的 md 列表项（- / * / > / # / 1. / [√]）拼到用户新消息前面，
旧 _strip_markdown_tail 只剥尾部，对头部 md 无能为力：
- 有空格 "- 关于我们" → 被误判为 md 大头整段丢弃（用户消息丢失，最糟）
- 无空格 "-关于我们" → 列表模式要求 \s+ 漏检 → 带 md 碎片入库污染查库关键词 → 查库无结果

修复：
- 新增 _MD_HEAD_PATTERNS + _strip_markdown_head()，循环剥离开头 md 标记，
  容忍缺失空格（-关于我们 也要处理）；剥完为空返回 None 整段丢弃；保留尾部用户真实提问。
- 安全边界：仅匹配单字符/空方括号（[√]/[ ]/[x]），绝不命中多字游戏名词[钻石]；
  用户日常不以 - * > # 1. 起头，剥这些前缀安全；->_ 服务器地址 箭头也能恢复。
- 集成进 4 个调用点（in-loop 过滤 / 尾部过滤含问句保护 / 逐行过滤 / 去重后过滤），
  顺序：bot旧回复剥离 → 头部 md 剥离 → 尾部 md 剥离 → md文档/噪声/回复残片判定。

独立单测 22 例全过（含多字方括号不误杀、纯 md 返回 None、箭头恢复）。
 2026-08-21 10:44:29 +08:00
youpaishidifu 80bc8519c1 增强Markdown过滤器检测中文编号列表和代码块内容，防止Bot自言自语 2026-08-21 10:01:36 +08:00