Supabase：先在分支里试改，再决定怎样带回线上
Supabase为应用提供Postgres数据库、数据接口及配套后端服务。分支让团队在独立环境中尝试结构变化，检查测试结果与迁移差异，再决定是否合并到正式项目。
先给出你的方案与理由，再展开思路，检查是否遗漏了重要的取舍与验证。这些问题没有唯一答案。
01
产品思考中阶
合并结构前，确认页应该让人看懂什么？
练习场景
为自己的数据库管理工具设计“将预览结构合并到生产”的确认页。摄影工作室需要给预约增加拍摄时长。练习是自拟产品方案，不要求复刻 Supabase，也不要求实际执行 SQL。
已知条件
- 预览分支从生产结构版本 V1 建立，只包含结构和人工测试记录，没有真实客户预约。结构差异不是两边数据记录的合并。
- 预览里增加 duration_minutes 必填整数列，并删除旧 notes 列。生产有 800 条历史预约；目前没有提供时长补值方案，也没有确认 notes 是否仍被客服使用。
- 页面生成差异后，另一位同事把生产升级为 V2，新增了预约时间约束。此时原先基于 V1 的差异与确认已经过期。
- 系统能够提供当前生产版本、预览版本、差异清单与检查记录。页面只负责让人理解风险并确认正确版本，不需要设计跨数据库事务或承诺自动撤销已执行变更。
交付物与推演
画出首次审阅、生产版本变化后、补齐检查后三个状态。明确指出哪两项业务问题还没有答案，哪些动作应暂不可提交，以及怎样向用户说明重新生成差异的原因。用两项观察任务检验用户是否把“测试库能保存”误认为“800条历史记录能迁移”；不预设真实测试结果。
查看思路
- 把目标与版本放在决策前。 清楚展示预览来源 V1、当前生产 V2 和实际合并目标；把结构变化与数据记录分开，避免误以为测试记录会补齐生产。
- 把操作翻译成业务问题。 必填时长需要历史记录补值与旧客户端兼容检查；删除 notes 需要确认客服用途与保留方式。不能只显示两行绿色差异和一个总勾选框。
- 让过期确认失效。 生产变化后保留旧预览供对照，但要求重新生成差异、处理冲突并检查。新版差异不能沿用旧版授权；这是一条设计要求，不假设产品已实现某种后端协议。
- 让证据对应到每项变更。 展示样例来源、旧记录测试、依赖检查及未完成项。没有答案时明确待处理，不用“预览成功”概括整个迁移。
- 观察是否理解后果。 给用户空库测试通过和生产已变的两个场景，让他说明下一步与依据。重点看是否识别补值、删列依赖和确认版本，而不是点击次数。