回滚脚本没写就敢点“执行迁移”？聊聊我用AI补齐这块短板的正确姿势
一、先说三个我亲眼见过的失败现场
做后端的人大概都经历过数据库迁移的“信仰时刻”：脚本跑完了，绿灯亮了，你心里默念“应该没问题吧”。然后某个索引建错了、某列数据丢了，你发现——没有回滚方案。
失败现场一：口头回滚。 “出问题就把表改回来呗。”结果迁移里夹了三条 DDL、两条数据更新，谁也说不清“改回来”具体指什么。凌晨两点对着生产库手动敲 SQL,手抖是常态。
失败现场二：AI一把梭。 后来大家学会了让AI写迁移脚本，提示词就一句“帮我写个加字段的迁移”。AI给出的正向脚本往往不错，但回滚部分要么是一句 -- 回滚:撤销上述操作 的注释，要么干脆没有。更糟的是，AI生成的 DROP COLUMN 看起来干净利落，可它不知道这一列在PostgreSQL里会连带锁表、不知道MySQL某些DDL是不可逆的物理操作。
失败现场三：回滚脚本写了但没验证。 有人确实让AI生成了回滚脚本，贴在文档里就完事了。真出事那天执行，发现回滚脚本引用的列名和正向迁移对不上，因为正向脚本后来改过，回滚脚本没人同步更新。
这三个现场指向同一个问题：AI写迁移脚本的能力被高估了，AI帮你建立“迁移-回滚”成对思维的潜力被低估了。
二、AI在回滚方案这件事上，到底能帮你做什么
先纠正一个认知：AI的价值不是“替你写回滚SQL”,而是在整个迁移生命周期里承担几个具体角色：
- 可逆性审查员：你给它正向迁移，让它先逐条判断哪些操作可逆、哪些不可逆、哪些有条件可逆，再决定回滚策略。
- 成对脚本生成器：一次性生成正向+回滚两份脚本，并保证两者的版本号、命名、对象引用严格对齐。
- 风险标注器：标出锁表风险、锁等待超时、大数据量更新可能触发的复制延迟，以及回滚时长的预估逻辑。
- 演练用例作者：为回滚脚本生成一套测试步骤——在影子库上先跑正向、再跑回滚、再做数据一致性校验。
三、我的AI使用流程(四步)
第一步：喂上下文，不喂任务。 把当前表结构(脱敏后)、迁移工具(如Flyway/Alembic/自定义脚本)、数据库版本、数据量级一起给AI。这一步决定了后面所有输出质量的下限。
第二步：先让AI做审查，再让它写。 让AI先输出“可逆性分析报告”，人工确认哪些操作接受不可逆、哪些必须可逆。这一步把决策权留在人手里。
第三步：成对生成，互相校验。 让AI同时产出up和down脚本，并额外要求它写一段“回滚校验清单”——回滚后哪些表、哪些列、哪些行数应该恢复原状。
第四步：让AI生成演练SQL。 包括影子库建表、正向执行、模拟故障、回滚执行、一致性比对的完整流程，可以直接在预发环境跑通。
四、可直接复制的提示词模板
你是一位资深数据库工程师,请针对以下数据库迁移需求,完成回滚方案设计。
【环境信息】
- 数据库类型与版本:如 PostgreSQL 15 / MySQL 8.0
- 迁移工具:如 Flyway / Alembic / 原生SQL脚本
- 涉及表的数据量级:如 orders 表约 800 万行
- 当前表结构(脱敏后):
<粘贴DDL>
【迁移需求】
<描述变更,如:新增 settle_status 列,并将历史数据按规则回填>
【请按以下顺序输出】
1. 可逆性分析:逐条列出每个操作是否可逆、锁表风险、
预计影响时长;不可逆操作请明确指出并给出替代建议
(如先备份再变更)
2. 正向迁移脚本:带版本号,大表变更请给出分批策略
3. 回滚脚本:与正向脚本版本号对齐,处理数据回填的逆操作
4. 回滚校验清单:回滚后应核对的具体SQL与预期结果
5. 演练步骤:在影子库验证"正向→回滚"完整流程的命令序列
【约束】
- 不要输出"撤销上述操作"这类无实现细节的注释
- 回滚脚本必须可独立执行,不依赖正向脚本中的变量五、用AI前后的对比
| 维度 | 之前(只让AI写正向脚本) | 之后(成对生成+审查) |
|---|---|---|
| 回滚脚本 | 注释一句或缺失 | 与正向成对、版本对齐 |
| 可逆性判断 | 靠人肉回忆DDL特性 | AI逐条标注，人做决策 |
| 回滚可信度 | 从未验证过 | 影子库演练，有校验清单 |
| 出事恢复时间 | 小时级，手工拼SQL | 分钟级，按清单执行 |
| 心理状态 | 上线靠信仰 | 上线带安全网 |
时间账也很直观：以前补写回滚方案平均要花半个工作日还心虚；现在按这套流程走，提示词填好上下文，一次生成加人工审查大约半小时，且产出物可沉淀为团队模板反复复用。
六、几点提醒
- AI对特定数据库版本的DDL行为可能记混，可逆性分析一定要人工复核，尤其是
DROP、TRUNCATE、列类型收窄这类操作。 - 大表回滚往往比正向更慢，分批策略在回滚侧同样需要。
- 回滚脚本要纳入和正向脚本相同的代码评审流程，它也是“会上生产的代码”。
- 用AI网关或API调用时，模型档位选择和费用以官网价格页为准，建议审查类任务用强模型、批量生成演练SQL可用轻量档位。
数据库迁移这件事，正向脚本是功能，回滚脚本才是底气。与其在事故当晚临时抱AI佛脚，不如现在就把这套流程沉淀下来。
如果你想开始实践，可以先注册一个AI网关账号，把上面的提示词模板跑起来：https://api.thistoken.ai/register
---
不想折腾多家供应商的接入差异？在 https://api.thistoken.ai/register 注册，用一个 base_url 调用所有模型。