视觉理解

你把一张手机截图丢给 AI，问它"这上面写的什么"，它一秒钟就答出来了。你会觉得它"看见"了这张图。但它并没有"看"，它是在数方块。这一节要把这件事从头拆到尾：一张图片进入模型之前会被切成多少块、每块折算多少钱、为什么同一张图在不同模型上价格能差三十倍、为什么它能读清一整页合同却数不清桌上有几个杯子、以及一条几乎所有人都猜错的官方结论——主流大模型都不保证能判断一张图是不是 AI 生成的。所有数字都来自厂商官方文档，查询日期是 2026 年 8 月 6 日。

先把"视觉理解"这四个字拆开

视觉理解（Vision Understanding）这个词听着玄，其实就是"你给图，它给字"。注意方向——图片是输入，文字是输出。这一点必须先钉死，因为它和"文生图"是完全相反的两件事，而这两件事在日常聊天里经常被混着说。

这里顺手澄清一个流传很广的误会。Anthropic 官方文档里有一句写得非常直白的话：Claude 只能理解图像，不能生成或编辑图像（原文表述是 Claude can only understand images, not generate or edit them）。也就是说，你让 Claude"画张图"，它做不到——这不是它今天心情不好，是能力边界上就没有这一项。"能看懂图"和"能画出图"是两套完全不同的机器，一个模型有前者不等于有后者。

为什么值得单开一节讲视觉理解？因为它是目前落地最扎实的多模态能力。读发票、读体检单、读快递面单、读仪表盘、把手写笔记转成文字、帮视障者描述眼前的东西——这些都是今天就能用、而且每天有人在真用的场景。而要用好它，你必须先搞明白它按什么收钱、在什么地方靠不住。这两件事恰好都有官方文档可查，不需要靠猜。

模型怎么"看"：图片先被切成方块

把图片切成方块这个思路，来自一篇 2020 年的论文（Vision Transformer，业内简称 ViT）。它的核心主张一句话就能说完：既然 Transformer 处理"一串 token"很在行，那就把图片也变成一串 token 喂给它。

怎么变？说白了就是三步：

第 1 步 · 划格子
    一张 1024 × 1024 的图，用 32 × 32 的方格去铺
    横着能铺 1024 / 32 = 32 格
    竖着也能铺 1024 / 32 = 32 格
    总共 32 × 32 = 1024 个方格

第 2 步 · 把每个方格压平
    一个 32×32 的彩色方格里有 32 × 32 × 3 = 3072 个数字
    （3 是红绿蓝三个通道）
    把这 3072 个数字过一层线性变换，压成一个向量
    → 这个向量的地位，和一个文字 token 的向量完全一样

第 3 步 · 排队进模型
    [图块1][图块2]...[图块1024][文字token1][文字token2]...
     └────────── 图片部分 ──────────┘└──── 你的问题 ────┘

    从这里往后，模型完全不区分"这个 token 是图还是字"
    它就是在一条混编的队伍上做注意力计算

第 3 步是整件事最关键、也最容易被忽略的地方。图块和文字 token 进了模型之后是平权的、混编在一条队伍里的。这正是"多模态"这个词真正的技术含义——不是"接了一个读图插件"，而是图和字共用同一套注意力机制、在同一个空间里互相看。所以你能问"图里左边那个人穿的衣服和右边那个是同一件吗"，模型的"文字问题"确实能"看到"图块。

换成大白话：这就相当于把图片翻译成了模型的母语。模型的母语是"一串向量"，图片本来是另一种语言，切块加压平这两步就是翻译。翻译完之后，图和字在模型眼里没有身份差别，就像公交车上刷卡的乘客——不管你是学生卡、老年卡还是普通卡，刷完之后在系统里都只是"一次上车记录"。

OpenAI 的两套算法：Patch 制与 Tile 制

知道了原理，来看真实账单。OpenAI 目前同时并行着两套图像计费算法，用哪套取决于你调的是哪个模型。这件事本身就有点意思——它是技术迭代留下的地质层。

