AgentHubAgentHub
返回全部博客

为什么 AI 读错截图里的数字:它拿到的图比屏幕上那张小得多

AgentHub 编辑部··26 分钟阅读·77 次阅读
为什么 AI 读错截图里的数字:它拿到的图比屏幕上那张小得多

先说结论:它看到的那张图,比你屏幕上那张小得多

你一定见过这种事:把一张表格截图发给 AI,让它读某一格的数字,它给你念错了一个数——把 3 念成 8,把 1,208 念成 1,280。你以为它眼神不好,或者以为它在敷衍你。

真实原因在图进模型之前就已经决定了:你发的那张图,会被平台按一套固定规则先缩小、再切成格子,然后才交给模型看。 一张 1920×1080 的截图,在 Claude 的默认档里会被压成 1456×819;一张 4K 截图压得狠一点,最后也是 1456×819。你屏幕上 12 像素高的那行小字,进模型之后只剩 9.1 像素。

而模型看图的单位不是像素,是一个 28×28 像素的方块(官方叫 visual token,视觉词元,可以理解为“一个不可再分的视觉格子”)。9.1 像素高的字,连半格都占不满。它在这一格里收到的信息是“这里有点黑,形状偏圆”,不是“这是 3 还是 8”。

所以它不是在看你的图,是在看你那张图被缩印之后的马赛克版,然后凭语言经验把字猜出来。 这篇给你三样东西:一是各家官方的缩放规则原文(都是能查到的现行文档);二是我自己按官方公式实现了一遍算出来的表,每个数你拿计算器都能复算;三是一条最管用的做法,它同时解决“看不清”和“太贵”两件事——别发整张大图,裁一块发。

一个类比:把 A4 表格缩印到名片上

想象你要问朋友一张 Excel 表里的数字。你有两个选择:

一是把整张 A4 纸缩印到名片大小,然后问朋友“第三行第七列那个数是多少”。朋友盯着那张名片看,那行字已经细得像蚊腿,他大概率会给你一个“看着像”的数。

二是把那一小块用原尺寸剪下来递过去。

绝大多数人现在对 AI 做的事就是第一种:发一张全屏截图,问里面 20 像素见方的一个数。而截图这个动作本身,在很多平台上还会先被压一遍。

这篇的全部要点就是:你控制不了它怎么缩,但你控制得了你递多大一块过去。

官方规则一:Claude 把图切成 28×28 的格子,超上限就先降采样

这是我把各家规则里最完整的一条,因为它给了公式,也给了对照表(Anthropic 官方视觉文档,我逐字抄下来):

其一,切格子的公式:「Claude processes images in patches instead of pixels. Each patch is a 28×28-pixel block of the image, referred to as a visual token. An image, therefore, costs ⌈width / 28⌉ × ⌈height / 28⌉ visual tokens.」(Claude 按块处理图像而不是按像素。每块是 28×28 像素,叫一个视觉词元。所以一张图的代价是:宽除以 28 向上取整,乘高除以 28 向上取整。)

其二,两个上限:官方写「Each model has a maximum native image resolution, expressed as a long-edge limit and a visual-token limit. Images larger than either limit are downscaled before processing.」(每个模型都有一个最高原生分辨率,用“长边像素上限”和“视觉词元上限”两个数表示。超过其中任何一个,图就会在处理前被缩小。)

现行文档给的档位是两档:标准档长边 1,568 像素、词元上限 1,568;高解析档(Claude 4.7 及以后)长边 2,576 像素、词元上限 4,784。还有一句关键说明:「When an image is downsized, Claude scales it to the largest size that fits the tier's limits while preserving its aspect ratio.」(要缩的时候,它缩到“能装进上限的最大尺寸”,并且保持宽高比。)

其三,官方自己给的对照表(这一行一行都是它文档里的原表,不是我编的):

你发的图标准档实际进模型标准档词元高解析档实际进模型高解析档词元
200×200不缩64不缩64
1000×1000不缩1,296不缩1,296
1092×1092不缩1,521不缩1,521
1920×10801456×8191,560不缩2,691
2000×15001269×9521,564不缩3,888
3840×21601456×8191,5602576×14494,784

