限制每轮候选数量

一次生成几十张图看似提高选择空间，也会快速造成判断疲劳。方案差异不清、评审标准不稳时，更多候选只会延长挑选时间。^[1]

可以把探索拆成多轮：

1. 第一轮只生成三到五个方向；
2. 按预先标准选择一个或两个；
3. 记录保留和淘汰原因；
4. 第二轮只修改一个主要变量；
5. 满足交付标准后停止继续生成。

若团队无法说明两个候选的差异，先回到标准，不急着生成下一批。决定记录可以保存色调、构图、光线、材料、品牌、内容和实现风险，后续成为可复用的审美资产。^[1]

用决策矩阵选最终方向

评审候选时，可以把维度写成一张表，避免会议只讨论个人喜欢哪一张。

每项可以记录「通过、需修改、否决」，不必制造一个看似精确的总分。事实错误、侵权风险、无法完成主要任务和无法接管等问题，可以直接设为否决项，不让其他视觉优点抵消。

评审还要保存候选版本和修改原因。三个月后重新设计时，团队能够知道某个方向为何放弃，避免重复同一轮探索。

把参考图变成资产，而不是收藏夹

参考图只有在能够检索、解释和再次调用时，才会提升下一次工作。

一项视觉资产可以包含：

• 原图或合法预览；
• 来源和许可；
• 色调、构图、光影、材质和细节描述；
• 适合的产品、用户和场景；
• 不适合的情境；
• 可替换变量；
• 生成说明或实现参数；
• 成功与失败版本；
• 最终使用位置。

公开 Prompt 库可以帮助理解组织方式，项目仍应保留自己的判断记录。直接复制提示词得到的是一次输出，持续积累的资产是「观察—解释—生成—判断—修正—归档」的完整循环。^[1]

竞品截图也只能作为研究材料。可以分析其信息层级、模式和交互，不能复制商标、客户素材、独特插画和完整品牌表达。

从预览到生产之间还有一段工程

模板和 AI 输出通常先解决静态默认画面。生产页面还要处理：

• 真实路由和导航；
• 表单验证、提交、重试和成功；
• CMS 内容模型和编辑权限；
• 登录、支付、分析和第三方接口；
• 加载、空、错误和权限状态；
• SEO、分享图、重定向和站点地图；
• 性能、图片、字体和缓存；
• 键盘、语义、屏幕阅读器和 Locale；
• 日志、监控、备份和回滚。

生成代码可以作为原型或实现起点。进入现有仓库前，需要检查技术栈、依赖、组件边界、状态管理、安全、测试和维护方式。看起来稳定的预览，不会自动满足项目工程规范。

设计交付还要确认内容如何更新。由谁改价格、增加案例、翻译新页面、处理表单和撤下过期活动？没有编辑流程的页面，上线后很快会失真。

用阶段门控制返工

小团队不需要复杂的审批系统，也可以把交付分成几个明确阶段。每一阶段只解决一类不确定性。

方向确认

这一阶段确认用户、主要行动、内容顺序、品牌方向和平台。可以使用低保真结构、模板拆解和少量 AI 候选。尚未确认方向时，不急着完成所有页面和精细动效。

输出至少包括页面清单、核心文案、参考方向、禁用方向和平台决定。验收通过后，大幅改变目标用户或主要行动应当作为范围变化处理。

视觉系统确认

在一张代表性页面中完成字体、颜色、间距、组件和关键素材。评审真实文案、最长内容和主要状态，确认设计能够扩展到其他页面。

这一阶段通过以后，再批量制作次要页面和素材。这样可以避免整站完成后才发现品牌、对比或组件方向需要重做。

功能整合

把表单、CMS、支付、分析、Cookie、搜索或第三方服务接入真实环境。使用测试账号和测试数据走完整流程，记录成功、失败、超时和重复操作。

设计稿中的「提交成功」画面不能代替真实提交。外部服务返回的错误、延迟和权限问题，都需要进入页面状态。

发布候选

冻结本次发布范围，完成浏览器、设备、可访问性、本地化、性能、SEO、链接、权限和内容核验。所有已知问题写入清单，并区分发布前必须解决与可以后续处理。

接管验收

在最终所有者的账号、Workspace、仓库和域名中完成发布。接管方根据文档独立修改一段文案、替换一张图片、发布一次，并演练恢复上一版本。制作方只在旁观察和补充说明。

能够独立完成这组动作，才说明交接文件和权限真正可用。

选择 Framer 时先接受托管边界

Framer 适合快速设计、管理、发布和托管营销网站。页面可以使用组件、CMS、Locale、表单、响应式和平台提供的发布能力。若项目愿意长期在托管平台中维护，这条路径能够减少自建基础设施工作。

截至 2026 年 8 月，Framer 官方仍明确说明：已发布网站不能导出为可独立自托管的 HTML 文件或静态站点包。其预渲染、图片优化、字体子集、服务端渲染和缓存等能力依赖平台基础设施。^[2]

因此，决定使用 Framer 前要回答：

• 项目是否接受由 Framer 托管；
• 是否需要完整导出源码并自托管；
• 现有后端、认证和数据如何集成；
• 平台价格、用量和功能变化怎样影响运营；
• 故障或迁移时有哪些替代方案；
• 客户是否能获得项目、账单和域名控制。

需要完整源码、自有部署、复杂后端或严格基础设施控制的项目，可能更适合在代码仓库中实现。也可以用 Framer 做原型与视觉参考，再由工程团队重建，但这应在预算和范围中明确，不能把「Copy CSS」视为整站迁移。

接管要覆盖项目、账单和域名

平台项目可以转移，不代表交付已经自动完成。

Framer 2026 年 6 月的官方说明显示，项目可以移动到另一个 Workspace；移动时原有订阅会取消，未使用价值转为原 Workspace 的账户额度，目标 Workspace 若需要付费能力，需要重新启用订阅。权限和账单也可能变化。^[3]

这意味着交付前要实际演练：

1. 客户建立自己的账号和 Workspace；
2. 邀请方式与权限符合双方约定；
3. 项目移动或转移后能够打开和编辑；
4. 新 Workspace 的套餐和账单已配置；
5. 自定义域名、DNS、表单、分析和第三方服务仍正常；
6. 客户拥有必要凭据和恢复方式；
7. 原制作方保留或移除访问权限符合合同；
8. 页面在转移后重新完成发布检查。

不要共享个人账号密码来完成协作。为每位成员建立独立账号和适当权限，既便于撤销，也能保留操作归属。

为切换当天准备一份运行清单

网站从制作环境进入正式环境时，可以安排一个短暂但明确的切换窗口。清单至少覆盖：

• 旧站内容和配置已经备份；
• 新站最终 URL、Canonical、重定向和分享图正确；
• DNS 记录、证书和域名续费负责人明确；
• 表单收件人、Webhook 和自动回复使用正式配置；
• 分析、转化事件和隐私设置使用正式账号；
• CMS 编辑者和发布权限已经建立；
• 关键页面在未登录或隐私窗口中可访问；
• 移动端、搜索引擎抓取和站点地图完成抽查；
• 出现严重问题时知道怎样回退；
• 制作方和所有者知道切换后的联系窗口。

上线后的第一天和第一周还要检查表单送达、404、重定向、分析事件、性能和用户反馈。交付验收不应在 DNS 切换的瞬间结束。