编程#代码#测试#调试
代码迁移 / 版本升级改造清单
梳理从旧版本到新版本的破坏性变更，产出分批改造与回滚方案。
适用工具ClaudeChatGPTCursorDeepSeek
提示词
你是负责技术升级的工程师。请为下面的迁移任务出一份可执行的改造清单。
一、变更盘点
先把这次升级会碰到的破坏性变更分类列出：
1. 语法 / API 层面（哪些函数被移除、签名变了）
2. 配置 / 构建层面（配置文件格式、构建命令、环境变量）
3. 依赖层面（必须同步升级的连带依赖）
4. 运行时行为变化（默认值改变、错误处理方式改变、异步语义改变）
每一条标注：影响范围（全项目 / 局部）、是否必须改、改起来大概多麻烦。
二、分批计划
把改造拆成 3-4 批，每批都能独立上线、独立回滚：
- 第 1 批：低风险、无行为变化（先做，建立信心）
- 第 2 批：机械替换类改动
- 第 3 批：需要改逻辑的改动
- 第 4 批：清理旧代码与兼容层
每批说明：改哪些文件、预期影响、验证方式。
三、逐项改造指令
对每一类变更，给出「改前 → 改后」的代码对照示例（用我项目里的真实写法，不要用教科书例子）。
四、风险与回滚
- 最可能出问题的 3 个地方，以及怎么提前发现
- 回滚需要准备什么（分支策略、灰度开关、数据兼容处理）
- 哪些改动一旦上线就不能简单回滚（例如数据结构变更），单独标红
五、验证清单
给出可勾选的检查项，覆盖：编译通过、单测通过、关键页面手测、性能无明显下降、日志无新增报错。
迁移信息：
当前版本 → 目标版本：【版本号】
项目规模：【文件数量 / 大致代码行数】
测试覆盖情况：【有单测 / 无测试 / 只有部分】
约束：【例如：不能停机 / 必须一周内完成】文中【】为可替换变量，使用前请替换成你的具体内容。
变量填充：填一填直接用
已识别 4 个【】占位变量，填写后一键生成成品提示词；留空的变量会保留占位符。
使用技巧
- 能分批就别一次性改完，一次性迁移出问题很难定位是哪一处引起的。
- 先升级依赖再改代码，很多时候依赖一升，一半的报错就自己消失了。
- 涉及数据结构的改动永远单独一批做，且提前想好回滚。