AI 能讀懂你的聊天截圖，但不一定讀得對

把聊天截圖貼進 AI 工具，多半直接就能用。它會告訴你誰說了什麼，看得懂玩笑，還能擬出一則說得通的回覆。但「多半」到底是多少，沒人給過數字。本站其他頁面談過另一個問題：模型拿到文字之後，怎麼在好幾輪對話裡弄清楚誰在說話、追蹤沒人回答的問題、判讀諷刺，解讀你收到的訊息那一頁和回覆前先讀完整串對話背後的研究談的就是這些。這一篇不談那個問題，談的是更前面的一步：模型到底有沒有把圖讀對。

我是做 Subtext 的兩個人之一。它是一款檢查語氣、擬回覆的 App，聊天截圖是輸入方式之一，所以我當然希望這裡有個對它有利的答案。可惜沒有。以下是我在一個範圍更窄、對 Subtext 也沒那麼有利的問題上查證得到的：現在具備視覺能力的模型，把手機截圖當成圖片（而不是逐字稿）來讀，到底讀得多準；還有，你把截圖交給這類 App 之後，它會怎麼處理。下面每一份來源，都是我自己打開看過的。

先說結論：如果是清楚的英文文字，答案大致是可以；一旦字很小、圖片解析度低，或者不是拉丁文字，就沒那麼可靠了，已發表的錯誤率會跟著攀升，中文和阿拉伯文尤其明顯。這些測試用的都不是真實的聊天截圖，至於深色模式，我連一項測試都沒找到。接近結尾的地方，Subtext 處理兩張畫出來的聊天截圖的兩次實測，會讓你看到在最容易的情況下讀一張截圖是什麼樣子，而且只限於最容易的情況。

讀截圖，先是圖像問題，才是語言問題

聊天截圖是一張由像素組成的圖，不是一段電腦已經能直接解析的文字。模型要推論一則訊息在說什麼，得先把像素正確轉成字元，不管通訊軟體用的是什麼字型、字級、對比和版面，都得認得出來。這一步就是光學字元辨識（OCR），靠的是讀任何其他圖片時也會用到的那套視覺系統。大多數談 AI 處理訊息準不準的說法，講的是這一步之後的推論，很少談到這一步本身。

目前有的數字

最直接的測試，是 2023 年一項評估 GPT-4V 在多個基準測試上 OCR 能力的研究¹。在英文場景文字上，它在 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%。論文直接寫道，GPT-4V「雖然能靈活處理各式各樣的 OCR 任務，卻沒有勝過現有最先進的 OCR 模型」，而且「處理非拉丁語言時表現出侷限」¹。

這只涵蓋一代模型，測的是整理過的場景文字資料集，不是訊息截圖，所以請把它當成這個一般性問題的下限參考，不要當成對今天任何一款 App 的定論。即使如此，要檢驗「AI 讀圖片裡的非拉丁文字，和讀拉丁文字一樣好」這個簡單的說法，它仍是我找得到、最直接也查得到的數字。依這份證據，並非如此。

解析度也有影響。同一篇論文發現「輸入影像的解析度與辨識表現呈正相關」¹。這對壓縮過或被大幅縮小的截圖很不利，而許多手機在人們重新儲存或轉傳圖片時，產生的正是這種圖：模型還沒讀到第一個字，就已經吃虧了。2025 年有一篇範圍更窄的預印本，把這一點測得更精確，不過它只測了以固定大小呈現的單一日文漢字，不是聊天截圖。多模態模型在大約每英寸 300 像素時，表現和專用的 OCR 方法相當，而「低於 150 ppi 時，表現會明顯下降」²。至於這個門檻，對壓縮過的手機截圖裡的小字是否同樣成立，我找不到相關的測試。不過方向是兩篇各自獨立的論文都同意的：對這類模型來說，文字越小、解析度越低，表現下滑得就比專門設計的 OCR 更快。

談到深色模式，以及更廣義的低對比文字，我找不到任何已發表的評估，把多模態模型在這類截圖上的準確度，拿去和同一批截圖的淺色模式版本相比。傳統的 OCR 流程，處理深色圖片之前通常會先把顏色反相，因為在那種較舊的技術裡，對比反轉是已知會引發誤讀的原因，這顯示這個疑慮本身並不離譜。至於現在大家拿來讀聊天截圖的多模態模型，據我所能找到的，沒有人做過同樣的測試，所以我不會寫一個自己無法佐證的數字。

