Lovable Drafts：先试出不同方案，再决定哪一版上线

让想法变成可以实际比较的页面

Lovable 面向想把需求做成网页应用的人：通过与 AI 对话生成和修改页面，而不必先手写整套界面。它的 Drafts 是项目里的试验空间，适合创作者、设计师与负责文案的同事一起探索方案。

假设一个课程网站已经上线，团队想知道首页应该先讲课程成果，还是先展示课程目录。只在聊天里讨论这两种说法，很难看到真实的阅读顺序；直接反复修改同一页面，又容易让“正在试”与“已经决定”混在一起。草稿让两种方向分别拥有对话和预览，比较的对象于是从描述变成了页面。

以一个明确问题创建候选方向

假设课程网站已经上线，团队想试“先讲学习成果”和“先展示课程目录”两种首页。按Drafts 发布说明，从项目顶部名称进入 New draft，为一个方向建立独立对话和预览。描述修改时把要解决的问题写清楚，例如让新访客先理解学完能做什么，而不只要求“更好看”。

这里讨论发布说明覆盖的前端修改，如版式、文案、颜色与动效。初版数据库结构和登录设置的修改仍在项目主对话中处理，不能把草稿当作所有系统变更的隔离环境。

在各自预览中推进，再比较同一个任务

1. 发展一个方向：在草稿里修改与查看，让“成果优先”沿自己的逻辑展开。
2. 保留另一条路线：另建草稿尝试目录优先，不必为看另一版先覆盖当前方向。
3. 比较阅读结果：建议使用相同课程信息和屏幕宽度，检查首次来访者能否读懂适合谁、能学到什么。这是比较方法，不是产品替用户给出的转化评估。
4. 检查数据影响：草稿帮助说明各草稿共享后端。预览中的测试报名可能写入真实记录；删除草稿不会撤销这些写入。

页面没上线与数据没被改动是两种状态。边看边试的便利，应与具体操作会影响什么一起被理解。

先接受方案，再决定对外生效

满意后 Accept，把草稿接回项目；不采用的方向可以删除。接受后还可以检查手机阅读、链接与表单行为，再通过 Publish 让页面修改对访客生效。

这条流程有三个不同位置：试验中的草稿、已采用的项目、对外发布的页面。选中好方案不必立即上线，暂缓发布也不必丢掉选择成果。流程的最终产物是一版已经检查并决定对外使用的页面，而不是仅增加了几次 AI 生成。

把一个不断变化的答案，变成几个可以保留的选项

在课程首页的例子里，AI 做出第一版后，团队常常沿着它继续修改：标题不够有力就改标题，信息太多就删信息。几轮之后，人可能已经忘了最初还有另一条路线。独立草稿改变的不是生成质量，而是候选方案的保存方式。

每份草稿拥有自己的对话和预览，意味着“突出成果”可以继续讨论成果的呈现，“先讲目录”也能沿自己的逻辑展开，而不必把两套要求挤进同一段修改历史。读者可以在相同内容、相同屏幕条件下切换查看。由此带来的设计收益，是让选择依据更容易回到目标：新访客是否知道课程适合谁、学完能做什么。这里的比较方法是使用建议，不是产品自动完成的效果评估。

这也解释了为什么草稿不宜只叫“备份”。备份回答的是“坏了怎么回去”，候选方案回答的是“哪条路值得继续”。同样保存一个版本，界面给它的身份会改变人接下来的行为。草稿过多也会增加选择成本；能生成十版，不意味着有十个值得比较的方向。

接受与发布分开，让内容判断和上线时机各有一次决定

负责文案的人认为新首页更清楚，与负责人决定今天让所有访客看到新首页，是两件事。Accept 把选中的草稿接回项目，Publish 再让页面改动上线，这两次动作给出了不同的承诺。

仍以课程网站为例：团队可以先接受新的介绍方式，随后检查手机上是否读得完、按钮是否指向正确课程，再决定发布时间。设计者不必在“舍不得丢掉好方案”和“现在还不能对外发布”之间二选一。这个分离并不自动保证检查发生，但给检查留下了一个明确位置。

可迁移的启发是：AI 把生成变快之后，产品仍要把“试验中、已采用、已生效”表达清楚。让不同承诺对应不同状态与动作，用户才容易知道自己正在选择什么，以及下一次点击会影响谁。