其四,一句必须记住的警告:「Claude might hallucinate or make mistakes when interpreting low-quality, rotated, or very small images under 200 pixels.」(图质量差、被旋转过、或者短边小于 200 像素时,Claude 可能产生幻觉或者读错。)厂商文档里明写“会幻觉”三个字,这在国内教程里几乎没人引。

其五,一个批量场景的坑:官方写「If a single API request contains more than 20 images, a stricter per-image dimension limit applies」(一次请求里超过 20 张图,会对每张图启用更严的尺寸上限),并给出通用建议「resize each image so that neither dimension exceeds 2000 px」(把每张图的两边都控制在 2,000 像素以内),超了会直接返回 invalid_request_error。一次丢几十张截图让它整理,图会被拒或者被压得更狠,就是这个规则在起作用。

我自己按官方公式算了一遍,六行锚点全对上

光抄表没意思,关键是这套规则能不能自己复算。我把公式写成十几行代码(⌈x⌉ 就是向上取整,小学生都会按计算器),然后拿官方那张表当测试:官方说不缩的行我算出来不缩、官方说压成 1456×819 的行我算出来 1455×819(差 1 像素是取整方式),六行全部对上。

对上之后,就可以算官方表里没有、但你天天遇到的尺寸:

你的图进模型实际变成面积剩多少你屏幕上 12 像素的字,它看到几像素
手机聊天截图 1170×2532724×156738%7.4 像素
Mac 全屏截图 2880×1800(字 24 像素)1388×86823%11.6 像素
1080p 表格截图 1920×10801455×81957%9.1 像素
4K 截图 3840×2160(字 16 像素)1455×81914%6.1 像素
手机拍的发票 4000×3000(字 18 像素)1268×95110%5.7 像素

三个最该停下来的地方:

一,4K 不比 1080p 看得更清,它俩进模型后是同一张图。 官方表里 1920×1080 和 3840×2160 两行,标准档的“实际尺寸”和“词元数”一模一样(都是 1456×819、1,560)。因为上限卡在那儿,你多出来的那 600 多万个像素,在门口就被扔掉了,只留下更糊的插值结果。

二,手机长截图是最吃亏的一种。 它的边长比接近 1:2.2,缩放是被长边卡住的:1170×2532 压成 724×1567,宽度只剩 62%。你想问的那行聊天内容,字高从 12 像素掉到 7.4 像素——比一张横屏截图掉得更多。这就是很多人感觉“发长截图它更容易读错”的原因,不是错觉。

三,拍照的图更惨。 手机随手一拍就是 4000×3000(12 兆像素),进模型只剩 1268×951,面积只剩十分之一。你拍得越清楚,被扔掉的部分越多。

图 1|三个自己算得出来的数:字高剩几像素、折算成扫描口径、裁一块要付多少词元
图 1|三个自己算得出来的数:字高剩几像素、折算成扫描口径、裁一块要付多少词元

官方规则二:GPT 家族按 512 的方格收费,最短边先压到 768

OpenAI 的官方图像指南给的是另一套完全不同的机制(我把它的关键句摘出来):detail 参数决定处理方式——「detail: low uses a fixed token count」(低清模式用固定词元数,85),「detail: high and auto use tile-based sizing」(高清和自动模式按方格算),规则是「scale shortest side to 768px... count 512px squares」(最短边超过 768 就先等比压到 768,然后数需要多少个 512×512 的方格),每格 170 词元、底座 85(「gpt-4o base 85, tile 170」)。

我按这套算同一张 1920×1080:最短边 1080 压到 768 → 图变成 1365×768 → 需要 3×2=6 个方格 → 85 + 6×170 = 1,105 词元,字高从 12 像素变成 8.5 像素。

两个必须知道的细节:

一,低清模式是灾难级的。 固定 85 词元意味着整张图被塞进 512×512 里。一张 1080p 截图进去,面积只剩 13%,你那行 12 像素的小字变成 3.2 像素——三个像素高,横和竖都粘在一起。很多网页端“快速问答”、以及图片在聊天软件里被压过一遍再转发,走的就是这类低清通道。它在这种模式下读错数字,是必然事件不是意外事件。