表情符號也在同一張圖裡，但關於它們的研究，回答的並不是大家通常會問的那個問題。重點比較不在模型分不分得出某個形狀是表情符號，而在它看到的是哪一個表情符號，因為同一個字元，在不同地方畫出來的圖案並不一樣。Unicode 聯盟統一規範的是碼位（code point）和它的意義，圖案不在其中。Apple、Google、Samsung 和其他每一家廠商，都各畫各的圖案³。有一項調查，對象是 710 位剛發出一則含表情符號推文的 Twitter 使用者，其中至少 25% 不知道自己用的表情符號，在別人的手機上可能長得不一樣；調查讓他們看到自己的某一則推文，在另一個平台上實際顯示的樣子之後，有 20% 說，早知道就會修改，或乾脆不發³。這個落差，在兩個人用兩支不同的手機看同一個字元時就已經存在。截圖讓可用的資訊又少了一層：一旦截圖，傳訊的人那個平台畫出來的圖案就被壓成一張靜態圖片，原本的碼位也不見了，模型讀這張圖，沒辦法還原底下到底是哪個表情符號。跨平台的歧義，再加上截圖的壓縮，會不會改變模型說錯表情符號背後情緒的頻率，看來還沒有人做過這項測試。

本站其他頁面沒有談到的出錯情形

除了上面像素層級的問題，還有幾項特定的聊天功能，各自用自己的方式讓正確判讀變得更難。下面有些內容有研究支撐，有些只是對介面運作方式的平實描述，背後沒有專門的研究。我盡量把兩者分開寫，免得沒有研究支持的說法，沾了有研究支持的說法的光。

群組聊天和多人對話串。一對一的截圖，只有兩個視覺組別可以分，這一邊和那一邊。群組對話串就打破了這個規律。三個以上的人可能共用同一種氣泡顏色；名字可能只標在一連串訊息的第一則上方，後面每一行都沒有；而被裁掉一部分的大頭貼，也可能是判斷誰在說話的唯一視覺線索。我沒有找到專門的研究，測試模型在群組聊天的截圖裡，能不能把每一行話正確歸給說話的人。最接近的研究，量的是一個相關但不同的問題：書面會議逐字稿裡的發言者歸屬，而不是截圖裡的氣泡。這一塊，本站已經在讀完整串對話的那一頁談過。這裡寫的，只是同一個問題在截圖上會怎麼出現的機制描述，不是經過測試的發現。說話的人更多，每一行能用的視覺線索卻更少，從表面上看就是比較難的歸屬任務，不管有沒有人量過到底難多少。

點按反應和表情符號反應。貼在別人訊息氣泡角落的小表情符號，像是愛心、笑臉或大拇指，有兩個彼此獨立的風險。第一個是模型能不能正確認出那個又小、有時還互相重疊的圖案，這一點我找不到直接的測試。第二個是反應被正確認出來之後，它到底代表什麼，這一部分已經有研究者做過。一項分析檢視了超過 650,000 則附有反應的 Telegram 訊息，發現不論訊息本身讀起來是中性還是負面，正面反應都佔了多數，結論是表情符號反應「不能可靠地作為情緒映照或內容共鳴的指標」⁴。這是來自單一平台、單一主題領域（加密貨幣相關頻道）的大樣本，而且仍是預印本，所以精確數字請當作暫定。對讀截圖的人來說，最要緊的那一點，不受這些但書影響：就算模型或真人把反應的表情符號正確認出來，也還是不知道對方傳這個反應到底想表達什麼。

引用回覆和對話串介面。多數通訊軟體都讓你針對前面某一則訊息回覆，並把被引用的片段顯示成一塊比較小、顏色較淡的區塊，放在新訊息上方。在截圖裡，這種視覺處理（縮小的字、較淺的顏色，有時加一條直線）是唯一的線索，讓人知道那一行是被引用的前文，而不是畫面上看起來輪到發言的那一方所傳的新訊息。裁切的位置只要差幾個像素，這個區別就可能消失。我沒有找到任何研究，量過模型多常把引用的片段誤認成新訊息，或反過來把新訊息誤認成引用。這是介面呈現對話串的方式本身會造成的出錯情形，聽起來合理，但沒有經過測試。

