第一圈：把迁移任务缩成一个小改动
数据库迁移，就是用可追踪的脚本修改数据库结构或已有数据。例如，给订单增加一个备注字段，或者把旧的状态值转换成新格式。编程智能体可以帮助起草脚本，但它不知道你没有说出的业务规则，也不能替你承担执行后果。
第一次练习，建议只做“新增一个允许为空的字段”。先别让智能体同时改字段名称、清洗历史数据、删除旧字段。任务越小，你越容易看懂脚本，也越容易发现它做了不该做的事。
发车前：交代数据库版本和业务约束
只说“帮我写个迁移”远远不够。不同数据库及其版本，对修改表结构、事务和锁的处理并不相同。缺少上下文时，智能体可能生成语法正确、实际执行却有风险的脚本。
- 说明数据库类型、准确版本，以及项目正在使用的迁移工具。
- 提供相关表结构、索引、约束和经过脱敏的示例数据，不要上传生产密码或真实客户资料。
- 说明表的大致规模、是否持续有写入，以及应用发布时新旧版本是否会同时运行。
- 明确数据含义，例如空值代表“尚未填写”，不能擅自替换成“没有备注”。
可以这样下达任务：“只生成迁移草案，不连接数据库，不执行命令。先列出假设、待确认问题和可能的锁表风险。缺少信息时先问我，不要猜测。”
权限围栏：能写文件，不等于能改生产库
最重要的保护措施，是不给智能体生产数据库的写入凭据。让它在隔离环境中读取必要的结构信息、编辑迁移文件，并通过变更审查提交草案。执行迁移应由另一个受控流程完成，而不是让智能体自行决定。
如果需要查询结构，优先提供导出的结构文件。确实需要连接数据库时，也应使用权限受限的账号，并限制可访问的环境。不要把“执行前询问一次”当作唯一防线，权限本身就应该阻止越界操作。
脚本审查：逐项找出不可逆动作
拿到草案后，先请智能体用普通话解释：修改哪些对象、触及哪些数据、失败后会留下什么状态。再由熟悉项目的人检查脚本，不要只看它附带的“安全”评价。
- 是否出现未要求的删除、清空、字段类型缩窄或批量覆盖？
- 新增非空约束、默认值或索引时，是否可能扫描大表、重写数据或长时间持锁？
- 脚本中断后，迁移工具会怎样记录状态？再次执行会不会重复写入或造成冲突？
- 失败时能否通过事务撤销？当前数据库是否支持相关结构变更参与事务？
回退脚本也需要审查。删掉新字段虽然可能恢复旧结构，却会丢掉期间写入的新数据；“有回退文件”不代表“能够无损恢复”。
演练一圈：用接近真实的数据验证
先在临时数据库验证基本语法，再到使用脱敏数据的预发布环境演练。测试数据应包含空值、重复值、历史异常值，以及接近真实规模的数据分布，不能只放几条整齐的样例。
执行前后核对记录数量、关键字段和约束，并运行相关业务测试。还要观察锁等待、资源占用和应用报错，演练中断后的处理步骤。小数据集执行成功，只能说明这一组样例通过，不能证明生产环境没有风险。
分段放行：先兼容，再搬数据，最后清理
需要替换旧字段时，可以采用分阶段方案：先增加新字段，让应用兼容新旧结构；再按稳定顺序分批补齐历史数据，记录进度并允许暂停；核对一致性后切换读取；最后另开一次迁移清理旧字段。
这一过程必须处理新增写入。补数据期间，应用可能还在修改旧字段，需要明确双写或其他同步办法，并验证两边是否一致。不要让智能体把这些步骤压成一个“大脚本”，也不要在所有应用实例完成切换前删除旧结构。
最后检查点：备份可恢复，异常可叫停
正式执行前，确认备份覆盖范围、恢复方法和负责人，并在隔离环境验证恢复流程。约定停止条件，例如出现持续锁等待、业务错误或数据核对异常时立即暂停；恢复备份也可能影响备份之后的新写入，需要提前安排。
需要为编程智能体接入模型时，可以使用 SwiftRelay 模型中转服务，按实际使用的词元量付费；欢迎注册，在隔离项目中先练习一份迁移草案。模型接入解决的是调用问题，不替代数据库权限隔离、人工审查和恢复演练。
第一圈的合格标准，不是智能体独立完成上线，而是你能解释每一步改动，并知道出错时由谁、用什么办法处理。