二,同一个平台的不同模型,图的价差不止十倍。 官方句子里那句「gpt-4o-mini base 2833, tile 5667」值得多看一眼:小模型处理一张图的词元数,是大模型的三十多倍。原因各家写法不同,但结论对用户是同一个:“小模型便宜”这句话,在带图的请求里不一定成立。

而 OpenAI 官方文档里那句最佳实践,我认为是全篇最值钱的一句原话:「Small text: Enlarge text within the image to improve readability.」(图里有小字时:把图里的字放大,能提高可读性。)厂商自己在文档里承认小字读不清,并给了“放大”这个解法。

官方规则三:Gemini 不缩图,但按块收钱

谷歌的官方图像文档给的是第三种取舍:「258 tokens if both dimensions <= 384 pixels. Larger images are tiled into 768x768 pixel tiles, each costing 258 tokens.」(两边都不超过 384 像素的小图算 258 词元;更大的图按 768×768 切块,每块 258 词元。)它还提供 media_resolution 参数,官方说明是「The media_resolution parameter determines the maximum number of tokens allocated per input image or video frame.」(它决定每张图或每帧最多分配多少词元),并有一句我认为你应该贴在显示器上的话:

「Higher resolutions improve the model's ability to read fine text or identify small details, but increase token usage and latency.」(更高的分辨率能提高模型读细字、认小细节的能力,但会增加词元消耗和响应时间。)

这句话把整件事的本质讲完了:看清小字这件事是有价格的,各家只是把价格牌挂在不同位置。 谷歌挂在“你自选分辨率档位”,Claude 挂在“两档上限”,OpenAI 挂在“detail 参数”。

我按它的规则算:1920×1080 → 3×2=6 块 → 1,548 词元;一张 4000×3000 的发票 → 6×4=24 块 → 6,192 词元。注意它没有把图缩小——所以字高保住,代价是钱。

国内厂商这一栏:官方给的是“有效工作区间”

阿里云百炼的视觉理解文档没有给像素到词元的换算公式(我这次没抓到,见文末),但给了一个更贴近使用场景的区间,原话是:

「Qwen2.5-VL 模型 480*480 ~ 2560*2560 分辨率范围内,物体定位效果较为鲁棒,在此范围之外检测精度可能会下降(偶发检测框漂移现象)。」

“检测框漂移”这个词很值得翻译一下:你让它“圈出图里那个按钮在哪”,它会给出一个位置框——超出这个分辨率区间,框会画到别的地方去。这跟读错数字是同一族问题的两种表现:图太大或者太小,它的空间判断就开始不可靠。

同页还有一句限制:「图片数量受模型图文总 Token 上限的限制,所有图片和文本的总 Token 数必须小于模型的最大输入。」图和字抢的是同一个上下文预算——这一层我在另一篇里算过:它一次能“递进去”多少,直接决定它记得多少:《AI 为什么聊着聊着就忘了你说的话》。

它为什么是“读成最像的那个”,而不是“读不出”

这是全篇最容易搞混的一点,也是把这件事从“像素不够”升级到“为什么会错得很有信心”的关键。

格子不够用,理论上模型应该说“我看不清”。但它不会。因为它的输出端不是在报告像素,是在生成一个词。 前面讲过它生成文字的机制:每一步给出一排候选词加概率,然后抽一个:《为什么同一个问题问 AI 两遍,答案不一样》。视觉信息也一样,进到这套生成机制里,“这一格里有点黑、偏圆、下面有一横”这种模糊信号,会被接上语言先验:在金额语境里,长得像 8 的候选概率更高,它就报 8。

这就是为什么它读错的时候语气和读对时一模一样——这不是它在硬撑,是“从一排候选里挑一个最像的”这个动作本身不带“我不确定”的标记。这一层机制站内那篇讲幻觉的文章讲得更完整:《AI 为什么会一本正经地胡说八道》。视觉读错是幻觉的一个特例:它的输入被降级了,输出却没有任何降级提示。

顺带解释一个常见体验:为什么它经常把 0 读成 O、1 读成 l、把 1,208 读成 1,280。 前两组是形状在低分辨率下真的合并了;最后一组是位数变了——因为逗号在压缩后几乎消失,“分隔符”这个信息丢了,它就靠语境补一个“最合理的金额”。你看到的是一位数之差,它经历的是一整格信息缺失。