第一套 · Patch 制（GPT-5 系列在用）。公式极其干净，官方直接给出：

original_patch_count = ceil(width / 32) × ceil(height / 32)

ceil（读作"晒欧"，全称 ceiling，"天花板函数"）这个词听着玄，其实就是"不管余下多少，一律进位"。宽度 1000 像素除以 32 等于 31.25，ceil 之后是 32——相当于装修贴瓷砖：最后一列只剩三分之一宽的空隙，你也得整整切一片砖去贴，不可能贴"零点二五片砖"。

官方给的算例可以直接背下来：一张 1024×1024 的图 = 1024 个 patch。验算一下：1024÷32 = 32，32×32 = 1024，正好。这个例子好记，可以当成心算基准——看到一张一千像素见方的图，就想到"一千来个 patch"。

那图片太大怎么办？超预算就按比例缩放。每个模型档位有两个上限，谁先撞到算谁：

官方还给了第二个算例，正好演示了缩放：一张 1800×2400 的图，缩放之后是 1452 个 patch。你可以验算这个逻辑——原图直接算是 ceil(1800/32) × ceil(2400/32) = 57 × 75 = 4275 个 patch，撞破了 high 档的 2500 上限，于是被按比例缩小，缩到 1452 个才停手。注意这个结果比上限 2500 还低不少——因为缩放要保持长宽比，还要让缩完的边长仍是整数格，只能取一个"安全落点"。

还有一层容易漏掉的乘数。小模型算出 patch 数之后，还要再乘一个倍率才是最终计费 token：

• gpt-5.4-mini× 1.62
• gpt-5.4-nano× 2.46
• o4-mini× 1.72

这个倍率的存在意味着一件反直觉的事：越小的模型，同一张图折算出的 token 反而越多。为什么？因为小模型的单价便宜，厂商用倍率把"图像这件事的真实成本"补回来——图像处理的算力开销并不随模型变小而等比例下降。换成大白话：这就像快递的体积重量规则，一箱泡沫塑料明明很轻，照体积算却按十公斤收钱，因为它占的车厢空间是实打实的。

第二套算法 · Tile 制：先缩到 768，再数 512 的方块

Tile 制用在 GPT-4o、GPT-4.1 和 o 系列上。Tile（读作"泰欧"）就是"瓦片、地砖"的意思，它干的活儿相当于用一块块大地砖去铺图片，而不是用小马赛克。流程是：

第 1 步 · 缩放
    把图片缩放到"最短边 = 768 像素"

第 2 步 · 数 512 见方的瓦片
    看缩放后的图能被切成几块 512 × 512

第 3 步 · 算钱
    总 token = base（固定底价） + 每块瓦片的单价 × 瓦片数

各模型的两个数字（官方口径）：
    gpt-4o / gpt-4.1  →  base 85   + 170 / tile
    gpt-5 系（tile 制）→  base 70   + 140 / tile
    gpt-4o-mini       →  base 2833 + 5667 / tile   ← 看清这个数字

前两行很正常，一张图几百个 token，符合直觉。但第三行需要你重读一遍。

★ 反直觉的一条账：mini 模型的图像成本高得离谱

把三行放到一张表里对比，那个反常之处就藏不住了。假设一张图占 4 个 tile：

同一张图，在 gpt-4o-mini 上折算出的 token 数是在 gpt-4o 上的三十三倍。这完全违背"mini 就是便宜版"的直觉。它之所以这样定，是因为 mini 的 token 单价本来就低得多，厂商需要用一个大得夸张的折算系数把图像的真实成本补齐——最终两者的实付金额并不会真差三十三倍。但是！token 数是实打实变多了，而这会带来两个纯技术后果，跟钱无关也躲不掉：

• 吃掉上下文窗口两万五千个 token 是一大块地皮。如果 mini 的窗口只有十几万 token，几张图就能把窗口塞满，你的文字部分就没地方放了。
• 拖慢首字响应输入 token 越多，prefill 阶段（就是第 8 章讲的"把你的问题读进去"那一步）越慢，第一个字出来得越晚。
• 撞限流API 限流是按"每分钟多少 token"算的。图一多，你可能明明只发了几张图就被限流了。

