先说结论:它看到的那张图,比你屏幕上那张小得多
你一定见过这种事:把一张表格截图发给 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×1080 | 1456×819 | 1,560 | 不缩 | 2,691 |
| 2000×1500 | 1269×952 | 1,564 | 不缩 | 3,888 |
| 3840×2160 | 1456×819 | 1,560 | 2576×1449 | 4,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×2532 | 724×1567 | 38% | 7.4 像素 |
| Mac 全屏截图 2880×1800(字 24 像素) | 1388×868 | 23% | 11.6 像素 |
| 1080p 表格截图 1920×1080 | 1455×819 | 57% | 9.1 像素 |
| 4K 截图 3840×2160(字 16 像素) | 1455×819 | 14% | 6.1 像素 |
| 手机拍的发票 4000×3000(字 18 像素) | 1268×951 | 10% | 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,面积只剩十分之一。你拍得越清楚,被扔掉的部分越多。
官方规则二: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 ppi | 18.2 像素 | 125 ppi |
| 16 像素(小标题) | 110 ppi | 12.1 像素 | 83 ppi |
| 12 像素(表格、聊天记录) | 82 ppi | 9.1 像素 | 62 ppi |
| 10 像素(网页辅助说明) | 69 ppi | 7.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×819 | 1,560 | 9.1 |
| 裁出那块表格 600×400 | 不缩 | 330 | 12.0 |
| 裁半屏 960×540 | 不缩 | 700 | 12.0 |
| 裁一行表头 1200×300 | 不缩 | 473 | 12.0 |
| 整张放大 2 倍再发 | 仍被缩到 1455×819 | 1,560 | 9.1 |
| 整张放大 3 倍再发 | 仍被缩到 1454×818 | 1,560 | 9.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 像素的格子里塞不下一行小字的差别,于是它凭语境把最像的那个数字填给你。 所以别放大、别发整屏、别问“对不对”——裁一块、先复述、再核对,这三步不需要任何参数,也不需要你懂词元。