研究给的三个数:它能“看懂”,但“看清”是另一回事

厂商文档讲的是规则,研究给的是代价有多大。四篇我逐条打开核过的论文,结论一条比一条具体。

第一个数:约 150 ppi 是分界线。 一篇 2025-03-31 提交的 arXiv 预印本(arXiv:2503.23667,《Context-Independent OCR with Multimodal LLMs: Effects of Image Resolution and Visual Complexity》,单一作者 Kotaro Inoue,页面没有同行评审标注,所以它只能当方向线索)用单字符图片测了一批多模态模型的识别,摘要里那句结论非常干净:「multimodal LLMs can match conventional OCR methods at about 300 ppi, yet their performance deteriorates significantly below 150 ppi.」(大约 300 ppi 时能追平传统 OCR,低于 150 ppi 时表现显著退化。)

这个数离你的日常体验太远,所以我把它折算成“字有多高”:中文小五号(10.5 磅)的字框高约 3.70 毫米,按这个换算,150 ppi 那道门槛相当于字框高约 22 像素,300 ppi 相当于约 44 像素。反过来看你的截图:

你屏幕上的字折算成扫描口径被压到 0.758 倍之后折算
24 像素(正文大字)165 ppi18.2 像素125 ppi
16 像素(小标题)110 ppi12.1 像素83 ppi
12 像素(表格、聊天记录)82 ppi9.1 像素62 ppi
10 像素(网页辅助说明)69 ppi7.6 像素52 ppi

看懂这张表的顺序很重要:不是你截图不清楚,而是“屏幕上 12 像素的小字”本身就只有约 82 ppi,本来已经在那条退化线以下了;被平台再压一道,掉到 62 ppi。 换句话说,你让它读的那行字,从你发图之前就已经超出它的可靠工作区间。

第二个数:它“看”得见,但不见得“感知”得到。 BLINK 那篇论文的标题就是结论(arXiv:2404.12390,《BLINK: Multimodal Large Language Models Can See but Not Perceive》,Xingyu Fu 等十人,已被 ECCV 2024 接收)。它把 14 个经典计算机视觉任务改写成 3,807 道选择题,摘要里的对比是:「While humans get 95.70% accuracy on average, Blink is surprisingly challenging for existing multimodal LLMs: even the best-performing GPT-4V and Gemini achieve accuracies of 51.26% and 45.72%, only 13.17% and 7.63% higher than random guessing.」(人类平均 95.70%,当时最强的 GPT-4V 与 Gemini 只有 51.26% 和 45.72%,只比随机猜高 13 和 7.6 个百分点。)“能对话”和“能分辨图里的细节”之间,隔的不是模型大小,是两套能力。

第三个数:它自己列出了弱点清单。 OCRBench(arXiv:2305.07895,Yuliang Liu 等十人,2023-05-13 首发、现行版本 v7)把视觉文字能力拆成五类任务——文字识别、场景文字问答、文档导向问答、关键信息抽取、手写数学式识别——它在正文里给出的短板原话是:「particularly in handling multilingual text, handwritten text, non-semantic text, and mathematical expression recognition.」(尤其在处理多语种文字、手写文字、无语义文字和数学式识别时。)

第四条最扎中国用户的心:非英文本来就吃亏。 《Holistic Analysis of Hallucination in GPT-4V(ision)》(arXiv:2311.03287,Chenhang Cui、Yiyang Zhou 等七人,2023-11-06)在摘要里报告:「a notable regional bias, whereby GPT-4V(ision) is better at interpreting Western images or images with English writing compared to images from other countries or containing text in other languages.」(明显的地域偏差:它解读西方图片、英文文字的图片,强于其他国家或其他语言文字的图片。)同一套压缩规则,作用在本来就吃亏的文字上,误差会被叠两次。

这四篇的时效必须说清楚:它们测的是 2023 到 2025 年初的模型(GPT-4V、初代 Gemini 这一批),今天的模型在这些基准上已经进步很多。所以它们能证明的是“这类弱点是机制性的、被反复测量过的”,不能拿来给今天某一家模型打分。你要判断手上这个模型行不行,还是得回到第三节那三个实验。

一张图到底占多少上下文:和一篇稿子比

