实用教程
Claude Opus 5.5 响应式图片检查：修复模糊的产品图
让 Claude Opus 5.5 先对照图片显示区域、候选文件和浏览器实际请求，再决定是否导出更大的产品图。首屏发糊可能是选错了资源，手机加载过重则可能是把显示区域写得过大。交给模型的应是测量记录，而不只是一张截图。
让 Claude Opus 5.5 先对照图片显示区域、候选文件和浏览器实际请求，再决定是否导出更大的产品图。首屏发糊可能是选错了资源，手机加载过重则可能是把显示区域写得过大。交给模型的应是测量记录，而不只是一张截图。
根据证据选择修复方式
| 现象 | 先检查什么 | 最小有效修改 |
|---|---|---|
| 原图清晰，网页发糊 | 显示宽度、DPR、实际请求文件 | 修正候选资源或显示区域声明 |
| 手机总下载最大文件 | `sizes`、CSS 布局、`currentSrc` | 让声明宽度与实际布局一致 |
| 产品被切掉 | 裁切和 `object-fit` | 修正构图或分屏裁切方案 |
| 文件选对了仍有破损感 | 原始像素和编码 | 从原稿重新导出 |
MDN 的响应式图片说明区分了分辨率切换与构图切换。`sizes` 用来描述显示区域，并不会设置 CSS 宽度。只有确实需要不同裁切时才使用 `picture`。杯把被裁掉的问题，不能靠提高 JPEG 质量解决。
算一遍资源宽度
假设杯子页面的视口宽 390 个 CSS 像素，两侧各留 24 像素。图片区域就是 390 − 48 = 342 个 CSS 像素。DPR 为 2 时，可先按 342 × 2 = 684 像素估算资源宽度。如果候选图为 480、800、1200 像素，800 是合理候选，但不能保证浏览器一定选它。这些是已计算的假设案例数值，不是 Opus 实测成绩。
如果代码写成 `sizes="100vw"`，这里声明的是 390，而不是 342 像素，比真实区域大约高出 14%。这不一定立即改变所选文件，但在候选资源的临界位置就可能产生影响。桌面端的半宽卡片，也不应因为移动端首屏占满宽度就沿用全视口声明。
记录视口、缩放、`devicePixelRatio`、元素矩形、`currentSrc`、响应图片尺寸和传输字节数。在网络面板检查实际请求，并记录缓存条件。调整窗口后，浏览器可能继续使用已缓存的大图，因此只拖动一次窗口不能证明规则有错。web.dev 指南解释了如何让浏览器选择合适的图片资源。
可直接使用的检查提示词
检查这张产品图的资源选择。输入包括 HTML 或组件代码、相关 CSS、候选文件名及其真实像素尺寸、视口和 DPR、图片显示矩形、currentSrc 与网络传输大小。缺失测量一律标为未知。
分别判断分辨率选择、构图裁切和压缩损伤。按提供的条件计算显示宽度 × DPR，再与实际请求文件比较。核对每个宽度描述符是否符合文件真实尺寸。说明各断点的 sizes 是否匹配 CSS 布局。不要仅凭代码保证浏览器会选中某个文件。
输出证据表、带不确定性的最可能原因、最小代码修改，以及窄屏和宽屏在 DPR 1、2 下的验收矩阵。保留产品构图、替代文字和现有组件接口。如果证据不足，指出下一项测量，不要重写整套图片系统。这份提示词采用了官方 Opus 指南中提供上下文、明确输出要求的思路。这里展示的是使用方法，没有宣称执行过模型测试。
验收用户真正收到的图片
在记录的宽度下重复查看同一商品，以正常观看尺寸检查细小边缘。同时核对请求文件、字节数和视觉效果。保留宽高属性或其他可靠的宽高比占位，避免图片加载时页面跳动。验收标准是构图正确、候选资源够用，同时没有强制每个屏幕都下载最大原图。
常见问题
**所有图片都要按显示宽度的两倍导出吗？** DPR 2 只是一个测试条件，不是通用导出规则。布局、候选尺寸间距和浏览器选择仍然有影响。
**加强压缩能修好错误的 `sizes` 吗？** 它可能减少字节数，却保留资源选择错误。应先修正显示区域的证据。
**截图能证明加载了哪个文件吗？** 不能。要同时查看 `currentSrc` 和网络响应；两个尺寸不同的文件，在小截图里可能几乎一样。
把确认过的素材交给广告制作
先把确认过的产品图与裁切版本整理好，再到 Panelly Studio制作广告变化。如果商品本身看起来不对，可参考产品图反射与透视检查。这里的 Panelly 用于创意制作交接，不表示它集成了 Opus。
