编程开发 编辑复核
依赖升级影响与回滚计划
把依赖升级拆成兼容性、漏洞、构建、运行时和发布验证，避免只改版本号就认为升级完成。
PROMPT WORKBENCH
复制后替换变量
保留结构，先填真实信息，再把结果交给模型运行。
你是一名依赖维护工程师。请基于锁文件、变更日志和真实使用路径规划升级，不把依赖作者的宣传能力当作本项目已验证行为。
先区分已知事实、合理假设和待核验信息；没有依据的内容写“待验证”，不要为了完整而猜测。
请按以下结构输出：
1. 记录当前版本、直接和间接依赖以及升级动机
2. 分析 API、类型、构建、运行时、许可证和漏洞影响
3. 安排单元、集成、浏览器、构建和生产健康检查
4. 给出分批发布、监控指标和可执行回滚动作
输入变量：
- 依赖包（{{package}}）：提供包名、当前版本和目标版本。
- 使用路径（{{usage_paths}}）：列出项目实际调用和关键页面。
- 发布环境（{{release_context}}）：说明 Node、构建、容器和部署方式。
- 风险容忍度（{{risk_tolerance}}）：说明是否允许停机、灰度和回滚时间。
约束：保留用户的真实语气和业务边界；把事实、推断与建议分开；涉及日期、价格、版本、法规或安全的内容写明来源和采集时间。HOW TO USE
使用说明
- 先读官方变更日志和项目锁文件，再运行最小验证集。
- 升级提交保留旧锁文件和镜像标签，验证失败就回到上一版本。
WHEN IT FITS
适用判断
适合这些情况
- 要升级的依赖被多处引用，需要评估波及范围。
- 你能提供当前版本、目标版本和实际的引用位置。
- 需要把升级拆成可以分批验证的步骤。
换个做法更好
- 你要评估的是升不升级这个决策本身：用《依赖升级风险评审》。
- 依赖只在一处用到且有测试覆盖：直接升，跑测试即可。
- 升级是安全补丁且不可延后：先升再说，计划是给可选升级用的。
FAILURE MODES
常见翻车与修正
- 模型列出的 breaking change 来自它的记忆，和实际 changelog 对不上。
版本细节容易记错。要求只使用你粘贴的 changelog 或迁移指南，记不清的标注「需查阅官方文档」。
- 只考虑了直接依赖，忽略了传递依赖的版本冲突。
把 lockfile 中相关部分粘进输入，要求检查是否有其他包锁定了旧版本。
- 没给回滚方案，升级后出问题只能硬扛。
补充要求：写明回滚步骤、需要一并回滚的代码改动，以及判断该回滚的信号。
ACCEPTANCE
怎么判断输出合格
- breaking change 都来自你提供的官方资料，没有凭记忆的断言。
- 检查了传递依赖的版本冲突。
- 升级拆成了可以分批验证的步骤。
- 有明确的回滚步骤和触发条件。
SAFETY BOUNDARY
使用边界
- 模型对具体版本的变更内容记忆不可靠，破坏性变更要以官方 changelog 为准。
- 升级前确认回滚方案可执行，锁文件和构建产物要能恢复到升级前的状态。