实用教程
用 Claude Opus 5.5 检查被 Gmail 截断的商品邮件
先让 Claude Opus 5.5 对比编写时的邮件 HTML 与实际收到的邮件，再决定删哪些商品内容。图片文件很小，不代表邮件正文也小：重复代码和改写后的追踪链接都会增加 HTML 大小。找出哪个环节增加了字节，再清理可省略的代码，同时保留优惠、链接目标和退订控件。
先让 Claude Opus 5.5 对比编写时的邮件 HTML 与实际收到的邮件，再决定删哪些商品内容。图片文件很小，不代表邮件正文也小：重复代码和改写后的追踪链接都会增加 HTML 大小。找出哪个环节增加了字节，再清理可省略的代码，同时保留优惠、链接目标和退订控件。
测量正确的文件
| 对象 | 能回答什么 | 不能证明什么 |
|---|---|---|
| 本地 HTML 文件 | 发送处理前的大小 | 实际投递后的大小 |
| 个性化与链接改写后的 HTML | 发送流程增加了多少内容 | 所有 Gmail 客户端的显示结果 |
| 收到的邮件及可见页脚 | 测试收件箱实际收到什么 | 每位收件人的投递情况 |
Mailchimp 将 Gmail 截断边界说明为约 102 KB。这是一条实用参考，不应把最后一个字节都用满。该说明也区分了邮件代码与外部加载图片的大小。记录明确的字节数，避免字符数和 KB 标签掩盖测量对象。
给发送处理预留字节空间
假设一封商品简报在链接改写前有 86,000 字节 HTML。100 个链接，每个增长 180 字节，估计得到 104,000 字节。删掉 14,000 字节的未使用区块后，估计降至 90,000 字节。这些加减运算已在本地计算；它不是实际发送结果，也不是普遍安全线。
真正需要测的是邮件平台处理后的最终 HTML。UTF-8 字节数可能大于可见字符数，多语言文字尤其如此。导出的邮件或 MIME 消息还可能包含传输编码与头部，因此必须说明测了哪一部分，不能把不同文件大小直接对比。新测试使用新主题，避免混入旧会话；同时检查收到的源码和屏幕上的结果。
把两个版本交给 Opus
检查这两份商品邮件 HTML：编写版本 A 和实际收到的 HTML 部分 B。有工具时计算 UTF-8 字节数，否则提供命令，不要编造测量值。定位重复区块、多余注释、重复样式及改写后的 URL。以下只是假设预算：初始 86,000 字节，100 个链接各增加 180 字节后是 104,000；删去 14,000 后是 90,000。保留优惠、必要商品信息、无障碍图片描述、有效链接目标、退订入口和必要页脚。按实际节省字节与显示风险排列修改建议。输出修改前后清单，以及使用新主题的 Gmail 测试方案。不要声称缩小外部图片就能保证 HTML 不截断；没有实际发送就不要说已发送。这个有限范围的请求参考官方 Opus 指南。本文没有执行模型或邮件投递测试。2016 年的社区问题记录过大小测量不一致的情况；它说明需要统一测量对象，不代表当今 Gmail 的保证。
减少字节，但保留读者做决定的信息
先处理重复或未使用的区块。删除邮件兼容代码前应复查显示：看似冗余的结构可能服务于特定客户端。保留价格、商品差异和购买所需操作；必要时把可选细节移到链接指向的商品页，但邮件自身仍应有用。不要为了大小预算删掉必要的页脚控件。
检查桌面和手机 Gmail 中的最终 CTA 与页脚，也检查受众使用的其他客户端。链接改写后重新核对所有目标，各语言版本分别验收。正文截断与预览文字问题是两回事。可以在 Panelly Studio 制作广告图，再放入邮件系统；本文不声称 Panelly 能发送邮件或集成 Opus。
实际操作中的问题
压缩主图能解决截断吗？
它可能改善图片加载，但远程图片的文件大小不等于邮件 HTML 大小。先测正文。
90,000 字节一定安全吗？
不是。这只是本例的规划数值。个性化、链接改写和客户端行为仍需通过实际收到的邮件验证。
可以把所有样式和注释都压缩掉吗？
保留可读源码，用可撤回的候选版本测试。兼容性结构应保留到确认目标客户端不再需要它们为止。