會自動消失的訊息。閱後即焚的通訊 App，設計上就是讓訊息看過之後不留紀錄，而截圖偏偏就破解了這一點。在 AI 的問題出現之前，鑑識研究者就已經證明，這個前提比使用者以為的還要不牢靠。有一項研究直接測試了 WhatsApp、Snapchat 和 Telegram 的訊息自動消失功能，在它試過的情境中，有好幾個能從裝置資料和雲端備份裡，還原出照理已經刪除的內容⁵。這是關於平台本身的發現，不是關於 AI 讀平台截圖的發現，對模型的準確度也沒有任何量測。不過，不管有沒有 AI，它確實說明了一件事：讓限時內容撐過原定刪除時間的，不是只有截圖這一條路。至於 App 自己在畫面上的模糊處理，或「已截圖」的提示橫幅，會不會製造出模型可能誤認為內容的視覺雜訊，這同樣只是個合理的疑慮，我沒有找到專門的研究。

貼圖。貼圖主要靠姿勢和表情，而不是文字，來傳達意思，機器因此更難讀，連人也一樣。一項研究觀察了五個學生討論小組在真實的專案聊天中使用貼圖，並訪談其中七位參與者，請他們談自己用貼圖的情形。在檢視的貼圖中，有 34.7% 出現傳訊的人想表達的，和收到的人理解的不一致，主要原因是圖案本身的臉部和肢體表情含糊⁶。這是針對單一族群的小型質性研究，對象是亞洲某一所大學的學生，量的是人的誤讀，不是模型的。不過，它仍是實實在在的證據，說明就算是彼此已經認識的人，貼圖也是含糊的訊號。所以不論是人還是機器，只憑圖片來讀，你能期待的準確度上限都不高。

對話中途切換語言。在同一則訊息裡，或同一個對話串的不同訊息之間換用語言（語碼轉換，code-switching），在雙語和多語者的傳訊中很常見，對語言模型來說，也普遍是個有文獻記載的難題。2025 年有一篇針對這個領域的文獻回顧，直接說「多數大型語言模型（LLM）仍難以應付混合語言的輸入」⁷，卻沒有給出一個能直接套用到截圖上的數字，也就是同一個對話氣泡裡出現兩種語言的那種截圖。除了這篇回顧談的、範圍更廣的多語言文字問題之外，我找不到哪一項研究，把語碼轉換單獨當成讀截圖的問題來測。請把它看成底層技術裡真實、有文獻記載的困難，套用在一個還沒有人直接測過的情形上。

三款截圖 App 對你上傳的內容怎麼說

不是只有 Subtext 做了讀聊天截圖的 App。真正有用的比較，是看各家目前的說明文件自己怎麼說，上傳的內容會被怎麼處理，而不是看各家的行銷話術暗示了什麼。AI 寫作工具的整體版圖，我另外整理過；這裡我拿那篇提到的三款產品，對照它們各自的隱私權政策頁面，只查一個很窄的問題：保存、刪除，以及有沒有拿來訓練模型。

Keys AI Texting Coach 由 Charmed Inc. 開發，主打讀截圖，提供交友和傳訊息方面的建議，看來已經不再運作。截至 2026 年 9 月 27 日，Apple 自己的 iTunes 查詢服務，對它的 App Store 頁面（App ID 1510154956）回傳零筆結果⁸；它已知的網站網域，則把所有路徑，包括過去放隱私權政策的那一頁，全部轉址到網域停放頁面。不管從哪個管道，我都找不到這款 App 目前的隱私權政策。不論它當初怎麼寫截圖的處理方式，我今天都無從查證，也不會根據一個已經打不開的頁面，去重建某個說法。

Mei 是 Android 的預設訊息 App，另外提供選用的 AI 助理功能。它目前的條款（最後修改日期為 2023 年 10 月 3 日，我於 2026 年 9 月 27 日查閱⁹）寫道，訊息內容包括「圖片、照片、音訊或影片」，會儲存在它的伺服器上，「僅為通訊之目的」，而且「我們不會以其他任何方式使用」。另一方面，在說明可選用的 AI 助理實際會收到什麼時，同一份條款寫道，傳給 AI 當作脈絡的最近 20 則訊息，包含「表情符號、反應和網址」，但為了這個目的，「含附件的訊息、語音訊息和圖片不會被收集」。兩段合起來看，Mei 自己的說明文件是說，它的 AI 助理完全不處理圖片內容，截圖也包含在內。關於照片的儲存條款，講的是 App 內一般的訊息傳送，不是傳給 AI 的任何東西。另一項需要使用者主動開啟的 AI 助理功能，運作方式則不同：使用者開啟之後，Mei 會把裝置上完整的 SMS 與 MMS 訊息資料庫上傳，包含每一則訊息的文字，還有經過雜湊處理的電話號碼和聯絡人姓名，而政策寫明這些資料會「用於訓練 AI 模型」。這項條款沒有特別點名截圖或圖片，但它講的是廣泛地拿訊息文字來訓練，不只是聯絡人的中繼資料。

