实用教程
Claude Opus 5.5 分享预览检查：修复产品链接缩略图
产品链接显示错误缩略图时，让 Claude Opus 5.5 对照初始 HTML、引用图片和分享平台实际显示的卡片。这是三份不同的证据。页面上的产品图改对了，不代表分享元信息也更新了；元信息正确，也不代表旧卡片已经刷新。
产品链接显示错误缩略图时，让 Claude Opus 5.5 对照初始 HTML、引用图片和分享平台实际显示的卡片。这是三份不同的证据。页面上的产品图改对了，不代表分享元信息也更新了；元信息正确，也不代表旧卡片已经刷新。
先定位哪一层不一致
| 证据 | 能确认什么 | 下一步 |
|---|---|---|
| 初始 HTML 的 `og:image` 错误 | 返回的元信息有误 | 修正该路由的元信息来源 |
| 图片地址正确，响应内容错误 | 引用的资源有误 | 修复素材或其版本化地址 |
| 两者都正确，单个平台仍旧 | 可能是使用方的特定问题 | 记录平台结果，使用其支持的检查方式 |
| 只有 JavaScript 更新后的页面正确 | 浏览器界面与初始响应不同 | 先查服务端输出，再改设计 |
Open Graph 协议将 `og:title`、`og:type`、`og:image`、`og:url` 定义为基本元信息，也说明了图片尺寸和替代文字。协议规定的是元信息，不是统一的缓存期限，也不保证所有平台都渲染相同卡片。
一个杯子颜色错位的假设案例
假设米白杯页面展示正确，但分享链接后出现蓝杯。先保存该精确网址的初始 HTML，并记录重定向。如果 `og:image` 仍指向蓝杯，问题就在元信息生成。如果它指向米白杯文件名，实际返回的却是蓝杯像素，则要检查素材。文件名不能证明图片内容正确。
再假设初始响应与图片都符合米白杯，只有某个以前分享的卡片仍是蓝色。记录观察时间和平台，暂时保留原因判断。一篇历史 Stack Overflow 提问自述不同平台预览表现不一致，但不能据此确定它们当前的缓存策略。不要承诺固定刷新时间，也不要为了追赶预览而随意改变页面身份。
整理一个小证据包：请求网址、最终网址、响应状态、初始元信息值、图片状态及内容类型、真实图片尺寸、带观察日期的平台截图。只使用公开产品资料。以上案例为虚构示范，不是 Opus 实测结果。
可直接使用的元信息检查提示词
检查这个产品链接的分享预览。输入包括精确公开网址、重定向链、初始 HTML 响应、提取的 Open Graph 标签、图片响应状态/内容类型/尺寸，以及分享平台的带日期截图。区分缺失证据和已确认故障。
比较各输入里的商品身份、标题、描述和图片。检查重复或冲突的元信息，区分服务端初始响应和 JavaScript 执行后插入的值。确认引用图片能否公开获取，是否确实描绘目标商品。不要仅凭我登录后的浏览器就推断抓取方也能访问。
输出证据表、按可能性排序的诊断和最小元信息或素材补丁。没有独立理由时保持规范页面身份稳定。如果只有分享平台仍显示旧内容，说明不确定性和它所支持的下一项检查，不要编造清缓存接口或期限。给出重新抓取与新分享的验收步骤，但不要声称已经执行。官方 Opus 指南强调提供上下文和明确输出目标。本文给出的是审查方法，不表示模型原生具备发布能力或能控制平台缓存。
沿最终响应核验商品身份
补丁部署后，重新获取公开页面，检查初始标签和图片响应。确认各产品路由对应正确商品，翻译页面也使用相应语言。随后在目标平台观察一次真实分享。服务端是否正确与卡片是否刷新要分开记录：前者可能通过，后者仍在等待。
常见问题
**浏览器标签页标题正确就够了吗？** 不够。可见标题不能证明分享平台收到的初始响应是什么。
**要给所有网址加随机参数吗？** 不应一概这样处理。保留页面身份，素材确实变化时再有计划地管理素材版本。
**Opus 能强制社交平台刷新吗？** 这套流程只让它诊断提供的证据。真正的检查或刷新取决于平台可用的工具与访问权限。
先确定图片，再分发链接
在 Panelly Studio制作确认过的产品视觉，并让它与元信息中的商品保持一致。涉及追踪参数和跳转目标时，请用独立的广告活动链接检查流程。这里没有声称 Panelly 集成 Opus 或会自动发布到社交平台。
