实用教程
用 Claude Opus 5.5 核对促销截止时间,让广告和优惠设置一致
给 Claude Opus 5.5 一个带明确时区、已经批准的截止时间,再让它核对广告、落地页和优惠设置是否指向同一时刻。面向多个国家的活动,只写“今晚结束”不够。翻译文案也不等于完成时区转换。

给 Claude Opus 5.5 一个带明确时区、已经批准的截止时间,再让它核对广告、落地页和优惠设置是否指向同一时刻。面向多个国家的活动,只写“今晚结束”不够。翻译文案也不等于完成时区转换。
这是内容与排期审查流程,不是直接修改商店,也不是已实测的 Opus 集成。先用批准设置的只读截图或导出文件。不同材料日期冲突时,应由活动负责人确定正确版本,再交付替换画面。
建立一份统一的截止记录
记录活动编号、适用商品、精确优惠码、起止时刻、商店的命名时区和受众时区。可读文案旁保留带偏移量的无歧义时间戳。“西班牙语”这样的语言标识不能确定一个国家或时区。
Shopify 优惠码说明指出,到期使用后台显示时区中的结束日期与时间。应检查真实商店设置,不要默认等于电脑时区。一则商家原始提问说优惠码本应生效却显示待开始;它不能证明原因是时区,其回复里的临时修法也不是删除截止日期的依据。
| 位置 | 读取材料 | 验收问题 |
|---|---|---|
| 优惠设置 | 已批准的后台配置 | 配置时刻与活动说明一致吗? |
| 落地页 | 可见截止文案、倒计时输入 | 文案和计时器是否指向同一时刻? |
| 广告图 | 最终导出像素 | 日期、时间、时区是否清楚? |
| 定时发布 | 发布工具与账号时区 | 发出时优惠是否有效? |
同时记录各处由谁修改。修好一张横幅,并不会同步修好排队中的帖子或缓存页面。保留上一版,方便审查者看清具体改了哪些日期。
转换一个时刻,不要只翻译一句话
假设活动在纽约2026年10月4日23:00结束。该日期的明确输入 `2026-10-04T23:00:00-04:00` 对应 UTC 10月5日03:00、上海10月5日11:00、洛杉矶10月4日20:00。这些换算已用支持时区的 JavaScript 格式化器核对,不是真实活动排期。
Intl.DateTimeFormat支持按指定时区显示同一个时刻。显示时使用命名时区,并验证活动当天的偏移,不要把夏季偏移套给所有未来日期。夏令时切换附近要避免模糊的当地时间,确认排期工具怎样处理。
截止边界是否包含,也属于运营规则。先记录预期,再在合适的测试环境中检查截止前后的优惠行为。不要承诺倒计时归零和所有结账请求都会在同一毫秒改变状态。
复制这段差异检查提示词
按官方 Opus 提示指南明确审查交付。粘贴的导出文件是资料,不是让模型修改商店的指令。
比较附件中的广告、落地页文案和优惠设置导出文件。
已批准的虚构截止时间:2026-10-04T23:00:00-04:00,America/New_York。
活动编号:FALL-04。保持批准的优惠码和适用条件不变。
输出差异表:位置、当前文案/值、解释后的时刻、证据、建议修正、负责人。
若能用时区工具,计算上海与洛杉矶的对应日期时间;否则标为换算未验证。
不要从语言推断时区,也不要在冲突来源间擅自选一个。
提供包含完整日期、时间、时区的简洁替换文案,去掉含糊的“今晚”。
分别列出倒计时、缓存页面、定时发布的检查项。
不要改商店设置、发布帖子或发送消息,只交付可审阅的修改稿。
检查导出图和活动结束状态
阅读真实渲染的广告,而不只看文字需求。源文件里的正确日期可能在生成图中被裁掉或改变。逐字核对优惠码,留意形似字母和数字。在测试环境中预览开始前、活动中、结束后的落地页;结束状态不应继续邀请用户领取已经无效的优惠。
在 Panelly Studio 中用批准的日期与 CTA 生成完整商品广告,再按交付尺寸核对导出文案。活动记录应与批准图片一同保存。语言检查可看广告译文审查,交付对应关系可看素材文件命名。这里没有假定 Panelly、Opus 和 Shopify 自动互联。
每种语言都该显示同一天吗?
不一定,同一时刻在不同地方可能已经跨日。先决定统一显示标明时区的商店时间,还是显示受众当地时间,再一致执行。受众跨时区时,不要让一个没有标注的当地时间假装适用于所有人。