这个换算很能帮人建立体感。我拿站内一篇 5,500 汉字的中文稿实测过,它在主流词表下约 7,112 个词元(这件事的来龙去脉在这篇:《为什么 AI 数不清 strawberry 里有几个 r》)。

  • 一张 1080p 截图在 Claude 标准档:1,560 词元,约等于那篇稿子的 22%。
  • 同一张图在 Claude 高解析档:2,691 词元,约等于 38%。
  • 同一张图在 OpenAI 低清模式:85 词元,约等于 1%——你只给了它一篇稿子百分之一的信息,却指望它看清那行小字。
  • 一张 4000×3000 的发票在 Gemini:6,192 词元,接近一整篇稿子。

所以“发图很贵”和“发图看不清”不是两件事,是同一个旋钮的两端。 怎么按自己的场景定这个档位,那篇算账的文章给了三步法:《每百万 tokens 到底是多少字》。

最有用的一个数:裁一块,比发整张更清楚还更便宜

这是我在算完上面那些之后顺手做的对照,结论好到我想把它当封面:

你发什么进模型是否被缩词元那行 12 像素的字,它看到几像素
整张 1920×1080 截图缩到 1455×8191,5609.1
裁出那块表格 600×400不缩33012.0
裁半屏 960×540不缩70012.0
裁一行表头 1200×300不缩47312.0
整张放大 2 倍再发仍被缩到 1455×8191,5609.1
整张放大 3 倍再发仍被缩到 1454×8181,5609.1

两句话读完毕:

一,裁一块发,字高一点没损失,词元还少了 4.7 倍。 原因是缩放是被上限卡住的:600×400 的图离 1,568 的上限远得很,根本不触发降采样。你少给了它无关像素,它反而看清了。

二,把整张图放大再发,完全无效。 放大 2 倍、3 倍,最后进模型的仍然是 1455×819——因为限制的是“进模型后的尺寸”,不是“你上传的尺寸”。而且放大是插值算出来的假像素,图只会更糊。这条能省掉很多人半小时的折腾。

你自己五分钟能做的三个实验

实验一,量你这张图被压了多少。 右键你的截图文件看属性,记下宽高像素(这一步不用任何工具)。然后按上面的公式自己算:宽除以 28 向上取整,乘高除以 28 向上取整。如果你的图长边超过 1,568,先按“缩到 1,568 以内且词元不超过 1,568”倒推。算完你会知道:你那张图在它眼里是多大一块马赛克。

实验二,同图两次问,一次整图一次裁块。 挑一张你真有把握的小字截图(比如订单号、发票金额、表格里的一格)。第一次发整屏截图问那个数;第二次只裁那一小块问同一个数。如果两次答案不同,而裁块那次对了——你就亲手复现了这篇的全部结论。 我提醒一句:多做几次再下判断,因为同一张图问两遍本身也可能得到不同措辞的回答,那是另一套机制在动,两篇配合看更准:《为什么同一个问题问 AI 两遍,答案不一样》。

实验三,先让它复述,再让它回答。 不要问“这个金额是多少”,先说「把你在这张图里逐字读到的字符原样列出来,不要解释」,再问第二个问题。这一步的价值是:把“读”和“答”分开检查。 它复述出「1,280」还是「1,208」,你一眼就知道错在哪一层——是眼睛错还是脑子错。这个“先验收再放行”的写法,那篇讲提示词的文章里有一整套:《12 个真正好用的提示词》。

哪些图它天生吃瘪(按官方说明归类)

一,短边小于 200 像素的小图。 Claude 官方原话里点名的三类之一。缩略图、微信里被压过一遍的转发展开图、聊天里“点击查看大图”之前的预览,都在这一类。

二,被旋转过或者拍歪的图。 官方原话里第二类(rotated)。手机拍照时竖着拍成横躺,比裁一块更致命,因为它的训练分布里“正着的小字”占绝大多数。

三,密集表格。 一行 12 个字段、每个字段 4 个字符,整行的信息量远超格子数。这不是它不认真,是一格里塞不下那么多差别。

四,低对比与反光。 拍纸质单据时最常见:白纸上浅灰字、闪光灯在塑封面上打出一块白斑。白斑覆盖的那部分像素,和“字”在格子里长得一样。

