DeepSeek 視覺功能：擷取可核對的螢幕截圖資料

截圖資料擷取任務要等到有人能把回傳的欄位追溯回原始圖片，才算真正完成。拿到格式整齊的答案只是第一步。真正困難的情況是：某個數字無法辨識、某個數值被對應到錯誤的列，或是模型依上下文自行補上了遺漏的單位。在送出大批圖片之前，先圍繞這些情況設計工作流程。

根據 2026 年 10 月 12 日查閱的 DeepSeek 視覺指南，deepseek-flash 支援圖文混合輸入。9 月 10 日的更新日誌指出該名稱對應 V4.1 Flash。本文是十月份依據公開 API 文件整理的實作指南，而非新模型的發布消息。下方範例是實作範本；它既不是實際推論的執行紀錄，也不是 OCR 準確率基準測試。

準備邊界清楚的截圖

選擇輸出範圍小而明確的任務。例如：從單一庫存面板中擷取可見的狀態、品項名稱與顯示數量。不要一開始就下「看懂這個儀表板」這類指令，因為那等於把「哪些部分重要、要下什麼結論」的判斷丟給模型。

截取時保留足夠的上下文，包含欄位標題與單位。只裁切數字本身，可能會把解讀數字所需的資訊一併裁掉。如果原圖很長或很密集，把它切分成有命名的區域，並保留一份完整圖片作為定位參考。在送出請求之前，先為每個區域指定穩定的識別名稱，例如 panel-A 或 panel-B。

以正常閱讀大小檢查輸入圖。如果你自己都無法分辨截圖中的某個數字，要求模型給出更有信心的答案並不會把遺失的像素變回來。可行的話，用合適的比例重新擷取原始畫面。避免反覆縮放與壓縮，那會讓小字更難辨讀。

下方範例使用 PNG 檔。官方指南也支援 JPEG、GIF 與 WebP，並依檔案內容辨識格式。改副檔名並不會轉換檔案格式。請確認你實際送出的檔案，而不是只看副檔名。

定義模型可以留空的範圍

在撰寫請求之前先定義欄位。以庫存面板為例，一筆實用的紀錄可能包含：區域識別名稱、可見的品項名稱、顯示數量、顯示單位、狀態，以及一欄關於模糊處的註記。當原始措辭重要時，先保留原文；正規化留到後續步驟再處理。

讓「未知值」明確化。空白儲存格、被遮罩蓋住的文字、無法辨識的字元，是三種不同的觀察結果，不該全部變成零。如果下游系統必須要有數字，就把這筆紀錄保留待審，而不是為了滿足它的結構描述(schema)而捏造一個數字。

以下是一則原創的範例指令，用於你提供的截圖：

只讀取 panel-A 中的庫存表格。針對每個可見的列，依原樣回傳品項名稱、數量文字、單位與狀態。無法辨讀的欄位填入 null，並在註記中說明原因。不要推測隱藏的列、不要補完被截斷的名稱，也不要計算總計。附上一段簡短的位置描述，讓我能在圖片中找到每一列。

位置描述只是審核時的輔助，不是精確的邊界框座標。如果你的應用程式需要座標，請另外定義並驗證該需求。不要因為一段看似合理的位置描述，就認定擷取出的數值是正確的。

Start Creating

把圖片放進正確的 content 區塊

文件所記載的 Chat Completions 介面，會把文字與圖片區塊放在 user 訊息的 content 陣列中。本機圖片可以編碼成 data URL。要使用以下 Python 範本，請安裝相容 OpenAI 的 Python 用戶端，在本機環境中設定 DEEPSEEK_API_KEY，並在 screenshot.png 放一張真正的 PNG 圖。金鑰不要寫進原始碼檔案或瀏覽器端程式碼。

import base64
import os
from pathlib import Path
from openai import OpenAI

image = Path("screenshot.png").read_bytes()
if not image.startswith(b"\x89PNG\r\n\x1a\n"):
    raise ValueError("Use a PNG image for this example")
encoded = base64.b64encode(image).decode("ascii")

client = OpenAI(
    api_key=os.environ["DEEPSEEK_API_KEY"],
    base_url="https://api.deepseek.com",
)
result = client.chat.completions.create(
    model="deepseek-flash",
    messages=[{
        "role": "user",
        "content": [
            {"type": "text", "text": (
                "Read the inventory table in panel-A. Return each visible "
                "row's item name, quantity text, unit, status, and location. "
                "Use null for unreadable fields and add a note explaining "
                "the ambiguity. Do not infer hidden rows or calculate totals."
            )},
            {"type": "image_url", "image_url": {
                "url": "data:image/png;base64," + encoded,
                "detail": "original",
            }},
        ],
    }],
)
print(result.choices[0].message.content)

這個範本只會印出回傳內容供人工檢視；它不強制機器可讀的結構描述，也不驗證結果。在接上自動化匯入之前，請自行加上這些步驟。API 請求會依你的帳戶與供應商目前定價產生用量費用。

指南也提到公開圖片 URL 與 Files API 參照等其他輸入方式。依工作負載選擇傳輸方式：本機範例圖適合直接內嵌傳送；同一張圖片若要重複使用，可能較適合檔案參照。在擴大規模之前，先確認目前文件記載的大小限制，因為 base64 編碼也會讓請求主體變大。

範例中使用文件記載的 original 細節設定。但這不保證逐像素讀取：指南另外描述了圖片預處理，其中 low 設定會降採樣到 512 × 512，所以密集的截圖在拿細節換效率之前，需要特別留意。

驗證擷取結果後再進行任何計算

把輸入圖與回應並排開啟，一次核對一筆回傳的列。比對文字、列的對應關係與單位。數量可能抄寫正確，卻掛到隔壁的產品上；單純的拼字檢查查不出這種錯。

從一小組樣本開始，其中包含一般列、缺值、被截斷的名稱，以及一個模稜兩可的字元。這些是建議的評估案例。保留你自己核實過的答案，並記下每一次失敗是源自輸入圖片、擷取過程，還是應用程式解讀回應的方式。

只有在確認個別數值無誤之後，才計算總計。如果圖片同時包含小計與總計，保留它們各自的標籤，而不是依位置挑選其中一個。把文字轉成數字時，明確處理單位與小數點慣例。逗號在不同的來源文件中可能代表不同意思。

需要可重複的處理流程時，在每一筆審核過的紀錄中保留輸入識別碼、區域名稱、提示詞版本、請求的模型與原始回應。日後要修正時，才不用猜測某個數值出自哪張截圖。

區分傳輸錯誤與讀取錯誤

如果請求失敗，先檢查身分驗證、輸入格式、訊息結構與目前的大小限制，再考慮修改擷取指令。在這個 Chat Completions 範例中，圖片應放在 user 訊息內，並使用 image_url 區塊。不要把 Responses API 的 input_image 結構套用進來。

如果請求成功但某個數值錯誤，請檢查裁切範圍與任務定義。改用保留標題、更清楚的區域再試一次。若某個欄位仍然無法辨讀，就維持未知並轉交人工審核。對同一張圖片反覆要求明確答案，可能只會得到另一種猜測，不會得到更好的證據。

若要遷移舊模型名稱的專案，請參考另一篇 DeepSeek API 遷移指南。本文的擷取流程假設使用文件記載的現行名稱，重點在於「驗收資料」而非僅僅「收到成功的回應」。只有在必要欄位都能與來源圖片核對無誤之後，才發布或匯入結果。