[任务] 实验：让 DeepSeek 直接读图片附件 #102

关联与状态

路线图 #2，实验和数据。状态：待认领。图片附件现在用本地的 RapidOCR 识别（#47，PR #74）；这个实验看能不能换成让 DeepSeek 直接读图，结论出来之前不改现有做法。适合熟悉 Python 的同学。有问题直接在这里留言。

目标

抽取用的 DeepSeek V4.1 Flash（deepseek-flash）已经能直接读图片，见 DeepSeek 的说明。如果它读图片附件里的日期、时刻、网址和邮箱比本地识别准，抓取节点就不用在本地跑文字识别：省下识别一张长截图时约 1GB 的内存，也不用装 ONNX Runtime 和模型；代价是每张图多花一些 token。这个实验用数据回答换不换、怎么换。

范围

• 用 PR 实现图片附件的文字识别 #74 描述里的 9 张图片和同样的判对标准：日期、时刻、网址、邮箱在同一行里和原文一字不差才算对，一张里错一项就不算全对。
• 和本地识别（PR 实现图片附件的文字识别 #74 合并时的设置）比：关键信息认对几项、每张图的 token 用量和花费、耗时。
• 只让模型把图片转成文字，替换的是文字识别这一步，后面的编号抽取不变。
• DeepSeek 会把每张图缩到约 1300×1300 的像素量、最多 1024 个 token，长截图整张送进去字会缩得很小。整张送和切成几块送都试一下。
• 认错的逐条列出，分清是乱码，还是看着像对的值（比如年份改了、网址补全了）：后一种更难发现。不管用哪种做法，证据只在图片里的值都会送进审核页。
• 用自己的 DeepSeek key，不提交、不贴进 Issue 和 PR；9 张图跑一遍预计花费不到 1 元。
• 不做：不改抓取节点的代码；实验代码、图片和识别结果都不提交。

建议的第一步

先拿一张长截图（比如 PR #74 里的图片 5）分别整张送和切块送，看认对多少、花多少 token，再决定 9 张怎么跑。

验收标准

• 在同样的 9 张图片上比较了 DeepSeek 读图和本地识别：关键信息认对几项、token 用量和花费、耗时；认错的逐条列在 PR 描述里
• 结论（换不换；换的话长图怎么送）写进总体设计 §5.2
• 决定换的话另开任务改抓取节点，不在这个 Issue 里改