ConfiText 的隱私權政策（2026 年 2 月 10 日生效，我於 2026 年 9 月 27 日查閱¹⁰）只談「你在 App 中輸入的文字」，全部九個章節裡，沒有任何一處提到照片、圖片或截圖。它自己的宣傳網站只描述了一種輸入方式，也就是貼上使用者已經寫好的訊息，整個頁面上沒有出現任何截圖或照片上傳功能。照目前的情況看，保存的問題似乎不適用於 ConfiText：依它自己現在的網站所述，這款產品一開始就不接受截圖作為輸入。

三款的結果是：Keys 看來已經不存在；依 Mei 自己的說明文件，它的 AI 不讀圖片，但使用者開啟助理後，確實會拿訊息文字去訓練；ConfiText 根本不接受截圖。這沒有解決「讀截圖的 App 到底該怎麼處理保存」這個問題。但它確實表示，我原本想逐項比較三款競品的截圖政策，結果能互相對照、又真正適用的內容，比預期少得多。

移除中繼資料是常識，不是量測出來的結果

手機相機拍的每一張照片，檔案裡都可能嵌著 EXIF 資料，包括裝置型號、時間戳記，有時還有位置。分享照片之前先移除這些資料的建議，網路上到處都是。我找過有沒有對照研究，測量移除這些資料，或手動遮蓋截圖上看得見的內容，是否真的讓現實中的隱私損害降低到可以量到的程度，而不只是在書面上補起一個理論上的暴露缺口。我沒有找到。現有的都是描述性的資安文章，解釋有哪些欄位、怎麼移除，而不是拿移除過中繼資料的人和沒移除的人，來比較結果的實驗。請把這個建議看成合理但未經檢驗的做法，不要當成已經量測過的保護。

至於 Subtext 自己會怎麼處理截圖的中繼資料，我直接查了 Subtext 後端的系統提示詞和工具定義（functions/src/subtext_prompts.ts），寫任何產品說法之前，我一定先看這份檔案。那份程式碼裡，沒有任何地方會讀取、移除、檢查或以其他方式動到截圖的檔案中繼資料。Subtext 把圖片當成視覺輸入，交給底層具備視覺能力的模型，方式和處理其他任何圖片一樣；我讀過的提示詞和工具定義裡，沒有出現獨立的中繼資料處理步驟。我只是在陳述一個「沒有」，不是在宣稱一項功能。我沒有找到任何證據，顯示 Subtext 對截圖的中繼資料做了什麼，不論是哪個方向，我也不會宣稱程式碼裡看不到的能力。Subtext 讀截圖到底有多準，同樣沒有獨立的評估，這個缺口貫穿上面提到的每一款 App。隱私權政策確認的，是適用於所有附件（包括截圖）的一般規則，本站另外兩個頁面也這樣說：對話和附在上面的任何東西，會在最後一次使用後五天自動刪除，若已釘選則是九十天，而且上傳的內容不會拿來訓練 AI 模型。

兩張截圖交給 Subtext：最容易的情況

上面這些都不是對 Subtext 的測試，這一節也不是。這只是兩次實測，第一次是 2026 年 10 月 31 日做的，第二次是 2026 年 10 月 13 日，用的是上面所有證據都指向「最容易」的那一類截圖：一對一對話、淺色模式、大字級，沒有表情符號、沒有反應，也沒有引用回覆。只有一點不同：第一張截圖是中文的，正是上面已發表的數字往下掉的那種非拉丁文字。兩段對話都是我虛構的，是為這兩次實測特別畫出來的。App 回傳的，是它真正的輸出。第二次實測用的是英文版本：截圖裡的對話和草稿都是英文，所以那一段引用的標籤、理由和版本，都是 Subtext 以英文回傳的原文，後面附的中文說明是我加的。

