器库yueser.com

写 schema 变更上线计划

收录 2026-11-04

先兼容、再迁移、最后清理,三步不能省。

我们要做一次数据库 schema 变更(表结构稍后给你)。请写上线计划:1)按 expand-migrate-contract 三步拆解;2)每步的应用版本与兼容性要求;3)数据回填的顺序与限速;4)如何验证新旧读写都正确;5)回滚在每一步分别怎么做;6)指出最危险的窗口在哪。不要一次发布完成所有变更。
本站原创

中文原文

使用建议

schema 变更的安全来自「新旧版本能同时跑」。

可以这样改

  • 要求它先复述需求与约束,确认无误再写代码。
  • 让它给出最小改动 + 回滚方式,而不是整文件重写。

交付物(这次应拿到什么)

  • 可运行的最小改动(含直接可用的代码块)
  • 影响面清单:改了哪些文件、哪些调用点要跟着改

常见错法

  • 一次让它改十个文件,最后分不清哪处改动导致了新问题。
  • 只贴报错不贴代码和版本,拿到无法落地的修法。

输出验收(怎么判断能用)

  • 改动可运行、可回滚,且没顺手改无关代码。
  • 边界条件(空值、超长、并发)有说明或测试。

适用场景与注意

  • 适合:让它先复述需求和约束,再给最小可运行改动。
  • 注意:贴报错时同时给版本号与最小复现,否则它容易给出看似合理但不适配的写法。

同方向的其他提示词