五,手写体与印章压字。 手写分布多样、印章是彩色半透明覆盖层,两者都会把字的笔画边界糊掉。这类图我建议直接换方案:用文字提取专用模型或者扫描类工具先出文本,再把文本交给它。

六,一次几十张图。 除了 Claude 那条“超过 20 张启用更严上限”的规则,多图还会挤占上下文预算,图越多,每张分到的注意力越少。

三条别踩的误解

误解一:「它读错数字,说明它根本看不懂图。」 反了。它能读懂图这件事是真的——读大意很强,读精确字符很弱。这两件事用的是不同的能力:看懂“这是一张发票”靠语义,读出“金额是 1,208”靠像素级细节,而后者正好卡在缩放和格子的机制上。“看得懂”和“看得清”不是一回事,别用前者推断后者。

误解二:「换更贵的模型就解决了。」 换模型能改善识别能力,但改不了你上传那张图被压缩这件事——那是输入侧的规则。同一个模型,你把整屏截图换成裁块,效果差别可能比换一档模型还大。先修输入,再考虑换模型。

误解三:「它读得特别流畅,所以读对了。」 流畅度和正确性没有关系,这件事在文字幻觉里已经反复验证过(见前面链接的那篇)。在图上也一样:它把 1,280 报给你的时候,不会带一点犹豫。 判断依据只能来自你自己核对,或者来自“复述—再回答”这类强制它把中间结果交出来的做法。

这次我没核到的几件事(以及本文的数是哪来的)

按站里的老规矩,边界说清楚:

一,OpenAI 官方图像指南我只拿到了规则要点,没拿到那张低清/高清的完整原表,所以我只引用了能确认的数字:85、170、512 方格、最短边 768、以及 gpt-4o-mini 的 2,833 / 5,667。它家不同代模型是否有别的档位,我没写。

二,谷歌 media_resolution 各档位具体给多少词元,这次没抓到,所以我只写了“它决定每图最多分配多少词元”这一层,没有编档位数字。

三,阿里云百炼的视觉文档里没有像素到词元的换算公式(我打开的那几页确实没有)。所以国内这一栏我只给了它明确写着的分辨率区间和总词元限制,没有替它编一个“一个词元多少像素”。

四,“聊天软件转发会把图压到多小”我没有找到任何厂商的公开数字,所以正文里只用“被压过一遍”这种说法,没给具体比例。你要判断自己那张图的实际尺寸,用实验一那个右键看属性的办法。

五,本文所有“进模型实际变成多大、字高剩几像素、多少词元”,都是我按各家官方规则自己写的算术(脚本在 scratch/vision/exp.cjs,读者可自查)。我用官方那张表做了自检,六行锚点全部对上(1920×1080 我算 1455×819、官方 1456×819,差 1 像素是取整方式不同)。但我没有真的调用任何一家 API 去统计它的识别正确率——那需要花费和你手上的 Key。所以这些数告诉你的是“输入被压成什么样”,不是“某家模型今天读图正确率多少”。后者请按第三节那三个实验自己量。

六,ppi 换成“字高多少像素”是我自己的算术,假设是“中文 10.5 磅字框高约 3.70 毫米”。你换一个字号,那两列数会整体平移,但“屏幕上 12 像素的小字已经在 150 ppi 门槛以下”这个结论不变——因为 12 像素这个数是死的。

七,有两条我本来打算引的论文,核对时发现我记的 arXiv 编号对应的是完全不同的论文(一个编号下是编码理论的数学文章,另一个是 Qwen2 技术报告),所以这两条已经从正文里删掉,一条没留。另外还有一篇讲视觉基础问答缺陷的论文(有人转述给我,摘要里带 LeCun 的名字),我没有亲自打开核到原文,因此正文里也没有引用它。宁可少一段论据,也不放一条我没看过原话的引用。

八,OCRBench 那篇是否经过同行评审,我没核到(arXiv 页面没有标注会议信息),所以正文只用了它对能力分类和短板的那句描述,没有引用它给出的任何总分数字——那类分数换一版模型就会变,拿它当结论最容易误导。

三道判断题