实操结论很反常识：做图像任务时，不要条件反射地选 mini 省钱——先把两边的 token 数真算一遍。这是本节最有实用价值的一条，也是网上几乎没人提的一条。

detail 参数四档：你其实可以自己控制精度和成本

OpenAI 的图像输入有一个叫 detail 的参数，四个取值：low / high / original / auto。所谓 detail，说白了就是"你要它看多仔细"——看得越仔细，切出的块越多，钱越多、越慢。

最后一行是个需要格外小心的坑。auto 这个名字给人的感觉是"它会帮我省着用"，可官方明确说：在 GPT-5.5 及 5.6 上，auto 等价于 original，也就是不缩放。后果是——你什么参数都不填，扔一张手机原图（现在动辄四千像素宽）进去，token 消耗可能比在旧模型上还高。

这就像换了一台新洗衣机，旧机器的"自动"档默认是节水模式，新机器的"自动"档默认是深度清洗——你以为在省水，其实每次都在放满缸。迁移模型版本时，这类"默认值变了"的细节比"新增了什么功能"更容易咬人。

反过来说，original 也不是浪费。有三类任务必须用它，用低了就是白跑：

• OCROCR（Optical Character Recognition，光学字符识别——把图片上的字认成可编辑文本）。字小，缩一次就糊了，糊了就认错。
• 小目标检测找图里那个很小的东西（远处的车牌、电路板上的某个元件）。缩放等于把它抹掉。
• 坐标定位要模型报出"那个按钮在图上第几像素"。缩放会让坐标系整体失真。

输入的硬边界：格式、体积、张数

这些是查文档就能查到、但不查就一定会踩的死规矩。OpenAI 一侧：

• 支持格式PNG、JPEG、WEBP，以及非动图的 GIF。注意"非动图"这个限定——动图 GIF 不吃。
• 单次请求体积上限512 MB。这个额度相当宽裕。
• 单次请求图片张数最多 1500 张。
• 视频官方视觉文档没有列出 video 输入类型。严谨的说法是"官方文档未提供视频输入"，不能写成"明确不支持"——文档没提和厂商声明不支持，是两回事。

这个"文档没提 ≠ 明确不支持"的区分不是咬文嚼字。技术写作里最常见的失真，就是把"我没查到"写成"它没有"。这就像你翻遍了一本菜单没找到"红烧肉"，正确的说法是"菜单上没写"，而不是"这家店不会做红烧肉"——也许在小黑板上，也许要问服务员。本节所有"不支持"的断言，都只在厂商自己写了"不支持"时才这么写。

Claude 的算法只有一个除法：面积 ÷ 750

Anthropic 的公式比 OpenAI 简单得多，一个除法就完了：

tokens = (width px × height px) / 750

换成大白话：把图的长和宽乘起来得到面积，再除以 750。没有 ceil、没有分档、没有倍率。这就像菜市场论斤称的摊子——不管你买的是什么，上秤，看数字，乘单价。而 OpenAI 那套更像快递公司的计费表，要分首重续重、分体积重量、分不同产品线。

拿刚才那张 1024×1024 验算：1024 × 1024 ÷ 750 ≈ 1398 token。对比 OpenAI Patch 制的 1024 个 patch——同一张图，两家算出来的数字差了三成多。所以"这张图多少 token"这个问题，没有跨厂商的统一答案，必须指明是哪家。

Claude 一侧的限制清单（官方原文口径）：

"1.15 megapixels"这个数字要换算一下才有感觉：115 万像素，大概就是一张 1024×1024 的方图，或者 1280×900 左右的横图。而现在一部普通手机随手拍出来的照片是四千八百万像素——是这个建议值的四十倍。也就是说，你直接上传手机原图，其中大约 97% 的像素在进模型之前就被扔掉了，你还为"上传"这件事等了几秒钟。先在本地缩一次图，又快又省，效果几乎不变。

