GPT-6 Sol、Luna 看图曾出错？9月25日修复后这样复测

OpenAI 在 2026 年 9 月 25 日的更新中，修复了影响 GPT-6 Sol 和 GPT-6 Luna 图像理解的编码问题。之前在截图、文档图片或视觉自动化任务中遇到失败，值得用同一任务重新检查，再判断模型是否适用。官方 API 更新日志说明，这次修复涉及 API 和 Codex 的视觉任务，包括计算机操作。

这给了我们复核视觉评估的理由，但不证明所有编程问题都已解决。本文提供可重复执行的复测方法，不报告 Ofox 基准测试，也没有声称测出了修复前后的提升。

修复了什么，哪些结论还不能下

评估记录不能只写模型名。还要保存供应商路由、执行时间、图像预处理方式、提示词、推理设置和工具。如果网关转发前改动了图片，残留问题也可能出在图像转换环节。

如果要比较编程任务中的推理强度，可参考 Sol High 与 XHigh 推理强度指南，但不要把那个选择与本次视觉缺陷混为一谈。

准备一小组能核对答案的图片

从实际工作流中选图，只使用允许发送给供应商的材料，并事先移除隐私信息。保存原始文件，不要反复通过聊天软件转存截图。

这些是建议使用的样例，不是已经完成的测试。每类相关任务至少准备一张简单图片和一张困难图片。模糊或被裁切的材料应允许返回“无法辨认”，编造答案不能算提取成功。

运行前写好预期答案和容差。OCR 是否区分空格、标点？图表要求精确读数，还是允许依据坐标轴估算？导航只评价视觉判断，还是也评价之后的工具点击？这些标准都应先确定。

复测时不要同时改掉所有条件

1. 记录时间、精确模型 ID 和供应商端点；使用 Codex 时，还需客户端版本、所选模型、推理强度和相关工具设置。
2. 保持图片字节、图片顺序、问题和输出格式一致，保存每个输入文件的 SHA-256。
3. 比较不同模型时保持配置一致。某模型不支持某参数，应记录差异，不能悄悄删掉。
4. 如果输出波动会影响决策，每个样例运行不止一次。保留全部结果，包括失败和拒答。
5. 按事先确定的标准评分，耗时和供应商报告的用量单独记录，不与正确率混算。

没有真实保存的修复前结果，就不能称为前后提升。缺少旧记录时，把新表标为“修复后评估”，只比较实际获得的数据。凭记忆重写一个之前的错误答案，不构成基线。

可以用下面的 CSV 字段保存记录：

run_time_utc,provider,model,client_version,effort,image_sha256,case_id,expected,actual,correct,latency_ms,request_id

这只是建议的日志格式，不是供应商返回结构。不要把 API Key 或私有图片地址写进 CSV；原始响应另存，并限制访问人员。

修复后仍看错，先检查这些环节

更换供应商前，先打开真正发给 API 的文件，检查尺寸，确认小字没有在缩放中变得不可读。请求必须包含图片内容，不能仅在文本里写一个本地文件名。如果通过 URL 传图，要确认供应商无需你的浏览器登录状态也能取到图片。

再把“看懂”与“操作”分开：先让模型描述目标和可见状态，再让工具点击。描述正确但点击失败，与描述本身错误，是不同的问题。做信息提取时，也要检查应用有没有解析完整答案，是否丢掉了某个字段。

最后对照供应商支持的图片输入格式，检查实际发出的请求。纯文本请求成功，不证明图片请求路径正常。直连 OpenAI 时参考官方视觉指南；通过网关时还要遵循该网关的路由说明。

用结果决定是否继续采用这个配置

修复后评估应回答具体问题：这个配置是否满足你的截图或文档任务验收标准？读对一张清晰图表，不代表能可靠操作整个应用。

如果还要比较 API 成本，应保留实际用量和路由，不能按图片文件大小猜 token 数。Sol API 成本指南解释了为什么输入、输出和缓存应分开记录；本复测流程不假定任何新价格或折扣。