AI API 识别图片时方向错了或内容不全，怎样检查 EXIF、尺寸和传输格式？
手机上看着正常的照片，交给 AI 模型接口后却变成横着的表单、被压缩到看不清的小字，问题往往发生在模型之前的图片处理链路。
适用场景：浏览器预览正常，模型看到的却不是同一张图
适合合同拍照、发票抽取、商品图片审核、客服截图归类和 AI 自动化办公中的资料识别。它与文件上传预检不同：文件上传预检关注格式、大小和权限，本篇专门处理图片进入多模态模型之前的方向、像素、裁切和编码一致性。
常见表现包括：竖拍表格被当成横图，底部金额或签名总是漏掉，前端压缩后模型无法读到字号很小的文字，PNG 在开发环境正常而线上代理后变成错误 MIME。若请求经过 CCSwitch 配置、后端网关或对象存储，还会多出下载重定向、URL 过期和内容类型被覆盖等节点。
先建立一张图片证据卡
每次排查不要只保存文件名。对一个可复现样本，记录原始文件大小、像素宽高、EXIF Orientation、MIME、哈希、前端展示方向、发送方式和服务端接收后的哈希。哈希相同才说明服务端拿到的是同一份字节；若服务端重新压缩或转码，必须记录转换后的尺寸与格式。
这张卡不需要保存包含客户信息的图片原文。可使用已脱敏的表单样本，或只保存文件指纹、尺寸和裁切坐标。对于开发者 AI 调用，日志中只应保留 request_id、模型名、图像处理版本和失败分类，避免把完整图片 base64 写到长期日志里。
操作步骤：按图像生命周期检查
- 从原始文件开始检查。用图像工具或库读取像素尺寸和 EXIF Orientation，确认浏览器是否仅在显示层自动旋转。
- 在前端压缩、裁切、canvas 导出后再次读取宽高和 MIME。若代码把 JPEG 统一导成 PNG，或把长边限制得太小，需明确记录而非默认发生。
- 给上传请求加 request_id，并在服务端计算接收文件的哈希、大小和内容类型。不要只相信请求头中的
Content-Type。 - 若使用 URL 方式传图，服务端应记录最终下载响应的状态、Content-Type 和字节数，确认没有拿到 HTML 错误页、缩略图或过期占位图。
- 用固定提示词对原图、规范化后的图和压缩图分别跑一次，比较方向、关键字段和遗漏区域。模型参数保持一致，才能判断问题来自输入还是推理。
- 为需要 OCR 的场景定义最小文字高度、允许的裁切边距和最大压缩比。低于阈值时返回“需要重拍或人工处理”，不让模型编造看不清的字段。
失败表现：为什么只靠改提示词没有用
当模型稳定漏掉照片底部信息时，提示“请仔细阅读”通常无法恢复已经被裁掉或缩小的像素。先看服务端的最终宽高，再看是否有 EXIF 未处理。若同一张图有时正常有时横置，重点检查前端选择文件和 canvas 导出的两个路径是否一致。
当模型收到的 URL 返回 200 但仍识别为空，要检查 200 内容是否真是图片。许多存储服务会在权限不足或链接过期时返回 HTML 页面；只看 HTTP 状态会误判为模型能力问题。这个分层方法也可参考接口 200 但业务未完成的诊断。
常见问题 / 避坑
不要把所有图片都无差别压缩到同一尺寸。商品审核可接受较小图，票据和表格却需要保留细小文字。不要以浏览器预览为唯一依据，浏览器可能自动应用 EXIF 方向而服务端库没有。不要让业务端把 image/jpeg 当成真实性保证，文件内容需要实际解析。
使用 Codex 接入协助排错时，可让它生成脱敏样本表、核对处理函数和整理 request_id，但不要让它读取真实客户图库。AI 模型接口接入和模型调用管理的目标是让每一张进入模型的图片可解释，不是把所有图像都保存下来。
检查清单
- 原图和服务端最终文件都记录了哈希、MIME、字节数、像素宽高与方向。
- 前端压缩、裁切、旋转和 URL 下载路径均有固定样本。
- 模型测试使用相同提示词、相同模型版本和相同参数。
- 小字、边缘、竖拍、透明 PNG、错误 URL 和过期 URL 都覆盖了失败样本。
- 日志不包含完整图片、base64 或敏感字段，只保留必要的关联信息。
- 已结合文件输入隐私检查、响应编码排错、AI API 专题和AI 自动化办公专题复核流程。
验收标准
选择至少六类脱敏样本：竖拍表格、横向截图、小字号票据、透明 PNG、经压缩图片和无效 URL。验收时既看模型是否提取到关键区域，也看系统是否能准确拒绝无法读取的输入。只有图像证据、传输记录和业务结果能对应起来，图片理解才能成为稳定的开发者 AI 调用环节。