★ 一条必须标注的引用风险

上面这些 Claude 的数字来自官方文档原文，可以引用。但我必须同时告诉你一件事：那个页面看起来没跟上最新模型。证据有三条：

• 证据一页面通篇仍在说"Claude 3 和 4 系列"。
• 证据二代码示例用的模型名是 claude-sonnet-4-5。
• 证据三成本表里的计价基准是 Sonnet 3.7 的 $3/M token。

所以正确的引用姿势是：公式和张数限制照引（这类技术约束通常不随模型版本变），但价格必须另去 pricing 页核一遍。同一家厂商的两个页面更新节奏不同步，是查资料时最容易踩的陷阱之一。

这就像一家餐厅门口的价目牌和店里的菜单——门口那块牌子挂了三年没换，菜还是那些菜，价钱早就不是那个价钱了。看到"技术规格"和"价格"写在同一页时，要默认后者更容易过期。

用 Python 亲手把三套公式算一遍

公式讲一百遍不如自己算一遍。下面这段代码不需要联网、不需要 API Key，纯本地算数，把三套算法摊在一起对比：

import math

def openai_patch(w, h, patch_budget=2500, mult=1.0):
    """OpenAI Patch 制（GPT-5 系列）。返回最终计费 token 数。"""
    n = math.ceil(w / 32) * math.ceil(h / 32)
    if n <= patch_budget:
        return int(n * mult), "未缩放"
    # 超预算：按比例缩放，直到 patch 数落进预算
    # 面积按 scale 的平方缩小，所以 scale 取根号
    scale = math.sqrt(patch_budget / n)
    w2, h2 = int(w * scale), int(h * scale)
    n2 = math.ceil(w2 / 32) * math.ceil(h2 / 32)
    while n2 > patch_budget:          # 取整误差兜底
        w2, h2 = int(w2 * 0.98), int(h2 * 0.98)
        n2 = math.ceil(w2 / 32) * math.ceil(h2 / 32)
    return int(n2 * mult), f"缩放到 {w2}x{h2}"

def openai_tile(w, h, base, per_tile):
    """OpenAI Tile 制（GPT-4o / 4.1 / o 系列）。"""
    short = min(w, h)
    scale = 768 / short                  # 最短边缩到 768
    w2, h2 = w * scale, h * scale
    tiles = math.ceil(w2 / 512) * math.ceil(h2 / 512)
    return base + per_tile * tiles, f"{tiles} 个 tile"

def claude_tokens(w, h):
    """Claude：面积除以 750。"""
    return round(w * h / 750), "面积/750"

CASES = [(1024, 1024), (1800, 2400), (3024, 4032), (640, 480)]

print(f"{'尺寸':>12} {'GPT-5 patch':>13} {'gpt-4o tile':>13} "
      f"{'4o-mini tile':>14} {'Claude':>9}")
print("-" * 68)
for w, h in CASES:
    p, _   = openai_patch(w, h)
    t4, _  = openai_tile(w, h, 85, 170)
    tm, _  = openai_tile(w, h, 2833, 5667)
    c, _   = claude_tokens(w, h)
    print(f"{w}x{h:>6} {p:>13} {t4:>13} {tm:>14} {c:>9}")

# 官方给的两个基准算例，用来自查代码有没有写错
assert openai_patch(1024, 1024)[0] == 1024, "1024x1024 应为 1024 patch"
print("\n自查通过：1024x1024 → 1024 patch，与官方算例一致")

跑完你会看到几件事。第一，1024×1024 那一行的 GPT-5 列正好是 1024，和官方算例对上了，说明公式抄对了。第二，3024×4032（一张手机竖拍照片）那一行，gpt-4o-mini 列的数字大到刺眼——这就是上面那张表的现实版。第三，Claude 那一列和 GPT-5 那一列始终不一致，且差距随图变大而拉开。

