实践指南
数据库迁移交给 AI 时的风险控制
说明让 AI 编写 migration 时如何限制范围、强制评审与回滚预案，避免不可逆的线上事故。
RuleHub 编辑组约 2 分钟阅读
数据库migration安全AI 编程
迁移是高杠杆也是高风险
Schema 变更难回滚、影响全站。AI 能快速生成 migration 文件，也可能：删列不备份、锁表过久、在生产写法里夹带数据回填。必须把流程写死。
允许 AI 做的
- 根据已确认的设计稿生成迁移草稿
- 补充索引命名与常见约束语法
- 生成「如何在本地应用」的步骤说明
禁止 AI 独自做的
- 在生产库执行任何破坏性操作
- 无备份的 drop column / truncate
- 静默修改历史已合并的旧 migration 文件
这些应写入 Skill 反模式与团队 Rules。
推荐流程
1. 人先写清变更意图与兼容策略（双写、先加后删等）
2. AI 生成草稿
3. 人审查 SQL/DSL，关注锁与数据保留
4. 在 staging 应用并验证应用代码兼容
5. 生产按变更窗口执行，准备回滚脚本
审查关注点
- 是否可在线变更，估算表大小
- 默认值与空值是否导致应用崩溃
- 是否需要同时改 API 与缓存
- 回滚路径是还原 migration 还是正向补偿
与 API 安全的关联
迁移常伴随接口字段变更。权限与校验要同步，避免旧客户端写入新约束外数据。参见 API 安全清单。
小结
AI 是迁移草稿机，不是生产执行者。意图人工定、草稿 AI 写、评审人盯、环境分级执行——这条链不断，才能用上速度红利。
下一步：若仓库还没有 migrations Skill，用本文「禁止」列表先写反模式段。