上线十分钟发现迁移有坑，回滚脚本却还没人写——我让AI补上了这道保险

一个几乎所有小团队都踩过的坑

去年我们团队一次发版，数据库迁移脚本执行到一半，应用层报错，服务不可用。更尴尬的是：迁移前没有准备回滚方案。三个人围着数据库手工恢复，折腾了一个多小时才恢复到可用状态。

事后复盘，问题不在于「没人想到要回滚」，而在于：

• 回滚脚本永远是「有空再写」的那件事。写迁移脚本是上线刚需，写回滚脚本不阻塞发版，所以总被跳过。
• 回滚比迁移更难写。迁移是「加字段、建表」，回滚是「删字段、迁数据、处理外键、考虑已写入的新数据」，逻辑上更绕。
• 人工评审很难发现回滚脚本里的坑。比如 DROP COLUMN 是否锁表、回滚是否会导致迁移期间写入的业务数据丢失、跨数据库方言的差异。这些靠肉眼review，效率低且容易漏。

作为管理者，我意识到这不是态度问题，是流程问题。而流程问题的解法，往往不是「加强要求」，而是把成本降到零——让写回滚方案这件事便宜到没有理由不做。

AI能在这里做什么

我们的做法是：把「回滚方案」变成发版流程中的一个AI辅助产出物，具体分四步：

第一步：迁移脚本评审。 开发提交迁移脚本后，先让AI做一轮静态审查——找出破坏性操作、可能锁表的大事务、方言兼容性问题。这一步能在写回滚方案之前就暴露风险。

第二步：生成回滚脚本初稿。 把迁移脚本和表结构上下文喂给AI，生成配对的回滚脚本，每个迁移语句对应一段回滚逻辑，并标注数据丢失风险。

第三步：人工确认关键决策点。 AI会明确列出「无法自动回滚」或「回滚会丢数据」的项，比如迁移期间新增的数据在回滚时如何处理。这些决策必须由人来定，AI只负责把问题清单完整地摆出来。

第四步：纳入发版检查清单。 回滚脚本存入仓库，与迁移脚本同目录、同编号。发版前检查清单里加一项：「回滚脚本是否已评审」。没有这一项，不允许执行迁移。

这个流程跑了一个季度，最直观的变化是：回滚方案的覆盖率从「看心情」变成了100%,而且评审时间从平均一小时降到十几分钟——因为AI初稿已经把格式和常见坑都对齐了，人只需要做决策。

可复制的提示词模板

这是我们团队内部用的模板，你可以直接改造：

你是一名资深DBA，帮我为以下数据库迁移脚本生成回滚方案。

## 背景
- 数据库类型与版本：[如 PostgreSQL 15 / MySQL 8.0]
- 迁移脚本：

[粘贴完整迁移SQL]

- 相关表结构（可选但建议提供）：

[粘贴相关表的DDL]

## 要求
1. 逐条为迁移语句生成对应的回滚语句，输出成对格式：
   [迁移语句] → [回滚语句]
2. 明确标注每一对操作的风险等级（安全/需确认/危险），并说明理由。
3. 特别检查以下问题并单独列出：
   - 哪些回滚操作会导致数据丢失？迁移期间写入的新数据如何处理？
   - 哪些操作在目标数据库版本上会长时间锁表？给出降低锁表影响的做法。
   - 是否存在无法用SQL直接回滚的操作（如已删除的列数据）？给出补救思路（备份表、延迟删除等）。
4. 生成一份执行顺序说明：如果迁移执行到第N步失败，应该回滚到哪一步。
5. 不要执行任何操作，只输出方案。方案末尾列出需要人工决策的问题清单。

## 输出格式
- 第一部分：迁移↔回滚对照表
- 第二部分：风险与锁表提示
- 第三部分：部分失败的回滚路径
- 第四部分：需人工确认的决策点清单

一个使用建议：务必提供表结构上下文。只给迁移SQL,AI对数据依赖关系的判断会差很多；把相关表的DDL一起贴进去，生成质量明显提升。

用AI前后的对比

需要说清楚的一点：AI并不能保证回滚脚本百分百正确。我们的定位是——AI负责完整性和初稿质量，人负责关键决策和最终确认。这个分工不是偷懒，恰恰是风险控制：AI把「该想到的都想全」，人把「该拍板的都拍掉」，漏项和误判的概率同时下降。

管理者视角的三点经验

1. 回滚方案要流程化，不要靠自觉。 AI把成本降下来之后，才有资格把它写进检查清单。成本高的流程要求，最后都会变成形式主义。
2. AI产出物必须纳入版本管理。 回滚脚本和迁移脚本同仓同目录，发版时可追溯。AI生成的东西不落库，等于没做。
3. 保留人工决策点。 涉及数据丢弃的回滚永远需要人签字。AI可以列清单，不能替你决定丢不丢数据。

写在最后

数据库迁移回滚这类工作，技术含量不低但重复度高，恰好是AI最擅长分担的部分。如果你所在的小团队也在为「回滚方案没人写」发愁，不妨先从上面那个模板试起——接入统一的模型API即可开始，注册入口：https://api.thistoken.ai/register

---

本文的示例只需一个 API Key 就能复现：在 https://api.thistoken.ai/register 注册即用。