让 CC 升级依赖前做风险评估

进阶实战教程：在真正升级依赖前，让 Claude Code 评估版本跨度、破坏性变更、锁文件影响、回滚方案和分批策略。

这里不教 CC 执行依赖升级。

重点只放在升级前风险评估。企业项目里，很多依赖升级真正危险的不是命令，而是版本跨度、破坏性变更和回滚不可控。

风险评估要回答什么

为什么要升级。
升级哪些依赖。
当前版本和目标版本跨度多大。
是否跨大版本。
是否影响构建、运行、测试、部署。
锁文件变化会不会很大。
有没有回滚方案。
能不能分批升级。

先判断升级动机

依赖升级不是越新越好。先把动机分清：

动机	是否紧急	处理建议
安全漏洞	可能紧急	先确认影响范围和修复版本
框架生命周期结束	中高	制定专项升级计划
新功能需要	中	评估是否有替代方案
构建报错	中高	先定位是否真由依赖导致
例行更新	低	分批升级，避免集中爆炸

可以让 CC 先问清楚：

请先判断这次依赖升级的动机和紧急程度。

要求：
1. 区分安全、兼容、功能、维护四类原因。
2. 不要默认所有依赖都应该升级。
3. 如果只是例行更新，请建议低风险批次。
4. 如果是安全漏洞，请说明需要确认哪些信息。

动机不清，升级范围就很容易失控。

风险评估提示词

请做依赖升级前风险评估，不要修改文件。

目标：
【安全漏洞 / 功能需要 / 版本过旧 / 兼容问题】

请分析：
1. 当前包管理器和关键依赖。
2. 计划升级的依赖及其当前版本。
3. 是否跨 major 版本。
4. 可能的破坏性变更。
5. 受影响的代码区域。
6. 锁文件和安装风险。
7. 分批升级建议。
8. 回滚方案。
9. 是否建议现在升级。

分批策略

让 CC 输出：

请把依赖升级拆成批次。

要求：
1. 低风险 patch/minor 一批。
2. 构建工具单独一批。
3. 主框架大版本单独评审。
4. 类型、lint、测试工具单独验证。
5. 每批都有检查方式和回滚方式。

不要把所有依赖一次性升级。

破坏性变更检查

请列出这些依赖升级可能带来的破坏性变更。

重点：
1. API 是否变化。
2. 配置格式是否变化。
3. 默认行为是否变化。
4. Node 或运行环境要求是否变化。
5. 插件生态是否兼容。
6. 需要修改哪些代码。

如果 CC 无法确认，就标注待人工查官方文档。

锁文件怎么看

很多依赖升级的风险藏在锁文件里。不要只看 package.json。

让 CC 检查：

是否出现大量间接依赖变化。
是否有多个包管理器锁文件混用。
是否把不相关依赖一起更新了。
是否改变 Node 版本要求。
是否出现平台相关包变化。
是否有新增 install script。

提示词：

请只读分析本次依赖变更中的锁文件影响。

重点看：
1. 是否有不相关依赖被一起升级。
2. 是否有新增安装脚本或二进制包。
3. 是否改变运行环境要求。
4. 是否存在包管理器混用迹象。
5. 哪些变化需要人工确认。

锁文件变化很大时，宁可拆小批次，也不要硬合。

回滚方案

依赖升级前必须有回滚。

请为这次依赖升级设计回滚方案。

要求：
1. 如何还原 package 文件。
2. 如何还原锁文件。
3. 如何确认回滚后能安装和运行。
4. 如果升级过程中改了源码，如何区分源码改动和依赖改动。
5. 是否建议单独分支。

什么时候不建议升级

如果出现这些情况，先不要升级：

没有明确升级目标。
跨多个 major 版本。
测试和构建都不稳定。
锁文件历史混乱。
没人能验证核心业务。
涉及生产关键链路但没有回滚窗口。

升级后的验收不要只跑一次

依赖升级的验收至少分三层：

层级	要确认什么
安装层	能干净安装，没有锁文件冲突
构建层	lint、类型检查、测试、build 能通过
业务层	核心页面、接口、登录、提交、部署路径可用

让 CC 在执行前就写验收清单：

请为这次依赖升级设计验收清单。

要求：
1. 分安装、构建、业务三层。
2. 每层给出具体检查动作。
3. 标出必须人工确认的业务路径。
4. 不要把“安装成功”当成升级成功。

进入执行阶段的标准

只有满足：

升级目标明确。
风险批次清楚。
检查方式明确。
回滚方案明确。
高风险依赖有人确认。

才进入执行。

基础篇：依赖升级返回：实战案例