让 Claude Code 做依赖升级

Claude Code 依赖升级教程：教你如何让 CC 先评估风险、确认版本跨度、制定回滚方案，再小步升级 npm、pnpm、后端包或框架依赖。

依赖升级不是把版本号改掉就结束。

真正危险的地方在于：升级后项目还能不能启动、构建、测试、部署，旧功能有没有被破坏，团队有没有回滚方案。

所以让 Claude Code 做依赖升级时，第一句话不要说“帮我把依赖都升级到最新”，而要让它先评估。

适合让 CC 做什么

依赖升级可以让 CC 辅助这些工作：

识别当前依赖管理器，比如 npm、pnpm、yarn、pip、maven、go mod。
分析哪些依赖是运行时依赖，哪些是开发依赖。
判断版本跨度和潜在破坏性变化。
生成小步升级计划。
升级后跑构建、测试和最小功能检查。
整理升级说明和回滚方案。

不建议让 CC 一次性升级所有依赖。尤其是框架、构建工具、UI 组件库、数据库驱动、认证库，这些都可能带来连锁变化。

第一步：只读分析依赖现状

先这样问：

请先只读分析当前项目的依赖情况，不要修改文件。

请说明：
1. 当前使用什么包管理器。
2. 主要框架和关键依赖有哪些。
3. 哪些依赖属于运行时依赖，哪些属于开发依赖。
4. 哪些依赖升级风险较高。
5. 建议优先升级哪一类，暂时不要升级哪一类。

要求：
- 不要直接改 package.json 或锁文件。
- 不要建议一次性升级全部依赖。
- 输出风险分级和推荐顺序。

这一步的目标是让 CC 先建立依赖地图。

第二步：确定升级范围

依赖升级要先选范围。

常见范围有三种：

范围	适合场景	风险
补丁版本	修复小 Bug、安全补丁	较低
小版本	获取新能力、兼容改进	中等
大版本	框架或工具链升级	较高

可以这样让 CC 收窄：

这次只做低风险依赖升级。

范围：
1. 只升级 patch 或 minor 版本。
2. 暂时不升级主框架大版本。
3. 暂时不升级构建工具大版本。
4. 每次升级后都要说明影响和验证方式。

请给出一个分批升级计划。

如果是安全漏洞修复，可以这样说：

这次目标是修复依赖安全风险。

请先分析：
1. 漏洞来自哪个直接依赖或间接依赖。
2. 是否有官方修复版本。
3. 是否必须升级大版本。
4. 升级后最需要验证哪些功能。
5. 如果无法安全升级，是否有临时规避方案。

第三步：让 CC 做升级计划

计划应该包含：

要升级的依赖。
当前版本和目标版本。
为什么升级。
可能影响哪些功能。
需要执行哪些检查。
如何回滚。

提示词：

请根据刚才的分析，生成依赖升级计划。

计划格式：
1. 升级批次。
2. 每批包含哪些依赖。
3. 预计影响范围。
4. 升级后检查命令或检查路径。
5. 失败时如何回滚。

要求：
- 优先小步升级。
- 高风险依赖单独一批。
- 不要直接修改文件，先等我确认计划。

只有计划清楚，才进入修改。

第四步：执行时控制权限

如果项目是多人协作或真实业务项目，建议保持逐步审批，不要直接开高权限自动跑。

可以这样说：

按第一批计划执行依赖升级。

要求：
1. 只修改与本批依赖升级相关的文件。
2. 不要顺手格式化无关文件。
3. 修改后说明 package 文件和锁文件变化。
4. 执行必要检查，并解释结果。
5. 如果检查失败，先停下来分析，不要继续升级下一批。

依赖升级最怕“失败后继续叠加修改”。一旦失败，先停。

第五步：看懂升级后的 diff

依赖升级后，至少检查：

package.json 是否只改了预期依赖。
锁文件变化是否合理。
有没有无关源码文件被顺手改掉。
有没有新增未知依赖。
有没有删除必要配置。
构建脚本、测试脚本是否仍然存在。

可以让 CC 审查：

请审查这次依赖升级 diff。

重点检查：
1. package.json 是否只升级了计划内依赖。
2. 锁文件变化是否符合预期。
3. 是否出现无关源码改动。
4. 是否新增可疑依赖。
5. 是否有需要人工确认的破坏性变化。

第六步：验收依赖升级

不同项目的验收方式不同，但至少要覆盖：

安装依赖是否成功。
项目是否能启动。
构建是否成功。
测试是否通过。
关键页面或接口是否正常。
部署产物是否生成。

可以这样要求：

请为这次依赖升级做验收。

要求：
1. 先说明当前项目可用的检查方式。
2. 按从低成本到高成本的顺序执行检查。
3. 每个检查说明结果。
4. 如果有失败，先定位失败是否由依赖升级导致。
5. 最后给出是否可以进入下一批升级的判断。

失败时怎么处理

如果升级失败，不要继续升级下一批。

先让 CC 分类：

依赖升级后检查失败，请先分类，不要继续修改。

请判断：
1. 是安装失败、构建失败、测试失败还是运行失败。
2. 最可能由哪个依赖升级引起。
3. 是否可以通过小修兼容。
4. 是否应该回滚本批升级。
5. 推荐下一步操作。

如果定位不清，优先回滚本批升级，而不是继续堆改动。

可直接使用的完整提示词

/plan

请帮我做一次依赖升级，但先不要修改文件。

目标：
【例如：修复安全漏洞 / 升级低风险依赖 / 升级某个框架小版本】

要求：
1. 先只读分析依赖管理器、关键依赖和版本风险。
2. 按低风险到高风险分批制定升级计划。
3. 每批说明影响范围、检查方式和回滚方案。
4. 不要一次性升级全部依赖。
5. 计划确认后，只执行第一批。
6. 每批升级后必须审查 diff 并运行必要检查。

验收结果

学完后，应该能做到：

不再让 CC 一次性升级所有依赖。
能要求 CC 先分析依赖风险。
能把升级拆成可回滚的小批次。
能审查 package 文件和锁文件变化。
能通过构建、测试和关键路径验证升级结果。