Lovable Drafts：先试出不同方案，再决定哪一版上线
Lovable 是通过对话创建网页应用的工具。Drafts 让创作者和协作者在独立预览中尝试页面、文案与布局，再把选中的方案接回项目并发布。
先给出你的方案与理由，再展开思路，检查是否遗漏了重要的取舍与验证。这些问题没有唯一答案。
怎样让团队围绕同一个目标比较草稿？
练习场景
一个团队正在用 AI 建站工具制作课程首页，同时尝试“先讲学习成果”“先展示课程目录”“先介绍讲师”三个方向。每个方向都在独立草稿里修改。你要设计一个帮助团队选方案的入口，让比较围绕首次来访者的需要，同时识别各草稿是否还使用相同的课程信息。
已知条件与要求
为一个 AI 建站工具设计草稿比较入口。
- 团队同时保留三种首页方向，各有独立对话；一名成员刚修改了项目主版本。
- 使用者要回答“哪一版更适合第一次来的访客”，而不只是选自己喜欢的颜色。
- 你最多增加一个比较视图，不能要求用户先学习 Git。
- 说明视图应展示什么、怎样避免比较不同内容基线、怎样保留选择理由。不要假设系统能自动判断转化效果。
用这个情境检查你的方案
主项目把课程从 6 节改为 8 节，但草稿 A、B 还写 6 节，C 已改成 8 节。请展示比较视图如何让用户发现这个差异，再继续讨论页面组织，而不是把内容更新误当成设计方向的优劣。
需要交付什么
交付比较视图草图、一次从进入到记录选择的流程，以及一项让用户解释“为什么选这版、哪些条件还未验证”的任务。无需制作三张精美页面，也不需要编造转化率。
查看思路
- 先定义比较单位。 页面方向、文案内容和屏幕宽度要分开；如果候选使用了不同课程信息，视觉比较可能掩盖内容差异。可显示来源版本和差异提示，但是否强制更新要考虑等待成本。
- 让问题进入视图。 提供目标或检查项的位置，例如“访客能否说出适合谁”，比默认展示全部像素差异更接近决策。检查项由人确认，不能把模型评分当实验结果。
- 保存选择理由与被放弃的方向。 理由可以很短；记录它是为了日后理解决定，不应让试验变成填表工作。比较一次性选择与需要团队批准两种场景。
- 用任务观察验证。 给参与者三版内容不完全一致的页面，观察是否发现基线变化、能否解释选择；再测试窄屏和返回编辑后的状态。实验需真正执行后才能报告效果。
怎样解释未发布草稿中的共享数据？
练习场景
你为课程报名应用设计草稿预览。页面文案尚未向公众发布，但预览连接的是与正式应用共用的报名记录：浏览只是读取，提交测试报名会新增真实记录，删除会改变真实记录。你要让非技术用户理解“页面没上线”和“数据没有影响”是两件事，并在适当时刻说明影响。
已知条件与要求
草稿的页面改动尚未发布，但它使用真实应用数据。设计一个能让非技术用户理解这个边界的方案。
- 用户会浏览列表、填写测试报名、删除一条记录，三类动作的影响不同。
- 不允许把每次点击都变成确认弹窗，也不能声称删除草稿可恢复数据。
- 给出状态提示的放置位置、需要确认的时机，以及操作完成后的反馈。
- 说明怎样判断用户理解的是“共享数据”，而不是误以为整个草稿都已经上线。
用这个情境检查你的方案
用户在草稿中新增“测试学员”，随后删除整个页面草稿，以为测试记录也会消失。请设计操作前后的信息，让他能预测真实记录会怎样，而不需要先懂数据库术语。
需要交付什么
交付三类操作的提醒位置与强度表、一次写入或删除的完整反馈路径，以及“删除草稿后什么还在”的理解检查。真实恢复方式未提供时，不要虚构撤销按钮或回滚能力。
查看思路
- 区分页面版本与数据对象。 常驻提示可以说明当前处于草稿，但共享数据应另有可理解的名称和范围，避免一个“测试”标签包办两层含义。
- 按影响选择提醒。 只读浏览适合低干扰提示；删除或批量写入更需要动作附近的具体影响说明。用户点了确认，也不代表误操作后的恢复问题已经解决。
- 让反馈指向真实结果。 写入后说明记录去哪了；若需要恢复，指出实际恢复方式或明确无法由删除草稿撤销。
- 用预测而非复述检查理解。 在点击前询问哪一处会改变，再让用户解释删除草稿后记录是否还在。观察误解发生在哪一步，再调整用词和位置。