代码里那个 math.sqrt 值得解释一句：为什么缩放比例要开平方根？因为 patch 数正比于面积，而面积正比于边长的平方。你想把 patch 数减半，边长只需缩到原来的 0.707 倍（根号二分之一）。这就像装修算地板：房间边长砍一半，要买的地板不是砍一半，是只剩四分之一。凡是涉及"面积/体积"的换算，直觉几乎总会算错，因为人脑习惯线性。

上面这个分词器小工具本来是给文字用的，但你可以借它建立一个横向的量感：把一段文字粘进去，看它是多少 token，再回头看一张 1024×1024 的图是 1024 个 patch。你会发现——一张普通截图的 token 消耗，大约相当于一千多字的中文文本。一张图确实"胜过千言"，但它也确实按千言收费。

Gemini：三家里唯一能直接吃视频的

前面说了 OpenAI 文档未列视频输入、Claude 官方明确不支持视频。那想让 AI 看视频怎么办？答案是 Google 的 Gemini——它是三家里唯一原生支持视频输入的。这不是"能力更强"那种笼统的强，而是接口层面就有这一项。

先说四种喂视频的方式：

第四行值得单独说一句：你可以直接把一个 YouTube 公开链接贴进请求里，让模型去看那个视频。不用你先下载、不用你转码、不用你上传。这在工程上省掉的功夫非常可观——原本你得写一套"下载 → 抽帧 → 压缩 → 上传"的流水线，现在一行 URL 就完了。

能看多长？1M 上下文的模型可以处理默认分辨率 1 小时、低分辨率 3 小时的视频。这个数字换算一下更有感觉：3 小时基本等于两部电影，或者一场完整的公司会议录像，或者一整个下午的监控回放。另外 Gemini 2.5 及以后的版本，每个请求最多放 10 个视频。

视频是怎么被算成 token 的：每秒 300 个

这里是本节第二个"你必须知道否则会被账单吓到"的地方。视频的处理方式说白了就是：抽帧 + 抽音轨，然后把帧当图片算、把音频当声音算。

Gemini 视频处理的默认参数（官方口径）：

  采样帧率     1 FPS（每秒抽 1 帧）
  音频         1 Kbps，单声道
  时间戳       每秒都会附一个时间戳

每一项折算多少 token：

  一帧画面              258 tokens
  一帧画面（低分辨率）    66 tokens   ← media_resolution 设 low
  音频                  32 tokens / 秒

于是每秒视频的总账：

  默认档：  258（画面） + 32（音频） ≈ 290  → 官方口径「约 300 tokens/秒」
  低分档：   66（画面） + 32（音频） ≈  98  → 官方口径「约 100 tokens/秒」

把"每秒 300 token"这个数字往上乘，才能真正感受到它的重量：

看最后两行你就明白官方那句"1 小时默认分辨率 / 3 小时低分辨率"是怎么来的了：不是模型不想看更长，是 1M 的上下文窗口正好在这里被填满。1 小时 × 300 token/秒 = 108 万，刚过 1M；3 小时 × 100 token/秒 = 108 万，也刚过 1M。这两个"能力上限"其实是同一个窗口约束的两种花法——要么看得清但看得短，要么看得糊但看得长。

这就像你带一个固定容量的保温饭盒出门：装米饭能装三顿的量，装带汤的菜就只够一顿。饭盒没变，是你选了装什么。切换 media_resolution 这个参数，本质就是在决定"这个饭盒里装干货还是装汤"。

★ 1 FPS 这个默认值藏着一个大坑

官方自己提醒了一句非常重要的话：1 FPS 的采样会漏掉快速动作的细节。这句话值得展开，因为它决定了哪些视频任务今天根本做不了。

1 FPS 是什么意思？每秒只看一眼。而一段正常视频是每秒 25 到 30 帧。也就是说，模型看到的其实是一本"每秒一页"的连环画，中间那二十多帧全被扔了。

