Appearance
Deprecation and Migration 解决的是替换旧系统时只加新代码、不清旧代码的问题。迁移要先有替代方案，再识别使用方，逐步迁移，确认零使用后再删除。
AI 做迁移怎么不把旧代码拖死：Deprecation and Migration 怎么用
下载 deprecation-and-migration 中文版 Skill ZIP
旧接口还在跑，新接口也已经上线。
如果没有迁移计划，两边都会变成长期维护负担。
deprecation-and-migration 这个技能处理的就是这类问题：什么时候该废弃，怎么迁移，什么时候能删。
先确认旧代码还值不值得留
代码不是资产，代码是负担。
它需要维护、测试、升级依赖、修安全问题，还会占用后来者的理解成本。
但也不能因为看着旧就删。
废弃前要问：
- 它还提供独特价值吗？
- 有多少使用方依赖它？
- 替代方案是否已经可用？
- 迁移成本是多少？
- 继续维护的成本是多少？
没有替代方案就宣布废弃，用户只会被卡住。
迁移不是发一条通知
很多迁移失败，是因为只写了“旧接口已废弃，请使用新接口”。
这不够。
你要提供：
- 新旧接口对照。
- 迁移步骤。
- 示例代码。
- 验证方法。
- 截止时间或兼容窗口。
- 出问题时找谁。
如果使用方很多，最好提供脚本、codemod 或适配层，而不是让每个人手改。
逐步迁移比一次切换安全
大迁移不要一刀切。
常见方式有：
- 适配层：旧接口继续存在，内部调用新实现。
- 双跑：新旧系统并行一段时间，对比结果。
- 灰度切流：一部分用户走新系统，观察后再扩大。
- 分消费者迁移：一个模块一个模块切。
每一步都要能验证和回退。
删除旧代码要有证据
“应该没人用了”不够。
删除前要查：
- 代码搜索里是否还有引用。
- 日志或指标里是否还有调用。
- 文档和配置里是否还提到旧系统。
- 测试是否还覆盖旧路径。
- 外部消费者是否完成迁移。
确认零使用后，再删代码、删测试、删文档、删配置。
删得干净，迁移才算结束。
给 AI 的迁移 Prompt
md
请为这次迁移制定方案，不要直接删除旧代码。
需要包含：
1. 旧系统当前使用方。
2. 新系统是否覆盖旧系统关键场景。
3. 迁移步骤和验证方式。
4. 是否需要适配层或兼容窗口。
5. 旧代码最终删除条件。你可能还需要
同类技能：
迁移不是把新代码加上去就结束。旧代码什么时候下线，也要设计。