一,「我发的是原图,所以 AI 看到的是完整分辨率。」 不对。你发的是原图,它看到的是被平台规则降采样之后的图。 1080p 进 Claude 标准档是 1456×819,4K 进同一档也是 1456×819——上限卡住之后,你上传多大不重要。想要完整分辨率,只有两条路:换到官方给的高解析档,或者裁一块让它不需要缩。

二,「图里的字太小,我把整张图放大一点再发就好了。」 不对,而且是我实测里最反直觉的一条:放大 2 倍、3 倍之后,进模型的仍然是 1455×819,字高仍然是 9.1 像素。放大改变的是“你上传的尺寸”,限制的是“它接收的尺寸”,中间那一步会把你的放大整个抹掉,还额外引入插值模糊。该做的是裁一块,不是放大。

三,「它把数字读错了,说明这张图超出了它的能力,只能换 OCR 工具。」 有条件地对。先试“裁块 + 先复述再回答”这两步——很多读错是输入被降级造成的,不是能力不够。如果裁块之后它仍然读错,那才是真的超出它的像素级识别能力,这时候用文字提取专用工具出文本、再让 AI 处理文本,是更省事的分工。站内这份速查讲怎么把要求写成验收标准:《提示词写作技巧》。

现在能做的几件事

第一件,把“读小字”默认改成“裁一块”。 这是本篇唯一必须带走的操作:截图之后多花十秒,把要看的那块裁出来再发。 它同时给你三个好处:字高不损、词元更少、答案更稳。

第二件,重要数字一律要求它先逐字复述。 金额、订单号、身份证号、电话、日期。先让它把看到的字符原样列出来,你核对,再让它算。 这一步能把”眼睛错”和”脑子错”分开,也能挡住位数丢失那一类错误。如果你每天都要走这套流程,可以把它写成固定模板,而不是每次重新打一遍——提示词、Skill、MCP 这三种”把要求固化下来”的方式怎么选,这篇讲得清楚:《提示词、Skill、MCP 有什么区别》。

第三件,拍照前先想“正不正”,不要想“清不清楚”。 官方点名的三类困难里,旋转和低于 200 像素都在你能控制的范围里。把单据摆正、把要问的那部分拍满整个画面,比换一台像素更高的手机有用得多——因为它最终还是会缩到 1,268×951。

第四件,带图的请求单独算一次账。 一张图 85 词元和 6,192 词元差 73 倍,一个模型 85 词元和另一个模型 2,833 词元也差几十倍。如果你每天要处理几十张图,先按本文公式算一遍单张词元,再决定用哪一档。 那篇算账的文章给了完整方法:《每百万 tokens 到底是多少字》;如果量已经大到“算完还是贵”,那篇把 AI 账单砍掉九成的做法里也有“哪些活该交给便宜模型、哪些该交给本地工具”的分工思路:《把 AI 账单砍掉 90%》;如果你要在发布稿里比较各家读图能力,怎么读那些文档理解分数,这篇给了框架:《怎么读一份大模型发布稿》。

第五件,知道哪些图不该交给它。 票据、证件、合同扫描件属于“错一位数就有代价”的场景。这类内容我建议只做两件事:核对和留档,不要让 AI 替你判断金额对不对。 特别是别把别人的证件照、合同原件随手丢进对话框——这一条在站内那份安全清单里有更完整的处理办法:《让 AI 替你办事的安全清单》。

第六件,如果你要它处理的是“很多页文档里找一句话”,那是另一件事。 它属于检索,不属于读图:图读得清不清是眼睛的问题,找得到找不到是翻法的问题。 这两套机制要分开修:《AI 是怎么翻到你要的那一页的》。

一句话版本

它没在看你的图,它在看你那张图被缩印之后的马赛克版:一个 28×28 像素的格子里塞不下一行小字的差别,于是它凭语境把最像的那个数字填给你。 所以别放大、别发整屏、别问“对不对”——裁一块、先复述、再核对,这三步不需要任何参数,也不需要你懂词元。

推荐阅读

实战教程

为什么同一个问题问 AI 两遍,答案不一样:它不是在算答案,是在按概率抽一个词