换算成可感知的量：人眨一次眼大约 100 毫秒。1 FPS 意味着两次"看"之间隔了 1000 毫秒——相当于你在这一秒里眨了十次眼，而每次眨眼都错过了一格画面。再具体点：一个网球发球动作从举拍到击球大约 0.4 秒，在 1 FPS 下有可能整个动作一帧都没被抓到，模型只看到"举着拍"和"球已经飞出去了"两张静态图，中间发生了什么它得靠猜。

所以哪些任务要小心：

• 体育动作分析挥杆、投篮、起跳——关键帧就在那零点几秒里，抽不到就等于没看。
• 安全事故判定"是他先动手还是对方先动手"这种问题，答案往往在半秒之内，1 FPS 判不了。
• 快速手势 / 唇语手语和说话时的口型变化远快于每秒一次。
• ✅ 反过来，这些任务完全够用会议录像总结、讲座内容提取、监控里"有没有人进来"、影视剧情梗概、教学视频转文字笔记——因为这些内容的信息变化本来就以"秒"甚至"分钟"为单位。

一个实用的判断法：问自己"我要找的那个信息，在画面上停留超过一秒吗？"停留超过一秒的，1 FPS 抓得住；一闪而过的，抓不住。

用 Python 调 Gemini 看一段视频

下面是一段可运行的示意代码。文档示例用的模型是 gemini-3.6-flash，走 Interactions API。注意代码里我特意把 token 预估也算了出来——上线之前先估算，比事后看账单心慌好得多：

# pip install google-genai
import os
from google import genai

client = genai.Client(api_key=os.environ["GEMINI_API_KEY"])

# ---------- 方式一：直接给 YouTube 公开链接（最省事）----------
resp = client.models.generate_content(
    model="gemini-3.6-flash",
    contents=[
        {"file_data": {"file_uri": "https://www.youtube.com/watch?v=XXXXXXXXXXX"}},
        "这段视频讲了几个要点？按时间戳分段列出来，每段一句话概括。",
    ],
)
print(resp.text)

# ---------- 方式二：本地文件走 File API（大文件用这个）----------
f = client.files.upload(file="meeting.mp4")
resp2 = client.models.generate_content(
    model="gemini-3.6-flash",
    contents=[f, "会议里谁负责哪件事？列成表格：负责人 / 事项 / 截止时间。"],
)
print(resp2.text)

# ---------- 上线前先估成本 ----------
def video_tokens(seconds, low_res=False):
    """按官方口径估算：默认约 300 tokens/秒，低分辨率约 100 tokens/秒。"""
    frame = 66 if low_res else 258      # 每帧 token（1 FPS，所以每秒 1 帧）
    audio = 32                          # 音频每秒 token
    return seconds * (frame + audio)

for minutes in (1, 10, 60, 180):
    sec = minutes * 60
    hi, lo = video_tokens(sec), video_tokens(sec, low_res=True)
    flag = "  ← 超 1M 窗口" if hi > 1_000_000 else ""
    print(f"{minutes:>4} 分钟视频：默认 {hi:>9,} tokens / 低分 {lo:>9,} tokens{flag}")

# 输出会告诉你：60 分钟默认档就顶到 1M 窗口了，这不是巧合

特别注意最后那个循环打印出的东西。它会用一行输出告诉你官方那个"1 小时"上限的真正来源。很多教程只会告诉你"Gemini 能看 1 小时视频"，却不告诉你这个 1 小时是窗口算出来的——知道数字的来处，你才知道换了个窗口更大的模型时这个数字会怎么变。

DocVQA 榜单：一个必须小心解读的排行榜

讲能力总要有个量化标尺。文档理解领域最常被引用的是 DocVQA（Document Visual Question Answering，"文档视觉问答"——给一张文档图片，问一个问题，看模型答得对不对）。它有官方评测服务器，Task 1 是单页文档榜。当前榜单前列是这样的：

这张表如果不加说明就直接用，会误导人。有三件事必须同时告诉你。

