订单团队周五上线前：用 AI 陪练一次数据库字段变更

周五要上线的，不只是三个新字段

设想你在一个订单团队工作，周五要发布新的配送功能。订单表目前只有一个“收货地址”字段，现在需要拆成“省份”“城市”和“详细地址”。需求看起来只是改几列，实际却牵涉旧订单、结账页面、后台导出，以及尚未更新的服务。

数据库的结构，也叫模式，描述表里有哪些字段、字段接受什么类型的数据，以及哪些规则必须满足。增加字段、修改类型、建立索引，都属于结构变更。它与修改普通业务代码的区别在于：代码可以重新部署，已经写入的数据却不会自动恢复。

这里的 AI 陪练，不是让模型替你操作生产数据库，而是让它充当讨论伙伴：听你讲计划，追问遗漏，并模拟可能出错的情况。最终判断仍然需要数据库事实、测试结果和团队审核。

先把地址变更的背景交代完整

直接问“帮我写迁移脚本”，往往会得到一份看似合理、却不了解现场的答案。先交代数据库类型和版本、订单数量、发布方式，以及哪些程序还在使用旧字段。如果这些信息暂时不知道，就明确标记为待确认，不要让模型猜。

可以这样开始对话：“我们计划把订单的收货地址拆成三个字段。新旧服务会同时运行一段时间，旧订单不能丢失，结账流程不能中断。请先列出你必须确认的问题，再讨论迁移步骤，不要生成执行命令。”

• 提供经过脱敏的表结构、相关查询和字段含义，不上传真实姓名、地址、密钥或连接凭据。
• 列出所有读写方，包括接口、定时任务、报表和客服工具。
• 说明可接受的停机时间、延迟变化，以及谁负责批准发布。

让 AI 推演新旧版本同时运行的时刻

这次变更最危险的地方，未必是增加字段，而是新旧程序交接的过程。让 AI 分别检查：旧程序遇到新结构会怎样，新程序遇到尚未补齐的旧数据又会怎样。

一个常见思路是先扩展，再迁移，最后收缩。先增加允许为空的新字段，保留旧字段；随后部署兼容两种结构的代码；历史数据处理完成并验证后，再考虑移除旧结构。不要把这些动作塞进一次不可拆分的发布。

如果过渡期间同时写入两套字段，还要明确哪一套是权威来源、一次写入部分失败怎么办，以及旧版本是否仍会只更新旧字段。请 AI 按时间顺序模拟一次下单、修改地址和服务回退，通常比让它泛泛列出“最佳实践”更有用。

旧地址回填需要规则，也需要例外

把历史数据补进新字段，叫作回填。但一整段地址未必能够可靠拆分：有些缺少省份，有些使用旧地名，还有些只是配送备注。不要因为模型能生成解析方案，就认为每条地址都能准确转换。

先用脱敏样本验证规则，无法确定的记录进入待处理清单，不要猜测补齐。回填任务应当分批执行、记录进度，并能安全重试；还要避免覆盖用户刚刚修改的新地址。

请 AI 帮你检查回填计划是否包含批次大小、暂停条件和失败记录。具体参数则应通过接近生产规模的测试确定。新增字段或索引是否锁表，也取决于数据库版本和操作方式，必须查阅对应文档并实测。

把上线条件和回退边界写成清单

“出了问题就回滚”不是完整方案。旧代码能否读取上线后的数据？如果已经删除旧字段，恢复它需要多久？这些问题应在发布前回答。

• 上线前：在测试环境演练迁移与回填，确认备份可恢复，并验证新旧版本的读写行为。
• 上线中：观察结账错误率、数据库延迟、锁等待和新旧字段不一致数量，提前约定暂停阈值。
• 出现异常：停止回填，或通过功能开关切回旧读取路径；确认旧字段仍持续维护，才能依赖它回退。
• 稳定之后：覆盖约定的业务观察周期，确认所有使用方已经迁移，再单独安排删除旧字段。

最后让 AI 扮演发布审核人，要求它逐条指出计划中的假设、缺少的证据和无法回退的动作，而不是只问“这个方案有没有问题”。

用 RelayVano 组织这轮方案讨论

如果你希望在现有开发工具里完成这轮讨论，可以考虑按量付费的 RelayVano。它支持 Claude Code、Codex、Gemini CLI 和兼容 OpenAI 的开发工具包，接口基础地址为 https://api.relayvano.com，适合围绕脱敏结构、测试结果和发布清单反复推演。

你可以注册 RelayVano，从一次不连接生产数据库的方案审阅开始。让 AI 输出“已知事实、待确认项、分阶段步骤、停止条件”四部分，再由团队逐项验证。一次好的陪练，不是让你更快点击执行，而是让你知道什么时候还不能执行。