很多人第一次让 AI 编程工具改数据库，容易把重点放在“把字段加上去”。真正容易出问题的地方却在后半段：旧数据怎么兼容、迁移脚本能不能重复执行、线上失败后怎么回滚、接口和报表有没有一起改。数据库迁移不是普通代码修改，它同时影响数据、业务流程和上线窗口。
如果你已经在用 Codex、Claude Code 或 Cursor，可以把这类任务拆成一套固定流程：先让 AI 读懂业务意图，再生成迁移方案，最后用测试、审查和回滚清单兜住风险。更多 AI 编程工具选型和工作流，可以先看AI编程工具专题，项目交付和复盘方法也可以参考老达AI实践专题。
先把数据库迁移说成业务问题
不要一上来就写“给 users 表加一个字段”。更好的任务说明应该包含四件事：
- 为什么要改：例如要支持企业客户、分账、审批状态或多门店。
- 影响哪些对象：表、接口、后台页面、定时任务、报表、导出文件。
- 历史数据怎么处理：默认值、补齐规则、无法判断的数据如何标记。
- 上线边界是什么：是否允许停机、是否要灰度、是否需要双写过渡。
可以给 AI 这样的指令：
请先阅读当前项目的数据模型、接口和测试，不要直接修改。目标是为订单增加“结算状态”和“结算时间”，需要兼容历史订单。请输出受影响文件、迁移方案、风险点和需要我确认的问题。
这一步和普通需求拆解很像，但数据库迁移要额外要求 AI 找“读写入口”和“历史数据”。如果你还没有固定任务说明模板，可以回看AI编程任务说明怎么写，把里面的范围、验收和约束字段复用过来。
让 AI 先做 schema diff，而不是直接写迁移
数据库迁移至少要有两个视角：当前结构是什么，目标结构是什么。让 AI 先输出 schema diff，可以避免它只改 ORM 模型，却漏掉索引、唯一约束、默认值和关联查询。
一个靠谱的 diff 应该回答：
- 新增、删除、重命名了哪些字段或表。
- 字段是否允许为空，默认值是什么。
- 是否需要索引、唯一约束或外键。
- 历史数据是否需要 backfill。
- 旧代码和新代码是否能短时间共存。
如果 AI 建议直接删除字段，要特别谨慎。生产系统更常见的做法是先新增字段并兼容写入，再迁移读逻辑，最后确认没有引用后再删除旧字段。这个节奏比“一次性改完”慢，但可回滚性更好。
迁移脚本要检查三类安全性
AI 生成迁移脚本后，不要只看语法能不能跑。至少检查三类安全性。
第一是可重复执行。脚本失败后可能会重跑，如果没有判断字段是否存在、数据是否已经补齐，很容易二次执行出错。第二是数据量风险。一个简单的 update 在小库没问题，在大表上可能锁表。第三是回滚路径。新增字段通常容易回滚，删除字段、拆表和改类型就要提前备份或分阶段上线。
你可以要求 AI 同时给出三份内容：
- 迁移脚本：只做结构和必要数据变更。
- 验证 SQL：检查字段、索引、空值比例和异常数据。
- 回滚说明：说明哪些步骤可回滚，哪些步骤只能前滚修复。
这时 AI 适合当“第二双眼睛”。它能补清单、找遗漏，但不要让它绕过人工确认直接连生产库。安全审查的思路可以参考AI编程安全审查怎么做。
测试数据要覆盖旧数据和脏数据
数据库迁移最怕只测“新建一条正常数据”。实际验收至少覆盖四组数据：
- 迁移前已经存在的老数据。
- 迁移后新创建的数据。
- 字段为空、格式不一致、关联对象缺失的脏数据。
- 边界数据，例如最大金额、最长文本、重复编号和已关闭订单。
让 AI 帮你补测试时，可以明确要求：“请根据迁移方案生成测试用例，覆盖旧数据、脏数据、重复执行和回滚后的状态。”这比让它泛泛地“写几个测试”有效得多。
如果项目已经有自动化测试，让 AI 修改测试前先跑现有测试，再添加迁移相关测试。测试失败时，不要马上让它继续改代码，先要求它解释失败原因、影响范围和最小修复方案。这个习惯可以和AI编程测试自动化怎么做里的回归流程连起来。
上线前做一张迁移检查表
真正上线前，建议把 AI 的输出收敛成一张人工能读的检查表：
- 迁移目标：本次到底改变什么，不改变什么。
- 执行顺序：先部署代码还是先跑迁移，是否需要维护窗口。
- 影响范围：接口、页面、定时任务、报表、导出是否同步检查。
- 验证方式：跑哪些 SQL，看哪些日志，检查哪些页面。
- 回滚方案：失败时停在哪一步，谁来决定是否回滚。
如果你在用 Git 分支或工作树并行处理多个任务，还要保证迁移脚本和业务代码在同一个变更里评审，不要一个分支改模型，另一个分支改接口，最后上线时拼不起来。相关版本控制习惯可以参考AI编程版本管理怎么做。
一套可直接复用的提示词
下面这段可以直接放进 Codex、Claude Code 或 Cursor：
请作为谨慎的数据库迁移审查助手。先阅读项目的数据模型、迁移目录、相关接口和测试，不要直接修改。我的目标是：[写清业务目标]。请先输出：1. 受影响表和字段；2. 当前结构与目标结构 diff；3. 需要确认的问题；4. 推荐的分阶段迁移方案；5. 测试数据和验证 SQL；6. 回滚或前滚修复方案。等我确认后，再生成最小代码变更。
这段提示词的重点不是“让 AI 写得更多”，而是让 AI 先停在方案层。数据库迁移越复杂，越要把 AI 从“代码生成器”拉回“方案审查员”。
老达点评
AI 编程工具确实能大幅提高数据库迁移效率，尤其适合梳理影响范围、补测试和生成检查清单。但数据库里的历史数据不会因为 AI 写得快就变安全。我的建议是：让 AI 多做读取、比对、解释和生成草案，少让它直接碰生产执行。你真正要建立的不是一次迁移技巧，而是一套每次改表都能复用的安全流程。