第一件 · 榜单前列没有 GPT、没有 Claude、没有 Gemini。前面挤满的是专用方法和中国厂商、Meta 系的模型。榜上唯一一条 GPT 相关的条目是 2024 年 5 月 31 日提交的"GPT-4 Vision Turbo + Amazon Textract OCR"，分数只有 0.8736。

第二件 · 但你绝对不能因此断言"大厂弱"。原因很朴素：大厂通常不往这个评测服务器提交结果。它们更愿意在自己的发布博客里报自测分数。而榜单上的条目本身也是参赛方自报的。所以正确的读法是——这是"愿意提交者之间的排名"，不是"世界上所有模型的排名"。同理，也不能反过来拿厂商博客里的自测分往这个榜上填，那是两套口径混用。

第三件 · 榜首仍然低于人类。0.9729 对 0.9811，差 0.0082。听起来微不足道，换算一下：在一万道题里，机器比人多答错 82 道。如果你在做一个每天处理一万张发票的系统，这 82 张就是每天要人工返工的量。"接近人类水平"和"可以取代人类"之间，隔着这 82 道题。

顺便补一条我没有取得的信息：图表理解领域另一个常被引用的榜单叫 ChartQA，但我这次没有拿到权威的最新分数，所以本节不写任何 ChartQA 的具体数字。这就像你去医院体检，医生看到一项指标的化验单没出来，正确做法是写"待查"，而不是照着上次的结果填一个。

官方自己列的局限清单（这部分最值钱）

接下来是本节我认为最有价值的部分：两家厂商在官方文档里自己列出的"我们做不好什么"。厂商写自己的缺点，可信度天然高于任何第三方测评——因为没人会主动编造对自己不利的信息。

OpenAI 列出的局限：

• 专业医学影像不适用于 CT 这类专业医学影像。这条是安全红线，不是"效果一般"的问题。
• 非拉丁字母日文、韩文等非拉丁文字的表现可能下降。
• 小字字太小要先放大再传。
• 旋转 / 倒置文本歪着或倒着的文字容易误读。
• 线条样式难理解实线 / 虚线 / 点线之间的差异——这直接影响读图表，因为很多图表就靠线型区分不同数据系列。
• ★ 精确空间定位官方举的例子是识别棋局——它可能认得出这是国际象棋，但说不准每颗棋子具体在哪一格。
• 全景与鱼眼这两类畸变图像表现差。
• 计数只能给近似值。要精确数量就别指望它。
• CAPTCHA出于安全考虑被主动阻断——这条不是"做不到"，是"故意不做"。

Anthropic 列出的局限，和上面高度一致：

• 空间推理有限官方举的两个例子特别形象：读模拟钟表面（就是有指针那种钟）、描述棋子的精确位置。
• 小图易幻觉小于 200 像素的图容易让它编内容。
• 计数不精确和 OpenAI 一样。
• ★ 无法判断图像是否 AI 生成官方原文写得毫不含糊：Claude does not know if an image is AI-generated… Do not rely on it to detect fake or synthetic images.
• 不能识别图中人物身份这既是能力限制，也是主动的隐私策略。

两家独立写出的清单在"空间定位""计数""小字"三项上完全重合，这个重合本身就是有力证据：这些不是某一家的工程缺陷，而是"把图切成方块再当 token 处理"这条技术路线的共同代价。

为什么"数不清杯子"和"读得清合同"能同时成立

很多人第一次看到"能读整页合同却数不清桌上有几个杯子"会觉得矛盾。其实一点也不矛盾，把机制想清楚就顺了。

读文字为什么行？因为文字是高度冗余的、有强先验的。模型在训练里见过海量文本，看到"发票金额：￥1"再加半个模糊的形状，它能靠语言模型的能力把整个数字推出来——相当于你读一封笔迹很烂的信，凭上下文照样能猜出那个字是"钱"不是"我"。

数杯子为什么不行？因为"三个"和"四个"这件事没有任何冗余可依赖。它必须真的把每个杯子逐个点过去，而这需要精确的空间定位能力——恰好是它最弱的那项。更根本的原因在于注意力机制：注意力擅长的是"哪里跟哪里有关系"，而不是"一共有几个"。数数是一个需要按顺序遍历、且不能重复不能遗漏的过程，这压根不是注意力的工作方式。