同一句话原封不动问两遍,AI 的措辞不一样、甚至结论不一样。原因不是它心情不好:它每步拿到的不是一个答案,而是「一整排候选加各自的概率」,然后从中抽一个,连抽几百次就是一篇回答。这篇把「温度」讲回它的本义——softmax 公式里那个除号(Hinton 原话「T 是通常设为 1 的温度」「T 越大概率越平」),再给三张你我能自己复算的表:同一排候选,温度 0 抽一千次只出 1 种结果、0.2 出 2 种、2.0 时最冷门的词已占 7.35%;每个词有九成把握一致,写到 50 个词整段逐字一致的概率只剩 0.5%;单次七成答对的模型,抽九次投票变 90.1%(谷歌 Self-Consistency 论文实测 GSM8K +17.9 个百分点)。最关键的一条纠正:温度调到 0 官方也不保证复现——Anthropic 明写它「从未保证输出相同」,微软 Azure 的 seed=42 自家示例第三遍照样变了。还有一个 2026 年的现在时:Kimi 固定 1.0、传其他值报错,Gemini 新模型直接忽略,Claude 新代传非默认值返回 400,大厂正在把这些旋钮拆掉。

实战教程

为什么 AI 数不清 strawberry 里有几个 r:它看到的不是十个字母,是三块

问 ChatGPT「strawberry 里有几个 r」,它常常答 2。原因不是笨,而是它根本没收到十个字母——我用官方分词库实测,strawberry 在三本不同词表里都是三块:st / raw / berry,三个 r 分散在其中两块里,而「逐块拆开再累加」这个动作从来没被训练过。这篇用「矗字里有几个直」讲清这件事,再给你四个自己跑得出来的数:同一句 17 个汉字,老词表切 34 块、新词表切 15 块;站内一篇 5,500 汉字的中文稿实测 7,112 块,约 0.77 汉字一块,换本词表变 9,491 块、多算 33%(和 Anthropic 官方那句「约 30 percent more tokens」对得上);9.11 之所以比 9.9 大,是因为它看到的是整块「11」。也有一条必须纠正的流行说法:分词不是唯一原因,arXiv 三篇论文给的图景更麻烦,而「换了 tokenizer 就修好了」厂商从未公开解释过。

实战教程

冬天掉的电会还给你,夏天掉的不会:笔记本电池的两条账

冬天续航从六小时掉到三小时,进屋放一会儿又涨回来——这不是电池冻坏了,而是低温让你“暂时取不出”那部分电。Battery University 的 BU-502 给的数是:同一块电池在 27°C 能放出 100%,到 -18°C 只放得出约 50%。真正不会还给你的是另外三件事:高温、长期满电、低温充电。而“充到 80% 更耐用”也有代价——BU-808 的表写明 4.20V(充到 100%)大约 300–500 次循环,压到 4.00V 能到 1,200–2,000 次,但每次能用的电量也更少。这篇把八家厂商(微软、苹果 iPhone、苹果 Mac、华硕、戴尔、三星、谷歌、联想)的官方充电上限摆在一起,讲清“电池健康 87%”是怎么算的、为什么 0°C 以下不要充电,以及充电宝上的 3C 为什么是 2024 年才强制的。

实战教程

隔一堵墙,WiFi 为什么慢一半:它不是听不清,是换了个说法

图标只掉一格,网速却掉了七八成——因为 WiFi 变慢不是因为线路变细,而是发包的那一方主动换了一种更抗干扰、也更慢的说法。思科官方手册的原句是“有障碍或干扰时,设备会降到还能传数据的最高速率”,而那张档位表最慢一档只有 1 Mbps,最高 54 Mbps,差 54 倍。这篇用“打电话时放慢语速”讲清换档,用三张官方表讲清 dB(每 3 dB 功率差一倍,20 dB 只剩约百分之一)、2.4/5/6 GHz 的路宽差异,以及 Meraki 那句“实际吞吐通常只有标称的 50% 或更低”。末尾给你两个十秒能量出来的数和三道判断题。

探索更多生产力神器

不想只停留在理论?立即体验下一代 AI 工具与 MCP 插件

收录 ChatGPT 6、Claude 3.7、Devin 等热门 AI,以及 3000+ 开发者开源 MCP 插件与一键安装脚本。

为什么AI把截图里的数字读错:视觉词元、图像缩放与分辨率的通俗解释 - AgentHub