50%
tesseract 读对率
实测 · 现在生产在用
个人微信屏蔽了无障碍，自动代回只能截图认字，现在用的 tesseract 约 10–20% 误读。这份调研回答一个问题：有没有更准的读屏方案 —— 并用你们自己的 4 张真实聊天截图实测了一遍。
那 10–20% 误差的根子只有一条：个人微信在安卓上把无障碍控件树全屏蔽了，程序看不到「这是谁的消息、这个按钮叫什么」，只拿得到一张图片 —— 所以只能截图跑 OCR，而 tesseract 是十几年前的老引擎，中文弱、读不了表情图片、还会把键盘/时间戳当成消息。
减掉它有两条能落地的路：① 换更强的「眼睛」（还是截图，把 tesseract 换成视觉大模型或 PaddleOCR，改动小、风险零）；② 绕开 OCR 直接读微信的消息数据（hook / 协议，误差归零，但要换运行环境且封号风险高）。本次实测证明第①条当天就能把读对率从 50% 拉到 100%，是性价比最高的一步。第②条的生态细节，承接团队 07-03「个微三方生态全景」那份，不在这里重复。
企微把每个控件的文字都开放给系统无障碍接口，程序能精确读到；个人微信把整棵树屏蔽了，只剩一张图。下面每个坑，根子都在这。
只能对截图跑 OCR，中文 ~10–20% 误差，表情 / 图片 / 贴纸直接读不了。
截图里键盘弹开时，OCR 把 「PQRS」「WXYZ」当成对方消息（本次实测两次翻车都是这个）。
居中的 「16:28」「18:36」会被当成一条消息，得靠位置规则硬排。
主界面 / 聊天页 activity 全叫 LauncherUI，只能靠 OCR 顶部标题猜在哪一页。
拿 logs/ 里 4 张真实个人微信聊天截图，跑同一个真实任务 ——「读出对方（左侧气泡）发的最新一条消息」，两个引擎各跑一遍，跟人工标注逐字比对。脚本：_ocr_bakeoff.py。
| 指标 | tesseract chi_sim | Qwen2.5-VL-72B |
|---|---|---|
| 完全读对 | 2/4 50% | 4/4 100% |
| 平均字符错误率 | 50% | 0% |
| 抗键盘/时间戳干扰 | ✗ 会把键盘键当消息 | ✓ 自动忽略 |
| 表情 / 图片 | ✗ 读不了 | ✓ 能理解语义 |
| 单张耗时 | 1–1.5s 本地 | 3–9s 联网 |
| 成本 | 免费（本地） | 约 2 分/张（OpenRouter 实测 $0.0027：3385 token/张 × $0.8/M） |
样本只有 4 张，偏小；tesseract 的两次翻车都发生在键盘弹开的截图上（生产里读消息通常在打字前、键盘没弹，真实误读率没到 50% 这么夸张）。但结论方向是硬的：视觉大模型对「键盘、时间戳、表情、混排」这些正是 tesseract 命门的干扰，全都稳过。代价是慢几秒、每张要花 API 钱。下一步该用更大样本（几十张）复测再定。
截图流程完全不变，只把「认字」那一步的 tesseract 换掉。不碰微信本体，所以不增加封号风险 —— 这是本次实测走的路，也是我推荐先做的。
| 方案 | 它是什么 / 强在哪 | 取舍 |
|---|---|---|
| Qwen2.5-VL 72B（OpenRouter 在架） | 阿里多模态大模型，你们已在用 OpenRouter + Qwen，直接把截图丢给它读消息 + 按话定位元素。本次实测 100%。定价页：输入 $0.8/M、输出 $1/M。 | 要联网、慢几秒、约 2 分/张。省钱杠杆＝发前把截图降分辨率（3385 token 里几乎全是图片，尺寸减半 token 约降到 1/4）。 |
| PaddleOCR PP-OCRv5 | 百度开源，中文识别远强于 tesseract，可跑本地、免费、快。当纯 OCR 平替。 | 仍是「认字」，不理解语义 / 不会按话定位；表情图片还是读不了。 |
| GUI grounding UGround · OS-Atlas · GUI-Actor | 专为「只有一张手机截图」造的模型：给它一句话（「点开阳阳的对话」）直接吐坐标，同时替掉「认字」和「找坐标点」两步。 | 要自己部署 / 调用，工程量比换个 API 大；适合后续想连点击也智能化时。 |
这类工具通过 hook（钩住微信内部）或协议登录，直接拿到消息原文和发送人，完全没有 OCR 这回事、误差归零。但都要换微信运行环境，且都动了微信本体、封号风险明显高于纯截图。07-03 全景页有逐项深挖，这里只给对照。
| 工具 | 平台 / 机制 | 读消息误差 | 封号风险 | 适合 Akke 吗 |
|---|---|---|---|---|
| WeChatFerry 6.7k★ | PC 微信 · C++ hook | 0 | 中高 | 有云电脑可挂小号，最成熟；但锁死特定微信版本 |
| wxauto | PC 微信 · Windows UI 自动化 | ≈0 | 中 | 读控件非注入，较温和；作者已停维护 |
| Xposed 安卓 wework-1 等 | 安卓 · Xposed hook | 0 | 最高 | 要 root + 旧安卓 + 强绑版本，不建议碰 |
| Gewechat iPad 协议 | iPad 协议登录 · REST API | 0 | 高 | 免插件；协议类灰产重灾区，开山项目已被法务函腰斩 |
专门找过「微信自动化 / 读微信截图」的现成模型或数据集 —— 没有。HF 上没有微信专用工具，相关 Space 多是打不开的 fork demo。但这不影响路线①：你要的能力（读中文截图 + 理解语义）用通用视觉大模型（Qwen2.5-VL）或通用 OCR（PaddleOCR）就够了，不用等「微信专用模型」。
改动局限在 weixin_reply_android.py 一个读消息的函数，风险零、不增加封号。当天就能把读对率往 100% 拉，顺手解决表情读不了、键盘/时间戳误判、点错行。投入产出比最高。
现在只测了 4 张。跑 _ocr_bakeoff.py 攒到几十张真实截图（含表情、多轮、列表页）再量一次，确认 VL 的准确率和成本都能接受，再正式切。
若量放大到必须零误差，用 WeChatFerry 挂云电脑、拿一个可弃小号试封号风险。安卓 Xposed 那几个（root + 旧安卓）别碰，维护和封号成本都太高。
没有微信专用模型，也不需要 —— 通用 VL / PaddleOCR 已经够用。别再花时间找「微信专用」的轮子。
本页只回答「读屏怎么更准」，没有重新论证「要不要用个人微信做触达」 —— 那是风控和商业口径的事，沿用团队既有结论（日限 10 条、间隔 2–4 分钟）。
今日 WebSearch / WebFetch 联网核实 + 本机 _ocr_bakeoff.py 实测（4 张 logs/ 真实截图，Qwen2.5-VL 走 OpenRouter eval key）。