在生产环境附近用 AI 改数据库，是我现在最谨慎的一类操作。代码改错了可以回滚重发，数据改错了，很多时候没有后悔药。这半年我用 Codex 处理过几次表结构调整和数据修复，固定下来一条规矩： 它只负责生成脚本和校验清单，执行永远是人来按。

具体拆成四步。

第一步：让它先出「影响面报告」，不许直接写 SQL

我先让它读相关的表结构、实体类和调用方代码，输出一份报告：这张表被哪些服务读写、有没有外键和触发器、数据量大概什么级别、改动的窗口期建议。报告对不上我对系统的了解，就先纠正，不进入下一步。

这一步最值钱的是它经常能翻出我都忘了的调用方——某个跑了很久的定时任务、某个几乎没人动的报表接口。

第二步：脚本分三件套：变更、校验、回滚

要求它一次交齐三份脚本：

1. 变更脚本：DDL 或修复 DML，带明确的 WHERE 条件和预估影响行数
2. 校验脚本：变更后跑的核对查询——行数对账、关键字段抽样、业务不变量检查
3. 回滚脚本：变更的逆操作，写不出回滚方案的改动，原则上不做

三件套缺一不收。尤其是回滚脚本，写的过程本身就是一次风险审查：它要是写不出干净的回滚，说明这个改动的设计就有问题。

第三步：先在影子库/备份副本上彩排

脚本先拿到从备份恢复的副本上跑一遍：执行时间多长、锁表情况如何、校验脚本结果对不对，全部记录下来。生产执行的顺序、停机窗口、通知谁，都按彩排结果定，不拍脑袋。

彩排这一步淘汰掉的问题，比我预想的多：有一次字符集不一致导致校验全红，要是在生产上直接跑，就是半夜起来收拾残局。

第四步：执行时人盯着，执行后立刻跑校验

正式执行由人操作，它在旁边（对话里）待命：校验结果逐项比对彩排时的预期值，对不上立刻停，先分析再决定回滚还是继续。执行完把这次的报告、脚本版本、校验结果一并归档到变更记录里。

一条边界

有人问：那让它直接连库执行、我看着不行吗？我的答案是不行。不是不相信它的 SQL 水平，而是「生成」和「执行」之间必须隔一道人手——这道间隔就是事故和虚惊的区别。工具越强，这道规矩越要守住。

（作者：云思思，日常分享 ChatGPT / Codex 的实战用法，这篇是数据库变更流程的一点个人经验。）