用 Opus 5.5 改落地页：设计更好，购买流程也要保住

把一个明确的落地页修改任务、访客看到的广告，以及必须保留的功能一起交给 Opus 5.5。先改移动端首屏，再检查真实购买路径。首屏更清爽，只有在用户仍能选对商品、到达正确页面时才有意义。

Cursor 的模型说明把前端与 UI 工作列为 Opus 5.5 的优势。这说明它值得尝试，不代表每个生成页面都会提高转化。以下是建议的需求与验收方法，不是转化率实测。

先选当前页面上一个具体问题

假设一则蓝色手机支架广告，讲的是在小餐桌上轻松摆好手机。点进去的页面却先播放大幅抽象动画，商品在首屏以下，默认还选中了另一种颜色。第一次修改应该让商品和广告承诺重新对上，而不是再加一种装饰效果。

保存当前页面，并记录哪些交互已经正常工作。需要改代码时，应提供实际源文件。截图能说明视觉层级，但看不到结账逻辑、库存状态和统计事件。

这张表就是修改约定。如果提供的项目里缺少某种行为，应让模型指出缺口，不要声称保留了它根本看不到的实现。

可直接使用的改版提示词

修改附件中的虚构蓝色手机支架落地页。访客来自一则强调“小餐桌也能轻松摆好手机”的广告。保留现有商品标识、规格选择、结账跳转地址和统计事件名称。
在 390 px 宽度下，让商品、一个已批准卖点和主要 CTA 容易找到。使用提供的商品图、克制的字体搭配和舒服的间距。如果首屏动画抢走商品注意力，就去掉它。不要编造评价、折扣、配送时效或商品功能。
编辑前列出涉及的文件和行为。只修改这个页面及直接相关的样式，保留缺货、加载和报错状态。交付补丁、移动端预览，以及实际执行的检查。如果无法查看浏览器或结账集成，说明哪些尚未验证。

附上广告与页面截图时，要分别说明用途：一张确定广告承诺，一张展示当前界面。否则模型可能把整张广告的构图搬进网页，忽略文字换行和触摸操作需要不同处理。

检查四种状态，而不是只看截图

先在 390 px 宽度、商品正常可售的状态下查看页面。读一遍标题，与广告比较：是不是同一个卖点？商品颜色是否对应当前选中的规格，而不只是装饰图用了蓝色？

接着试一条更长的本地化标题。按钮应保持可读，内容不能溢出屏幕。这个练习可以用“页面不横向滚动”作为验收要求；不同语言的具体布局仍可以调整。

然后模拟现有的缺货状态。购买按钮不能使用时，应有清楚解释。最后触发现有报错路径，确认重试不会丢失用户选项。这些问题往往在精美截图里看不出来。

统计检查使用现有事件流或开发调试工具。不要为了写一句“通过”而临时编造追踪实现。如果测试环境没有原集成，就记录缺口，并在上线前补验。

把反馈写成局部修改

不要只说“再高级一些”，可以说：“保留商品位置和字号层级，把 CTA 上方留白减少一个间距单位，保留已选蓝色规格和现有按钮处理逻辑。”对照保存的基线检查改动区域，再跑相关交互检查。

从空白需求开始搭页面，可看原来的 Astra 落地页流程。已有页面能工作时，用这里的修改约定。在 Panelly 创作台制作或修改相配的完整广告图，按需要把标题和 CTA 一起生成，再把批准的图片作为页面改版背景资料。这里并不把 Panelly 描述成网站搭建器，也不表示已接入 Opus 5.5。

常见问题

广告和落地页必须长得一样吗？

商品、承诺和优惠应保持一致。布局可以不同，因为静态图片和可交互移动页面承担不同任务。

上线后能马上判断成功吗？

功能是否正常可以马上检查。转化变化需要可比流量与足够观察时间，页面变好看本身不能证明转化提升。

资料与延伸阅读

• Cursor：Opus 5.5 模型说明