截图别急着塞进长对话：把图片先变成一份可复用的文字档案

一、图片是输入，不是长期记忆

图片擅长表达布局、颜色、图标、截图原文和相对位置，却不适合充当长期上下文。 一张普通截图可能包含几百到上千个视觉 token；如果任务还要连续调用工具， 同一张图就可能随着多轮模型请求反复进入上下文。

DeepSeek 的视觉文档说明，图片会按尺寸折算成 token，并与文字一起计费。 更重要的是，Responses API 采用无状态方式：客户端需要在每次请求里带上当前活动上下文。 这并不表示每次都会重新上传整个无限长的线程，但尚未被截断或压缩的图片， 确实可能继续留在后续请求中。

二、把“看图”拆成一次独立工作

我更喜欢把视觉能力放在任务入口，而不是让原图陪任务跑完全程。 收到图片后，先做一次独立分析，输出一份 Markdown 档案：

# 图片档案

## 一句话摘要
## 完整可见文字
## 布局与关键元素
## 可操作信息
## 不确定项

这份格式看起来朴素，却刚好覆盖了后续最常用的信息：图里写了什么、东西在哪里、 它们是什么关系、哪些结论可以确定、哪些地方可能看错。主任务拿到这几段文字， 通常就不再需要原图。

三、一张图只分析一次，用内容哈希做缓存

如果同一张图会在多个任务或多次追问中出现，就应该给图片内容计算 SHA-256。 清晰度、问题和图片内容一起决定缓存键：同一组合直接读取已有档案， 不再调用视觉模型。

哈希解决的是“是不是同一张图”，清晰度和问题解决的是“这次需要看到什么”。 普通界面先用低清晰度；只有小字、表格、代码或细节关系看不清时，才裁剪目标区域， 再提高清晰度。不要为了省一次判断，默认把整张图按最高精度处理。

四、文字档案比“模型记忆”更可靠

文字档案的另一个好处，是可检查。模型说错了哪一行 OCR、漏了哪个按钮、 把左右关系说反了，你都能直接改档案；下一次任务读到的就是修正后的版本。 如果所有信息都藏在图片和模型记忆里，错误很难被发现，也无法复用。

档案还可以带来源信息：图片哈希、分析时间、使用的清晰度、原始文件名和模型用量。 这些元数据不是正文的一部分，却能让后续排查变得简单。真正需要审计时， 可以回答“这份结论来自哪张图、什么时候生成、有没有第二次分析”。

五、先分辨：是读字，还是理解画面

纯文字截图不一定需要视觉大模型。系统 OCR、轻量 OCR 工具通常更快、更便宜， 也不会上传整张图片。只有当任务涉及版面关系、图表趋势、产品外观、界面状态或复杂标注时， 才更值得交给视觉模型。

六、隐私不是最后再检查，而是入口就分流

截图比纯文本更容易带出意外信息：通知栏、账号头像、文件名、聊天对象、订单号、 浏览器标签页，甚至背景里没被注意到的窗口。上传前先裁剪到必要区域， 往往比事后再要求模型“忽略这些内容”更有效。

含账号凭据、身份证件、客户资料或私人聊天的图片，应优先本地处理， 或者先遮掉无关区域再交给云端模型。文字档案同样是敏感数据， 不应因为“已经不是图片了”就当作可以公开的材料。

七、可以直接照做的三步

1. 裁图。只留下任务需要的区域，先去掉通知栏、侧边栏和个人信息。
2. 看一次。让视觉模型输出结构化档案；纯文字截图可先本地 OCR。
3. 只带文字。主任务读取档案并完成后续步骤；档案不足时，再针对缺口做一次局部高精度分析。

这套方法最重要的变化，不是省下某一轮调用，而是把图片从“长对话的乘客”变成 “一次入库的资料”。图片负责提供证据，文字档案负责被检索、修改和复用， 主任务则专心完成判断、写代码和执行操作。

结论：先归档，再办事

视觉模型很强，但长对话不是图片仓库。把每张图一次性转成可核对的文字档案， 既能减少重复 token，也能降低敏感信息在上下文中停留的时间， 还能让后续任务拿到一份稳定、可修改、可复用的证据。

下次准备把截图拖进一个会聊很久的任务时，可以先问一句： 我真正需要的是这张图，还是图里已经被整理出来的那几段文字和关系？

参考来源

• DeepSeek Vision：图片格式、清晰度与 token 规则
• DeepSeek Responses API：无状态请求与图片输入