上一篇《让 Snipaste 使用微信 OCR》只适用于 Windows。由于工作原因，我开始使用 Linux。Snipaste 在 Linux 上的本地 OCR 方案只能依托于 Tesseract。我给 Tesseract 再一个机会尝试仍然不满意，转而跟上一次一样配置微信 OCR。其实 swigger/wechat-ocr 已经支持 Linux，也有一些衍生的 docker 镜像项目。不过我编译原项目就能得到可用的制品，思索以后决定让 AI 帮我封装。
我的环境是 Kubuntu 25.10 amd64，微信是 .deb 包安装的 4.1.0.16（当然要装 Linux 版），Snipaste 是 2.11.3（当然要是专业版）。拉 swigger/wechat-ocr 最新 commit 是 e32d4af。如果不想看下面的废话，可以直接获取 wechat-ocr-snipaste-linux.sh 文件使用。
准备工作
首先要自行编译 swigger/wechat-ocr，它添加 Linux 支持后就没有发布过 release。我不是很懂 C 程序编译，这个工程似乎既可以用 cmake 也可以用 clang。我遵循一个网友列出的命令：
mkdir build
cd build
cmake..
make当然需要先安装 cmake、make 等套件，也需要安装 python3-dev。否则会有类似以下报错：
为 wcocr 配置了符号导出 (wechat_ocr;stop_ocr;_ZN10CWeChatOCR;_ZN9CMojoCall;_ZT?10CWeChatOCR)
CMake Error at /usr/share/cmake-3.31/Modules/FindPackageHandleStandardArgs.cmake:233 (message):
Could NOT find Python (missing: Python_INCLUDE_DIRS Development
Development.Module Development.Embed) (found suitable version "3.13.7",
minimum required is "3.8")
从中也可以看到需要保证 Python 版本至少为 3.8。似乎也用了 C 语言的先进特性，老旧操作系统/标准库可能编译失败。
封装
成功的话就可以在 build 目录得到 test_cli 程序。可以像 README 指示的那样测试：
./test_cli /opt/wechat/wxocr /opt/wechat/ /home/shansing/Pictures/Snipaste/Snipaste_2026-02-24_xx-xx-xx.png 我本来路径依赖想写 go 代码封装为 Tesseract 格式，但是我想快点搞完这事。于是我想到用 Linux 上等公民 shell 脚本，想到最近 LLM AI 写代码很火，索性接下来交给 LLM AI。我选用的模型是 Claude Sonnet 4.5 中度思考。提示词形如：
我有一个 go 写成的 ocr 代理程序：
[这里是上一个工程的 main.go 源码，略]
现在我面临一个新问题，需要在 Linux 上使用。我决定不移植，另外用 shell 脚本封装官方的 `test_cli` 来使用。`test_cli` 的输入输出如下：
\```
$ ./test_cli /home/shansing/Pictures/Snipaste/Snipaste_2026-02-24_xx-xx-xx.png
Usage: ./test_cli <wechatocr_exe> <wechat_dir> <test_png>
$
./test_cli /opt/wechat/wxocr /opt/wechat/ /home/user/Pictures/Snipaste/Snipaste_2026-02-24_xx-xx-xx.png
OCR errcode=0/opt/wechat/wxocr
[86.97,53.71,601.09,130.45] r=1.000 高铁耳机寻回记
[92.08,168.82,833.85,199.51] r=0.960 Written by 闪闪的星 with❤on February 9,2026 in 生活
[86.97,250.67,1529.57,291.59] r=0.991 在高铁座位上突然想打喷嚏，顺手摘下口罩想改用纸巾遮挡口鼻，地一下两边苹果耳机飞出去。一只被我从旁
[89.52,312.05,626.66,345.30] r=1.000 边座位下方找到，另一只怎么寻也看不到。
[86.97,399.02,1529.57,437.39] r=0.995 我一会儿趴地上打手电筒，一会儿站起来看是不是飞到远处，一会儿想是不是只能买新的了。遥想曾经在豆瓣看
[84.38,455.29,1527.05,491.14] r=0.990 到过 AirPods 离异丧偶小组，但是耳机还不想收二手，于是又得耗费一千多大洋。坐回座位打算放弃了，意识到
[86.88,509.19,1529.64,555.17] r=0.963 刚刚我站起来有人好像说“这是谁的耳机”，但是当时我觉得他是在打电话，我又“社恐“没敢问，好一会儿过去了现
[86.97,575.51,1527.01,608.76] r=0.995 在也不好大声喊一句有谁捡到耳机。列车快到我的武汉站，我死马当活马医在小红书搜了遗失物品报备攻略，并
[89.52,634.34,483.43,667.59] r=0.997 且在百亿补贴下单一副新耳机。
[81.85,721.30,1498.88,759.67] r=0.972 结果我当天在武汉没待多久，自称“车长”的人就告诉我找到了。这可以列入"本来没抱期望，以为没有用结果有
[86.92,777.83,1532.17,815.99] r=0.994 用“的事迹。貌似是河南局承运，开往河南的途中按照我的要求转到另一车次回到武汉。我非常惊喜，取消新机订
[89.49,836.40,1529.59,872.24] r=0.995 单，最终返程时在站内领回。我好奇她们怎么找到的，可能是问了一句乘客就拿到了，也可能翻了座椅死角，但
[92.04,897.32,1514.24,931.07] r=0.984 这不重要。按照小红书的指示，我希望能寄送锦旗表达感谢，但对方表示不用花这个钱，拨打 12306 感谢就行。
[89.50,956.59,1457.99,994.67] r=0.973 我便克服”社恐“拨打了电话，慌慌张张说错重点，应该是寻回速度很快，我却多一遍强调“帮我省了很多钱”。
[1158.69,1051.26,1544.92,1076.84] r=0.929 hide comments ·back .home
debug play ocr DONE!
\```
其中 `<wechatocr_exe>` 对应我程序的 ocrBin，`<wechat_dir>` 对应我的 wechatDir。
你的任务是：编写一个 shell 脚本。仍然接收我原先程序的四个参数，做原先程序差不多的事（将标准输入的图片保存到临时目录，在成功或失败后删除），但是将 syscall 的 DDL 调用改成执行 `test_cli`。特别地，你需要过滤 `test_cli` 的输出，只保留 `[...] r=... ` 之后的文本，过滤无关 debug 消息行和前缀。你可以把 debug 信息输出至标准错误，确保标准输出只有 OCR 识别的最终文本。第一个回复基本可用，赋予执行权限执行。这时我看代码发现 AI 错误理解 test_cli 的地位，于是我说：
我没看到你调用 `test_cli`，这是我另外一个程序，不是在 `OCR_BIN` `WECHAT_DIR` 里的接着调试一下。貌似卡住了，看代码没打印文件名。应该是随机串生成阻塞住了。换便宜的 GPT 4.1 mini 让其修改随机数方法：
UUID=$(cat /dev/urandom | tr -dc 'a-f0-9' | fold -w 32 | head -n 1)
这个阻塞住了。帮我换一种更简单的写法最终我选择的是：
UUID=$(cat /proc/sys/kernel/random/uuid)写好以后手动执行一下保证成功：
cat /home/shansing/Pictures/Snipaste/Snipaste_2026-02-24_xx-xx-xx.png | /home/shansing/dev/wechat-ocr-snipaste-linux/wechat-ocr-snipaste-linux.sh stdin stdout -ocrBin /home/shansing/dev/wechat-ocr-snipaste-linux/wechat/wxocr -wechatDir /home/shansing/dev/wechat-ocr-snipaste-linux/wechat/ > output.txt这里我仍然将微信目录复制出来了。成功之后就可以将 wechat-ocr-snipaste-linux.sh 选为 Snipaste 的 Tesseract 可执行文件。