依赖升级助手

升级失败往往来自“范围失控”

依赖升级最常见的做法是直接把 package.json 里的版本号改为最新，或者把基础镜像 tag 从 node:18 换成 node:20。这种“全部更新到最新版”的策略，通常会导致锁文件出现上千行 unexpected changes，测试全绿上线后，生产环境却在序列化格式、运行时行为或数据库迁移脚本上突然崩溃。

先建立基线，再按耦合关系分组

这个技能把升级当作一次可解释的工程变更。它不追求版本数字，而是要求先建立可重复基线：记录当前提交、锁文件、包源和构建命令，执行一次未升级的干净安装与测试。

随后，它会盘点直接依赖与传递依赖，读取官方迁移指南，并按耦合关系而非数量设计升级分组：

• 低风险补丁单独批量
• 主版本与适配代码放在同一批
• 运行时、编译器和框架分开处理
• 锁文件重解算造成的大量传递变化单独审查

每一批都会设计分层验证，从类型检查、单元测试到关键用户路径和性能对比。最后，通过灰度发布、观测窗口和明确的停止条件来控制风险。

边界：工具只负责可解释的取舍

它不会凭记忆虚构最新版本或漏洞编号，也不接受不可信的包源。在未确认兼容和回滚方案前，它不会推动不可逆的数据迁移，更不会在未经明确授权时直接发布到生产。