这就像超市收银台的两种能力。扫码枪对着条码一扫就出价格，快得惊人——因为条码是为机器设计的、冗余极强的编码。但你让同一个收银员目测一筐散装葡萄有多少颗，他也得一颗一颗数。扫码和数葡萄用的是完全不同的两套本事，一个快不代表另一个也快。

实用推论：凡是"精确计数"和"精确坐标"的任务，用专门的检测模型或传统计算机视觉方法，不要指望通用大模型。而"读懂内容、提取信息、归纳总结"这类任务，通用大模型极强。分工，而不是替代。

★ 一条与公众预期完全相反的事实：AI 不认识 AI

这条我要单开一节，因为它的科普价值最高，而且几乎所有人都猜错。

现在网上的假图越来越多，很自然的想法是"让 AI 帮我看看这张图是不是 AI 生成的"。而官方文档明确告诉你：别这么用。Anthropic 的原文是：Claude does not know if an image is AI-generated. Do not rely on it to detect fake or synthetic images.OpenAI 那份局限清单里也没有任何"能识别 AI 生成内容"的承诺。

换成大白话：主流大模型官方都不保证自己能认出 AI 生成的图。

为什么？想想它的训练方式就明白了。模型学的是"图片内容和文字描述之间的对应关系"——它学会了"毛茸茸四条腿的这种东西叫猫"。它从来没有被专门训练去回答"这张图是相机拍的还是模型画的"。更麻烦的是，AI 生成图的目标恰恰就是"看起来像真的"——生成模型的整个训练过程都在优化"骗过判别"这件事。相当于让一个人去鉴别假钞，而印假钞的人手里正好有这个鉴别员的全部评分标准，还在照着标准反复改版。

那它有时候确实"看出来"了怎么解释？它看的是内容层面的破绽——六根手指、字迹是乱码、影子方向对不上、栏杆穿过了人的胳膊。这属于"发现画面里有不合理的东西"，不是"检测出生成痕迹"。所以它会有两类错：漏判（生成得好的图它看不出）和误判（把真实照片里的怪事当成生成痕迹）。两类错都不可控，因此不能当检测工具用。

正确的做法是什么？看溯源信息而不是看画面：查内容凭证（C2PA 那类嵌在文件里的来源标记）、查原始文件的元数据、查这张图第一次出现在互联网上的时间和地点、找发布者核实。这些方法查的是"这张图从哪来"，而不是"这张图长得像不像真的"——前者可查证，后者本质上是一场军备竞赛。

常见误解一次澄清

写给要动手的人：八条实操建议

• 先算 token 再选模型尤其涉及 mini 档。把 patch 制、tile 制、面积除 750 三套公式都跑一遍你的真实图片尺寸，再决定用谁。直觉在这里几乎一定错。
• 上传前在本地缩图缩到 1024–1568 长边这个区间，通常效果不掉、速度和成本都降。手机原图 97% 的像素是白花的。
• OCR 类任务显式设 original别指望默认值帮你决定。同理，只做粗分类的任务显式设 low，别让 auto 帮你花钱。
• 精确计数改用专用工具目标检测模型或传统 CV 方法。通用模型的计数官方自己就说只是近似。
• 要坐标就明确要求归一化坐标让它输出 0–1 之间的相对坐标而不是绝对像素，能规避一部分缩放导致的失真。但仍要人工抽检——空间定位是它公认的弱项。
• 视频先估 token 再上传按每秒约 300（默认）或约 100（低分）估。发现要超窗口就先切片，或者切到 media_resolution=low。
• 快动作视频别用 1 FPS如果关键信息停留不足一秒，考虑先在本地按需抽帧，把关键片段当图片序列传。
• 别把它当鉴伪工具、别当医学影像工具这两条是官方明写的禁区，不是调参能解决的。越过去就是拿别人的风险赌自己的方便。