发布与验证
让 AI 把 Node 支持承诺写成 CI 矩阵
把支持承诺翻译成可维护的测试组合。
资料核验2026.11.12 · GitHub Actions · PR 与部署工作流
一个命令行工具声称支持 Node 22 和 24。只有一台装着 24 的电脑时，助手生成的代码很容易顺手用到当前运行时的能力。用 CI 矩阵把两份承诺都跑一遍，比口头说「应该兼容」更实在。
让助手从这一步开始
提供 package.json 的运行时要求和一个会触及文件路径的测试。让助手先列要支持的 Node 版本与操作系统组合，再给矩阵配置。不要靠本机当前版本推断兼容范围。
先选用户真的在用的组合
用版本轴覆盖最低支持版本和日常主版本。若产品依赖路径大小写、文件锁或原生模块，再给相应场景加系统维度。优先保留能捕捉真实差异的组合，避免所有轴一交叉就把检查时间翻倍。
矩阵任务默认可能在某一组合失败后取消其他组合。排查兼容性时，考虑关闭 fail-fast 一次，拿齐各环境结果再改。
把失败结果按组合呈现，读者应能看出到底是 Node 版本差异还是某个操作系统才触发。
把问题变成可重跑的样例
矩阵先设 Node 22 × Linux 和 Node 24 × Linux。若涉及跨平台文件名，再加一项确实受影响的系统。用一个主动失败的测试确认报告里能看出失败组合，别让结果都显示同一个任务名。
核对这几项输出
- 每个承诺版本都有独立的安装与测试结果。
- 最小版本失败时能看到是哪项 API 或语法触发。
- 调查期间需要时让矩阵收齐结果。
怎么判断改动能不能收
先覆盖会影响用户的轴，例如运行时与原生依赖的平台。只有确实有差异的项目才加更多组合。修好后用最低支持版本跑同一条失败用例，避免仅在新版本验收。
当最小版本失败时，让助手先打印实际执行的版本与安装方式，确认 CI 没有偷偷回到默认运行时。对原生依赖的失败另检查平台二进制。将修复限定到确实承诺支持的组合，比为了全绿无差别兼容每种配置更容易维护。