第一張截圖是和 Dana 的聊天，時間標示為今天 18:42。她先確認禮拜五的晚餐還算數，說她訂了 7:30 的 Luigi’s，問 Tom 能不能一起來，因為他這禮拜過得很不順，最後還想把借出去的書要回來，說還沒看完的話不急。送出時附的請求是「寫一個簡短友善的回覆」。Subtext 沒有擬出回覆。它先說「好,我來幫你寫個簡短又親切的回覆。先問你兩個小問題,這樣我才不會替你亂答。」，然後列出來的其實是三題。第一題是「Dana 問 Tom 可以一起來嗎,你的想法是?」，附了三個可以點的答案：「歡迎他來」、「有點不方便」和「看情況再說」。第二題是「那本書你要怎麼處理?」，同樣附了三個答案，其中一個是「還沒看完,下次再帶」。第三題沒有選項，問的是「還有什麼想順便跟 Dana 說的嗎?(例如關心 Tom、謝謝訂位)」。以上是 App 實際回傳的內容，沒有經過修改。

這三個問題提到的每一樣，都在截圖裡：Dana、Tom 要不要一起來、他這禮拜過得不順、那本書，還有她訂的位子。至於禮拜五、Luigi’s 和 7:30，它的回答一個字都沒提，截圖上的其他幾行也沒有。

第二張截圖送出時，附的不是請求，而是一則打好的草稿。截圖裡，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 表現，結果好壞參半：英文很強，非拉丁文字和低解析度文字則明顯較弱，而且測的都是整理過的基準測試，不是真實的聊天截圖。上面六項額外的出錯情形裡，有四項引用了相鄰問題的真實研究：反應被正確讀出來之後，到底在表達什麼；閱後即焚的 App 原本能把內容刪得多可靠；人們多常誤讀彼此的貼圖；還有語言模型整體上處理混合語言文字有多吃力。這四項研究，沒有一項測試過「模型從截圖上讀這些內容」的確切情形。另外兩項，也就是群組聊天的發言歸屬和引用回覆的混淆，背後完全沒有研究，不論相鄰與否，只有一段對介面怎麼運作的描述。競品檢查的結果，可以比較的也比預期的少：一款已經消失，一款依它自己的說法，把圖片排除在自己的 AI 功能之外，還有一款根本沒有接受過截圖。至於中繼資料的問題，結果是一個大家都在重複、卻似乎沒有人量過的建議。

這些都不表示，模型讀你的截圖，在一般使用上就不可靠。這裡規模最大、最直接的那項研究，量到的仍然是模型把大部分英文場景文字讀對。它要說的是另一件事：「視覺模型讀聊天截圖，和讀一般打字的文字一樣可靠」這個具體的說法，有真實、量化過的例外，有些例外還很大，另外還有好幾種困難情形，根本沒有人量過。

目前的情況就是這樣。Subtext 只是又一款做這件事的 App，被查證的程度，不比上面其他幾款多，也不比它們少。

資料來源的查證日期為 2026 年 9 月 27 日。文中的 Subtext 實測，第一次是 2026 年 10 月 31 日做的，第二次是 2026 年 10 月 13 日。

資料來源

1. Shi, Peng, Liao, Lin, Chen, Liu, Zhang and Jin (2023). Exploring OCR Capabilities of GPT-4V(ision): A Quantitative and In-depth Evaluation. arXiv. 針對 2023 年某一代模型的場景文字與文件 OCR 基準測試，不是訊息截圖。
2. Inoue (2025). Context-Independent OCR with Multimodal LLMs: Effects of Image Resolution and Visual Complexity. arXiv 預印本，單一作者。測試 100 個獨立的日文漢字，字型大小和解析度皆受控制，不是聊天截圖。
3. 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 使用者的調查，內容是他們自己含表情符號的推文，並不是測試模型怎麼讀這些推文。
4. Tardelli, Alvisi, Cima, Cresci and Tesconi (2025). Emoji Reactions on Telegram: Unreliable Indicators of Emotional Resonance. arXiv 預印本。加密貨幣相關 Telegram 訊息上超過 650,000 筆反應，只有一個平台、一個主題領域。
5. 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 讀截圖。
6. Tang, Hew, Herring and Chen (2021). (Mis)communication through stickers in online group discussions: A multiple-case study. Discourse & Communication. 同一所大學的五個討論小組和七位受訪者；量的是人的誤讀，不是模型的。
7. 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 預印本文獻回顧，沒有針對截圖的測試。
8. Apple. iTunes Lookup API result for Keys AI Texting Coach, app id 1510154956，2026 年 9 月 27 日查閱。回傳零筆結果；這款 App 看來已不在上架清單中。
9. Mei. Terms of Service and Privacy Policy，最後修改日期為 2023 年 10 月 3 日，2026 年 9 月 27 日查閱。
10. ConfiText. Privacy Policy，2026 年 2 月 10 日生效，2026 年 9 月 27 日查閱。