发布与合并：Publish 是合并不是替换
合并（Merge）vs 替换（Replace）
PolyAI 的发布系统最核心的设计决策是：Publish = 合并，不是替换。
| 方式 | 行为 | 风险 |
|---|---|---|
| 替换（Replace） | 把 Branch 的完整配置覆盖 Live 的配置 | 同事在你 Publish 之前已经发布的改动会被你覆盖掉 → 静默丢失 |
| 合并（Merge） | 把 Branch 相对于 Live 的差异增量叠加到 Live 上 | 不会静默丢失，真冲突才会弹出来让你选 |
举个例子：
- Live 当前状态：欢迎语 A、Flow X、Topic Y
- 同事 1 在自己的 Branch 上改了 Topic Y（改成 Topic Y1）→ Publish → Live 变成 A、X、Y1
- 同事 2 在自己的 Branch 上改了 Flow X（改成 Flow X1）→ Publish → Live 变成 A、X1、Y1（两个改动都在）
如果是替换模式，同事 2 会把同事 1 刚改的 Topic Y1 给覆盖回 Y——而且两个人都不知道，直到客户反馈"怎么改了又变回去了"。PolyAI 用合并彻底避免了这个问题。
冲突处理
如果两个人改了同一个配置项（比如都改了欢迎语），合并时 PolyAI 会检测到冲突：
- Live 当前的欢迎语是 A
- 同事 1 改成了 B 并 Publish → Live 变成 B
- 同事 2 同时也在改欢迎语，改成了 C，要 Publish
此时 PolyAI 不会静默选择 C 或 B——会弹出一个冲突对话框：
欢迎语有两个版本待合并
- Live 当前："您好，这里是 XX 语音助手"（来自同事 1）
- 你 Branch 上："您好，欢迎致电 XX，我是今天的语音助手"（来自同事 2）
请选择保留哪个版本，或者合并成新版本：____
你可以选其中一个、或者手动编辑成两者的组合。不会静默丢失任何改动。
发布的版本历史
每次 Publish 都会在 Live 的版本历史里留一个快照。在 Deployments 面板的 Live history 区域可以看到：
- 每次发布的时间和操作者
- 发布的完整 diff（和上一版本比，改了什么）
- 版本标签（可以手动加比如 "v1.2 - 退款 Flow 上线"）
- 一键 Roll back 按钮
这意味着：你可以精确回到任何一次发布的状态。
和 Roll back 的关系
因为发布是合并而不是替换，所以 Roll back 也很干净——回到某个历史版本就把 Live 恢复到那个版本的完整快照，后续再 Publish 的改动不会被意外覆盖。Roll back 后的状态本身会成为一个新的历史版本。
发布的三种典型场景
单人小改动
改话题 → Sandbox 测 → 直接 Publish → Live最简单，跳过 Staging，改完测完直接上生产。适合 FAQ 微调、语音参数优化这类低风险改动。
团队大改动
多人各自 Branch 改 → Sandbox 各自测 → 依次 Publish（合并到 Live）→ Staging 完整 UAT 验收 → 生产 Publish典型的 Branches 模式协作方式。每个人改自己的部分，互不阻塞，最后 Staging 里一起验收。
Sub-branches 大版本
主 Branch 下多个 Sub-branch 并行改 → 各自测 → 依次合并回主 Branch → 主 Branch Publish 到 Live适合一个大版本多个子任务一起上线。