编程开发 编辑复核
依赖升级风险评审
从版本变更、破坏性 API、运行时、许可证和构建差异判断升级范围与验证矩阵。
PROMPT WORKBENCH
复制后替换变量
保留结构，先填真实信息，再把结果交给模型运行。
你是一名依赖治理工程师。请基于官方变更日志和仓库实际用法评估升级风险，不要只看语义版本号判断安全。
先区分已知事实、合理假设和待核验信息；没有依据的内容写“待验证”，不要为了完整而猜测。
请按以下结构输出：
1. 升级目标、当前版本和直接/间接依赖
2. 官方 breaking changes、弃用和运行时要求
3. 仓库中受影响的调用点和配置
4. 构建、测试、性能和生产验证矩阵
5. 分阶段升级、观察和回滚方案
输入变量：
- 依赖包（{{package}}）：提供包名、当前版本、目标版本和来源。
- 仓库用法（{{usage}}）：列出关键 API、配置和插件。
- 运行环境（{{runtime}}）：提供 Node、操作系统、构建和生产环境。
- 验证能力（{{checks}}）：说明已有测试、构建和灰度方式。
约束：保留用户的真实语气和业务边界；把事实、推断与建议分开；涉及日期、价格、版本、法规或安全的内容写明来源和采集时间。HOW TO USE
使用说明
- 先阅读官方 changelog 和本仓库锁文件，再决定升级范围。
- 升级提交应保持可独立回滚，不与无关功能混合。
WHEN IT FITS
适用判断
适合这些情况
- 要决定这次升不升级，需要先看清风险和收益。
- 有多个依赖待升级，需要排出先后。
- 升级不是强制的，可以选择推迟。
换个做法更好
- 已经决定升级，需要的是执行步骤：用《依赖升级影响与回滚计划》。
- 这是修复严重漏洞的补丁：不需要评审风险收益，直接升。
- 依赖没有实际使用：先确认能不能直接删掉。
FAILURE MODES
常见翻车与修正
- 评审只讲收益，没算迁移成本。
要求估算改动涉及的文件数、需要重写的测试和验证工作量，并和收益放在一起比较。
- 模型断言某版本有安全问题，但没有具体的 CVE 编号。
要求所有安全声明附 CVE 编号或官方公告链接，说不出出处的标为「需核实」。
- 没考虑不升级的风险，比如版本落后太多导致以后升不动。
补充要求：分别说明立即升级、推迟一个季度、长期不升三种选择的后果。
ACCEPTANCE
怎么判断输出合格
- 收益和迁移成本都有估算，可以直接比较。
- 安全声明都有 CVE 或官方出处。
- 分析了推迟和不升级的后果，不只看升级本身。
- 给出了明确的建议和判断依据，不是列完选项让你自己选。
SAFETY BOUNDARY
使用边界
- 模型对具体版本的安全公告和破坏性变更记忆不可靠，风险判断要以官方公告和 advisory 为准。
- 带安全修复的升级不要因为「风险高」而无限期推迟，未修复的漏洞风险通常更大。