一键回滚：出问题了怎么办
回滚是发布设计里的一等公民
PolyAI 从一开始就把"出问题能快速回滚"作为核心功能设计的——不是一个后来加的补丁。这和很多对话 AI 平台不同（那些平台根本没有版本管理，改坏了只能手动修）。
回滚操作步骤
- 打开 Deployments → Live history 面板
- 你会看到一个时间线，列出所有历史版本（每次 Publish = 一个版本）
- 找到问题发生之前的那个版本（可以看 diff 判断哪个版本引入了问题）
- 点击 Roll back 按钮
- 确认后，Live 立即恢复到那个版本的完整状态
整个过程不超过 30 秒——和 Publish 本身一样快。
回滚后发生了什么
回滚不是"撤销"或"回退"——它是把选中的历史版本作为新的 Live 版本推送一次。这意味着：
- Live 立即开始用这个历史版本处理客户对话
- 回滚本身也成为 Live history 里的一个新条目（标注为 Rollback）
- 后续任何 Publish 都是在回滚后的版本上合并，不会被之前的"坏版本"残留影响
举个例子：
Live history:
v1: 初始版本
v2: 同事 1 改的 Flow（OK）
v3: 同事 2 改的 Topic（引入 bug）
v4: 你 Roll back 到 v2 ← 回滚操作本身成为一个新版本
v5: 同事 1 发布的新改动（基于 v4 合并，不会被 v3 残留影响）这个设计保证了回滚的确定性——你永远知道 Live 在跑哪个版本。
什么时候该回滚 vs 手动修
| 情况 | 推荐 |
|---|---|
| 大范围出问题（比如 Flow 整体坏了、ASR 完全听不懂） | Roll back，快速恢复服务，事后再修 |
| 小范围问题（比如某个话题内容写错了、欢迎语有个错别字） | 直接在新 Branch 上修，测完 Publish |
| 不确定问题范围 | 先回滚到上一个确认 OK 的版本，再逐步排查 |
| 问题在 Staging 阶段就发现 | 不用回滚——Staging 里改了就行，还没到 Live |
判断标准：客户正在受影响 → 先回滚保服务，再慢修。
回滚的安全保障
因为 PolyAI 的发布是合并而不是替换，所以 Roll back 也不会被其他人的 Publish 静默破坏。即使你回滚后同事 3 又发布了自己的改动，这个发布是在你回滚后的版本上合并的——不会把那个有 bug 的版本偷偷带回来。
和 Git 的类比
PolyAI 的版本历史和回滚设计高度借鉴 Git：
| Git 概念 | PolyAI 对应 |
|---|---|
git commit | Publish 生成一个历史版本 |
git log | Live history 时间线 |
git diff | 每个版本的 diff 视图 |
git revert | Roll back（产生新的回滚提交 / 版本） |
git reset --hard | PolyAI 没有这个操作——故意不做，因为硬重置太危险 |
唯一的区别是：PolyAI 不让你做 git reset --hard 这种破坏性操作。回滚永远是安全的。