
文章写作工具
AI 能读你的聊天截图,但不一定读得对
截图里的小字和非拉丁文字,AI 读错的比例有多高?本文梳理已发表的错误率、没人测量过的深色模式差距、三款截图应用对上传内容的说法,以及清除元数据是否真有可测量的作用。
作者 Samet Durgun · Subtext 联合创始人 · 阅读约需15分钟
· 更新于2026年10月31日
把聊天截图贴进 AI 工具,通常直接就能用。它会告诉你谁说了什么,听得懂玩笑,还会起草一条说得通的回复。可“通常”到底有几成把握,没有人给过数字。我想把这个问题,和本站别处已经讲过的另一个问题分开。至于模型拿到文字之后的事,也就是在多轮来回里分清是谁在说话、记住一个没人回答的问题、读出讽刺,本站已有专文讲过,可以看读懂你收到的消息,以及回复前先读完整段对话背后的研究。本文谈的是更靠前的一步:模型一开始有没有把图片读对。
我是做 Subtext 的人之一。它是一款检查语气、起草回复的应用,聊天截图是它的输入方式之一,所以我有理由希望这里的答案对它有利。可惜我没有这样的答案。下面写的,是我能核实的一个更窄、对它也没那么有利的问题:今天具备视觉能力的模型,把手机截图当作图像而不是现成的文字记录来读,到底读得有多好;以及截图一旦交给这类应用,会发生什么。下面每一条来源,我都亲自打开读过。
先说结论:清晰的英文文字,大多能读对;一旦字号小、图像分辨率低,或者文字不是拉丁字母,就没那么可靠了,已发表的错误率会随之上升,中文和阿拉伯文上升得尤其厉害。这些测试用的都不是真实的聊天截图,而关于深色模式,我一项测试也没找到。文章靠后的地方,Subtext 对两张画出来的聊天截图做的两次运行,展示了读一张截图在最简单的情形下是什么样子,也仅限于最简单的情形。
读截图,先是图像问题,然后才是语言问题
聊天截图是一幅由光点构成的画面,不是计算机本来就能解析的一段文字。模型要先把像素正确地变成字符,才谈得上去推理一条消息在说什么,而且不论消息应用碰巧用了什么字体、字号、对比度和排版,都得读对。这一步叫光学字符识别(OCR),依托的是读取其他图片所用的同一套视觉系统。关于 AI 处理消息的准确率,人们的说法大多针对这一步之后的推理,很少有针对这一步本身的。
现有的数字
最直接的测试,是2023年对 GPT-4V 的 OCR 能力所做的评估,覆盖多个基准测试1。在英文场景文字上,它在 CUTE80 基准上的单词准确率为88.0%,在另外三个更难的英文数据集上为62.0%到66.0%;专用 OCR 系统在同样这四个基准上的成绩,则是68.2%到98.6%。在中文场景文字的 ReCTS 基准上,GPT-4V 得分为零。同一篇论文里另有一项多语言测试,它的文字检测与识别(text spotting)F1 分数,英语达到82.49%,法语83.42%,阿拉伯语只有16.55%,中文只有1.36%。论文直言:“尽管能灵活应对各种 OCR 任务,GPT-4V 并未超过现有最先进的 OCR 模型”,而且它“在处理非拉丁语言时表现出局限”1。
这只是某一代模型,测的又是精选的场景文字数据集,不是消息截图,所以只能把它当作这个普遍问题的参照基线,而不是对今天任何一款应用的定论。即便如此,要驳“AI 读图片里的非拉丁文字,读得和拉丁文字一样好”这种简单说法,它仍是最直接、可以核查的数字。就这份证据来看,并不是这样。
分辨率也有影响。同一篇论文发现,“输入图像的分辨率与识别表现之间存在正相关”1。这对压缩过或被大幅缩小的截图不利:人们重新保存或转发图片时,很多手机输出的正是这样的图片。模型还没读到第一个字,就已经吃了亏。2025年的一篇范围更窄的预印本,测得更精确一些,不过只测了按固定大小渲染的单个日文汉字,并不是聊天截图。在每英寸约300像素时,多模态模型能与一种专用的 OCR 方法打平,而“低于150 ppi 时,它们的表现会明显恶化”2。这个门槛对压缩过的手机截图里的小字是否同样成立,我没有找到相关测试。方向倒是明确的:文字更小、分辨率更低时,这些模型比专用 OCR 退化得更快。这一点,有两篇各自独立的论文看法一致。
单说深色模式,以及更广义的低对比度文字,我没有找到任何已发表的评估,把多模态模型的准确率,拿去和同一张截图的浅色版本做比较。经典的 OCR 流程通常会先把深色图像反相再处理,因为在那种较老的技术里,对比度反转是出了名容易引发误读的情形。这似乎说明,这种担忧并非空穴来风。至少在我能找到的资料里,没有人对如今人们用来读聊天截图的多模态模型做过同样的测试,所以我不打算给出一个自己拿不出依据的数字。
表情符号也在同一张图里,而关于它们的研究,回答的是和人们通常的提问不同的问题。重点不太在于模型能不能认出某个图形是表情符号,更在于它看到的是哪一个表情符号,因为同一个字符,在不同的地方画出来并不是同一幅图。Unicode Consortium 规定的是码位和它的含义,不规定具体图案。Apple、Google、Samsung 等各家厂商,都会为它画自己的字形3。一项调查找了710名刚发过带表情符号推文的 Twitter 用户,其中至少25%的人不知道,自己的表情符号在别人的手机上可能是另一副模样;而在调查给他们看过自己的一条推文在另一个平台上实际显示成什么样之后,20%的人说,他们当初会修改,或者干脆不发3。这种差距,存在于用两部不同手机看同一个字符的两个人之间。截图使这件事更难办:截图把发送者所在平台画出来的东西压成一张静态图片,读这张图的模型无法还原出底层到底是哪个表情符号,除非平台自己的字体已经固化在像素里。跨平台的歧义,加上截图的压缩,这两者叠在一起,会不会改变模型说错表情符号背后情绪的频率,这样的测试,似乎还没有人做过。
前面提到的两篇文章没有涉及的几种出错情形
除了上面像素层面的问题,聊天里还有几个具体的功能,各有各的办法,让正确读取变得更难。下面有些内容有研究支撑,有些只是对界面如何运作的直白描述,背后没有专门的研究。我尽量把两者分开,免得一边借了另一边的分量。
群聊和多人对话。一对一的截图,只给模型两组视觉线索,把发言分到这一边或那一边。群聊打破了这种格局。三个或更多的人可能共用同一种气泡颜色;发送者的名字可能只出现在一连串消息的第一条上方,后面每一行都没有;一个被裁剪过的头像,可能是判断谁在说话的唯一视觉线索。专门测试模型在群聊截图里能否把每句话归对发言人的研究,我没有找到。最接近的研究测的是一个相关但不同的问题,即会议文字记录里的发言人归属,而不是截图里的气泡,这块内容本站已经在讲如何读完整段对话的那一页里写过。这里写的,只是按界面的运作方式,对同一个问题在截图里的表现所做的描述,不是经过检验的发现。说话的人更多,每一行能借助的视觉线索更少,这样的归属任务,单从表面看就更难,不管有没有人量过究竟难多少。
点按回应和表情回应。别人的气泡一角别着一个小小的表情符号,可能是爱心、大笑,也可能是竖起的大拇指,这里有两个彼此独立的风险。第一个是模型能不能把这个很小、有时还互相重叠的字形认对,这一点我没有找到直接的测试。第二个是回应被正确读出之后意味着什么,这一块有研究者做过。一项研究分析了65万多条带有回应的 Telegram 消息,发现无论底下的消息读起来是中性还是负面,正面的回应都占主导,结论是表情回应“不能可靠地充当情绪呼应或内容共鸣的指标”4。这是来自单一平台、单一话题领域(与加密货币相关的频道)的大样本,而且仍是预印本,所以具体数字应视为暂定。对读截图的人来说,要紧的那一点不受这些保留意见影响:把回应的表情符号认对了,并不能让任何人,不管是模型还是人,知道这个回应究竟在表达什么。
引用回复和回复线程的界面。多数消息应用允许你针对较早的某条消息回复,被引用的片段会显示成一个更小、更暗淡的块,放在新消息的上方。在截图里,字号变小、颜色变浅、有时还有一道竖线,这些视觉处理是唯一的信号,能说明某一行是被引用的上下文,而不是视觉上轮到发言的那一方发来的新消息。裁剪时多裁或少裁几个像素,这个区别就可能消失。模型有多常把被引用的片段误当成新消息,或者反过来,我没有找到测量它的研究。这是一种有可能出现的失误,根子在界面呈现回复线程的方式上,并没有经过检验。
会自动消失的消息。主打阅后即焚的消息应用,把消息设计成看过之后不留记录,而截图恰恰让这个设计落了空。在 AI 的问题出现之前,取证研究者就已经表明,这个前提比用户以为的更不牢靠。有一项研究直接测试了 WhatsApp、Snapchat 和 Telegram 的消息自动消失功能,在它试过的几种场景里,从设备数据和云备份中恢复出了本该已经删除的内容5。这是关于这些平台的发现,不是关于 AI 读这些平台的截图,也没有测量模型的准确率。撇开 AI 不谈,它确实表明:截图并不是临时内容躲过预定删除的唯一途径。应用自带的屏幕模糊,或者“已截屏”的提示横幅,会不会带来模型可能误当成内容的视觉干扰,同样只是一种有可能存在的担忧,这方面我没有找到专门的研究。
表情包。表情包靠姿势和神情传意,多过靠文字,这让机器更难读懂,事实证明,人也一样。一项研究考察了五个学生讨论小组在真实的项目聊天里使用表情包的情形,并就各人自己怎么用表情包,访谈了其中七名参与者。结果发现,在被检视的表情包里,有34.7%出现了发送者本意与接收者理解不一致的情况,主要原因是图案本身的面部和肢体表情含糊6。这是一项针对单一人群的小型质性研究,对象是亚洲某所高校的大学生,测的是人的误读,不是模型的误读。不过,它仍是实打实的证据,说明哪怕在彼此认识的人之间,表情包也是个含糊的信号,这就给“任何读者,不管是人还是机器,光凭图像能读到什么程度”设了一个不高的上限。
对话中途切换语言。在一条消息里,或者同一段对话的几条消息之间切换语言(语码转换,code-switching),在双语和多语的聊天里很常见,对语言模型来说,也是有文献记载的难题。一篇2025年的领域综述直言,“大多数大语言模型处理混合语言的输入时仍然吃力”7,却没有给出一个能直接套用到“一个气泡里有两种语言的截图”上的数字。除了综述所说的、更宽泛的多语言文字问题,我没有找到专门把语码转换当作读截图问题来研究的论文。这是底层技术里真实存在、有文献记载的难点,但放到聊天截图这个场景下,还没有人直接测试过。
三款截图应用对你上传的内容怎么说
Subtext 不是唯一专为读聊天截图做的应用。有用的比较,是看各家当前的文档自己怎么说上传内容的去向,而不是看营销话术暗示了什么。更广的 AI 写作工具格局,我另文梳理过;这里我对照那篇文章里提到的三款产品各自的隐私页面,只查一个窄问题:留存、删除,以及是否用于训练模型。
Keys AI Texting Coach 出自 Charmed Inc.,主打读截图后给出约会和聊天方面的建议,现在看来已经下线。截至2026年9月27日,Apple 自己的 iTunes 查询接口,对它在 App Store 的页面(应用 ID 1510154956)返回零个结果8;它已知的网站域名,把所有路径(包括过去放隐私政策的那一个)都重定向到了一个域名停放页面。我通过任何渠道,都没能找到这款应用现行的隐私政策。它当年就截图处理说过什么,我今天无法核实,我也不会根据一个已经打不开的页面,去重构出一个说法。
Mei 是一款可设为 Android 默认短信应用、带有可选 AI 助手的应用。它现行的条款最后修改于2023年10月3日,我在2026年9月27日核查过9。条款称,消息内容,包括“图片、照片、音频或视频”,存储在它的服务器上,“仅用于通信”,“我们不会另作他用”。另外,在说明可选的 AI 助手实际会收到什么时,同一份文件写道,作为上下文发给 AI 的最近20条消息,包含“表情符号、回应和网址”,但出于这一目的,“带附件的消息、语音消息和图片不会被收集”。合起来读,Mei 自己的文档是说,它的 AI 建议功能完全不处理图片内容,截图也包括在内。关于照片的存储条款,说的是应用内普通的消息收发,与发给 AI 的内容无关。此外还有一项单独的 AI 助手功能,需要用户主动开启,运作方式不同:用户打开它时,Mei 会上传设备上完整的短信和彩信数据库,包括每条消息的文字,外加经过哈希处理的电话号码和联系人姓名,政策写明这些数据“用于训练 AI 模型”。这条训练条款针对的是这项单独的功能,与上面说的服务器上存储的消息内容不是一回事。这一条没有专门点名截图或图片,但它说的是用消息文字做训练,范围很宽,并不只限于联系人元数据。
ConfiText 的隐私政策自2026年2月10日起生效,我在2026年9月27日核查过10。它只谈到“你在应用中输入的文字”,全部九个部分里没有一处提到照片、图片或截图。它自己的营销网站只描述了一种输入方式,即粘贴用户已经写好的一条消息,页面上哪里也没有出现截图或照片上传功能。就目前所见,留存问题似乎不适用于 ConfiText。按它现行网站的说法,这款产品根本不接受截图作为输入。
三款合起来看:一款似乎已经不存在,一款自己的文档把图片排除在它的 AI 实际读取的内容之外,却会在用户打开其助手时用消息文字训练模型,还有一款压根不接受截图。这并没有定下读截图的应用该怎样处理留存。但它确实说明,把三款点名竞品的截图政策放在一起比较,一致之处和适用之处,都比我事先设想的少。
清除元数据是常识,不是测出来的结论
手机拍的每一张照片,文件里都可能嵌着 EXIF 数据:设备型号、时间戳,有时还有位置。分享照片前先清除这些数据的建议,网上随处可见。我找过对照研究,想看清除这些数据,或者手动遮盖截图里看得见的内容,能不能让现实中的隐私伤害出现可测量的下降,而不只是在纸面上封住一个理论上存在的暴露口。我没有找到。现有的是描述性的安全类文章,讲有哪些字段、怎么清除,没有一项实验,拿清除过元数据的人和没清除的人比较结果。这条建议合理,但没有经过检验,别把它当成已经测出来的保护。
至于 Subtext 自己怎么处理截图的元数据,我直接读了 Subtext 后端的系统提示词和工具定义(functions/src/subtext_prompts.ts)。本站有条规矩:对产品下任何结论之前,都要先核对这个文件。那段代码里没有任何地方读取、清除、检查截图的文件元数据,也没有以其他方式碰过它。Subtext 把图片当作视觉输入,交给底层具备视觉能力的模型,和交出其他图片的方式一样;在我读到的提示词和工具定义里,没有出现单独的元数据处理步骤。我把这当作“没有”来陈述,而不是一项功能。我没有发现任何证据,表明 Subtext 对截图的元数据做过什么,不论哪个方向,我也不会声称代码里看不到的能力。Subtext 自己读截图究竟有多准,同样没有独立的评估,上面点名的每一款应用都有这个空白。隐私政策确认了、本站前面那两篇文章也已经写明的,是适用于所有附件(包括截图)的通则:一段对话以及附在上面的所有内容,最后一次使用后五天自动删除,被置顶的对话则是九十天,上传的任何内容都不会用来训练 AI 模型。
把两张截图交给 Subtext:最简单的情形
上面的一切都不是对 Subtext 的测试,这里的两次运行也不是。这只是2026年10月13日做的两次运行,截图的版式是上面所有证据都指向“最容易”的那一类:一对一的对话,浅色模式,大字号,没有表情符号,没有点按回应,也没有引用回复。文字方面,第一次是中文,应用也设成了简体中文,按上面的数字,这不算最容易的文字;第二次是英文的截图和草稿。两段对话都是我编的,专门为这两次运行画成了截图。应用写回来的内容是它真实的输出,第二次的内容下面保持英文原样引用,括号里的中文说明是我加的,不是 Subtext 返回的内容。
第一张截图的时间是今天18:42,内容是和 Dana 的聊天。她先确认周五晚上的饭还去不去,接着说自己订了 Luigi’s,时间是7:30,问 Tom 能不能一起来,还说他这周挺不顺的,最后请你把她借给你的那本书带上,没看完也不急。和截图一起提交的请求是“写一条简短友好的回复”。Subtext 没有写回复,而是先说“Dana订好位子了”,“回起来很简单”,不过“有两件事得你来定”,所以它先问一下,理由是“这样回复才是你真实的想法”。接着它问了三个问题。第一个是“Tom一起来,你觉得可以吗?”,可点选的答案有“欢迎他来”“可以,想关心一下他”“其实有点顾虑”;第二个是“那本书你周五要带给Dana吗?”,可点选的答案有“带上”“还没看完,晚点还”“忘了放哪了”;第三个是“除了这些,你还有什么想跟Dana说或者问的吗?”,这是开放式的,没有可点选的答案,要你自己写。以上是应用的真实输出,没有改动。
写一条简短友好的回复
Dana订好位子了,回起来很简单,不过有两件事得你来定,我先问一下,这样回复才是你真实的想法。
- Tom一起来,你觉得可以吗?
- 那本书你周五要带给Dana吗?
- 除了这些,你还有什么想跟Dana说或者问的吗?
应用提到的每一处,都和截图相符:Dana 订好了周五的位子,Tom 能不能一起来,还有那本书,而且后面这两件事确实都是 Dana 问的。第三个问题是它自己多问的,问你还有没有别的话想说,截图里没有对应的一行。
第二张截图提交时,附的是一份打好的草稿,而不是一个请求。截图里,Priya 在周四取消了约定,并答应下周再约。今天,你问 Priya 今晚还去不去,说自己订了8点的桌子,她又取消了一次,还问:“那改到下周行吗?”草稿是“Sure, no worries. Whenever you have time.”(大意:好的,没关系。你什么时候有空都行)。
Subtext 标出了“Whenever you have time”这几个词,返回的标签是“Passive-aggressive”(被动攻击)和“Mixed messages”(矛盾信号),情绪词是“Disappointment”(失望)。第一个标签的理由说,这几个词“can read as a quiet jab after a repeated cancellation, since it suggests Priya hasn’t made time.”(大意:在对方一再取消之后,这个说法可能被读成不动声色的挖苦,因为它暗示 Priya 没有抽出时间)。第二个标签的理由说,这种没有给出确切时间的说法“is vague and doesn’t answer her question about next week.”(大意:含糊,没有回答她关于下周的问题)。它给出的第一个版本是“Sure, no worries. Next week works for me. Let me know which day suits you.”(大意:好的,没关系。下周我可以。你看哪天方便,告诉我)。
两个标签依据的都是截图,而不只是草稿,具体来说,是对方的名字、这已经是第二次取消,以及对话末尾那个还悬着没有回答的问题。所以在这两张干净的截图上,Subtext 从图里复述的每一个细节,都与原图一致。这两次运行对小字号或非拉丁文字(公开发表的数字就是在这些情形下下降的)说明不了什么:第一张虽然是中文,但字大而清楚,也只是一个例子。对深色模式或群聊(没有人测量过)也是一样。
综合起来看
先把那两次运行放在一边,把上面的四个部分合起来看,整体情形参差不齐,而且并非偶然。唯一有真实、可核查的准确率数字的部分,也就是视觉模型内部的通用 OCR 表现,结果好坏参半:英文不错,非拉丁文字和低分辨率文字则可测量地更弱,而且测的是精选的基准测试,不是真实的聊天截图。上面六种额外的出错情形里,有四种引用了针对相邻问题的真实研究,分别是:回应读对之后究竟意味着什么;阅后即焚类应用一开始删除内容有多可靠;人们误读彼此的表情包有多频繁;语言模型处理混合语言文字,总体上有多吃力。这四项研究,没有一项测试过模型从截图里读出这些东西的确切情形。另外两种,群聊里的发言归属和引用回复的混淆,背后没有任何研究,不管相邻的还是别的,只有对界面如何运作的描述。对竞品的核查,能比较的东西比设想的少:一款已经没了,一款按它自己的说法,把图片排除在自己的 AI 功能之外,一款压根没接受过截图。至于元数据,则成了一条人人都在重复、却似乎没有人测量过的建议。
这并不意味着,模型读你的截图,在一般使用中就不可靠。这里规模最大、最直接的研究,测到的仍是模型把大多数英文场景文字读对了。它的意思是,“视觉模型读聊天截图,和读普通键入的文字一样可靠”这个具体的说法,有真实的、量化过的例外,有些例外还不小,另外还有好几种难读的情形,根本没有人测量过。
目前的情形就是这样。Subtext 只是又一款做这件事的应用,验证得并不比上面其他几款更多,也不比它们更少。
来源核查于2026年9月27日,Subtext 的两次运行在2026年10月13日。
参考来源
- Shi, Peng, Liao, Lin, Chen, Liu, Zhang and Jin (2023). Exploring OCR Capabilities of GPT-4V(ision): A Quantitative and In-depth Evaluation. arXiv. 场景文字和文档 OCR 基准测试,测的是2023年的某一代模型,不是消息截图。
- Inoue (2025). Context-Independent OCR with Multimodal LLMs: Effects of Image Resolution and Visual Complexity. arXiv 预印本,单一作者。测试了100个孤立的日文汉字,字号和分辨率受控,不是聊天截图。
- Miller Hillberg, Levonian, Kluver, Terveen and Hecht (2018). What I See is What You Don’t Get: The Effects of (Not) Seeing Emoji Rendering Differences across Platforms. Proceedings of the ACM on Human-Computer Interaction, CSCW. 对710名 Twitter 用户就他们自己带表情符号的推文所做的调查,不是测试模型能否读懂这些推文。
- Tardelli, Alvisi, Cima, Cresci and Tesconi (2025). Emoji Reactions on Telegram: Unreliable Indicators of Emotional Resonance. arXiv 预印本。针对加密货币相关 Telegram 消息的65万多条回应,单一平台、单一话题领域。
- Heath, MacDermott and Akinbi (2023). Forensic analysis of ephemeral messaging applications: Disappearing messages or evidential data? Forensic Science International: Digital Investigation. 测试的是 WhatsApp、Snapchat 和 Telegram 自己的删除行为,不是 AI 读截图。
- Tang, Hew, Herring and Chen (2021). (Mis)communication through stickers in online group discussions: A multiple-case study. Discourse & Communication. 同一所大学的五个讨论小组和七名受访者;测的是人的误读,不是模型的误读。
- Sheth, Sinha, Patil, Beniwal and Singh (2025). Beyond Monolingual Assumptions: A Survey of Code-Switched NLP in the Era of Large Language Models across Modalities. arXiv 预印本综述,没有针对截图的专门测试。
- Apple. iTunes Lookup API result for Keys AI Texting Coach, app id 1510154956. 核查日期:2026年9月27日。返回零个结果;这款应用似乎已不在上架列表中。
- Mei. Terms of Service and Privacy Policy. 最后修改于2023年10月3日,核查日期:2026年9月27日。
- ConfiText. Privacy Policy. 生效日期:2026年2月10日,核查日期:2026年9月27日。