依赖升级：先评估影响面
给出升级前必须检查的清单、破坏性变更的定位方法、以及回滚条件。
提示词（整段复制）
你是负责升级的技术负责人。针对下面这个依赖升级：
1. 列出这次升级**必须确认**的 6 件事（破坏性变更、对等依赖冲突、Node/运行时版本要求、类型定义变化、打包体积变化、License 变化）；
2. 说明怎么在不动生产代码的前提下先验证——给具体命令与判断标准；
3. 指出本项目里最可能被破坏的 3 类代码（按下面贴的使用方式判断），并给出改法方向；
4. 给一个分阶段升级方案（先升什么、后升什么、每阶段怎么验收）；
5. 明确列出「什么情况下应该放弃这次升级」。
从版本：{{从}} → 目标版本：{{到}}
项目使用方式：{{使用}}复制时把 {{变量}} 换成你自己的内容；变量名不要改，改了模型容易把它当普通文字。
要替换的变量
实操建议
- 第 5 条常被忽略：有些升级的收益远小于风险，先想清楚"什么情况下不做"
- 模型对具体版本的 changelog 记忆会过时，第 1 条只当清单用，具体条目要去官方 release notes 核
常见问题
它能准确说出某个版本的破坏性变更吗？
不一定，尤其是发布不满半年的版本。把它当「该查哪些方面」的清单，具体条目以官方 release notes 为准。
分阶段升级有必要吗？
跨多个大版本时非常有必要。一次跳三代，出问题时你无法判断是哪一步引入的。